UNIVERSIDADE DO VALE DO ITAJAÍ SÉRGIO NICOLAU DA SILVA ESTUDO DA PLATAFORMA BREW COM ÊNFASE NO DESENVOLVIMENTO DE UM PROTÓTIPO PARA CELULAR

Transcrição

1 UNIVERSIDADE DO VALE DO ITAJAÍ SÉRGIO NICOLAU DA SILVA ESTUDO DA PLATAFORMA BREW COM ÊNFASE NO DESENVOLVIMENTO DE UM PROTÓTIPO PARA CELULAR São José 2005.

2 SÉRGIO NICOLAU DA SILVA ESTUDO DA PLATAFORMA BREW COM ÊNFASE NO DESENVOLVIMENTO DE UM PROTÓTIPO PARA CELULAR Trabalho de Conclusão de Curso apresentado à banca examinadora do Curso de Ciência da Computação na Universidade do Vale do Itajaí - UNIVALI, Centro de Educação São José, como requisito parcial para obtenção do título de Bacharel em Ciência da Computação. Orientador: Prof. Dr. Alexandre Moraes Ramos. São José SÉRGIO NICOLAU DA SILVA

3 SÉRGIO NICOLAU DA SILVA ESTUDO DA PLATAFORMA BREW COM ÊNFASE NO DESENVOLVIMENTO DE UM PROTÓTIPO PARA CELULAR Este Trabalho de Conclusão de Curso foi julgado adequado como requisito parcial para a obtenção do título de Bacharel em Ciência da Computação, tendo sido aprovado pelo Curso de Ciência da Computação, Centro de Educação São José da Universidade do Vale do Itajaí (SC). São José, 14 de dezembro de Prof. Esp. Alecir Pedro da Cunha Responsável pela Coord. do TCC Prof. M. Eng. Fernanda dos Santos Cunha Coordenadora do Curso Apresentada à Banca Examinadora formada pelos professores: Orientador: Prof. Dr. Alexandre Moraes Ramos Prof. Dr. Paulo Roberto O. Valim, membro da banca examinadora Prof. Dr. Paulo Roberto Riccioni, membro da banca examinadora

4 DEDICATÓRIA Dedico este trabalho de conclusão de curso aos meus Pais, Juracy da Silva e Nicolau Adolfo da Silva, pelo apoio, por me ensinar a ser a pessoa que sou hoje e por sonhar junto comigo o que se torna agora uma realidade. À Luciana da Rosa Ferreira e Silva que nestes cinco anos foi minha namorada, noiva e é minha amável esposa, companheira, paciente e compreensiva.

5 AGRADECIMENTOS Agradeço a Deus por ter me dado forças para superar mais esta fase de minha vida. Aos meus familiares pela paciência e apoio prestado ao longo desta caminhada. Aos amigos que compartilharam comigo os sofrimentos e alegrias nestes cinco anos de estudos. A coordenação do curso de Ciência da Computação pelo belo trabalho que realiza. A todos os professores do curso de Ciência da Computação pela dedicação e apoio.

6 O conformismo é o carcereiro da liberdade e o inimigo do crescimento. (Jonh Kennedy)

7 RESUMO Este trabalho apresenta um estudo sobre a plataforma BREW para desenvolvimento de aplicativos para celulares, disponibilizando as informações necessárias para os interessados em desenvolver trabalhos na área por meio do desenvolvimento de um protótipo. Será apresentada inicialmente uma revisão sobre tecnologias celulares identificando as partes que a compõe e as diversas tecnologias disponíveis no mercado brasileiro tanto para serviços de voz quanto para serviços de dados, além de algumas tendências do mercado mundial. Em nível de desenvolvimento de software são apresentadas algumas das tecnologias de desenvolvimento de soluções para celulares que estão disponíveis no mercado. Na segunda parte é realizado o detalhamento da plataforma BREW, apresentando as partes que a compõe, focando principalmente na preparação do ambiente de desenvolvimento Visual Studio.NET integrando-o ao BREW SDK (BREW Software Development Kit). Em seguida é apresentada a utilização prática dos componentes do SDK e, por meio de um código fonte comentado, a forma de implementação de aplicações na plataforma BREW. Visando avaliar melhor a plataforma será desenvolvido um protótipo que é um controle remoto total para residências onde permitirá ao usuário acionar ou desligar qualquer ponto elétrico na residência como ligar u desligar um ar-condicionado, alarme residencial, luz externa etc. Neste protótipo serão utilizados os recursos de acesso a arquivos, conexão socket, tratamento de eventos e utilização dos recursos de tela. Ao final serão apresentadas as considerações finais sobre a plataforma, dificuldades encontradas e conclusão sobre os estudos realizados.

8 ABSTRACT This work presents a study on platform BREW for development of applicatory for cellular, provide the necessary information for the interested in developing works in the area by means of the development of an archetype. A revision on cellular technologies will be presented initially identifying the parts that in such a way compose it and the diverse available technologies in the Brazilian market for services of voice how much for services of data, beyond some trends of the world-wide market. In level of software development some of the technologies of development of solutions for cellular are presented that they are available in the market. In the second part detailing of platform BREW is carried through, presenting parts that compose it, mainly focused in the preparation of the environment of Visual development Studio NET integrating it it BREW SDK (BREW Software Development Kit). After that it is presented the practical use the components of the SDK and, by means of a commented code source, the form of implementation of applications in platform BREW. Aiming at to evaluate the platform better it will be developed an archetype that are a total remote control for residences where it will allow the user to set in on or off any electric point in the residence as to on or off a air conditioning, residential alarm, external light etc. In this archetype the archives will be used the file resources, connection socket, treatment of events and use of the screen resources. To the end the final consideration on the platform will be presented, joined difficulties and conclusion on the carried through studies.

9 SUMÁRIO 1 INTRODUÇÃO CONTEXTUALIZAÇÃO PROBLEMA OBJETIVOS Geral Específicos Escopo e Delimitação RESULTADOS ESPERADOS JUSTIFICATIVA ASPECTOS METODOLÓGICOS ORGANIZAÇÃO DO TRABALHO DESENVOLVIMENTO CONTEXTO REDE CELULAR Conceitos Básicos Primeira Geração (1G) Segunda Geração (2G) Segunda Geração e Meia (2,5G) Terceira Geração (3G) Quarta Geração (4G) TECNOLOGIAS PARA DESENVOLVIMENTO DE SOFTWARE Superwaba J2ME Visual Studio.NET BREW VISÃO GERAL BREW DISTIBUTION SYSTEM BREW SDK (SOFTWARE DEVELOPMENT KIT) Relação entre classes, módulos e aplicação MIF(Module Information File) e o BAR(BREW Applet Resourse) SDK disponíveis PREPARANDO O AMBIENTE PARA DESENVOLVIMENTO Requisitos mínimos Instalando o SDK Preparando o Visual Studio.NET CRIANDO UMA APLICAÇÃO BREW MIF Editor Configurando a aplicação...58

10 3.5.2 Univali.c comentado PROTÓTIPO: CONTROLE REMOTO PARA RESIDÊNCIA Modelagem do protótipo Diagrama de classes de domínio Diagramas de seqüência Implementando o protótipo Arquitetura do ambiente Interface IShell: Controlando a aplicação Interface IDisplay: Manipulado a tela do celular Interfaces INetMgr e ISocket: Criando uma conexão Socket Stream (TCP) Interfaces IFileMgr e IFile: Manipulando arquivos Recursos visuais criados por meio do BREW Resource Editor Criando e manipulando menus (IMenuCtl) Funcionamento do protótipo COMPARANDO FERRAMENTAS DE DESENVOLVIMENTO CONSIDERAÇÕES FINAIS CONCLUSÃO E TRABALHOS FUTUROS CONCLUSÃO TRABALHOS FUTUROS...97 ANEXO 1: UNIVALI.C...98 ANEXO 2: MODELAGEM DO SERVIDOR ANEXO 3: FONTE DO SERVIDOR (UNSERVIDOR.PAS) REFERÊNCIAS BIBLIOGRÁFICAS...133

11 LISTA DE FIGURAS Figura 1: Topologia básica da rede celular...20 Figura 2: Representação da célula em uma rede celular...22 Figura 3: Cluster de células Figura 4: Representação da divisão do espectro de freqüência em canais (FDMA) Figura 5: Estrutura dos timeslots TDMA...27 Figura 6: Espalhamento dos dados nas portadoras disponíveis...29 Figura 7: Estrutura de frames e timeslots da GSM Figura 8: Evolução para redes 3G...38 Figura 9: Modelo de negócio integrado do BDS Figura 10: Tela de configuração do sistema Figura 11: Tela de configuração de variáveis de ambiente...55 Figura 12 : Ambiente configurado e com o BREWAppWizard disponível...56 Figura 13: Recursos que a aplicação fará uso...57 Figura 14: Tela Options...58 Figura 15: BREW MIF Editor...59 Figura 16: Informando um Class ID local...60 Figura 17: MIF Editor - Configuração da aplicação...61 Figura 18: Configurando o modo Debug no Visual Studio...65 Figura 19: Configuração do simulador...66 Figura 20: Controle remoto via celular...67 Figura 21: Casos de uso...68 Figura 22: Diagrama de classes de domínio...73 Figura 23: Diagrama de seqüência: Configurar Sistema...74 Figura 24: Diagrama de seqüência: Conectar ao servidor...75 Figura 25: Diagrama de seqüência: Ligar / desligar ponto de controle...76 Figura 26: Arquitetura do ambiente de simulação...78 Figura 27: BREW Resource Editor...85

12 Figura 28: Criando um recurso...86 Figura 29: Tela principal...89 Figura 30: Tela de configuração...90 Figura 31: Controle dos pontos...91

13 LISTA DE TABELAS Tabela 1: Faixas de freqüência disponíveis no mundo para GSM Tabela 2 Capacidade de dados das classes de terminais GPRS...34 Tabela 3: Sistemas cdmaone disponíveis...35 Tabela 4: Comparação dos sistemas CDMA Tabela 5: Modulações e esquemas de codificação EDGE...41 Tabela 6: Caso de uso: Configurar sistema...69 Tabela 7: Caso de uso: Conectar no servidor...70 Tabela 8: Caso de uso: Verificar estados dos pontos de controle...71 Tabela 9: Caso de uso: Alterar estado de um ponto de controle...72

14 13 1 INTRODUÇÃO 1.1 CONTEXTUALIZAÇÃO A evolução tecnológica nos últimos anos possibilitou ao mercado prover novos produtos e serviços, atendendo as necessidades dos usuários. Uma das áreas cuja evolução tecnológica promove um grande avanço é a telefonia, que permitiu ao usuário ter o acesso a este serviço levando o terminal de acesso sempre com ele: o telefone celular. A telefonia celular, que inicialmente veio atender a necessidade do mercado e dar mobilidade ao serviço de voz, hoje é mais que isso: é acesso à Internet, contas de , conexão de dados sem fio a qualquer instante, multimídia, além do serviço se voz. Isto se deve ao avanço das redes, que têm capacidade para trafegar tais dados com a eficiência necessária, e a evolução dos equipamentos, principalmente dos aparelhos celulares e similares onde por meio destes os usuários usufruem dos serviços disponíveis. Segundo a Anatel 1 (2005b) em janeiro de 2005 eram 68,6 milhões de aparelhos celulares habilitados. Além deste crescimento, os fabricantes de aparelhos celulares e similares disponibilizam cada vez mais recursos tecnológicos nestes, tornando-os capazes de realizar tarefas complexas, antes somente vistas em computadores, além da comunicação de voz. A união do mercado em constante expansão com os aparelhos high tech nos dá a visão do tamanho do mercado disponível para os envolvidos e interessados em atuar na telefonia celular, principalmente no desenvolvimento de aplicativos que atendam as necessidades dos usuários. Nos dias de hoje, discute-se quais tecnologias dominarão o mercado, tanto em nível de acesso ao serviço quanto para desenvolvimento de aplicações que satisfaça as necessidades dos 1 Agência Nacional de Telecomunicações é o órgão do governo brasileiro responsável pela regulamentação das telecomunicações no Brasil.

15 14 usuários comuns e corporativos. O fato é que a concorrência é acirrada, empresas de tecnologia apostam em seus padrões. Na área de desenvolvimento de software, novas ferramentas e novos recursos são colocados no mercado a fim de conquistar a maior fatia possível deste. 1.2 PROBLEMA Uma das dificuldades das operadoras de telefonia celular era, inicialmente, identificar qual tecnologia mais apropriada para o mercado em termos de evolução. Principalmente na segunda geração (2G), muitas foram as tecnologias disponíveis e utilizadas pelas operadoras de telefonia celular e, desta gama de tecnologia, destaca-se hoje duas delas: GSM (Global System Mobile for Communitation) e CDMA (Code Division Multiple Acess). Segundo Taurion (2002, p.18), em % do mercado mundial eram baseados em GSM e 13% em CDMA. O CDMA, um padrão que foi criado na época da segunda guerra mundial para evitar que as mensagens fossem interceptadas pelos inimigos e o GSM, criado na década de 90 na Europa, foi o padrão que conquistou mais mercado até hoje. Estas tecnologias serão vistas com mais detalhes no capítulo 2. O fato é que, pelos estudos efetuados pelo ITU (International Telecommunication Union) e pelos serviços que serão prestados em médio prazo, a evolução baseada na CDMA se mostra muito mais atraente e viável quando se fala em comunicação de dados a altas taxas de transmissão (TAURION, 2002). Existe ainda o problema de como prover os serviços em nível de aplicação, de uma forma mais integrada e padronizada possível, ou seja, os softwares envolvidos no desenvolvimento, distribuição e integração. Existem hoje algumas tecnologias que se destacam no mercado, como a J2ME da Sun, Visual Studio.NET da Microsoft, Superwaba e a BREW da Qualcomm. Diante do exposto acima, as operadoras devem escolher as tecnologias buscando a melhor solução para atender a demanda de mercado com o melhor custo benefício possível. Para a tecnologia de acesso ao meio, a ITU já aponta a solução CDMA como a mais adequada, tendência essa que deve ser seguida. A dificuldade está na plataforma de software para os aplicativos fornecidos aos usuários.

16 15 É este problema, a escolha da melhor plataforma de software para prover serviços, que será abordado neste trabalho, realizando os estudos sobre uma das plataformas: a Plataforma BREW da Qualcomm, empresa detentora da tecnologia CDMA, apontada pela ITU como a melhor opção para o futuro. 1.3 OBJETIVOS Geral Estudo da plataforma BREW com ênfase no desenvolvimento de um protótipo para celular Específicos Conhecer as estruturas em nível de software do BREW SDK (BREW Software Development Kit) para desenvolvimento de aplicativos para a plataforma BREW. Abordar de forma geral o BDS (BREW Distribution System) que, junto com o BREW SDK, compõe a solução BREW da Qualcomm. Criar um protótipo que rode sobre a plataforma BREW, através do uso de um simulador de telefone celular em um microcomputador. Comparar de forma geral a plataforma BREW com outras disponíveis no mercado Escopo e Delimitação Este trabalho vai focar seus estudos em uma breve explanação das tecnologias móveis, apresentando sua evolução e conceitos gerais de algumas destas tecnologias, e na plataforma BREW, realizando uma suscinta comparação com as demais plataformas que se destacam no mercado: J2ME, Superwaba e Visual Studio.NET. Para a BREW, serão apresentadas suas características, recursos disponíveis e, baseado em um protótipo, a utilização de alguns recursos desta plataforma para o desenvolvimento de software.

17 RESULTADOS ESPERADOS Conhecer a BREW no que diz respeito à integração ponta-a-ponta proposta pela plataforma e ter domínio sobre o ambiente de desenvolvimento de software para dispositivos móveis com suporte a BREW. Mapear as diferenças gerais entre a BREW e as demais soluções de mercado que serão avaliadas no decorrer da pesquisa. Demonstrar o funcionamento da plataforma relacionado ao módulo de suporte às tecnologias disponíveis para desenvolvimento, através do protótipo implementado. Vale ressaltar que os resultados esperados são em relação à plataforma BREW e não ao protótipo desenvolvido para estudos da mesma. 1.5 JUSTIFICATIVA Como está sendo vivenciada já há algum tempo no mundo do desenvolvimento de software, principalmente nas empresas especializadas em fornecer soluções seguindo normas como ISO e CMMI, um padrão se faz necessário para se projetar, implementar e implantar softwares de forma eficiente e adequado ao mercado. E é este fator que está levando os fabricantes, operadoras e desenvolvedores de soluções para celulares a buscar e adotar uma plataforma para sistemas em serviço móvel celular, agregando valor a este segmento do mercado de telefonia celular. Existe hoje a tendência de alguns padrões serem adotados para o desenvolvimento de soluções para celulares nas quais se destacam o J2ME (Java 2 Micro Edition) da Sun, Visual Studio.NET da Microsoft e a BREW (Binary Runtime Environment for Wireless) da Qualcomm. Adotar uma destas tecnologias no mercado da telefonia celular onde os usuários cada vez mais buscam por soluções que atendam suas necessidades, pode fazer a diferença para colocar a empresa em uma posição confortável no mercado. Uma plataforma integrada que permita aos fabricantes disponibilizarem dispositivos compatíveis entre si, aos desenvolvedores produzir aplicações sem preocupação com os dispositivos e às prestadoras o fornecimento das aplicações e ter o controle tanto da distribuição como da cobrança dos serviços.

18 17 Devido ao ITU ter apontado as tecnologias baseadas no CDMA como a melhor escolha para o futuro conforme Taurion (2002), ter no mercado brasileiro a operadora Vivo (que atua com CDMA e a plataforma BREW) que em abril de 2005 ocupava o primeiro lugar em participação de mercado com 38,82% dos celulares (ANATEL, 2005d), além dos estudos na área de telefonia celular realizados por graduandos na UNIVALI normalmente serem direcionados as tecnologias J2ME ou WAP (Wireless Application Protocol), será objeto de estudo a plataforma BREW da Qualcomm, empresa detentora também da tecnologia de acesso a rede CDMA. É importante salientar que esta plataforma pode ser aplicada comercialmente independente da interface aérea que define a tecnologia de acesso. 1.6 ASPECTOS METODOLÓGICOS Para realização do projeto será efetuada uma pesquisa bibliográfica baseadas em materiais disponíveis no site da Qualcomm, além de livros e publicações relacionados a serviços na telefonia móvel celular e a plataforma BREW, além do ambiente de desenvolvimento de software para celulares. Para o protótipo será utilizada a UML para modelagem, através da ferramenta de suporte e uma ferramenta para desenvolvimento de software para telefones celulares, além de uma ambiente de simulação em microcomputador. Serão definidos os diagramas de caso de uso, classe de domínio e diagramas de seqüência para o protótipo. 1.7 ORGANIZAÇÃO DO TRABALHO Este trabalho abordará as tecnologias de acesso ao sistema celular e desenvolvimento de software com ênfase na plataforma BREW da Qualcomm. O capítulo 2 abordará inicialmente de uma forma geral as tecnologias celulares, desde a sua criação até os dias atuais com uma breve previsão para o futuro, baseado em publicações. A segunda e última parte abordará algumas das tecnologias para desenvolvimento de software para dispositivos móveis O capítulo 3 aborda mais profundamente a plataforma BREW da Qualcomm, que faz parte do objetivo deste trabalho, explanando as partes que a compõe, focando no ambiente de

19 18 desenvolvimento de aplicações para celulares. Também será apresentado o protótipo para estudos da plataforma, sua modelagem e descrição da utilização de alguns recursos da BREW. No capítulo 4 serão apresentadas as considerações finais sobre os estudos realizados. Ao final, no capítulo 5, será apresentada a conclusão dos estudos realizados, seguido das fontes bibliográficas referenciadas no capítulo 6.

20 19 2 DESENVOLVIMENTO 2.1 CONTEXTO A telefonia celular hoje é extremamente disseminada no mundo inteiro. Segundo a Universidade Estadual de Londrina (1998) esta tecnologia surgiu em 1946 pela Bell Telephone Company com uma única estação de rádio base no próximo tópico será visto o que é uma estação rádio base atendendo a todos os terminais de telefone celular. Desde então, foi aprimorada e expandida. Nos dias atuais, é muito comum ver um terminal celular. No Brasil a telefonia fixa possui 42 milhões de acessos (ANATEL, 2005a) enquanto que a móvel já ultrapassa a casa dos 68 milhões de acessos (ANATEL, 2005b). Estes números são expressivos para o mercado e devem ser bem maiores no futuro, com as chamadas redes convergentes, ou seja, um único número de acesso ao serviço tanto na fixa quanto na móvel. O mercado brasileiro é atendido por várias operadoras de telefonia. Oficialmente, segundo a Anatel (2005c), são 40 operadoras que se reúnem em grupos e formam outros 8 grandes grupos: TIM, Claro, Vivo, Oi, Brasil Telecom Celular, Opportunity, Sercontel e Algar. Cada uma destas 40 operadoras utiliza uma das tecnologias disponíveis que são: AMPS, TDMA, CDMA e GSM. Será apresentada a evolução tecnológica, o funcionamento de cada uma destas tecnologias, quais são as tecnologias atuais que dominam o mercado brasileiro e o que o mercado mundial aponta para o futuro da telefonia celular.

21 REDE CELULAR O telefone fixo, ou seja, um aparelho telefônico com um par de fios metálicos que vão desde a sua casa até uma central telefônica impede o aparelho de ser móvel pela dependência do par de fios. Foi esta necessidade de mercado, a mobilidade, que deu início a uma revolução, ou seja, substituir o par metálico pelo acesso por meio de ondas eletromagnéticas Conceitos Básicos Um telefone celular é basicamente um rádio transmissor que se comunica com uma torre e esta o conecta a uma rede de telecomunicação. A figura 1 mostra a topologia básica de uma rede celular: Telefonia Fixa AUC VRL HRL EIR MSC Estação móvel BSC BSC Torre de Rádio Figura 1: Topologia básica da rede celular. (adaptada por Sérgio N. da Silva) Fonte: Sharma (2001, p.18).

22 21 Com base na figura acima, descreve-se de forma geral os componentes da rede e seu papel na composição desta topologia, conforme Sharma (2001). Estação móvel: são os aparelhos celulares. Pode ser também outros dispositivos móveis com capacidade de se comunicar com a rede celular como os PDA (Personal Digital Assistent). Torre de Rádio: é por meio deste componente que a comunicação do celular se dá com a rede de telecomunicações, também chamadas de ERB (Estação Rádio Base). Basicamente é a forma de acesso que define a tecnologia celular adotada por cada operadora. Será visto mais à frente os tipos e diferenças entre elas. BSC (Base Station Controler): este componente é responsável por controlar uma ou mais torres de rádio base, tanto em nível de efetuar uma conexão do móvel na rede para uma ligação de voz ou dados quanto na execução do handoff que será estudado mais a frente. MSC (Mobile Switch Center): é o componente responsável pelo controle de todas as BSC que estão conectadas em qualquer uma das torres do sistema e, principalmente, pela comutação dos terminais dentro da rede de celular e com a rede de telefonia fixa. Ela faz uso direto de outros quatro elementos da rede: HLR, VLR, AuC e EIR. HLR (home location register): é o componente responsável por fornece a MSC todas as informações referentes aos terminais válidos da operadora, como status do terminal e localização atual (em que torre de rádio ela está). A informação da localização do terminal é atualizada pelas unidades móveis periodicamente, facilitando a comutação sempre que uma chamada é encaminhada ou originada do móvel. VLR (visitor location register): é o componente responsável por manter o cadastro dos telefones visitantes para a operadora que atua na área onde está o terminal. Exemplificando, quando um terminal da operadora A está ligado e operando na área de atuação da operadora B, esta faz a identificação deste terminal, valida com a operadora A e configura-o como visitante em sua rede. AuC (authentication center): é o componente que fornece a MSC as informações necessárias para validar um terminal em nível de serviço, ou seja, se o terminal que está solicitando a utilização de um serviço da rede tem realmente permissão para tal. Podemos ainda citar como exemplo um dispositivo móvel que foi configurado na rede sem permissão de efetuar

23 22 ligações DDI (Discagem Direta Internacional). Ao tentar efetuar uma ligação desta categoria, a MSC verifica na AuC que este terminal não tem acesso, não permitindo assim a utilização deste serviço. EIR (Equipament Identify Register): é o componente que mantêm o registro dos terminais, números de identificação na rede, número de série do aparelho, identidade na rede entre outros. O que deu nome à telefonia celular, basicamente, foi à forma como ela é constituída em nível de acesso ao sistema, ou seja, a comunicação entre o terminal móvel e a torre de rádio. Dornan (2001, p.42) reforça que o termo celular costuma ser considerado pejorativo, representando os antigos telefones analógicos ainda bastante populares em muitas regiões do mundo [...] Entretanto, na verdade, quase todos os sistemas móveis são celulares: dependem de uma rede de células[...] Uma torre de rádio, em termos gerais, é um transmissor e receptor de ondas eletromagnéticas que se comunica com a estação móvel. Cada torre de rádio tem um determinado alcance que depende basicamente da sua potência para transmissão e da geografia ao seu redor. À área atendida por uma torre de rádio recebe o nome de célula. Circular Hexagonal Cobertura de uma área geográfica Figura 2: Representação da célula em uma rede celular. Conforme podemos observar na figura 2, existem duas representações para a célula: a circular e a hexagonal. A mais adotada é a hexagonal pois possibilita uma melhor visão do sistema,

24 23 auxiliando no entendimento da rede celular, como pode ser visto na figura 2. Então, quando um terminal está na célula de uma torre ele faz a comunicação com esta para acessar o sistema. No entanto, quando temos várias torres, existe uma fronteira entre elas. É nesta fronteira que ocorrem dois fenômenos que são considerados crítico para um sistema de telefonia móvel: o handoff e a interferência entre células. O handoff ocorre quando um terminal em movimento sai da área de cobertura de uma torre e se dirige para outra, então ela deve passar a se comunicar com a torre mais próxima. Segundo Dornan (2001, p.44) são procedimentos muito complexos, por que a estação-base precisa calcular com exatidão quando o usuário está atravessando a fronteira da célula. Existem dois tipos de handoff: o hard handoff e o soft handoff. O hard handoff é quando o terminal móvel não tem capacidade para estar conectado a mais de uma torre de rádio ao mesmo tempo. Isso significa que a rede deve ser rápida o suficiente para perceber que o terminal está numa área de fronteira entre torres e decidi o momento certo para a transição, sem que a conexão entre a estação móvel e o sistema seja interrompido. Com isso, uma transição entre torre pode não ocorrer quando: a estação móvel está se deslocando a uma velocidade acima do limite suportado pela rede (100 Km/h para sistemas analógicos e 300 Km/h para digitais), quando não existir uma torre mais próxima para a conexão ou quando a torre que deveria atender a estação móvel não possuir canais livres para a comunicação. No caso do soft handoff a diferença básica é que a estação móvel consegue estar conectada a mais de uma torre de rádio ao mesmo tempo durante a transição. Assim, uma torre só libera a conexão com a estação móvel após a outra torre ter feito a conexão com sucesso. O soft handoff é mais eficiente porém é bem mais complexo para ser implementado. O outro fenômeno crítico, a interferência, ocorre sempre que torres vizinhas estão atuando nas mesmas faixas de freqüência ou canais. Neste caso, se uma estação móvel está nesta área simplesmente pára de funcionar pois ela não sabe identificar o sinal. Para que isso não ocorra, o espectro de freqüência disponível deverá ser quebrado de tal forma que, cada torre utiliza uma faixa de freqüência diferente das torres vizinhas. Esta técnica é chamada de cluster. A figura 3 mostra uma rede onde os canais disponíveis foram divididos em 3 grupos, onde se diz que para esta rede o tamanho do cluster é igual a 3 (DORNAN, 2001).

25 24 Canais 1, 4, 7, Canais 2, 5, 8, Canais 3, 6, 9, Figura 3: Cluster de células. Fonte: Dornan (2001, p.50). Assim, quanto maior o tamanho do cluster de uma rede, menos canais estarão disponíveis por estação de rádio. Dornan (2001, p.50) explica que cluster com tamanho igual a três são pouco comuns em redes reais pois as células não são exatamente hexagonais e nem todas tem o mesmo tamanho.[...] os sistemas mais comuns usam tamanho de clusters iguais a sete ou doze [...] A partir da utilização de tecnologias digitais nas redes de telefonia celular, um novo e importante componente começou a fazer parte desta evolução: a codificação e decodificação de voz em dados digitais, também conhecida por codec. Ele é o responsável por converter a voz humana em sinal digital que será transmitido pelo móvel de origem e reconstroi o sinal original na recepção deste no móvel de destino, sem que haja degradação do sinal, ou seja, perda de informação. Dornan (2001,p.58) diz que a maneira mais simples de digitalizar sinais sonoros é extrair amostragens da forma de onda em intervalos regulares. Este é basicamente o funcionamento do codec, retirando amostras da onda referente a voz a ser transmitida, convertendo-a em dados digitais (bits) para a transferência e recuperação. Além da conversão para bits, também faz uso de algoritmos de compressão dos dados, visando a otimização da utilização dos recursos de rede, particularmente a banda disponível. No entanto, tornou-se um outro fator preocupante para a rede celular, pois, para uma melhor qualidade de voz, um número maior de amostras devem ser coletadas, mais dados digitais são gerados necessitando transmitir no mesmo espaço de tempo fazendo uso de algoritmos mais eficientes para compactação, controle de erros devem ser aplicados e conseqüentemente mais rápidos devem ser os codecs e mais energia eles consumirão.

26 25 Esta é a base de um sistema móvel celular. O ponto que difere as tecnologias mais antigas das atuais e futuras é a forma de acesso ao serviço, ou seja, como se dá a comunicação entre a estação móvel e a torre de rádio. A seguir, serão apresentadas algumas tecnologias de acordo com as gerações e os aspectos técnicos que as diferem Primeira Geração (1G) As tecnologias de primeira geração ou 1G como são chamadas, são caracterizadas pela comunicação analógica entre a estação móvel e a torre de rádio. Destaca-se o AMPS (Advanced Mobile Phone System) que foi utilizada nas Américas, NMT (Nordic Mobile Telephone) utilizada no Japão e a TACS (Total Access Communication System) na Europa (SHARMA, 2001). No Brasil, a tecnologia analógica adotada para implantar o sistema de telefonia celular foi a AMPS. No AMPS aplica o FDMA (Frequency Division Multiple Access) em seu espectro de freqüência disponível. O FDMA faz a multiplexação de acesso por divisão de freqüência. Na verdade, é o mesmo sistema utilizado para transmissão de TV e rádio, onde para cada portadora sintonizada no receptor um canal de TV ou rádio é captado. No caso da AMPS, possui dois espectros disponíveis de freqüência de 25MHz, uma para transmissão da torre para a estação móvel (conhecido como downlink) e outros para o sentido inverso (uplink) onde, aplicando a FDMA, são criados vários canais de acesso de 30KHz no espectro de freqüência disponível para o sistema (figura 3), onde efetivamente apenas 24KHz de cada canal são utilizados para comunicação. Os outros 6KHz são desprezados para sanar o maior problema existentes em sistemas FDMA que são as interferências entre canais vizinhos (Dornan, 2001, p.50). Sobre cada canal de acesso é aplicada a técnica FM (Frequency Modulation) onde existe uma freqüência portadora e sobre esta é feita a transmissão dos dados modulados a freqüência, ou seja, uma variação no comprimento de onda. Criando uma relação entre banda disponível (25 MHz) e tamanho dos canais criados pela FDMA (30 KHz), verifica-se que o AMPS possui a capacidade máxima de 832 canais ou comunicações simultâneas, porém, 42 são utilizados para controle (Dornan, 2001, p.49). Estes canais de controle também são chamados de setup (ALENCAR, 2001, p.193).

27 26 Figura 4: Representação da divisão do espectro de freqüência em canais (FDMA). Para o AMPS utilizado nas Américas, possui as seguintes características (Dornan, 2001, p.51): Espectro de freqüência para downlink: 869 a 894 MHz Espectro de freqüência para uplink: 824 a 849 MHz Espectro total do canal: 30KHz Espectro útil: 24 KHz Capacidade máxima de transmissão de dados: 9,6 kbps Para que haja uma comunicação entre estação móvel (ES) e torre de rádio (TR), a ES aloca junto a TR dois canais de controle e negocia através destes quais canais de voz serão utilizados para a comunicação. Com isso, para cada chamada telefônica em andamento na rede, existe entre móvel e torre a ocupação de 4 canais. Esta é uma das tecnologias que compões a 1G e que possibilitaram disponibilizar o serviço de voz com mobilidade, porém, algumas deficiências destas tecnologias não permitiam que novos serviços pudessem ser oferecidos ao mercado, como comunicação de dados mais rápida. Além disso é de fácil quebra de sigilo do sinal pois não existe nenhuma preocupação de segurança. Para sanar estas deficiências, foram concebidos os sistemas de segunda geração (2G) apresentados a seguir.

28 Segunda Geração (2G) Nesta geração, novos conceitos foram definidos e a utilização de tecnologia digital foi aplicada, visando prover serviços com melhor qualidade e segurança aos usuários. Vários padrões foram oferecidos ao mercado e cada operadora de telefonia celular acabou adotando o que entendia como a melhor opção para a evolução de suas redes. No Brasil, os padrões adotados pelas operadoras foram o TDMA (Time Division Multiple Acess), CDMA (Code Division Multiple Acess) e o GSM (Global System for Mobile Communication). O TDMA é baseado na tecnologia AMPS, ou seja, possui um espectro de freqüência disponível, realizando o FDMA nestes criando canais com banda de 30KHz cada. As diferenças são basicamente duas: transmissão digital dos dados e aplicação do conceito de timestlots nos canais. O timeslots é a divisão do canal em intervalos de tempo (Alencar, 2001, p. 176). No caso do TDMA, cada canal é dividido em três intervalos de tempo, ou seja, cada canal, também conhecido como frame, é compartilhado (multiplexado) entre três usuários. Na comunicação entre estação móvel e torre de rádio, são utilizados dois timeslots, um para uplink e outro para downlink que possuem estruturas diferentes A figura 5 mostra a estrutura dos frames e seus timeslots, além do tamanho em bits e tempo de duração de cada estrutura. Figura 5: Estrutura dos timeslots TDMA. (adaptado por: Sérgio N. da Silva) Fonte: Dornan (2001, p. 78).

29 28 Analisando a figura 5, percebe-se que o frame E está destacado no multiframe. Este é utilizado para sinalização do sistema. Com isso, uma estação móvel inicia sua comunicação com a torre de rádio através de um timeslot de controle pré-definido na configuração da rede, recebendo a identificação de qual canal e timeslot deve ocupar para a transferência dos dados. Quando está em comunicação, o aparelho só transmite no seu timeslot, ficando em silêncio durante todo o tempo restante dos demais timeslots do mesmo canal. Segundo Alencar (2001), a capacidade de transmissão de um canal é de 48,6 kbps ou seja, 16,2 kbps por timeslot e, conseqüentemente, por usuário conectado. Destes 16,2 kbps, 7,95 kbps (49%) é referente a voz codificada (saída do codec), 5,05 kbps (31%) para controle de erro e 3,2 kbps (20%) para controle do sistema de telefonia celular. Com essa digitalização foi possível aumentar a segurança das redes, além de fornecer novos serviços como o SMS (Short Message Service) para troca de mensagens de texto curtas (até 160 caracteres) e identificador de chamadas. Além disso, a realização do handoff foi aperfeiçoada. Nesta tecnologia, a estação móvel faz uso da técnica chamada MAHO (Mobile Assisted Handoff) que realiza uma verificação das torres de rádio as quais ela consegue contato via canais de controle e encaminha estas informações a torre a qual ela está efetivamente conectada no momento. De posse destas informações, a torre atual define qual a melhor opção de torre destino para realizar handoff com a maior segurança possível (Alencar, 2001, p. 176). Outra tecnologia de segunda geração é a CDMA (Code Division Multiple Access) da empresa Qualcomm, cujo desenvolvimento no setor de tecnologias celulares teve a mesma repercussão que a Microsoft em software para PC e da Cisco em hardware para redes (DORNAN, 2001, p.53). O CDMA, também conhecido por IS-95, é baseado no DSSS (Direct Sequence Spread Spectrum), onde exige uma largura de banda de canal de 1,25MHz, bem maior que os 30KHz do TDMA. No entanto, apesar das exigências aparentemente grandes, o espectro realmente é aproveitado de maneira mais eficaz do que em outros sistemas, por causa da possibilidade de ser compartilhado por transmissões diferentes (DORNAN, 2001, p. 53).

30 29 Figura 6: Espalhamento dos dados nas portadoras disponíveis. Fonte: Oliveira e Filho (2003). O DSSS é uma forma de utilização de toda a faixa de freqüência disponível através do espalhamento de espectro. Basicamente, a transmissão é feita de forma pseudo-aleatória em todas as portadoras disponíveis conforme figura 6. A forma é considerada pseudo-aleatória pois, na prática, esta seqüência deve ser conhecida tanto pelo transmissor quanto pelo receptor do sinal. Ao transmitir, a estação móvel gera a seqüência pseudo-aleatória de canais e realiza a transmissão dos dados em todas as portadoras do sistema. Para que o receptor identifique a que estação móvel pertence o sinal, cada conexão transmissor-receptor é provida com um código particular, de tal forma que as conexões simultâneas são diferenciadas por códigos distintos e com baixa correlação entre si. (Waldman e Yacoub, 1999, p. 56). Segundo Dodd (2000, p. 378), este código tem tamanho de 40 bits e é chamado de walesh code. Com esta tecnologia, todas as estações móveis são capazes de utilizar todo o espectro de freqüência disponível, ou seja, mais de uma estação móvel utilizando a mesma banda ao mesmo tempo. Se isso é possível, mais de uma torre de rádio também pode utilizar as mesmas freqüências, o que não acontecia com o TDMA e AMPS que necessitam de configuração de clusters na rede. Esta característica permite aos sistemas que utilizam CDMA realizar o soft handoff, isto é, estar conectado a mais de uma célula ao mesmo tempo. Neste sistema, o que difere então uma célula de outra é a defasagem entre os códigos (walesh code), onde após a estação móvel realizar o procedimento com segurança, libera código da célula de origem, ficando apenas conectada a célula de destino.

31 30 O CDMA possibilita então taxas de transferência de 9,6 kbps e / ou 14,4 kpbs (configurável pela operadora de telefonia), com uma taxa de espalhamento de até 1,22 Mbps para portadoras de 1,25 MHz (Waldman e Yacoub, 1997, p. 58). Mesmo a CDMA sendo a mais indicada para a evolução das redes para as próximas gerações, a tecnologia de 2G que mais conquistou mercado foi a GSM, que teve seu início em 1982 através de um grupo de trabalho chamado Groupe Spéciale Mobile que, inicialmente, batizou a tecnologia como GSM. Em 1988 o grupo GSM começou a fazer parte do ETSI (European Telecommunications Standards Institute) que testou e disponibilizou comercialmente a tecnologia GSM em 1992, onde o significado da sigla GSM passou a ser Global System for Mobile Communication (ALENCAR, 2001, p.175). A GSM é baseada na TDMA, ou seja, divisão de cada canal em timeslots. No caso da GSM, a banda disponível para cada canal é de 200KHz e para cada canal são criados 8 timeslots (na TDMA eram 30KHz com 3 timeslots). Esta tecnologia foi projetada para atender o mercado utilizando a faixa de freqüência de 900MHz na Europa, no entanto foi licenciada para novas bandas conforme tabela abaixo: Tabela 1: Faixas de freqüência disponíveis no mundo para GSM. Tipo de GSM Freqüência uplink Freqüência downlink Tamanho da Célula GSM ,4 457,6 MHz 460,4 467,6 MHz Maior possível ou MHz ou 488,8 496 MHz GSM MHz MHz Grande DCN MHz MHz Pequeno PCS MHz MHz Menor possível Fonte: Dornan (2001, p.67) A GSM 450 é a mais recente e foi disponibilizada para substituir as redes analógicas baseadas na tecnologia NMT (Nordic Mobile Telephony). A GSM 900 foi a primeira e também com o objetivo de reaproveitar a faixa disponível para telefonia analógica na Europa. No caso da DCN 1800, foi licenciada também para a Europa, sendo a faixa de 1800 MHz exclusiva para uso do GSM e a PCS 1900 para a faixa dos 1900 MHz porém disponibilizada nas Américas. (DORNAN, 2001, p.66).

32 31 A capacidade máxima de transmissão de um canal na tecnologia GSM é de 270,8 kbps, taxa essa possibilitada pela utilização de um sistema de modulação de canais chamado de GMSK (Gaussian Minimum Shift Keying). Como cada canal possui oito timeslots, a capacidade máxima por timeslot é de 33,9 kbps. A figura a seguir mostra a estrutura de frames e seus timeslots. Figura 7: Estrutura de frames e timeslots da GSM. (adaptado por: Sérgio N. da Silva) Fonte: Dornan (2001, p.69). A GSM utiliza dois frames - no caso da figura 7 são o E e R - do conjunto multiframe: um para controle do sistema e outro para utilização em serviços como SMS e identificador de chamadas. Quando um timeslot é utilizado para comunicação, este transporta todas as informações que se deseja transmitir, também possibilita ao sistema identificar se o timeslot está transportando dados ou voz, ou ainda se são dados do próprio sistema para controle deste, além dos dados propriamente ditos com seu controle de erro, criptografias e outros. Com todas estas informações sendo transmitidas dentro de um timeslot, sua capacidade de dados de usuários efetivamente transmitidas cai a aproximadamente um terço do total, dependendo principalmente do codec utilizado pela rede e estação móvel para codificar voz e dados (DORNAN, 2001, p.69). Tecnologias de segunda geração então disponibilizaram ao mercado uma telefonia celular digital, de melhor qualidade que a 1G, mais segurança das informações transmitidas via interface aérea, além de serviços como troca de mensagens e identificador de chamadas.

33 32 O mercado de transmissão de voz alcançou então um grau de qualidade satisfatório, mas a transmissão de dados ainda era relativamente lenta para nas necessidades multimídias. Estas sim necessitam de altas taxas de transferência, possibilitando várias novas facilidades aos usuários como vídeo conferência, assistir a filmes e acesso a Internet sem fio. Para atender estas necessidades, foram concebidas as tecnologias consideradas 2,5 G e 3G, que serão vistas a seguir Segunda Geração e Meia (2,5G) Esta geração é, na verdade, um aprimoramento das tecnologias de segunda geração, porém, dando a elas uma maior capacidade para comunicação de dados. Algumas das tecnologias existentes, e que serão abordadas neste tópico, são: HSCSD, GPRS e cdmaone. O padrão HSCSD (High Speed Circuit Switched Data) é uma atualização muito simples para o GSM, fornecendo a cada usuário mais de um timeslot na operação de multiplexação (DORNAN, 2001, p.70). Entre as características deste padrão, estão: Utilização de codec específico para comunicação de dados permitindo uma taxa de transferência de 14,4 kbps; Permite agrupar até 4 timeslots subseqüentes para a transmissão de dados, elevando a taxa para 57,6 kbps; Permite transferência dos dados entre estação móvel e torre de forma assimétrica, ou seja, taxa de download diferente da taxa de upload; No entanto, este padrão possui alguns problemas. Na maioria das regiões onde o GSM é utilizado as redes já estão chegando ao seu limite, o que dificultaria a implantação já que seria necessário investimento para ampliação da rede, já que um cliente que utiliza o HSCSD necessitaria de, teoricamente, quatro vezes mais de banda disponível. Além disso, o fato de um terminal móvel ter que transmitir quatro timeslots subseqüentes provoca um aumento no consumo de energia e de emissão de radiação, sem mencionar que as primeiras estações móveis com suporte a transferência plena no HSCSD literalmente incendiaram (Dornan, 2001, p.71). Neste caso, a melhor opção para o HSCSD era o sistema assimétrico, com velocidades maiores de download do que uploads, o que atende perfeitamente a navegação na Internet que tem justamente esta característica.

34 33 Já o GPRS (General Packet Radio Service) foi o padrão que melhor se adaptou as redes GSM no mundo. Nesta tecnologia foi aplicada a técnica de comutação de pacote, muito utilizada nas redes de computadores, ao invés da comutação de circuito como é feito na GSM e HSCSD. Segundo Dornan (2001, p.73) a comutação de pacotes usa a largura de banda apenas quando necessário, liberando intervalos de fluxo de dados para outros usuários. Isso significa que um único timeslot com taxa de 14,4 kbps pode ser compartilhado entre vários usuários, no entanto, a transmissão neste é permitida apenas um usuário por vez. Desconsiderando o problema de consumo de energia que acabava levando as estações móveis a se incendiarem e que também é enfrentado pela tecnologia GPRS, o limite teórico da taxa de transferência neste sistema é de 115,2 kbps, ou seja, a utilização de oito timeslots subseqüentes. Ainda segundo Dornan (2001, p.73) existe no mercado a tendência de realizar todo o tipo de transferência de informação, seja ela voz ou dados, através de GPRS. No caso específico de voz, o sinal analógico seria tratado por um codec de velocidade variável para satisfazer as necessidades. Esta é uma visão de futuro, pois, hoje o GPRS depende o GSM para existir, ou seja, os telefones celulares necessitam suportar os dois tipos de comutação: pacotes e circuitos. Para padronizar os projetos de telefones celulares com suporte a GPRS, foram definidos três modos distintos chamados de graus A, B e C. Telefones de grau A são capazes de transmitir simultaneamente dados por comutação de pacote e circuito, ou seja, ele permite que o usuário realize uma chamada de voz enquanto está no processo de envio de um . Os aparelhos classificados como grau B permitem ao usuário possuir as duas conexões simultâneas, porém, na de dados (comutação por pacote) ele somente recebe pacotes. Exemplificando ele pode estar falando ao telefone e receber uma notificação que tem um novo em sua conta de correio eletrônico. Já o grau C é literalmente ou um ou outro, ou seja, caso o usuário esteja navegando na Internet e uma chamada de voz é solicitada, o aparelho suspende a comutação por pacote não há a desconexão inicia a comutação de circuito para a chamada de voz, retomando a de pacotes assim que finalizada a ligação. Além do grau do GPRS, também foram definidas classes, onde em cada uma das 29 existentes (ver tabela 2) são especificadas as quantidades máximas de timeslots que serão alocados tanto no uplink quanto downlik, definindo ainda se é possível realiza comunicação no modo full duplex. Como exemplo, para atingir a taxa máxima de transferência que é de 115,2 kbps, um

35 34 aparelho celular deve ser da classe 18. Nesta está definido que o sistema fará uso de 8 timeslots para cada link com comunicação full duplex em uma rede GPRS. Tabela 2 Capacidade de dados das classes de terminais GPRS Classe Timeslots utilizados (máximo) Lacuna Capacidade (kbps) Full Downlink Uplink Total entre slot Downlink Uplink duplex Redes ,4 14,4 Sim GMS,GPRS ,8 14,4 Sim HSCSD, GPRS ,8 28,8 Não HSCSD, GPRS ,2 14,4 Sim HSCSD, GPRS ,8 28,8 Sim HSCSD, GPRS ,2 28,8 Não HSCSD, GPRS ,2 43,2 Não HSCSD, GPRS ,6 14,4 Sim HSCSD, GPRS ,2 28,8 Sim HSCSD, GPRS ,6 28,8 Não HSCSD, GPRS ,6 43,2 Não HSCSD, GPRS ,6 57,6 Não HSCSD, GPRS ,2 43,2 Sim HSCSD, GPRS ,6 57,6 Sim HSCSD, GPRS ,0 72,0 Sim GPRS ,4 86,4 Sim GPRS ,8 100,8 Sim GPRS ,2 115,2 Sim GPRS ,4 28,8 Sim GPRS ,4 43,2 Não GPRS ,4 57,6 Não GPRS ,4 57,6 Não GPRS ,4 86,4 Não GPRS ,2 28,8 Não GPRS ,2 43,2 Não GPRS ,2 57,6 Não GPRS ,2 57,6 Não GPRS ,2 86,4 Não GPRS ,2 115,2 Não GPRS Fonte: Dornan (2001). Adaptado por: Sérgio N. da Silva.

36 35 O cdmaone é um padrão desenvolvido pela Qualcomm para as redes que utilizam o CDMA. Basicamente faz a transferência de dados da mesma forma que o CDMA realiza para voz. Este padrão utiliza código walesh code (ver página 23) de 64 números, onde cada número é de 64 bits, calculados de tal forma que um número acabe cancelando o outro. Além disso, cada bit a ser enviado é multiplicado pelo código, que é individual por usuário, ou seja, cada bit de dado é enviado 64 vezes, viabilizando uma velocidade total de 19,2 kbps no downlink mas o aparelho ouve os vários canais a uma taxa 64 vezes maior, ou seja 1228,8 kbps (Dornan, 2001, p.81). Em teoria, com esta técnica poderia haver até 64 usuários transmitindo ao mesmo tempo por canal disponíveis. Na prática foi constatado um limite de 10 a 20 usuários para um bom desempenho do sistema. Além desta limitação prática, não são somente os bits que são transmitidos 64 vezes. Este fator de multiplicação também se aplica à energia utilizada para transferir um bit e a quantidade de irradiação a qual o usuário é exposto. Para solucionar este problema, um rigoroso controle é realizado pelo aparelho na transmissão, visando deixar o aparelho com o mínimo de atividade possível e garantir que o nível dos sinais seja praticamente o mesmo para todos na torre de rádio, garantindo assim que todos os aparelhos sejam ouvidos pela torre com igualdade de intensidade de sinal. As duas versões disponíveis de cdmaone são apresentadas na tabela a seguir. Tabela 3: Sistemas cdmaone disponíveis. Nome da versão Freqüência Freqüência Tamanho da uplink downlink célula Concorre com TIA/EIA/IS-95A MHz MHz Maior possível TDMA / D- AMPS ANSI Menor GSM MHz MHz possível J-STD-008 Fonte: Dornan (2001, p.83).

37 Terceira Geração (3G) Segundo Dornan (2001), para identificar uma tecnologia de terceira geração, foi estipulado um parâmetro básico que deve ser atendido: ser capaz de transmitir informações a uma taxa mínima de 144 kbps em condições normais de operação e não limites máximos, como o que acontecia com algumas tecnologias da 2,5G. A ITU (International Telecommunication Union) em 1992 percebeu a importância que a telefonia celular teria no futuro, concorrendo com a telefonia fixa. Então foi criado um projeto que disponibilizou hoje o que conhecemos como o conjunto de normas para a terceira geração de celular chamado de IMT-2000 (International Mobile Telecommunications 2000). Na época, a visão da ITU era a convergência dos serviços de telefonia convencional, Internet e aplicações multimídias e definiu seis classes de serviços que devem ser suportados pela 3G (DORNAN, 2001): Voz: além do serviço de voz que conhecemos, sempre prezando a qualidade destes, inclui-se nesta definição o correio de voz integrado com o através da síntese e reconhecimento da voz. Necessita de uma taxa simétrica 28,8 kbps utilizando circuitos virtuais (circuitos criados sobre comutação de pacote). Mensagens: mensagens incluem com anexos e troca de mensagens para efetuar transações financeiras. Possui as mesmas taxas do serviço de voz, porém, utiliza comutação de pacote. Comutação de dados: possibilitar a conexão de dados para redes corporativas ou Internet, via acesso discado ou conexão sempre ativa, além de serviços de fax. A conexão através de discagem deve ser mantida para atender equipamentos mais antigos que ainda utilizam esta forma de conexão. Taxa de 43,2 kbps simétrica sobre circuito virtual. Meio de multimídia: permitir o acesso a Web, trabalhos de colaboração, jogos e mapas para localização. Utiliza 19,2 kbps para upload e 768 kbps de download com comutação de pacote. Multimídia de alto nível: neste nível, será possível acesso a Web a alta velocidade, com qualidade de imagem em alta definição e som com qualidade de CD, além de comércio

38 37 eletrônico de músicas, vídeos, softwares, entre outros. Dados com taxa de 2Mbps para download e 20 kbps para upload com comutação de pacote. Multimídia interativa de alto nível: realizar vídeo conferência e vídeo fones com qualidade suficiente para proporcionar a telepresença. Taxas de 256 kbps simétrica sobre circuito virtual. Para se conseguir um aumento na taxa de transmissão, basicamente se utiliza duas técnicas: utilização de banda extra de espectro e modulação utilizando sistema octal ao invés do binário. Um outro fator é que a tendência é utilizar como base o CDMA, devido a sua capacidade para lidar com novos usuários (DORNAN, 2001). O fato é que deve existir um plano para migrar as redes atuais de 2G e 2,5G para as de 3G. Conforme Dornan (2001, p.105), originalmente a ITU desejava um padrão global único, mas isso não foi conseguido. O principal problema enfrentado para tal migração é a compatibilidade entre sistemas. Dornan (2001) apresenta três compatibilidades necessárias apontadas pela ITU: Atualizações diretas: é o aperfeiçoamento do sistema atual das operadoras, adicionando a comutação por pacote e um melhor sistema de modulação do sinal sem alterar o tamanho das células e a estrutura de canais existentes. Roaming: para o ITU, está relacionado a um telefone móvel que suporte vários sistemas diferentes possibilitando que seja utilizado em todo o mundo. Alguns aparelhos poderão suportar todos os sistemas, mas inicialmente, suportarão apenas um. Handoff: possibilitar o handoff entre redes de tecnologias diferentes sem que o usuário perceba. A única situação em que se admite que o usuário identifique a mudança é quando, por exemplo, está usando um serviço disponível somente para 3G, como uma vídeo conferência, e faz um handoff para uma rede de 2G. Neste caso a vídeo conferência será interrompida pois a rede 2G não suporta. Para ITU, a escolha para migrar as redes para a 3G é a utilização de dois padrões que possuem características técnicas que permitem a existência destes com os anteriores, sem prejuízos aos usuários: cdma2000 e W-CDMA. Dornan (2001, p.95) mostra uma espécie de gráfico que

39 38 traça os caminhos para a migração das tecnologias mais utilizadas no mundo para redes para a 3G com a maior compatibilidade possível. PDC W-CDMA GSM GPRS EDGE HSCSD AMPS / TDMA D-AMPS+ cdma2000 1Xtreme cdmaon cdmatwo 1XMC HDR 3XMC Gerações Sistema 2G Sistema 3G Atualizações previstas para migração Fácil adaptação Necessidade de nova modulação Troca dos sistemas de rádio Figura 8: Evolução para redes 3G. (adaptado por: Sérgio N. da Silva) Fonte: Dornan (2001, p.95). Além da W-CDMA e a cdma2000, existe ainda o padrão EDGE que surgiu e posteriormente foi considerado um sistema padrão IMT O W-CDMA (Wide CDMA) foi projetado para permitir o handoff entre ela e uma rede GSM no modo hard handoff já que o GSM não faz soft handoff, porém, uma rede GSM não pode ser atualizada para W-CDMA. Para permitir uma maior velocidade na transferência de dados, esta tecnologia adotou uma banda de 5MHz o CDMA utiliza 1,25MHz fato que batizou a tecnologia com o nome atual. Uma outra característica desta tecnologia é o ajuste do ganho conforme a intensidade do sinal, onde cada bit é enviado de 4 a 128 vezes, ao contrário do cdmaone que sempre envia os bits 64 vezes (DORNAN, 2001). Com esta técnica utilizando códigos variáveis, chamados de código Gold, e a modulação do cdmaone, esta tecnologia chega a taxas de 4Mbps por canal em cada célula. Após 1996, o W-CDMA passou a ser conhecida na Europa como UMTS. Para as redes cdmaone, um conjunto atualizações da rede em nível de software e modulação foi disponibilizado denominado de CDMA Segundo Dornan (2001, p.109) até a metade de 2000, parecia claro o percurso para atualização do cdmaone. O produto final era considerado como um sistema chamado cdma2000 3XMC por combinar 3 canais, resultando

40 39 em uma banda mais larga. O problema era que este sistema não possuía compatibilidade com o W-CDMA utilizado na Europa e Japão. Existem muitas características equivalentes entre as duas tecnologias. Basicamente o que diferencia uma da outra é a freqüência de ressonância do transceptor, onde a do cdma2000 necessita ser múltiplo da cdmaone, mas a do W-CDMA precisa ser adequada à estrutura do GSM para possibilitar a compatibilidade de handoff. Procurando buscar uma solução para este problema, a Motorola e Nokia lançaram o 1Xtreme, prometendo bem próximas às do 3XMC só que utilizando um canal ao invés de três, proporcionando as operadoras que utilizam cdmaone evoluir as redes para capacidades superiores as demais tecnologias concorrentes. Na figura 8, é apresentada a cdma2000 como um conjunto de 4 tecnologias, com a seqüência de evolução entre elas para se chegar a velocidades de 3G: 1XMC, HDR, 3XMC e 1Xtreme. A 1XMC faz uso de multiportadoras e é a evolução inicial para as operadoras que utilizam a cdmaone. Para isso, elas devem realizar um upgrade no hardware das estações bases sem alterar as interfaces de rádio (antenas). Além disso, esta evolução utiliza duas vezes cada código Walsh, prometendo o dobro de velocidade do cdmaone. 3XMC é o que a ITU considera como a que atende as especificações IMT-2000, com desempenho idêntico ao W- CDMA. O que o ITU ainda está aguardando são telefones celulares capazes de suportar freqüências de ressonância variáveis, permitindo assim a utilização destes tanto com W- CDMA quanto 3XMC. O HDR é uma proposta da Qualcomm para aumentar a capacidade de transferência de um canal de 1,25 MHz do 1XMCD, chegando a taxas de 2,4 Mpbs para downlink e 307,2 kbps para uplink. Estas velocidades são compartilhadas por todos os de uma célula, sendo que apenas 29 telefones conectados ao mesmo tempo. A baixa velocidade de uplink é motivado pela aplicação de TDMA, além do CDMA, nos canais que são divididos em 240 timeslots. Uma outra característica que limita esta tecnologia é que o HDR é somente aplicado a comunicação de dados e não de voz. 1Xtreme é o padrão especificado pela Nokia e Motorola para concorrer com o HDR. A diferença básica é que ele pode ser aplicado tanto para dados como para voz. Na tabela a seguir pode se verificar as velocidades disponíveis para cada sistema.

41 40 Tabela 4: Comparação dos sistemas CDMA. Sistema CDMA Banda do Canal Ressonância Taxa máxima Taxa Real cdmaone 1,25 MHz 1,2288MHz 115,2 kbps 64 kbps cdma2000 1XMC 1,25 MHz 1,2288MHz 384 kbps 144 kbps cdma2000 1Xtreme 1,25 MHz 1,2288MHz 5,2 Mpbs 1200 kbps cdma2000 HDR 1,25 MHz 1,2288MHz 2,4 Mpbs 621 kbps cdma2000 3XMC 3,75 MHz 3,6864 Mhz 4 Mpbs 1117 kbps W-CDMA (UMTS) 5 MHz 4,096 MHz 4 Mbps 1126 kbps Fonte: Dornan (2001). Um padrão então surgiu contrariando a tendência apontada pelo ITU em sistemas de 3G somente baseados em CDMA: o EDGE (Enhanced Data Rates for GSM Evolution). Este padrão só foi aceito como IMT-2000 no ano de 2000, apesar da intenção de criar o EDGE não ser de colocar uma tecnologia baseada em TDMA para concorrer com as demais que são oriundas do CDMA e sim para aproveitar a banda disponível, enquanto uma operadora migra para a W-CDMA, para ampliar a capacidade de dados das redes que possuíam HSCSD e GRPS (DORNA,2001). O EDGE é uma tecnologia que utiliza a modulação 8-PSK substituindo o GMSK utilizado na GSM. Com esta modulação, a taxa de transferência sobe para 64,2 kbps contra os originais 21,2 kbps do GSM. O EDGE, ao ser implantando em uma rede, conseqüentemente teria disponível o GPRS e, em alguns casos, o HSCSD. Assim, caso um telefone celular esteja conectado a rede que disponibiliza EDGE mas este possui somente suporte a GPRS, ele poderia fazer uso do GPRS puro sem nenhum problema. Por este motivo, esta tecnologia também é conhecida como EGPRS (Enhanced GPRS) ou EHSCSD (Enhanced HSCSD). Um dos problemas da tecnologia é o fato de utilizar o 8-PSK para aumentar a velocidade, pois, esta técnica de modulação é mais sujeita a erros que a GMSK. Para tal, de acordo com a qualidade da conexão, o EDGE especifica nove MCVs (Modulation and Configuration Schemes), conforme tabela abaixo:

42 41 Tabela 5: Modulações e esquemas de codificação EDGE. MCS Capacidade do slot Modulação Capacidade do canal MCS-1 8,8 kbps GMSK 70,4 kbps MCS-2 11,2 kbps GMSK 89,6 kbps MCS-3 14,8 kbps GMSK 118,4 kbps MCS-4 17,6 kbps GMSK 140,8 kbps MCS-5 22,4 kbps 8PSK 179,2 kbps MCS-6 29,6 kbps 8PSK 236,8 kbps MCS-7 44,8 kbps 8PSK 358,4 kbps MCS-8 54,4 kbps 8PSK 435,2 kbps MCS-9 59,2 kbps 8PSK 473,6 kbps Fonte: Dornan (2001). Estas são as tecnologias que são reconhecidas pelo ITU como as que atendem as especificações do IMT Como toda tecnologia, as evoluções não param por ai. Novos padrões estão sendo concebidos, a fim de disponibilizar para o mercado de telefonia celular a quarta geração Quarta Geração (4G) A 4G ainda está praticamente em fase de especificação e desenvolvimento. Ela promete fornecer ao mercado de telefonia celular taxas de transmissão da ordem dos 100Mbps (DORNAN,2001). No entanto, em uma conferência chamada Conferência Internacional Para Além da Terceira Geração (ICB3G-2004) a operadora NTT DoCoMo do Japão, para surpresa de muitos, apresentou os resultados dos testes realizados em uma cidade do Japão. Nos testes, a operadora chegou a uma taxa de transferência máxima de 300 Mbps e de 135 Mbps para um móvel de deslocando a uma velocidade de 30 Km/h. Nos planos a operadora está a utilização da tecnologia MIMO (Multiple Input & Multiple Output), que permite chegar a taxas de até 1Gbps em movimento (JB ONLINE, 2004). Após esta apresentação geral das tecnologias que possibilitam disponibilizar os serviços de voz e dados aos usuários da telefonia celular e suas respectivas gerações, ficam claro o poder

43 42 que estas redes tem e terão em médio prazo para a comunicação de dados. Este fator é uns dos maiores atraentes para os desenvolvedores de soluções para a comunicação móvel. Para tal, será abordado algumas das plataformas de desenvolvimento de software, em especial a plataforma BREW da Qualcomm. 2.3 TECNOLOGIAS PARA DESENVOLVIMENTO DE SOFTWARE Superwaba Esta plataforma de desenvolvimento de software, criada em 2000, é uma evolução do projeto de software livre Waba, da empresa Waba Software, voltada ao desenvolvimento de software para PDA (Digital Personal Assistent). Baseada em um SuperWaba SDK que define uma linguagem, uma máquina virtual, um conjunto de classes padrões e um padrão de armazenagem de classes, os desenvolvedores podem fazer uso das mesmas ferramentas disponíveis para Java, mesmo o SuperWaba não tendo nenhuma relação com o Java em termos de especificação (SUPERWABA, 2005a). Dentre suas características, destaca-se o suporte a criação de bibliotecas nativas em C/C++, tokenizador de XML, máquina virtual com suporte a diversas plataformas, leitura de arquivos PalmDoc, algoritmos de criptografia Blowfish, MD5, SHA1 e TEA, suporte a TCP/IP, USB, serial, Bluetooth e infra-vermelho. Além destas características técnicas, o Superwaba está disponível em duas formas de licença que são a GPL (GNU General Public License) e a LGPL (GNU Lesser General Public License). A GPL é aberta e livre para qualquer pessoa que queira desenvolver um software baseado nesta tecnologia, desde que seu software também seja livre, ou seja, herda a licença GPU. Já a LGPL necessita que seja realizada uma subscrição anual que, mesmo o Superwaba continuar sendo um software livre, permite criar aplicações proprietárias. Esta tecnologia foi utilizada na COPEL, Companhia Paranaense de Energia, para disponibilizar às suas equipes de campo uma extensão da rede através do uso de handheld conectado à rede via celular, dando agilidade à execução de atividades, aumentando em 20% a produtividade (SUPERWABA, 2005b).

44 J2ME A Java 2 Micro Edition é uma edição do Java criada para atender dispositivos com pouca capacidade de processamento e armazenamento, como os celulares e PDA (Personal Digital Assistant). Como estes dispositivos não tem capacidade para implementar todas as funcionalidades disponíveis na J2SE (Java 2 Standard Edition), fez se necessário a especificação de uma versão mais leve que é o caso da J2ME (MUCHOW, 2002). Ela foi concebida e baseada em dois novos conceitos: configurações e perfis. Chama-se de configurações a parte que contemplas a JVM (Java Virtual Machine) e as APIs que podem ser utilizadas. Existem várias configurações disponíveis, mas as mais comuns são as CDC (Conected Device Configuration), que utiliza uma JVM, e a CLDC (Conected Limited Device Configuration) que é baseada em uma máquina virtual reduzida chamada de KVM. (ALMEIDA, 2004). As características básicas de cada uma delas, segundo Almeida (2004) são: CDC o o o Com no mínimo 512 KB de memória para execução da JVM. Com no mínimo 256 KB para alocação de memória em tempo de execução. Conectividade de rede, largura de banda alta e acesso permanente. CLDC o o o o o Com 128 KB para executar a KVM. 32 KB para alocação de memória em tempo de execução. Interface restrita com o usuário. Baixo consumo, normalmente alimentado por bateria. Conectividade de rede, normalmente dispositivos sem fio com largura de banda baixa e acesso intermitente. Já os perfis são recursos adicionais para determinadas linhas de dispositivos móveis, como interfaces com usuários e modelos de persistências de dados. Segundo Muchow (2002, p.5), podem ser vistos como uma extensão de uma configuração fornecendo ao desenvolvedor bibliotecas para escrever aplicativos para um tipo particular de dispositivo.

45 44 Alguns perfis disponíveis pela Sun Microsystems (2001) são: MIDP (Mobile Information Device Profile): utilizado em celulares; Foundation Profile: para dispositivos sem interface gráfica; Personal Basis e Personal Profile: para dispositivos que tem capacidade de processamento suficiente para rodar uma JVM (CDC). Pelo fato do J2ME estar se popularizando por meio dos celulares, a MIDP é o perfil mais difundido no mercado. Para que se possa utilizar este o dispositivo tem que ter recursos mínimos como 128Kb de memória não volátil para o perfil propriamente dito, 32Kb para a heap (volátil) e 8Kb para persistência (não volátil). Para aplicações gráficas ele exige um mínimo de resuloção (96 x 54 pixels). Além disso, possibilita interface com dispositivos para entrada de dados como o teclado e conexão de rede. Em nível de segurança, este perfil utiliza a mesma técnica aplicada nas java applets: uma aplicação não pode acessar nenhum servidor externo ao seu domínio. Na versão mais atual (MIDP 2.0), já disponibiliza os mesmos recursos de segurança que a J2SE. Com esta tecnologia, a mesma portabilidade que a Sun ofereceu ao mercado de computadores está oferecendo aos dispositivos móveis, facilitando o desenvolvimento de software e a abrangência destes em nível de compatibilidade de dispositivos Visual Studio.NET Criada pela Microsoft ela possibilita, entre outras aplicações práticas de desenvolvimento, criar aplicativos para dispositivos móveis. Haddad (2004a) afirma que com o Visual Studio.NET é possível criar uma aplicação para executar em telefones celulares ou diretamente em um navegador. Para desenvolver um aplicativo para dispositivos móveis no Visual Studio.NET, além desta ferramenta é necessário ter instalado um SDK chamado Mobile Internet Toolkit 1.0 da Microsoft, além de um simulador para testes como o Microsoft Mobile Emulator 3.0, porém, existem outros simuladores disponíveis no mercado, inclusive de fabricantes de dispositivos celulares como a Nokia e a Ericsson.

46 45 Com esse conjunto de ferramentas o Visual Studio.NET se transforma em uma framework completo para desenvolvimento de aplicativos para celulares. Para facilitar a identificação e utilização dos recursos suportados por este tipo de dispositivos, ao instalar o SDK é disponibilizado uma caixa de ferramentas com todos os componentes disponíveis para o desenvolvimento. A linguagem de programação utilizada para desenvolvimento poderá ser Visual Basic.NET, Visual C# ou ASP.NET (HADDAD, 2004b). Com esta facilidade, desenvolvedores de soluções em Visual Studio.NET têm um grande potencial para atuar também nas áreas de telefonia celular. Para este trabalho, será adotado o Visual Studio.NET com o SDK 3.0 e Simulador da BREW, desenvolvendo assim o protótipo que foi proposto. Estas são apenas algumas das tecnologias disponíveis no mercado. Será dedicado o capitulo seguinte ao estudo da plataforma que será utilizada para este trabalho: a Plataforma BREW da Qualcomm.

47 46 3 BREW 3.1 VISÃO GERAL A Plataforma BREW 2 é uma proposta da fabricante Qualcomm que visa realizar a integração total da cadeia de soluções para aplicações móveis no que se diz respeito a dispositivos compatíveis, desenvolvimento de aplicativos, distribuição e faturamento de aplicativos, com a segurança necessária para todos os envolvidos. Considerando que esta proposta garanta também a satisfação dos usuários de serviço móvel, a solução da Qualcomm busca também aumento da receita média por usuário das operadoras, chamada de ARPU (Average Revenue Per User). A Qualcomm (2002) afirma que a plataforma BREW (Binary Runtime Environment for Wireless), ambiente binário de tempo de execução para aplicativos sem fio) da QUALCOMM e o BREW Distribution System (BDS, sistema de distribuição do BREW) fornecem a única tecnologia comercial e sistema de negócios que pode atender a esses requisitos. Estas características fizeram com que 45 operadoras em 25 países adotassem a BREW como solução para fornecer aplicativos aos usuários (QUALCOMM,2005). Entre elas está a VIVO, operadora de telefonia celular que atua no Brasil e possui mais de 38% do mercado nacional (ANATEL, 2005b). No caso específico da VIVO, ela disponibiliza o Vivo Downloads, um site na Internet ( que permite aos seus clientes visualizar os aplicativos disponíveis, que também pode ser feito diretamente pelo celular, fornecendo informações como preço e disponibilidade, além de orientações de como adquirir os aplicativos via celular. 2 Plataforma BREW (Bynary RunimeEnvironment for Wireless) disponível em

48 47 No entanto, para que um dispositivo móvel tenha suporte a BREW ele necessita ter um chipset compatível com a plataforma. A fabricante Qualcomm disponibiliza os chipsets da série MSM TM (Mobile Station Modem) compatível com BREW. Outros fabricantes já caminham para compatibilizar seus chipsets com a plataforma BREW. (QUALCOMM,[ ]). Mesmo com essa restrição é verificado nos sites das operadoras de celular que utilizam BREW a grande variedade de aparelhos e fabricantes que fazem uso de chipsets compatíveis. Para entender melhor como se dá esta integração de ponta a ponta, serão apresentados os componentes da plataforma BREW. 3.2 BREW DISTIBUTION SYSTEM Como visto no capítulo anterior, existe no mercado algumas tecnologias voltadas para desenvolvimento de aplicações para dispositivos móveis, entre elas a BREW. No entanto, a Qualcomm foi ainda mais longe: definiu e implementou uma forma de distribuição chamada de BDS (BREW Distribution System). O BDS é responsável pelo comércio eletrônico entre desenvolvedores e operadoras, pela distribuição do software, por garantir a instalação deste software no celular do usuário, além da arrecadação e distribuição dos valores entre as partes envolvidas: Qualcomm, desenvolvedor e operadoras de celular. Antes de mostrar as características básicas do BDS, é importante entender como um aplicativo desenvolvido pode ser incluído no mercado. Para isso, uma das características desta plataforma é que para se tornar um desenvolvedor e fornecedor de soluções para BREW, não basta saber projetar e implementar, é preciso ser certificado. Para isso, é necessário que o fornecedor de soluções possua uma certificação digital classe III fornecida pela entidade certificadora VeriSign 3. A partir da certificação ele deverá se registrar na Qualcomm como desenvolvedor certificado para poder usufruir das ferramentas e documentações disponibilizadas pela empresa e no NSLT (National Software Testing Laboratory), instituição que realiza exaustivos testes nos aplicativos a pedido das operadoras (QUALCOMM, 2002). Com a garantia de que o aplicativo a ser oferecido está de acordo com as premissas básicas, estes são incluídos no BDS. Nele um mercado virtual é disponibilizado para operadoras e 3 Entidade certificadora VeriSign disponível em

49 48 desenvolvedores realizarem a compra e venda de aplicativos certificados, criando um relacionamento direto entre operadoras e desenvolvedores, onde estes definem um valor para os aplicativos. Após a compra pela operadora, ela disponibiliza os aplicativos para seus clientes, através de um servidor de downloads da plataforma (QUALCOMM,2002). O BDS possibilita a integração com o sistema de faturamento da operadora, facilitando o processo de cobrança por parte dela, já que esta plataforma faz também o controle para garantir que um software vendido foi efetivamente entregue e instalado com sucesso no dispositivo móvel do usuário final. A cada venda efetuada, a receita é dividida entre a operadora, o desenvolvedor e a Qualcomm, ou seja, o aplicativo é pago somente após a devida venda para o usuário final. Este repasse aos desenvolvedores é realizado trimestralmente. Na figura 9 é apresentado de forma sucinta como é o modelo de negócios promovido pelo BDS. É possível verificar que, por se tratar de um mercado virtual para todas as operadoras que fazem uso da plataforma atualmente, os desenvolvedores acabam disponibilizando seus aplicativos para um mercado mundial, facilitando a abertura de mercado para novos desenvolvedores. Figura 9: Modelo de negócio integrado do BDS. Fonte: QUALCOMM (2003a).

50 49 No caso de existir a necessidade de atualização de software do dispositivo móvel, a plataforma gerencia também esta ação, permitindo que a operadora e fabricantes de telefones celulares o façam através da interface aérea, sem a necessidade de realizar esta atualização em pontos autorizados, dando mais comodidade aos seus clientes, reduzindo custos. A plataforma BREW está posicionada de forma incomparável a capacitar os aplicativos móveis do futuro, ao mesmo tempo em que suporta as tecnologias e os requisitos de negócio da indústria da telefonia móvel. (QUALCOMM, 2002, p.25). Como o foco deste trabalho é analisar com mais detalhes a parte de desenvolvimento de aplicativos para a plataforma BREW, será apresentada então as partes que compõe o BREW SDK (Software Development Kit). 3.3 BREW SDK (SOFTWARE DEVELOPMENT KIT) O ponto importante para uma solução integrada e padronizada é a compatibilidade dos dispositivos móveis. Inicialmente, o caminho encontrado pelos fabricantes de hardware foi a possibilidade de ter um sistema operacional dentro de um dispositivo móvel. Algumas experiências foram efetuadas, porém, os custos dos aparelhos se tornaram uma barreira para o sucesso desta estratégia (QUALCOMM, 2002). Nesta área a BREW atua como uma camada de abstração, integrada diretamente a unidade de processamento do dispositivo, em memória RAM e flash, fornecendo uma conexão de software entre as funções de baixo nível do processador e os aplicativos desenvolvidos. Necessitando de apenas 150 KB para ser funcional, esta abstração elimina a necessidade dos desenvolvedores se preocuparem com o dispositivo para qual estão implementando a solução e sim no projeto e desenvolvimento da mesma, além de promover uma alta portabilidade e compatibilidade entre dispositivos móveis. O desenvolvimento de aplicativos para estes dispositivos é baseado na linguagem de programação C/C++. Segundo a Qualcomm (2002), existe no mundo cerca de 7 milhões de desenvolvedores em C/C++ que, tendo um conhecimento mínimo telefonia celular, podem atuar nesta área. Um outro ponto que merece destaque é o fato desta plataforma possuir suporte a J2ME, o que amplia mais ainda número de potenciais desenvolvedores. Isto é possível graças ao desenvolvimento de uma máquina virtual Java (JVM Java Virtual Machine), conhecidas também como VM (Virtual Machine) que roda sobre o BREW,

51 50 possibilitando todas as vantagens de integração também para aplicativos J2ME. A Qualcomm (2003b) ainda afirma que essas MVs podem ser transferidas pelo ar e provisionadas automaticamente em um aparelho telefônico com o cliente BREW 2.0 (presumindo-se que o dispositivo de destino tenha memória suficiente), o que significa esforço e custo zero para o fabricante de aparelhos, que pode ter aparelhos telefônicos Java no mercado simplesmente comercializando telefones baseados no BREW 2.0. Para realizar o desenvolvimento de aplicações para a plataforma BREW se faz necessário conhecer alguns conceitos básicos Relação entre classes, módulos e aplicação Todas as funcionalidades disponíveis na SDK e as que você cria estão disponíveis dentro de classes. Neste contexto, existem classes que são disponibilizadas pela versão da SDK normalmente da memória ROM do dispositivo - e as que você cria para desenvolver a aplicação. A aplicação necessariamente deve possuir uma classe que será implementada a partir da interface definida pela classe IApplet, que possibilitará iniciar a aplicação e processar os eventos do sistema e solicitações do usuário, já que a programação utiliza orientação a eventos (RISCHPATER, 2003). Um módulo possui a definição das classes e a implementação das interfaces utilizadas para a criação da aplicação. Toda aplicação recebe uma identificação única, chamada de ID, que é um inteiro de 32 bit. Para fins de comercialização, você tem que ser um desenvolvedor certificado pela Qualcomm, que fornecerá o ID para sua aplicação que será única dentre todas as aplicações registradas e comercializadas. É possível, porém, para desenvolver uma aplicação como teste você mesmo informar um ID para sua aplicação. Com base no ID, é criado um arquivo de definição em linguagem C que deve ser salvo no arquivo da aplicação com a extensão.bid (BREW ID). Após os passos de criação do código fonte da aplicação, deve-se então compilar para que seja executada no dispositivo móvel. Existe, basicamente, duas formas: gerando um arquivo DLL através do Visual Studio.NET ou utilizando o compilador ARM da Qualcomm e gerando arquivos de módulos com extensão.mod.

52 MIF(Module Information File) e o BAR(BREW Applet Resourse) O MIF é um arquivo de definições que informa ao BREW dados como ID da aplicação, ícone, nome da aplicação, além de outras informações como o autor do aplicativo. Para criar um arquivo de definição MIF, é utilizado o BREW MIF Editor disponível com o SDK. Existe também o BAR que é utilizado para informar alguns recursos que a aplicação utilizará como caixas de diálogo, ícones e strings específicas da aplicação, além de dados referente a portabilidade entre dispositivos. A criação deste arquivo é feita a través da ferramenta BREW Resourse Editor.(RISCHPATER, 2003) SDK disponíveis Ao se pensar em desenvolver um aplicativo para um dispositivo que suporte BREW, deve-se escolher qual SDK é mais adequado às necessidades. A BREW possui atualmente cinco especificações de SDK: 1.0, 1.1, 2.0, 2.1, 3.0 e 3.1. Cada uma das SDKs disponibilizam uma série de recursos que atende determinados dispositivos móveis, conforme uma Data Sheet de dispositivos disponíveis. É importante ressaltar que uma SDK com mais recursos sempre trará consigo os recursos de todas as outras anteriores. Exemplificando, se o desenvolvedor adotar a SDK 2.0, subentende-se que esta já possui seus recursos particulares além dos disponíveis para a SDK 1.0 e 1.1. (QUALCOMM, 2004). Junto com o SDK, são disponibilizadas algumas ferramenta: SDK Device Configuration: Permite configurar o Simulador para se comportar de acordo com os recursos e funcionalidades de uma determinada versão de SDK a qual se deseja projetar e implementar uma aplicação. SDK BREW Emulator: Também conhecido como Simulador, emula o dispositivo móvel em um PC para facilitar os testes das aplicações. BREW MIF Editor: Utilizado par criar e editar os arquivos MIF (Module Informatino File) que contém informações sobre as classes e módulos que devem ser suportados pela aplicação, além do identificador único da classe chamado de BID (Brew IDentfication).

53 52 BREW Resource Editor: Utilizado par criar e editar os arquivos BAR (BREW Application Resource) que contém informações sobre recursos adicionais da aplicação como ícones, algumas strings próprias para a solução e caixas de diálogos. BREW Simulator: Veio para substituir o BREW Emulator incorporando também o SDK Device Configuration. Este recurso está disponível somente na versão SDK 3.0. É possível em um mesmo ambiente de desenvolvimento ter varias versões de SDK instaladas. O que o sistema faz é instalar cada uma em um diretório e na hora que for iniciar o desenvolvimento, deverá ser especificado em qual versão deseja desenvolver. No próximo item será explanado os passos básicos para o desenvolvimento de um aplicativo simples. Agora será apresentado como prepara um ambiente para o desenvolvimento de aplicativos para a plataforma BREW. 3.4 PREPARANDO O AMBIENTE PARA DESENVOLVIMENTO Um ambiente de desenvolvimento para a plataforma BREW necessita basicamente de um SDK e um ambiente de desenvolvimento em C/C Requisitos mínimos Para que se possa ter um SDK disponível em um PC para o desenvolvimento de aplicações, é necessário que o microcomputador possua as características mínimas de software (QUALCOMM, 2004): Internet Explorer 5.5 SP2 ou superior com suporte a criptografia de 128 bits Sistema operacional Windows NT 4.0, Windows 2000 ou Windows XP Possuir privilégio de administrador do ambiente Instalando o SDK O primeiro passo é a instalação do BREW SDK que está disponível gratuitamente no site da BREW em onde encontra-se todas as versões de SDK disponíveis. Para instalar, basta escolher a versão desejada de acordo com os recursos que serão utilizados no desenvolvimento e seguir os passos conforme descrito no

54 53 site. É importante observar que o BREW SDK é instalado de forma on-line, sendo premissa para tal estar conectado a internet no momento da instalação, pois, o sistema é transferido por meio da internet para a máquina local e instalado, não disponibilizando em nenhum momento uma opção para download 4 do arquivo e posterior instalação do SDK. Para o protótipo implementado, que será apresentado no decorrer deste trabalho, foi instalado o BREW SDK que compreende as bibliotecas necessárias, o Simulador para testar as aplicações e o BREW MIF Editor e BREW Resource Editor que possibilita configurar as características básicas da aplicação e recursos respectivamente. Nesta versão, todos os recursos da plataforma estão disponíveis. Para utilizar o ambiente de desenvolvimento, deverá ser especificada uma variável de ambiente chamada BREWDIR que contém o caminho onde está instalado o SDK. Normalmente no momento da instalação esta configuração é feita automaticamente, mas, nos casos onde possui mais de um SDK instalado, pode ser necessária alguma alteração. Exemplificando, se for desenvolver para um SDK 3.1, deverá ir até o Painel de Controle do Windows e acessar o ícone Sistema (no caso do Windows XP) na aba Avançado e clicar no botão Variáveis de ambiente (figura 10). 4 Transferência de arquivos da internet para o microcomputador local.

55 54 Figura 10: Tela de configuração do sistema. Na tela de configuração de variáveis, basta editar o caminho que está definido na variável BREWDIR para o que se deseja, conforme figura 11.

56 55 Figura 11: Tela de configuração de variáveis de ambiente. Após estes passos o ambiente já possui o suporte BREW necessário para o desenvolvimento, bastando instalar uma ferramenta de desenvolvimento C/C Preparando o Visual Studio.NET O próximo passo é instalar o ambiente de desenvolvimento propriamente dito. Para o este trabalho, será utilizado o Visual Stúdio.NET Se ainda não estiver instalado no microcomputador, deve-se primeiro realizar tal instalação. O Visual Studio não possui suporte nativo a projetos para aplicações BREW, no caso o BREW Application Wizard que facilita o processo de desenvolvimento para a plataforma. Para instalar este recurso deverá ser instalado o BREW Add-Ins 3.0 for Visual Studio que está disponível em A instalação é similar ao BREW SDK e todas as considerações feitas para a instalação do SDK são válidas para este, exceto na necessidade de configuração do BREWDIR.

57 56 A partir deste momento, ao iniciar um novo projeto no Visual Stúdio por meio do menu File - > New. -> Project, estará disponível a opção BREWAppWizard, como mostra a figura 12.. Figura 12 : Ambiente configurado e com o BREWAppWizard disponível Está finalizada a configuração do ambiente integrado de desenvolvimento de aplicativos para a plataforma BREW baseado no Visual Studio.NET 2003 e BREW SDK 3 (3.1.3). É possível a utilização de outras ferramentas de desenvolvimento em C/C++ e fazer uso do BREW SDK, desde que esta ferramenta seja capaz de compilar e gerar uma DLL Windows (QUALCOMM, [ b]). No entanto o conjunto escolhido é prático e de fácil execução. A mesma configuração foi efetuada com o Visual C da Microsoft e os resultados foram os

58 57 mesmos, havendo apenas algumas alterações de telas. Com o ambiente configurado, será apresentada a criação de um novo projeto. 3.5 CRIANDO UMA APLICAÇÃO BREW Como foi apresentada no item anterior, a figura 12 mostra a tela para iniciar o desenvolvimento de uma nova aplicação BREW. Nesta deverá ser informado o nome para a nova aplicação na caixa de texto Name e em Location o diretório base onde será salvo todos os arquivos do novo projeto. Para este exemplo será utilizado univali para o Name e C:\projetos para Location, que ao final do processo será criada a estrutura de diretórios C:\projetos\univali Após informar o nome da aplicação e diretório base do projeto, será apresentada a tela a seguir para a definição dos recursos que serão suportados pela aplicação: Figura 13: Recursos que a aplicação fará uso. Definidos os recursos em General Settings, na opção Options (figura 14) possibilita iniciar o BREW MIF Editor e selecionar se deseja ou não que o wizard gere o arquivo inicial do projeto com comentários padrão que auxiliam no início do desenvolvimento.

59 58 Figura 14: Tela Options O BREW MIF Editor obrigatoriamente deverá ser executado para realizar a configuração básica da aplicação. Caso ele não seja iniciado automaticamente quando o botão MIF Editor for pressionado, poderá ser iniciado por meio do menu Iniciar do Windows em Programas, BREW SDK Tools MIF Editor Configurando a aplicação É por meio do MIF Edito que a aplicação será configurada, definindo os privilégios necessários para acessar os recursos, o BID que é o identificador da aplicação, o nome da aplicação, a categoria a qual ela pertencerá e o ícone que será apresentado para o usuário no menu de aplicativos do celular, no nosso caso, do simulador. A tela principal do BREW MIF Editor é apresentada na figura a seguir.

60 59 Figura 15: BREW MIF Editor O primeiro passo para configurar a aplicação é a definição da applet que pode ser feita clicando no New Applet em List of Applets defined in this Module. Pressionando este botão será apresentado a tela de configuração do BID. Como explanado no neste capítulo, o BID é o BREW Identified que identifica uma aplicação. Para a aplicação ser comercializada é necessário ser desenvolvedor autorizado BREW e esta identificação é fornecida pela Qualcomm. No entanto, é possível informar um BID local para o desenvolvimento e teste da aplicação no Simulador. É importante ressaltar que em não será possível instalar esta aplicação em um dispositivo móvel devido ao BID não ser oficial. Para se definir um BID local, basta selecionar a opção Locally e informar um Class ID e um Class Name. Na figura abaixo foi informado o Class ID 0xABCDE123 e o Class Name univali.

61 60 Figura 16: Informando um Class ID local Definido o Class ID será solicitado o diretório onde será salvo o BID (arquivo.bid). Salve-o no mesmo diretório da aplicação que será desenvolvida, neste exemplo será no diretório C:\projetos\univali. Caso esta estrutura não exista, crie. Concluindo este passo, será informado o nome da aplicação e o ícone que será associado à aplicação conforme figura abaixo.

62 61 Figura 17: MIF Editor - Configuração da aplicação Além destas configurações, deverá ser definida no MIF Editor na aba Privileges quais recursos a aplicação deverá ter acesso. Estes privilégios devem estar de acordo com o que foi informado na tela apresentada na figura 12 onde foram selecionados os recursos que deverão estar disponíveis no ambiente de desenvolvimento, ou seja, informamos o que será utilizado no desenvolvimento e depois damos privilégio para a aplicação utilizar os recursos na execução. A configuração está finalizada. Para salvar o arquivo com as definições da aplicação deverá ser selecionada a opção Save no menu File do MIF Editor e salvar um arquivo com extensão mfx (Module Information Resource) no mesmo diretório dos projetos, neste caso no C:\projetos será salvo o arquivo univali.mfx, que é um arquivo XML. Depois de salvo é necessário compilar o arquivo com as definições que será feito pelo menu Build e Compile MIF Script que gerará um arquivo com o mesmo prefixo do arquivo mfx, mas com a extensão mif que é um arquivo binário das configurações. Fechar o MIF Editor e clicar em Finish do wizard.

63 62 A partir deste ponto o ambiente de desenvolvimento estará com a estrutura básica de nossa aplicação, disponibilizando 3 arquivos criados automaticamente pelo wizard: univali.c, AEEAppGen.c e o AEEAppMod.c. Os dois últimos possuem ainda seus arquivos de recursos, ou header como são conhecidos na linguagem C/C++, que são incluídos ao projeto por meio da diretiva #include no conteúdo do arquivo univali.c Univali.c comentado A seguir será apresentado o código fonte do arquivo univali.c visando detalhar um pouco mais o desenvolvimento através de comentários deste código. É necessário ter uma base de programação na linguagem C. /*======================================================================= FILE: univali.c =======================================================================*/ /*======================================================================= INCLUDES AND VARIABLE DEFINITIONS ====================================================================== */ #include "AEEModGen.h" // Definições da interface do módulo #include "AEEAppGen.h" // Definições da interface Applet #include "AEEShell.h" // Definições da interface Shell #include "univali.bid" // Arquivo com o ClassID /* Estrutura da Applet. Todas as variáveis dentro da estrutura são referenciadas por "pestrutura->variável" */ typedef struct _univali { AEEApplet a ; // Primeiro elemento da estrutura deve ser AEEApplet AEEDeviceInfo DeviceInfo; // permitir acesso às informações dos dispositivos (hardware) IDisplay *pidisplay; // permite acesso à interface Display de uma forma padrão IShell *pishell; // permite acesso à interface Shell de uma forma padrão // Aqui você pode adicionar suas variáveis! univali; /* Function Prototypes */ static boolean univali_handleevent(univali* pme, AEEEvent ecode, uint16 wparam, uint32 dwparam); boolean univali_initappdata(univali* pme); void univali_freeappdata(univali* pme); /*======================================================================= FUNCTION DEFINITIONS ====================================================================== */ /*======================================================================= FUNCTION: AEEClsCreateInstance. Método necessário para todas as aplicações. Instancia a aplicação em memória e gera o evento ETV_APP_START =======================================================================*/

64 63 int AEEClsCreateInstance(AEECLSID ClsId, IShell *pishell, IModule *po, void **ppobj) { *ppobj = NULL; if( ClsId == AEECLSID_UNIVALI ) { // Cria a Applet e prepara a estrutura desta. if( AEEApplet_New(sizeof(univali), ClsId,pIShell,po,(IApplet**)ppObj, (AEEHANDLER)univali_HandleEvent, (PFNFREEAPPDATA)univali_FreeAppData) ) // a função FreeAppData é chamada depois de enviar o evento // ETV_APP_STOP para o HandleEventfunction { //Inicializa os dados da Applet antes de // enviar o e EVT_APP_START para o HandleEvent if(univali_initappdata((univali*)*ppobj)) { //Dados inicializados com sucesso return(aee_success); else { // Libera a Applet, liberando a memória alocada // quando o método AEEApplet_New for requisitado. IAPPLET_Release((IApplet*)*ppObj); return EFAILED; // Fim da AEEApplet_New return(efailed); /*========================================================================= FUNCTION univali_handleevent. Esta função tem a finalidade de tratar os eventos que ocorrem durante a execução da aplicação. Ele é criado automaticamente pelo Wizard. Abaixo segue um exemplo. =========================================================================*/ static boolean univali_handleevent(univali* pme, AEEEvent ecode, uint16 wparam, uint32 dwparam) { switch (ecode) { // Aplicação iniciando case EVT_APP_START: // Aqui você coloca o código referente à ação! return(true); // Aplicação está sendo finalizada case EVT_APP_STOP: // Aqui você coloca o código referente à ação! return(true); // Aplicação foi colocada em modo suspenso case EVT_APP_SUSPEND: // Aqui você coloca o código referente à ação! return(true); // Aplicação está retornando do modo suspenso case EVT_APP_RESUME: // Aqui você coloca o código referente à ação! return(true); // Um SMS foi entregue para a aplicação.

65 64 // A Mensagem é passada através do parâmetro dwparam como um //(char *) case EVT_APP_MESSAGE: // Aqui você coloca o código referente à ação! return(true); // Uma tecla foi pressionada. O parâmetro wparam traz a // informação da tecla que gerou o evento. // Os códigos das teclas estão em AEEVCodes.h. // Um exemplo: código "AVK_1" refere-se a tecla "1" precionada case EVT_KEY: // Aqui você coloca o código referente à ação! return(true); // Se nenhuma das condições forem satisfeitas, encerra o // processamento desta função. break; return FALSE; // Esta função é chamada quando a aplicação é iniciada boolean univali_initappdata(univali* pme) { // Coleta as informações referentes ao telefone. // Referencia todos os dados da estrutura da // seguinte forma: pme->deviceinfo // Verifica se o dispositivo é compatível com a API necessária. pme->deviceinfo.wstructsize = sizeof(pme->deviceinfo); ISHELL_GetDeviceInfo(pMe->a.m_pIShell,&pMe->DeviceInfo); // As interfaces referentes ao Shell e Display sempre são criados por // default, possibilitando acessá-las através do "pme->" sem o "a." pme->pidisplay = pme->a.m_pidisplay; pme->pishell = pme->a.m_pishell; // Neste ponto você pode colocar seu código alocando os recursos // necessários // Não ocorrendo nenhuma falha, retornará sucesso na execução return TRUE; // Esta função é chamada quando a aplicação está sendo finalizada void univali_freeappdata(univali* pme) { // Insira seu código aqui para desalocar os recursos utilizados, // liberando-os da memória. // Exemplo para liberar cada interface //if ( pme->pimenuctl!= NULL ) // Verifica se não é nula //{ // Libera a interface //IMENUCTL_Release(pMe->pIMenuCtl) // Seta para NULL evitando problemas // caso haja a tentativa de liberar novamente //pme->pimenuctl = NULL; // /*====== Fim do código =====================================*/ Por se tratar de um código fonte em linguagem C, verifica-se que, com exceção da função AEEClsCreateInstance, todas as funções possuem um parâmetro declarado como univali * pme que aponta para a estrutura da aplicação. Com isso, todo o acesso a recursos da aplicação

66 65 é efetuado através deste ponteiro. Logo, em todas as funções que serão criadas pelo desenvolvedor necessitam deste ponteiro caso a função necessite interagir com alguma parte da estrutura como alteração de tela, acesso a rede, informações sobre o dispositivo móvel etc. Após o sistema ter sido compilado, será gerado um arquivo DLL no diretório definido para o projeto, no nosso caso em C:\projetos\univali. Para garantir que o arquivo DLL será gerado no diretório do projeto deverá ser verificada a configuração nas opções no menu Project e selecionar Properties. Na janela que aparece deverá ir a Linker no item Debug e as caixas de texto Generate Debug Info e Generate Program Database File deverão estar configuradas como mostra a figura a seguir: Figura 18: Configurando o modo Debug no Visual Studio Sempre que um novo projeto é criado esta configuração deve ser feita se desejar utilizar os recursos de depuração do Visual Studio. Após esta configuração, para se realizar a depuração da aplicação ao selecionar a opção de debug pela primeira vez o Visual Studio solicitará qual aplicativo será responsável por executar tal DLL. Deverá ser selecionado o arquivo BREW_Simulador.exe que se encontra

67 66 no diretório bin onde foi instalado o SDK. Exemplificando, se o SDK utilizado for o 3.1.3, ele provavelmente estará em C:\Arquivos de programas\brew 3.1.3\bin\, considerando um microcomputador com o sistema operacional Windows XP Professional no idioma português (Brasil). Além da definição de onde se encontra o BREW Simulator, no simulador deve-se informar o diretório onde estão os arquivos mfx criados, neste caso no diretório de projetos C:\projetos. Esta configuração é realizada por meio da opção Change Applet Dir.., informando diretório do projeto conforme figura abaixo: Figura 19: Configuração do simulador É bom ressaltar também que, dependendo dos recursos que serão utilizados pela aplicação, deverá ser habilitado no simulador para utilizá-los, como a conexão a transmissão de dados para realizar uma conexa à Internet. Isso pode ser feito por meio do menu Tools do BREW Simulator. Além dos privilégios, esta opção permite também simular a potência do sinal de rede, carga de bateria, selecionar o tipo de rede que está sendo utilizada (GSM, CDMA, UMTS), a taxa de transferência, entre outros. 3.6 PROTÓTIPO: CONTROLE REMOTO PARA RESIDÊNCIA Muito se ouve falar nas casas do futuro. Uma das características destas casas é o controle total através de controle remoto, dando mais comodidade aos moradores. Uma tendência mundial é a conectividade à internet através das conexões chamadas de Banda Larga, onde se tem uma conexão à Internet 24 horas, além da evolução tecnológica exposta no capítulo 2 que apresentou os rumos da telefonia celular focando cada vez mais em comunicação de dados.

68 67 Serão exploradas estas tendências de mercado para aplicar em um protótipo alguns dos recursos disponíveis na plataforma BREW: interface com usuários, conexão de dados por meio do celular e manipulação de arquivos. Para isso será apresentado e desenvolvido um protótipo para fazer do telefone celular um controle remoto para residências, onde será utilizada a conectividade à internet via celular acessando um software que simulará um servidor instalado em uma residência e conectado via banda larga a internet. A figura a seguir ilustra a idéia do controle remoto: Internet Figura 20: Controle remoto via celular Por meio de um software instalado em um celular, o proprietário de uma residência dotada de conexão Banda Larga e um servidor com capacidade para ligar e desligar pontos de energia poderá de qualquer lugar que possua o serviço móvel celular disponível, verificar o estado dos pontos de controle e até mesmo alterar seus estados (ligar/desligar). Imaginemos que o proprietário chegará mais tarde em casa e, por este motivo, ele poderá ligar uma lâmpada externa ou interna para deixar o ambiente iluminado, ou até mesmo acionar o ar-condicionado em um dia quente para que, ao chegar a casa, encontre o ambiente climatizado e confortável. Na área de segurança, poderá verificar se não esqueceu o alarme residencial desligado ao sair para uma viagem e ativá-lo caso tenha esquecido. Para o protótipo proposto, o servidor será simulado através de um software, porém, para um produto comercial deverá haver além de um software em um microcomputador uma interface (hardware) que permita controlar os pontos desejados. A evolução para este modelo seria um periférico com software embarcado que dispense a utilização de um microcomputador para executa a função de servidor.

69 68 A seguir será apresentada a modelagem do sistema cliente que será utilizado no celular e que é o foco dos estudos deste trabalho Modelagem do protótipo Visando atuar no foco deste trabalho, será apresentada a modelagem do protótipo que será executado no celular, no nosso caso no BREW Simulador. Figura 21: Casos de uso A seguir será visto o detalhamento de cada caso de uso acima indicado.

70 69 Tabela 6: Caso de uso: Configurar sistema Nome do Caso de Uso Configurar sistema Caso de uso geral (include) Nenhum Ator principal Usuário Ator secundário Servidor Resumo Descreve os passos necessários para o usuário configurar a conexão com o host Servidor. Pré-condição Nenhuma Pós-condição Configuração armazenada em arquivo Fluxo base Ações do Ator Ações do Sistema 1. Exibe configurações atuais 2. Informa endereço IP do servidor 3. Informa a porta do Servidor 4. Confirma alterações 5. Sistema armazena as alterações em um arquivo de configuração Fluxo Alternativo No passo 4 o usuário cancela a operação Não executa o passo 5

71 70 Tabela 7: Caso de uso: Conectar no servidor Nome do Caso de Uso Caso de uso geral (include) Ator principal Ator secundário Resumo Pré-condição Pós-condição Ações do Ator Conectar no servidor Nenhum Usuário Servidor Realizar a conexão do software cliente (celular) com o servidor via conexão Socket Stream. Nenhuma A conexão é estabelecida Fluxo base Ações do Sistema 1. Verifica se a configuração foi efetuada 2.Realiza a conexão com o servidor de acordo com as configurações 3. Exibe menu principal e a mensagem Conectado! Fluxo Alternativo 1 No passo 1, caso a configuração não tenha sido efetuada, informa a mensagem Configuração inválida para o usuário. Executa o passo 3 Fluxo Alternativo 2 No passo 2, caso a conexão não seja estabelecida exibe a mensagem Falha na conexão. Executa o passo 3

72 71 Tabela 8: Caso de uso: Verificar estados dos pontos de controle Nome do caso de uso Caso de uso geral (include) Ator principal Ator secundário Resumo Pré-condição Pós-condição Ações do Ator Verificar estados dos pontos de controle Nenhum Usuário Servidor Descreve como o sistema fará para solicitar ao servidor a lista de pontos de controle e seu estado atual (ligado ou desligado) O sistema Cliente deve estar conectado ao Servidor A lista de pontos com seus estados deverão estar disponíveis na tela do celular. Fluxo base Ações do Sistema 1. Solicita ao Servidor a lista de pontos de controle e seus estados 2. Sistema exibe na tela a lista de pontos e seus estados Fluxo alternativo No passo 2 não há pontos configurados no Servidor. Exibir a mensagem: Não há pontos configurados no servidor.

73 72 Tabela 9: Caso de uso: Alterar estado de um ponto de controle Nome do caso de uso Ligar / desligar pontos de controle Caso de uso geral (include) Verificar estados dos pontos de controle Ator principal Usuário Ator secundário Servidor Resumo Permite ao usuário ligar / desligar pontos controlados pelo servidor Pré-condição O sistema Cliente deve estar conectado ao Servidor Pós-condição A lista de pontos com seus estados deverão estar disponíveis na tela do celular com os estados atualizados. Fluxo base Ações do Ator Ações do Sistema 1. Solicita ao Servidor a lista de pontos de controle e seus estados 2. Exibe na tela a lista de pontos e seus estados 3. O usuário navega pelos pontos listados e pressiona a tecla Select para alterar estado do ponto 4. Solicita ao servidor a mudança do estado do ponto selecionado 5. Atualiza o estado do ponto selecionado na tela do celular 6. O usuário seleciona a opção Sair Fluxo alternativo No passo 6 o Usuário poderá voltar ao passo 3 caso deseje alterar o estado de outro ponto de controle Com base nos casos de uso identificados, será apresentado os diagramas de seqüência para implementar os casos de uso acima apresentados.

74 Diagrama de classes de domínio O diagrama abaixo apresenta as classes de domínio identificadas para a implementação do protótipo. EA 5.0 cd Unregistered Data Model Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered ControleRemoto Tela Menu EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered 1 EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered EA 5.0 Unregistered Trial Version EA 0..* 5.0 Unregistered Trial Version EA 5.0 Unregistered 1 Conexao Pontos EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered EA 5.0 Unregistered Trial Version EA 5.0 Unregistered Trial Version EA 5.0 Unregistered 1 1 Figura 22: Diagrama de classes de domínio

75 Diagramas de seqüência Utilizando a mesma ordem dos casos de uso, segue os diagramas de seqüência para implementar a aplicação cliente. Figura 23: Diagrama de seqüência: Configurar Sistema O diagrama acima mostra a seqüência necessária para realizar a conexão ao servidor responsável pelo controle da residência.

76 75 Figura 24: Diagrama de seqüência: Conectar ao servidor Neste diagrama é apresentada a seqüência que o sistema deverá realizar para se conectar ao servidor remoto. Ao final será apresentada para o usuário uma tela do resultado da tentativa de conexão.

77 76 Figura 25: Diagrama de seqüência: Ligar / desligar ponto de controle Neste diagrama estão compreendidos os casos de uso Verificar estados dos pontos de controle e Ligar / desligar pontos de controle Implementando o protótipo Com base na especificação acima, será apresentado alguns pontos principais da implementação. O código fonte completo da aplicação encontra-se no anexo 1. Para adaptar o desenvolvimento estruturado às especificações realizadas em UML, as funções que representam os métodos de uma determinada classe serão precedidos do nome da classe. Exemplificando, as funções responsáveis pela conexão par conectar ao servidor será

78 77 conexao_conectar(). Isto foi necessário devido a algumas restrições encontradas e detalhadas no capítulo 4. Visualizando o código fonte no anexo 1 fica mais clara esta adaptação. Todos os recursos do BREW SDK estão disponíveis em estruturas de dados, interfaces que manipulam estas estruturas e tipos de dados específicos da plataforma. Exemplificando, para manipular a tela do celular se utiliza a estrutura de dados do tipo IDisplay onde utilizamos o método da interface IDISPLAY_DrawText() para escrever na tela um texto que deve ser do tipo AECHAR exclusivo para a plataforma BREW. Serão expostos a seguir alguns dos recursos utilizados na aplicação e que são importantes para o entendimento de como é o desenvolvimento e o comportamento das aplicações na plataforma BREW. A documentação de todos os recursos disponíveis é instalada no microcomputador juntamente com o BREW SDK, porém, estaremos utilizando apenas alguns deles para exemplificar a utilização destes. Para tal, todos os exemplos abaixo serão baseados na na struct da linguagem C definida a seguir que é praticamente a mesma do univali.c do anexo 1. typedef struct _univali { AEEApplet a; // Instância o IApplet AEEDeviceInfo DeviceInfo; // Permite o acesso as informações do dispositivo IDisplay *pidisplay; // Acesso os recursos do Display (IDisplay) IShell *pishell; // Acesso as funcionalidades de Shell INetMgr *pinetmgr; // Gerenciador de conexões de rede ISocket *pisocket; // Conexão socket IMenuCtl *pimenuctl; // Recurso de menu ITextCtl *pitextctl // Recurso de caixa de texto char *bufferin // Buffer utilizado para armazenar os dados // recebidos pela conexão socket char *bufferout // Buffer utilizado para armazenar os dados a //serem enviados pelo socket univali; Outro ponto importante a salientar é que no desenvolvimento em C (estruturado) em todas as funções do sistema possuirá um parâmetro univali * pme, que será a instância da aplicação e será por meio desta que teremos acesso a todos os recursos definidos na struct univali. Quando for executada alguma ação no display, por exemplo, para se acessar o ponteiro do display deverá ser chamada pme->pidisplay (pme é a aplicação e pidisplay uma variável da struct).

79 Arquitetura do ambiente A figura abaixo apresenta a arquitetura do ambiente de desenvolvimento e simulação. Figura 26: Arquitetura do ambiente de simulação O ambiente é composto por dois microcomputadores que formam uma rede local baseada em ethernet e conectados por meio de um HUB 10/100baseT. O protocolo utilizado pela conexão entre as máquinas foi o TCP/IP. No microcomputador da esquerda foi preparado o ambiente de desenvolvimento, bem como o de simulação do telefone móvel celular provido pelo BREW Simulator. No segundo computador foi implementado o simulador da residência com o software que simula o servidor que recebe a conexão do cliente instalado no celular e faz a ativação e desativação dos pontos de controle Interface IShell: Controlando a aplicação A interface IShell é a responsável por iniciar e parar uma aplicação, instanciar classes / estruturas e tratar eventos da aplicação como o pressionar de uma tecla. A IShell poderá ser utilizada para instanciar as estruturas de interface com o usuário como a ITextCtl que permite ler um texto digitado pelo usuário. Para realizar esta ação, utiliza-se a seguinte função disponível na interface IShell: ISHELL_CreateInstance(IShell * pishell, AEECLSID cls, void * * ppobj). Em pishell é passado o Shell instanciado na aplicação, no caso de nosso exemplo seria pme->ashell. Por padrão toda a estrutura de uma aplicação base em BREW possui um ponteiro do tipo IShell com o nome pishell. No caso da struct univali, pode-se verificar esta situação onde á foram declaradas as variáveis com as estruturas para IDisplay e IShell, sendo *pidisplay e *pishell respectivamente.

80 79 O parâmetro AEECLSID refere-se ao tipo de estrutura também chamada de classe pela plataforma que será instanciada. Na documentação da API do SDK estão todas os AEECLSID disponíveis, no caso de um ITextCtl será a AEECLS_TEXTCTL. O parâmetro ppobj é o ponteiro para a variável do tipo ITextCtl que receberá a estrutura criada, no nosso caso poderá ser pme->pitextctl ou uma variável teste tipo declarada dentro da função em execução. No código fonte univali.c, vimos que após iniciar uma aplicação é chamada por padrão da plataforma a função static boolean univali_handleevent(univali* pme, AEEEvent ecode, uint16 wparam, uint32 dwparam) quando ocorre um evento no aparelho celular. Este evento pode ser o pressionar de uma tecla, uma mensagem SMS (Short Message Service) destinada para a aplicação entre outras. Esta função é tratada pela interface IShell, onde por meio dos parâmetro da função pode-se identificar qual evento ocorreu e tratá-lo de forma adequada. Exemplificando, caso o usuário pressione uma tecla, será gerado um evento onde o parâmetro ecode será passado a informação EVT_KEY e no param wparam a informação AVK_9 que corresponde a tecla 9 do telefone. Mais a frente será visto como tratar eventos de seleção de um item de menu e como estas informações são identificadas nesta função Interface IDisplay: Manipulado a tela do celular. Esta interface é responsável pelas ações na tela como desenhar, escrever textos, exibir menus, entre outras. Para limpar a tela do celular pode-se usar a função IDISPLAY_ClearScreen(IDisplay * po) onde é passado no parâmetro o display da estrutura da aplicação. Exemplificando, ao invocar o univali_handleevent após iniciar a aplicação (parâmetro ecode igual a EVT_APP_START) poderá incluir o comando IDISPLAY_ClearScreen(pMe->pIDisplay). O pme é repassado para a função univali_handleevent por parâmetro Interfaces INetMgr e ISocket: Criando uma conexão Socket Stream (TCP) A plataforma BREW disponibiliza estas duas interfaces que permite aos desenvolvedores utilizarem recursos de conexão que antes eram vistos somente em microcomputadores. Para a aplicação utilizar tais recursos é necessário que esta tenha privilégios para acesso a rede de

81 80 dados (ver capítulo 3.5.1). A INetMgr é responsável por gerenciar a rede, possibilitando criar uma conexão socket por meio da conexão de dados disponíveis nas redes de telefonia celular. Para criar um gerenciador do tipo INetMgr deve-se utilizar a interface IShell da mesma forma que apresentamos no capítulo para criar um ITextCtl, onde o AEECLSID será o AEECLSID_NETMGR. Além disso, na estrutura da aplicação, deverá conter uma variável do tipo INetMgr * e que será passada para a ISHELL_CreateIntance pelo parâmetro ppobj, no caso da struct univali será a pme->pinetmgr. Disponibilizado o gerenciador, por meio dele é possível criar o socket do tipo ISocket utilizando a função conforme exemplo abaixo: ISocket socket = INETMGR_OpenSocket(pMe->pINetMgr, AEE_SOCK_STREAM); É possível criar um socket do tipo UDP alterando o parâmetro que define o tipo de AEE_SOCK_STREAM para AEE_SOCK_DGRAM. Caso seja criado um socket com sucesso retornará o ponteiro em socket. Caso contrário socket será NULL. O próximo passo é realizar a conexão com o servidor. Antes de mais nada, deve-se observar que todos os dados transferidos e recebidos além da ação de conexão são não bloqueantes e assíncronos. Esta conexão é efetuada pela interface ISocket conforme apresentado a seguir. É importante a análise do código e seus comentários para entender como ela funciona. boolean conexao_conectar(univali * pme) { int resultado; // variável temporária para armazenar o resultado dos comandos // Faz a conversão do endereço IP para o padrão INAddr INAddr addr = conexao_converttoinaddr( ); // Cria um socket do tipo stream pme->pisocket = INETMGR_OpenSocket(pMe->pINetMgr,AEE_SOCK_STREAM); // Se criou o socket, tenta a conexão. if (pme->pisocket){ // Repare que é passada uma função conexao_connectcallback como parâmetro resultado = ISOCKET_Connect(pMe->pISocket, addr,aee_htons(5000), conexao_connectcallback,(void*)pme); // Retorna verdadeiro, porém, se a conexão foi efetuada com sucesso ou não // será tratado pela função conexao_connectcallback return TRUE; else{ // Falha na criação do socket return FALSE; // Se o resultado é um erro diferente do AEE_NET_WOULDBLOCK, // ocorreu um erro na função conexao_connect

82 81 if (resultado && (resultado!= AEE_NET_WOULDBLOCK)) { int erro = ISOCKET_GetLastError(pMe->pISocket); return FALSE; else if (resultado!= AEE_NET_WOULDBLOCK){ // Conexão OK! return TRUE; // Por padrão retorna erro return FALSE; Percebem-se três características básicas: O endereço de destino (endereço IP) não é do tipo string e sim do tipo INAddr. A função que realiza esta conversão está no código fonte univali.c em anexo; A porta também não é um inteiro e sim um tipo específico da plataforma, no caso o tipo INPort. A função AEE_htons faz a conversão de int para INPort; Se não ocorrer nenhuma falha nesta função, o sucesso ou não da conexão é tratado pela função conexao_connectcallback e é chamada de forma assíncrona. Quando a tentativa de conexão for finalizada, a aplicação chamará a função conexao_connectcallback passada como parâmetro para INETMGR_OpenSocket. Por padrão a conexao_connectcallback deve possuir os seguintes parâmetros: void * puser, int nerror. Em puser será passada a instância da aplicação que poderá ser acessada realizando um type cast para univali (nossa struct). No parâmetro nerror será repassado o código referente ao erro ou sucesso da conexão. Para realizar a escrita ou leitura de dados o mesmo deverá ser feito para tratar os comandos por meio de funções chamadas na plataforma de Call Back, com uma pequena diferença que é o fato da interface ISocket tentar enviar ou ler ela encaminha como o parâmetro da função de call back NULL. Se nesta tentativa retornar um erro AEE_NET_WOULDBLOCK, ele fará uma nova tentativa agora passando a função de call back. Vejamos no exemplo a seguir. boolean conexao_escreve(univali * pme){ // Variável para tratar o resultado int resultado; // Verifica se o socket está instanciado if (!pme->asocket) return TRUE;

83 82 //Cancela a função callback referente a escrita ISOCKET_Writeable(pMe->pISocket, NULL, NULL); // Verifica o tamanho dos dados a serem escritos resultado = strlen(pme->bufferout); // Tenta escrever os dados resultado = ISOCKET_Write(pMe->pISocket, pme->bufferout, strlen(pme->bufferout)); // Se ocorreu erro if (resultado == AEE_NET_ERROR){ // Falha no envio return FALSE; //Não ainda não enviou os dados if (resultado == AEE_NET_WOULDBLOCK){ //Associa uma função call back a escrita ISOCKET_Writeable(pMe->pISocket, conexao_writecallback,(void*)pme); else{ // Se já enviou os dados return TRUE; Como visto será realizada a tentativa de envio dos dados sem a utilização da função de call back. Se necessário, será associada uma função, no caso do exemplo conexao_writecallback, para tratar o call back. Neste caso específico significa que o socket ainda não está preparado para enviar os dados, então, ao chamar a função de call back deverá ser submetida a função conexao_escrever novamente. Nesta segunda tentativa o envio será efetuado com sucesso sem a necessidade da função call back,ou seja, após o ISOCKET_Write resultado terá SUCESSO. Por este motivo que o buffer de entrada e saída ficam na struct, já que necessitamos dos dados para enviar ou ler novamente no tratamento do callback da leitura e escrita. No código fonte univali.c estão todas as funções de envio e recebimento dos dados com suas respectivas funções de call back e comentários que podem servir de auxílio para um melhor esclarecimento desta função. Esses são as funções e requisitos básicos para a utilização do recurso de socket. Vale ressaltar que tanto na configuração da aplicação realizada pelo desenvolvedor por meio do MIF Editor, quando no BREW Simulator deverão ter os privilégios adequados para utilizar estes recursos.

84 Interfaces IFileMgr e IFile: Manipulando arquivos Para que uma aplicação consiga manipular arquivos é necessário também que esta tenha tal privilégio. Pra isso, basta indicar esta permissão no momento da configuração da aplicação como que é feita por meio do BRE MIF Editor, conforme apresentado no capítulo A manipulação de arquivos nesta plataforma está dividida nas interfaces IFileMgr e IFile. A IFileMgr é um gerenciador de arquivos que permite às aplicações criar, apagar e renomear arquivos e diretórios no dispositivo móvel. A estrutura de diretórios que a plataforma utiliza são (QUALCOMM, 2005): fs:/ : É o diretório raiz; fs:/~/ : Diretório referente a onde está aplicação corrente; fs:/sys/ : Local onte está instalado o sistema BREW. Vale lembrar que estes celulares não possuem um sistema operacional e sim recursos disponíveis nos chipsets; fs:/mod/ : Diretório onde estão os arquivos referentes aos módulos que provem as interfaces dos recursos; fs:/mif/ : Local onde estão os arquivos.mif que são os dados básicos do sistema e que é gerado pelo BREW MIF Edigdor; fs:/shared/ : Este local pode ser utilizado para compartilhar arquivos com outras aplicações. Pode-se dizer que é um diretório publico para todos os aplicativos do celular; fs:/address/ : Aqui estão todos os contatos armazenados na agenda do telefone fs:/ringers/ : Local onde são armazenados os arquivos com os toques; fs:/card0/ : Disponível na versão BREW 3.1, neste diretório é possível acessar dados de um cartão de memória removível como um MMC (MultiMedia Card); fs:/~<clsid>/ : Disponível também na versão BREW 3.1, é possível acessar o diretório de uma aplicação especifica através de seu Class ID. Exemplificando, no caso da aplicação univali, seu Class ID é o AEECLSID_UNIVALI. O diretório da aplicação univali poderá ser acessado através do fs:/~aeeclsid_univali/; Além do caminho onde se encontra o arquivo desejado, ele poderá ser aberto em três modos diferentes: somente leitura (_OFM_READ), leitura e escrita (_OFM_READWRITE) ou ainda leitura e escrita a partir do fim do arquivo (_OFM_APPEND). Além destes, existe ainda o modo _OFM_CREATE que é utilizado para criar um arquivo novo. A seguir seque o exemplo

85 84 de como utilizar estes recursos. No univali.c também foram utilizados para armazenar as configurações de conexão ao servidor. Para criar um gerenciador devemos ter uma valiável do tipo IFileMgr. Pode ser declarada como IFileMGr *filemgr e instanciá-lo conforme abaixo: ISHELL_CreateInstance(pMe->pIShell,AEECLSID_FILEMGR,(void **)&filemgr); Após estar criado poderemos declarar e criar uma variável arquivo como por exemplo IFile *file e abrir o arquivo com o comando: file = IFILEMGR_OpenFile(fileMgr, fs:/~/univali.cfg, _OFM_READWRITE); Veja que será aberto o arquivo univali.cfg que está no diretório da aplicação (fs:/~/) e o parâmetro _OFM_READWRITE indica que ele será aberto para leitura e escrita. Se o arquivo não existir, file conterá NULL. Deverá então ser criado o arquivo, se assim desejar, com o mesmo comando, porém, com o parâmetro _OFM_CREATE e na seqüência aberto com o mesmo comando e parâmetro _OFM_READWRITE. A escrita pode ser executada por meio do comando IFILE_Write(file,buf,sizeof(char)*strlen(buf)) onde buf contém os dados e é do tipo char*. A leitura utiliza-se o comando IFILE_Read(file,buf,numChar) onde o buf é do tipo char* e o numchar é o número de caracteres a serem lidos do arquivo. Finalizada a manipulação do arquivo poderá ser fechado o arquivo com o comando IFILE_Release(file) e, se julgar necessário, o gerenciador com IFILEMGR_Release(fileMgr) Recursos visuais criados por meio do BREW Resource Editor Existe disponível na plataforma BREW alguns recursos visuais como textos, figuras, menus e componentes de diálogos de forma fácil e rápida. O BREW Resource Editor permite ao desenvolvedor incluir recursos destes tipos de uma forma mais prática e ágil. A tela principal do Resource Editor é apresentada abaixo:

86 85 Figura 27: BREW Resource Editor Como pode ser percebido, existem quatro tipos de recursos disponíveis: Strings: são textos previamente especificados. Normalmente eles são utilizados para definir o título de uma tela, ou de um menu, textos estáticos que serão exibidos na tela, descrição de itens de menu, entre outros; Objects: são diferentes tipos de objetos como uma imagem ou um arquivo no formato html; Binaries: algum recurso que já foi gerado em outra aplicação e deseja-se importar, como uma tela padrão de usuário e senha, por exemplo; Dialogs: são os diálogos propriamente ditos com o usuário do celular, como por exemplo uma nova tela de entrada de dados como um texto a ser enviado via SMS. Ao criar um destes recursos, todos têm em comum dois atributos: seu ID e Name. O ID será um número designado automaticamente pela ferramenta e o Name o programador é quem irá identificá-lo. Para criar um novo recursos, basta ir no menu Resource e selecionar o tipo desejado. A figura a seguir mostra um recurso do tipo string criado.

87 86 Figura 28: Criando um recurso Pode-se verificar que o ID deste recurso chamado de STR_TITULO é o 1001, designado pela própria ferramenta, porém, possibilita a edição que não é aconselhável. O conteúdo deste recurso é a frase Olá UNIVALI. Depois de criado os recursos desejados, deverá salvar os recursos no mesmo diretório onde está sendo desenvolvida a aplicação e compilado os recursos que gerará dois arquivos: um com extensão.brh e outro.bar. O.brh será feito o include deste na aplicação e o.bar contém os recursos já compilados, ou seja, no formato binário. Como acessar estes recursos será apresentado no tópico seguinte que faz uso de menu por através da interface IMenuCtl baseado em recursos do tipo string criados com o BREW Resource Editor Criando e manipulando menus (IMenuCtl) Para criar e manipular menus a plataforma disponibiliza a interface IMenuCtl. É por meio desta interface que pode ser criados menus de 4 tipos (QUALCOMM,2005):