Transmissão de dados através de telefonia celular ... · Transmissão de dados através de telefonia ... Rua Inconfidentes, 395, Primavera, 93340-140, Novo Hamburgo, RS, Brasil

Transmissão de dados através de telefonia celular:avaliação de desempenho de uma conexão

de dados utilizando GPRSRodolfo Pedó Pirotti1Marcos Zuccolotto2

Resumo

Com o aumento da utilização dos serviços de transferência de dados utili-zando a infra-estrutura da telefonia celular, novas possibilidades se abrirampara algumas aplicações, especialmente aquelas em que é aceitável certalatência na transferência de dados e determinada taxa de erros, mas quenecessitam de uma cobertura de sinal ampla. Sendo GSM a tecnologiamais difundida no mundo e dispondo do serviço GPRS para a transferênciade dados, este artigo, apresentado como a sequência do artigo Transmissãode dados através de telefonia celular: arquitetura das redes GSM e GPRS(PIROTTI; ZUCCOLOTTO, 2009), propõe uma metodologia para determi-nar o desempenho de uma conexão de dados ponto a ponto na rede GPRS.O texto detalha a execução dos testes propostos e apresenta os resultadosobtidos na aplicação desta metodologia na avaliação do serviço GPRS deduas operadoras.

Palavras-chave: GPRS. Avaliação de desempenho. Telemetria.

Abstract

Due to the increase of data transmission using mobile phone networks, new

possibilities were created to some applications, specially when a delay or a

non-zero error rate are acceptable, and a good signal coverage is needed.

The most used mobile phone network in Brazil is the GSM network, which

offers the GPRS service to data transmission. So, this article, presented

as a sequence of Transmissão de dados através de telefonia celular: arquite-tura das redes GSM e GPRS (PIROTTI; ZUCCOLOTTO 2009), proposes

tests to evaluate the GPRS service performance. The text shows the details of

the proposed tests and the results.

Keywords: GPRS. Performance evaluation. Data transmission.

1 Engenheiro Eletricista. Engenheiro de Desenvolvimento da Elster Medição de Energia Ltda. Artigo baseado parcialmente em monografia apresentadapara obtenção do diploma de Engenheiro Eletricista na Universidade do Vale do Rio dos Sinos – UNISINOS, 2008. E-mail <[email protected]>

2 Mestre em Engenharia Elétrica – UFRGS. Professor do curso de Engenharia Elétrica – UNISINOS e do Curso Técnico em Eletrônica – Fundação EscolaTécnica Liberato Salzano Vieira da Cunha. Rua Inconfidentes, 395, Primavera, 93340-140, Novo Hamburgo, RS, Brasil. Email <[email protected]>

Recebido em 29/05/09 e aceito em 02/08/09.

188

Pirotti, R. P., Zuccolotto, M.

Revista Liberato, Novo Hamburgo, v. 10, n. 14, p. 187-199, jul./dez. 2009

1 IntroduçãoO uso dos serviços da telefonia celular

para transferência de dados tem se tornadocada vez mais viável e atrativo. Em aplicaçõesde sistemas de telemetria, gerenciamento dedistribuição e consumo de energia elétrica,gás, água e automação comercial, o uso deredes com longo alcance (preferencialmentesem fio) e com infraestrutura já existente setorna interessante, evitando o custo de insta-lação de uma infraestrutura de transmissorese receptores em diversos locais. Neste ponto,a transmissão de dados utilizando as redesde telefonia celular torna-se interessante eatrativa por já possuir uma infraestrutura ins-talada e com cobertura abrangente.

A tecnologia mais difundida no Brasilcomo padrão para telefonia celular é a tecno-logia GSM (Global System for Mobile Com-

munications). Dentro das redes de telefoniaGSM, foi posteriormente desenvolvido o ser-viço GPRS (General Packet Radio Service),que permite uma taxa de transmissão teóricade até 171 kbits/s, e o serviço EDGE (Enhan-

ced Data rates for Global Evolution) com umataxa máxima teórica de 473,6 kbits/s. Recen-temente, foi lançado também o serviço cha-mado 3G (utilizando as tecnologias UMTS,HSDPA e outras). O 3G torna-se interessantequando se deseja trafegar grandes volumes dedados. Para pequenos volumes, que é o casodas aplicações citadas, o GPRS e o EDGE tor-nam-se mais acessíveis, sendo utilizados emampla gama de aplicações.

No artigo intitulado Transmissão de da-dos através de telefonia celular: arquitetura dasredes GSM e GPRS (PIROTTI; ZUCCO-LOTTO, 2009), foi realizada uma apresenta-ção da arquitetura das redes GSM e GPRS,abordando e descrevendo os elementos exis-tentes na rede e os principais conceitos envol-vidos. Este estudo teórico fundamenta o pre-sente artigo que propõe um conjunto de tes-tes a serem realizados numa conexão de da-dos GPRS para avaliar seu desempenho econfiabilidade do serviço, uma vez que é um

serviço de transmissão de dados oferecido porempresas cujo maior foco, atualmente, é atransmissão de voz. Por se tratar de uma redesem fio, o serviço GPRS está suscetível a di-versos fatores como qualidade do serviçoprestado pela operadora de telefonia, cober-tura disponível, quedas de sinal, atrasos derede, entre outros. Detalhes dos procedi-mentos de implementação de uma conexãoGPRS são apresentados, seguidos da descri-ção da estrutura e software desenvolvidos paraa realização dos testes. Ao final do trabalho,são avaliados os serviços de conexão de da-dos GPRS de duas operadoras de telefoniaatravés da metodologia proposta.

2 Arquitetura da rede GPRSUma rede de telefonia celular é composta

por diversos elementos interligados entre siatravés de canais de comunicação. Cada ele-mento possui uma função distinta, como en-viar o sinal de RF até um telefone celular oubuscar numa base de dados, se o usuário quesolicitou uma chamada tem autorização paraisto. Esses elementos são instalados de acordocom a região de cobertura e as necessidadesda operadora de telefonia celular. A figura 1resume, de forma gráfica, a arquitetura e oselementos da rede GPRS.

Figura 1 – Arquitetura rede GPRS

Em Pirotti e Zuccolotto (2009) foi apre-sentado um estudo da arquitetura e dos ele-mentos de rede das redes GSM e GPRS, des-crevendo os principais conceitos e elementos.Recomenda-se consulta a este trabalho parauma melhor compreensão da terminologiautilizada a seguir.

MS

189Revista Liberato, Novo Hamburgo, v. 10, n. 14, p. 187-199, jul./dez. 2009

Transmissão de dados através de telefonia...

3 Estabelecendo uma conexãode dados

Para uma troca de dados na rede GPRS,é necessário um terminal GPRS, que é umequipamento capaz de utilizar os serviços darede. Os também chamados modems GPRSpossuem o hardware para a comunicação RF,além do suporte à GSM e GPRS de acordo comas normas GSM, sendo configurados e utiliza-dos através de comandos AT.

Um modem GPRS, para estar apto a tro-car dados na rede, precisa executar algunsprocedimentos, realizados através de coman-dos AT, definidos pelas normas GSM, espe-cialmente as referenciadas por European

Telecommunications Standards Institute (2003;2001; 2000). Uma vez concluído, os elemen-tos da rede identificam o modem e permitemo seu acesso.

Para utilizar os serviços da rede GPRS,como transferência de dados, é necessário regis-trar-se na rede. A partir deste evento, os ele-mentos da rede passam a trocar informações epermitir a ativação de alguns serviços porparte da MS (SVERZUT, 2005; EUROPEANTELECOMMUNICATIONS STANDARDSINSTITUTE, 2000). A figura 2 ilustra a sequên-cia de procedimentos de registro.

Figura 2 – Procedimentos na rede GPRS

O registro na rede GPRS é realizado atra-vés do procedimento de GPRS Attach, que fazcom que o SGSN efetue o registro da MS narede, buscando sua identificação e trocandoinformações com outros elementos da redepara validar o procedimento. Feito isto, a MSpossui um enlace lógico com o SGSN, e umgerenciamento de mobilidade é estabelecidotanto na MS como no SGSN.

O comando para realizar o procedimentode attach ou deattach na rede GPRS é o co-mando +CGATT.

A seguir, a MS necessita ativar um con-texto PDP (Packet Data Protocol) para iniciara transferência de dados (SVERZUT, 2005;EUROPEAN TELECOMMUNICATIONSSTANDARDS INSTITUTE, 2000).

Um contexto PDP possui informaçõesa respeito da transferência de dados na rede,como o IP da MS, a APN em uso, dentre ou-tras. Primeiro, deve-se definir um contexto PDPe após, ativá-lo. Estes procedimentos são reali-zados através dos comandos +CGDCONTe +CGACT.

Na figura 3, é demonstrado o exemplo deum attach na rede, e logo após é realizada umadefinição de contexto (comando +CGDCONT)e sua ativação (comando +CGACT).

Figura 3 – Execução do comando +CGACT

3.1 Seleção da operadora

A norma GSM prevê dois comandos es-pecíficos para seleção e registro da operadoraGSM, os comandos +COPS e +CREG.

O comando +COPS pode ser usado paraverificar o modo de seleção e a operadoraatualmente selecionada ou para forçar saídada rede.

Na figura 4, há um exemplo da execuçãodo comando +COPS. Primeiro, foi realizadouma saída forçada da rede. Logo após, foi defi-nida a busca automática pela operadora; apósisto, um comando de leitura para verificar quaisoperadoras estão acessíveis à MS e, por fim,um comando para verificar em qual opera-dora o módulo estava conectado (porém nãoregistrado).

É possível verificar, na resposta ao co-mando de leitura AT+COPS=?, o seguinte es-tado para as operadoras.

190



Figura 4 – Execução de comandos de seleção de operadora

O comando +CREG serve para verificaro estado da MS na rede GSM (se está registra-do em operadora local ou em roaming, porexemplo), e também para configurar a indi-cação de mudanças no registro da rede (como,por exemplo, uma queda da rede) através deURC (Unsolicited Result Code), que pode serusado como um evento em linguagens de pro-gramação para detectar estas mudanças.

4 Plataforma de desenvolvimentoA plataforma escolhida para o desenvol-

vimento experimental foi o módulo TC65, fa-bricado pela Siemens/Cinterion. O móduloTC65 é um modem GPRS com diversos peri-féricos integrados e suporte à linguagem Java(J2ME), tornando possível o desenvolvimentode aplicações e sua execução no TC65, contan-do com a interface GPRS e protocolos TCP eIP já embarcados.

Para a codificação em Java foi utilizado oambiente Eclipse SDK 3.1.2, conforme espe-cificado na documentação fornecida pelaSiemens/Cinterion.

A antena utilizada para os testes é umaantena omnidirecional da marca Aquario, mo-delo GM-1007, que apresenta um ganho de7 dBi.

4.1 Modem Siemens/Cinterion TC65

O modem da Siemens/Cinterion TC65é um modem com suporte a GSM e GPRS.Voltado a aplicações para transferência de da-dos ou voz sob GSM ou GPRS, apresenta as

características: suporte a Java J2ME (IMP 2.0),GSM quad-band (850/900/1800/1900 MHz),processador ARM7, memória flash de 1,7 MBe memória RAM de 400 KB, pilha TCP/IP inte-grada com acesso através de comandos AT ouJava, suporte aos protocolos TCP, UDP, HTTP,FTP, SMTP, POP3, GPRS multislot classe 12e coding scheme de 1 a 4.

5 Desenvolvimento da aplicaçãoO software, codificado em Java com ori-

entação a objeto, foi organizado em classes,para facilitar seu desenvolvimento e enten-dimento. As classes foram criadas de acordocom sua funcionalidade, oferecendo os méto-dos necessários para integração com o restan-te do software. Para o desenvolvimento do có-digo utilizou-se o ambiente Eclipse, e o pro-jeto (Workspace) recebeu o nome de Comuni-cacaoGprs. As classes criadas são apresen-tadas na figura 5.

Tabela 1 – Resposta do comando +COPS

Figura 5 – Classes desenvolvidas no software

A classe KPrincipal estende a classeMIDlet, sendo responsável pela inicializaçãoda aplicação e pelo gerenciamento da execu-ção. Na inicialização do software, os procedi-

odatsE arodarepoadotxeT arodarepoadogidóC)CNMeCCM(

adanoicelesarodarepO-2 oralC 50427

levínopsidarodarepO-1 lisarBMIT 40427

levínopsidarodarepO-1 raluleCTrBARB 61427



mentos indicados pelo fluxograma da figura 6são realizados para garantir que a rede GPRSestá disponível, e o servidor para troca de da-dos está ativo.

Figura 6 – Fluxograma básico classe KPrincipal

A classe KGprs possui os métodos paraverificação da rede GPRS e configuração domódulo TC65. Um dos métodos desta classe,VerificaRedeGprs(), é chamado logo na inicia-lização da aplicação e realiza o seguinte fluxopara garantir que a rede GPRS está disponível:

Figura 7 – Fluxograma do método VerificaRedeGprs

Essas etapas são realizadas utilizandoos comandos AT da norma GSM +COPS,+CGATT, +CGACT, +CGDCONT e +CREG.Com esses passos, ao final do método, é pos-sível ter a certeza de que a rede GPRS estádisponível.

Outros dois métodos foram implementa-dos para exibir informações sobre a célula naqual o modem está registrado, bem como asinformações das células das quais ele conse-gue captar sinal. Esta informação é útil nomomento de uma instalação em campo, paradetectar se o sinal está adequado, posicionar aantena da melhor forma possível e avaliar ascondições do sinal da operadora utilizada.Por exemplo, caso o sinal esteja baixo ou compoucas células vizinhas, pode ser recomen-dável optar por outra operadora de telefoniacelular, ou então utilizar uma antena commaior ganho.

É importante cuidar também a existênciade várias células com níveis de sinal muito pró-ximos. Isto pode fazer com que o modem tro-que repetidamente de célula, causando, even-tualmente, erros de transmissão nos dados emalgum momento, os denominados erros dehandover, de acordo com Benko (2004).

A classe KSyncAtCommand estendea classe ATCommand (desenvolvida pelaSiemens / Cinterion), possui apenas um mé-todo utilizado para envio de comandos AT aomódulo.

A classe KConSerial contém os métodospara uso da porta serial do modem TC65. Estaclasse foi desenvolvida para uso no teste detempo de tráfego da rede GPRS.

A classe KConSocket implementa osmétodos para manipulação da conexão socket

com o servidor o envio e a recepção de dadose montagem dos blocos de dados a serem en-viados, sendo a principal classe para a troca dedados na rede GPRS. Todos os métodos neces-sários para o envio e recebimento de dados estãonesta classe.

A classe KRelogio possui apenas doismétodos, um para ajuste e outro para leitura dorelógio interno do modem GPRS e foi desen-volvida para ser utilizada no teste de taxa de

192



transferência, para cálculo do tempo de envio,em segundos.

A classe KThreadTesteDelayRede, comojá indicado no nome, estende uma classeThread e foi desenvolvida para o teste de tem-po de tráfego.

A classe KThreadVerificacaoSinal, aexemplo da anterior, é uma classe que estendea classe Thread, e foi criada para que seja possí-vel monitorar o sinal GSM da célula de serviçoe das células próximas, podendo ser usada tantona inicialização da aplicação para verificar osinal no local de instalação do modem GPRS,como durante a execução da aplicação, paramonitorar possíveis quedas de sinal.

6 Desempenho da rede GPRSEmbora a rede GPRS possua uma capaci-

dade teórica de até 171 kbits/s como taxa detransferência para uma MS, na prática estacondição dificilmente é atingida. Diversos fato-res afetam a taxa máxima de transferência,como a capacidade de timeslots de cada MS, acondição de coding scheme suportada, o nívelde sinal e o tráfego existente nos elementos queformam a rede GPRS. Além disto, uma redeGPRS é uma rede menos homogênea que umarede por fio, apresentando oscilações de desem-penho também em função da interface aérea(BENKO, 2004).

Algumas pesquisas já foram realizadaspara determinar de diferentes formas algumascaracterísticas da rede, como tempos de atra-so, taxa de erros e outras.

Benko (2004), através da análise do ca-beçalho do protocolo TCP no ponto onde osdados saem do GGSN para a internet e che-gam da internet para o GGSN, apresenta estu-dos envolvendo o tempo de estabelecimentode uma conexão TCP na rede GPRS, o tempoque um pacote de dados leva ao sair da MSaté chegar ao GGSN, além de análises dethroughput e perda de pacotes e o efeito daalteração do tamanho do pacote de dados TCP.

Um dos estudos analisou o tempo neces-sário para o estabelecimento de uma conexãoTCP entre uma MS e um servidor localizadona internet. Em mais de 11 mil conexões, a

maior parte levou em média 1 segundo paraocorrer, porém com os piores casos ficandoentre 5 e 10 segundos.

Já o levantamento para medir o tempode trânsito de um pacote de dados entre a MSe o GGSN indicou que mais da metade dasconexões analisadas gastaram mais de 1 segun-do (com máximo em torno de 2 segundos) paraque o pacote chegasse ao GGSN.

Quanto ao levantamento da perda de pa-cotes de dados, em 48% dos pacotes analisa-dos ocorreram perdas nos elementos da redeGPRS, enquanto apenas 5% ocorreram nainternet, e em outros 47% não houve erros.

A análise de goodput (termo utilizadopara indicar quantidade de dados transferidoscom sucesso, similar a throughput), indicou amaioria dos casos com velocidade estandoentre 25 e 30 Kbits/s.

Dentre outras análises envolvendo a alte-ração de parâmetros TCP, também realizadasno artigo, a que apresentou maior variação noresultado foi a diferença de goodput entre asconexões com MSS (maximum segment size),considerado como o tamanho do pacote dedados do protocolo IP vistos nas conexões TCP,alto (em torno de 1500 bytes) e baixo (em tor-no de 500 bytes). Os resultados indicaram umgoodput de 20.048 bits/s para pacotes comMSS em 500 bytes, e 24.936 bits/s para paco-tes com MSS em 1500 bytes, o que representauma diferença em torno de 20%.

Já Eronen (2008) realizou um estudo so-bre o tempo em que uma MS com conexãode dados GPRS estabelecida, porém sem trocade dados, fica com seu IP válido na internet.Conforme já visto, o elemento de rede GGSNinterliga as MS’s da rede GPRS à internet. Po-rém, existe o serviço de NAT que gerencia oIP visível na internet e a MS que está utilizan-do aquele IP. Quando uma MS deixa de trocardados, o NAT desaloca aquele IP e atribui aoutra MS.

Em função disso, existe um tempo má-ximo sem transferência de dados na rede, noqual, a partir deste tempo, o serviço NAT consi-dera a conexão como inativa e atribui o en-dereço IP a outra MS, causando uma quedana conexão.



Este tempo é difícil de determinar, poispode variar para cada fabricante de equipamen-to e operadora de telefonia, mas atualmente osvalores típicos são de 30 a 180 segundos parao protocolo UDP e 30 a 60 minutos para o pro-tocolo TCP.

Alguns produtos comerciais conhecidospossuem timeouts para o protocolo TCP de30 minutos (Juniper Netscreen firewall) ouaté 1440 minutos (Cisco IOS router NAT)(ERONEN, 2008).

7 Avaliação do desempenho da redeGPRS

Para avaliação experimental do desempe-nho de um enlace GPRS, propõe-se a execu-ção dos testes descritos a seguir:

7.1 Teste de tempo de tráfego

O teste de tempo de tráfego na rede GPRStem como objetivo verificar quanto tempo umpacote de dados leva para chegar ao seu desti-no a partir do momento em que é enviado pelaMS. Este teste pode ser realizado utilizando aarquitetura apresentada na figura 8.

Figura 8 – Arquitetura para o teste de tempo de tráfego

O teste possui a seguinte estrutura: umcomputador conectado na internet com IPconhecido e conectado através de uma portaserial no modem GPRS TC65, que por sua vezestá conectado a uma rede GPRS. No modemTC65, a aplicação mantém o modem conectadona rede GPRS, ou seja, com os procedimentos

de attach e ativação de contexto já realizados,bem como com uma conexão socket já estabe-lecida com o computador destino. A aplicaçãofica em execução, aguardando o recebimentode um byte pela porta serial, e assim que o rece-be, envia-o imediatamente para o computadorcom IP conhecido, através da rede GPRS e daconexão socket.

O computador possui um software queenvia um byte pela porta serial, registra o horá-rio deste envio e aguarda receber este byte

através da conexão socket estabelecida com omodem TC65, então, registra o horário de rece-bimento. Desta forma, é possível mensurar otempo existente entre o envio do byte pela portaserial e seu recebimento através da conexãosocket. O tempo da conexão serial entre o com-putador e o modem TC65 (inferior a 200ms)pode ser desprezado frente ao tempo de trá-fego da rede GPRS.

7.2 Teste de taxa de transferência

A taxa de transferência teórica em umarede GPRS varia em função da classe da MS edo coding scheme utilizado. Porém, de acordocom Benko (2008), esta taxa, na prática, pos-sui também outras influências, como o nívelde sinal, o tráfego existente na rede e outrosparâmetros utilizados, como tamanho de buf-

fers no protocolo TCP.O objetivo deste teste é obter um valor

médio da taxa de transferência na rede GPRS,dada em kbits/s. Uma observação importantedeve ser feita, quando o modem TC65 enviaum byte de informação, este byte é encapsu-lado pelos protocolos da camada OSI, geran-do a transmissão de um pacote com váriosbytes além do byte de informação. Esta quanti-dade extra de bytes não é abordada neste teste,pois a intenção é medir a taxa de transferênciaefetiva do ponto de vista da aplicação.

Em função do encapsulamento existente,pode-se prever que o envio de um byte por vezpela aplicação tende a ser menos eficiente doque o envio de uma quantidade maior de bytes,pois o efeito dos bytes acrescentados na trans-missão pelos outros protocolos se torna me-nor. Dada esta característica, propõe-se a rea-

194



lização de testes com diferentes tamanhos depacotes de dados.

Para a realização deste teste, a classeKPrincipal do software recebeu um trecho decódigo responsável pelo envio dos dados emedição do tempo necessário para o envio. Amedição de tempo foi realizada utilizando oRTC (Real Time Clock) interno do TC65. Osdados enviados são sempre constantes, pois oobjetivo do teste é apenas medir a taxa detransferência da rede.

No computador, uma aplicação que ape-nas abre uma conexão socket e fica lendo osdados é executada. A arquitetura utilizada parao teste é a mesma apresentada na figura 8.

7.3 Teste de perda de conexão porinatividade

De acordo com Eronen (2008) e Pagonis(2003), o serviço NAT existente no elementode rede GGSN possui um timeout configura-do, caso uma conexão esteja com tempo supe-rior a este sem transferir dados, o NAT derru-ba-a, atribuindo o endereço IP a outra MS.

Este teste foi planejado para verificar ovalor aproximado deste timeout e consiste basi-camente em abrir uma conexão socket com oservidor, mantendo-a inativa por um determi-nado tempo. Após decorrido este tempo, é en-viado um byte para verificar se a conexão ain-da está ativa. Em caso positivo, aumenta-se otempo de inatividade gradualmente, até o mo-mento em que não seja mais possível enviarum byte para o servidor.

Quando não for mais possível enviar osdados, encerra-se o teste, e então é verificadoo último valor de tempo de espera.

7.4 Teste de alteração de parâmetros TCP

O módulo TC65 possui três parâmetrosde configuração da rede TCP que são o objetode estudo deste teste. Os parâmetros são osseguintes:

- Ana Artigo 7 IRT (Initial Retransmission

Timeout): o protocolo TCP possui um métodoadaptativo para determinar o timeout pararetransmissão de pacotes perdidos ou com erro.Este parâmetro define o valor de atraso, em

segundos, para o início da primeira retrans-missão. O protocolo TCP aplica seu métodoadaptativo a partir deste valor, se necessário;

- MR (Maximum Number of Retransmis-

sions): este parâmetro define a quantidade detentativas de comunicação que o protocoloTCP irá fazer caso ocorra falha na primeiratentativa.

- OT (Overall TCP Timer for outstanding

connections): este parâmetro indica o tempode encerramento da conexão, caso os pacotesTCP/IP não recebam confirmação de recebi-mento (acknowledged).

Analisando os testes realizados por Benko(2004), é possível verificar os tempos de atrasonas conexões e perdas de pacotes. Decidiu-se então realizar testes alterando estes parâ-metros e verificando o resultado.

O teste utiliza a mesma arquitetura vistana figura 8, e no computador é executado umsoftware que recebe os dados enviados, contabi-lizando o número de bytes, para conferência.Para o sucesso do teste, a quantidade de bytes

recebidos deve ser igual à quantidade de bytesenviados pelo modem GPRS.

8 Resultados obtidosO teste de tempo de tráfego foi realizado

em duas cidades diferentes e duas operadorasde telefonia para evitar que um problema pon-tual da operadora alterasse o comportamentonormal da rede.

O teste foi repetido diversas vezes, varian-do-se o número de comunicações, bem comointervalo entre elas. Foi considerado erro decomunicação os casos cujo byte enviado pelomodem GPRS, após 1 minuto de espera, aindanão havia retornado ao computador.

Todos os testes, com as diferentes opera-doras, foram realizados dentro do mesmo diae em horários similares, evitando causar dife-renças significativas devido a horários de picoou fim de semana, por exemplo.

A tabela 2 apresenta os resultados obti-dos, onde cada coluna representa:

- N.C.: número de comunicações realiza-das no teste;

- I.C.: intervalo entre cada comunicação;



- Oper.: operadora utilizada;- Loc.: cidade onde foi realizado o teste

(Novo Hamburgo e Cachoeirinha);- Hor.: horário inicial do teste;- Méd.: média geral do tempo medido

entre o envio do byte pelo modem GPRS e orecebimento deste byte no computador desti-no, ou seja, o tempo de tráfego da rede, que éa medição objetivo deste teste;

- D.P.: desvio padrão dos tempos me-didos;

- Máx.: maior tempo medido;- Min.: menor tempo medido;- Erro: indica se o teste foi interrompido

pela ocorrência de algum erro de comunicação.Na tabela 3, encontra-se o resultado geral

dos testes realizados em função da operadorautilizada.

Tabela 2 – Resultados do teste de tempo de tráfego

.C.N .repO )s(.déM )s(.xáM )s(.níM

5271 A 59,3 57,15 12,0

0532 B 20,1 62,2 45,0

Tabela 3 – Resumo dos resultadosdo teste de tempo de tráfego

Os testes mostram que o tempo médioobtido com a operadora de melhor desem-penho é 3,87 vezes menor que a outra, bemcomo o desvio máximo da média foi de 1,24segundos.

O teste de taxa de transferência foi reali-zado utilizando duas operadoras de telefoniacelular diferentes, para efeito de comparação.Cada teste demonstrado a seguir foi realizado4 vezes, e o valor exibido é a média destas 4medições. Para obter medições variadas quan-to ao local, foram realizados testes na cidadede Novo Hamburgo e Cachoeirinha, de acor-do com o indicado na coluna “Local”. Os tes-tes realizados com a operadora B foram emmenor número, em função do custo financei-ro, pois o SIM Card desta operadora possui limi-tação de tráfego de dados mensal.

Na tabela 4, são apresentados os resulta-dos, as colunas da tabela representam:

- Tamanho Total: quantidade total de da-dos enviados pela aplicação ao computador viaconexão socket;

- Tamanho Pacote Divisão: tamanho decada pacote enviado, sendo a divisão em paco-tes realizada pela aplicação;

- Tempo Total: tempo total para o enviodos dados. A resolução disponível é de 1 se-gundo, de acordo com o relógio interno domodem GPRS;

- Taxa de transferência calculada: taxade transferência calculada após o envio dosdados;

- Operadora: indica a operadora utilizadapara o teste.

.C.N C.I )s(. .repO .coL .roH )s(.déM .P.D )s( )s(.xáM )s(.níM orrE

658 1 A HN 61h91 64,2 12,4 57,15 12,0 miS

009 1 B HN 11h02 66,0 90,0 4,1 65,0 oãN

002 3 A HN 45h02 97,1 36,1 60,21 4,0 oãN

002 3 B HN 93h02 49,0 71,0 2,2 75,0 oãN

021 5 A HN 21h12 21,2 43,2 4,81 76,0 oãN

021 5 B HN 82h12 51,1 21,0 62,2 78,0 oãN

01 03 A HN 15h12 7,2 83,2 2,8 90,1 oãN

01 03 B HN 54h12 21,1 3,0 9,1 89,0 oãN

19 1 A HN 40h22 2,21 87,01 3,64 4,0 miS

009 1 B HN 62h22 27,0 12,0 29,1 45,0 oãN

84 5 A HN 53h12 5,7 80,8 4,43 5,0 miS

021 5 B HN 84h12 51,1 11,0 29,1 37,0 oãN

003 1 A HCAC 21h21 70,1 73,0 12,3 18,0 oãN

001 5 A HCAC 62h21 8,1 74,0 67,4 70,1 oãN

001 5 B HCAC 04h21 24,1 22,0 52,2 69,0 oãN

196



A taxa de transferência é calculada daseguinte forma:

Na tabela 5, é apresentado o resumo doteste de taxa de transferência. Foram desconsi-deradas as medições realizadas com 1 kbyte,pois não é possível ter certeza do seu valor,pode-se apenas afirmar que foi superior a8 kbits/s.

Tabela 4 – Resultados do teste de taxa de transferência

arodarepO aidémaxaT

A s/stibk14,5

B s/stibk31,31

Tabela 5 – Resumo geral do teste de taxa de transferência

Os valores medidos para a operadora A,na cidade de Novo Hamburgo, apresentaramuma variação maior em relação à operadoraB. O teste com pacote de dados de tamanho500 kbytes não foi possível realizar com a ope-radora A em Novo Hamburgo, pois a conexãofoi derrubada antes do final do teste em todasas seis tentativas.

O teste de inatividade na rede foi repetido16 vezes, com os intervalos sem envio de da-dos variando entre 5 min, 10 min, 16 min e 30min, e os dados obtidos estão apresentados natabela 6.

etseT ataD arodarepO nim5 nim01 nim61 nim03

1 80/40/22 A KO KO KO KO

2 80/40/22 A KO KO KO KO

3 80/40/32 B KO KO KO orrE

4 80/40/42 A KO KO orrE -

5 80/40/42 A KO KO orrE -

6 80/40/42 A KO KO orrE -

7 80/40/42 A KO KO orrE -

8 80/40/42 A KO KO KO KO

9 80/40/62 A KO KO KO KO

01 80/40/62 A KO KO KO KO

11 80/40/72 B KO KO KO KO

21 80/40/72 B KO KO KO KO

31 80/40/72 A KO KO KO KO

41 80/40/72 A KO KO KO orrE

51 80/40/72 B KO KO KO orrE

61 80/40/72 B KO KO KO KO

Tabela 6 – Resultado do teste de inatividade na rede

latotohnamaT

ohnamaT

etocap

oãsivid

latotopmeT

edaxaT

aicnêrefsnart

adaluclac

arodarepO lacoL

etybk1 setybk46 s1< s/stibk8> A HN

etybk1 setybk215 s1< s/stibk8> A HN

etybk1 etybk1 s1< s/stibk8> A HN

etybk1 etybk1 s1< s/stibk8> B HN

setybk01 setybk46 s32 s/stibk84,3 A HN

setybk01 setybk215 s21 s/stibk76,6 A HN

setybk01 etybk1 s22 s/stibk46,3 A HN

setybk01 etybk1 s5 s/stibk00,61 B HN

setybk001 setybk46 nim6 s/stibk22,2 A HN

setybk001 setybk215 nim4 s/stibk33,3 A HN

setybk001 etybk1 s42nim2 s/stibk65,5 A HN

setybk001 etybk1 s94 s/stibk33,61 B HN

setybk005 etybk1 s40nim01 s/stibk26,6 B HN

setybk01 etybk1 s41 s/stibk17,5 A HCAC

setybk01 etybk1 s5 s/stibk00,61 B HCAC

setybk001 etybk1 s50nim1 s/stibk13,21 A HCAC

setybk001 etybk1 s45 s/stibk18,41 B HCAC

setybk005 etybk1 s03nim11 s/stibk08,5 A HCAC

setybk005 etybk1 s32nim7 s/stibk30,9 B HCAC



O teste de parâmetros TCP foi realizadoatravés do envio de blocos de dados, de100 kbytes cada, e verificado se todos os100 kbytes foram corretamente recebidos nocomputador. O teste foi realizado em doisdias distintos, na cidade de Novo Hamburgo,usando sempre a mesma operadora de tele-fonia celular. Os valores utilizados para osparâmetros IRT e MR do módulo TC65 sãoapresentados na tabela 7, e a tabela 8 apre-senta os resultados:

oãçarugifnoC )s(TRI RM )s(TO

1 1 1 1

2 1 1 04

3 01 02 1

4 01 02 04

Tabela 7 – Valores utilizados para o teste de parâmetros TCP

oãçarugifnoC edlatoTseõçacinumoc ossecuS orrE

1 02 0 02

2 52 61 9

3 02 0 02

4 02 02 0

Tabela 8 – Resultado do teste de parâmetros TCP

9 Considerações finaisVários fatores são determinantes para a

qualidade de uma conexão (PIROTTI; ZUCCO-LOTTO, 2009). Na análise dos elementos derede, foi visto que o serviço APN pode diferen-ciar o acesso dos usuários à rede GPRS, dandoprioridades (utilizando o conceito de QoS) acertos pacotes de dados.

Outra constatação importante foi a exis-tência do serviço NAT, que encerra conexõesinativas por muito tempo, causando a perdado IP em uso pela MS. Isto indica que não éadequado o software manter conexões abertaspor muito tempo. O mais indicado é abrir aconexão apenas no momento de enviar umbloco de dados e, após isto, encerrá-la.

Porém a constatação mais importanteenvolvendo o serviço NAT é a impossibilidadede iniciar a comunicação a partir do computa-dor ou estação fixa, por causa da constantealternância de IP do equipamento GPRS. Para

contornar esta restrição, é necessário imple-mentar um método que faça com que o equi-pamento comunique periodicamente seu en-dereço IP ou utilizar uma VPN (Virtual Private

Network) criada entre o computador destino ea operadora de telefonia celular. Estas soluçõesfogem ao escopo deste estudo.

Já a verificação de falhas em caso deum handover, apontada por Benko (2004),não pôde ser testada, mas foi implementadoum método no software que verifica o nívelde sinal da célula em uso e das células pró-ximas, possibilitando a identificação deste tipode problema. Se esta situação ocorrer no casode uma instalação onde o modem está fixo, amudança do tipo de antena utilizada poderesolver o problema, como uma antena dire-cional do tipo YAGI, apontando a captaçãodo sinal para apenas uma BTS. O uso de even-tos de troca de BTS e alteração de registro narede, habilitados através do comando +CREG,também auxiliam no diagnóstico deste tipode problema.

Outro ponto importante é a possibilidadede uso do serviço de SMS (da rede GSM, quefunciona independente do serviço GPRS), mes-mo não havendo disponibilidade de uso da redeGPRS. Caso a aplicação necessite enviar algu-ma informação importante ao usuário, e a redeGPRS esteja indisponível (procedimentos deattach e ativação de contexto não funciona-rem), ou mesmo se não obtiver acesso ao ser-vidor para envio dos dados, é possível enviarum SMS a um determinado número, avisandoda situação.

Na utilização de determinadas linguagensde alto nível, como Java, a indicação da ocor-rência de erros de comunicação não oferecemuitos detalhes, apresentando mensagens pa-drão como Network Idle Timeout ou então Re-

mote Host has Rejected the Connection. Nocaso dessas mensagens, não é possível desco-brir se a rede GPRS se tornou indisponível, seo serviço NAT encerrou a conexão, se o com-putador destino rejeitou a conexão ou se hou-ve um erro de transmissão causado por umhandover, além de outras possibilidades. Paradetalhar o erro e identificar a causa, é neces-sário o uso dos comandos AT, realizando, por

198



exemplo, o procedimento apresentado no flu-xograma da figura 7, executando os métodosde monitoração de rede implementados naclasse KGprs, ou ativando a indicação de even-tos de troca de BTS, com o comando +CREG.

Com relação aos testes de desempenhoda rede, os resultados foram significativos. Noteste de tempo de tráfego da rede, a ocorrên-cia de tempos superiores a 30 segundos foisurpreendente. Estes atrasos grandes obrigamo desenvolvedor da aplicação a escolher a estra-tégia a ser adotada em relação a timeouts e reten-tativas. Escolhas por grandes valores de time-

outs podem atrasar a comunicação, mas torna-se necessário caso a exigência pela garantia desucesso das comunicações seja grande.

Com relação ao teste de taxa de transfe-rência, a operadora B apresentou uma taxamédia quase 3 vezes superior à operadora A.Além disso, nos pacotes de 10 kbytes e 100kbytes, as taxas medidas para a operadora Bforam muito similares, indicando uma maiorestabilidade de rede nesta operadora.

Porém a taxa de 13,13 kbits/s observadana operadora B ainda é muito inferior ao valormáximo teórico da rede GPRS, de 171 kbits/s,sendo próxima da taxa encontrada por Benko(2004). Essa diferença pode ocorrer pelos se-guintes motivos: qualidade do sinal, tráfego darede e encapsulamento dos dados pelos proto-colos do modelo OSI. Pode-se afirmar que ovalor medido é o throughput da rede, pois medea taxa do ponto de vista da aplicação, já conta-bilizando os erros da rede, as retentativas e oencapsulamento de dados. Um aumento nobloco de dados enviados a cada comunicação,configurável de acordo com o tamanho do pa-cote de dados do protocolo IP, pode aumentara taxa de transferência, pois reduz o efeito dosdados acrescentados ao bloco original pelosprotocolos do modelo OSI. Porém, quantomaior o pacote de dados, mais chances deocorrerem erros e serem necessárias retenta-tivas. Cabe ao desenvolvedor buscar o valorótimo para sua aplicação, levando em conta ascondições da rede GPRS.

O teste de inatividade da rede, que visouavaliar o tempo no qual o NAT iria encerrar aconexão, confirmou os valores relatados por

Eronen (2008), que indicou que, para o proto-colo TCP, este tempo varia em média de 30 a60 minutos. Diversos testes não apresentaramerros com até 30 minutos de inatividade, ouseja, nestes casos, o timeout do NAT estava comtempo superior a 30 minutos. Em outros ca-sos, porém, inclusive da mesma operadora,intervalos de 16 minutos já causaram uma que-da na conexão. Assim, conclui-se que o timeout

mínimo utilizado pelo serviço NAT estava en-tre 10 e 16 minutos, e o máximo estava supe-rior a 30 minutos.

O teste de alteração de parâmetros TCPmostrou claramente a diferença entre as confi-gurações testadas. As configurações com umvalor pequeno para o parâmetro OT não obti-veram nenhum sucesso nas comunicações rea-lizadas (configurações 1 e 3), independente dovalor dos outros parâmetros. Isso indica que adeterminação do valor correto deste parâmetroé importante. Já as comunicações realizadascom valores pequenos de IRT e MR apresen-taram um índice de sucesso de 65% (apenascom um valor alto para o parâmetro OT, confi-guração 2). E, por fim, o teste com valoresaltos para IRT, MR e OT (configuração 4) apre-sentou 100% de sucesso nas comunicaçõesrealizadas. Conclui-se que o sucesso das comu-nicações está também diretamente relaciona-do com o valor desses parâmetros, especial-mente o parâmetro OT. Isto pode ser atribuídoao significado deste parâmetro, que é a quanti-dade de segundos aguardada pelo módulo paraencerrar uma conexão em caso de falha. Oencerramento da conexão faz com que a comu-nicação como um todo seja encerrada, nãohavendo possibilidade de retentativas. Assim,o valor atribuído ao parâmetro OT deve sermaior que o valor atribuído ao parâmetro IRTpara permitir que o módulo realize retentativasde comunicação em caso de falha ao invés deencerrar a conexão. Mas deve-se tomar cui-dado ao atribuir valores altos para os três parâ-metros, pois o módulo aguardará um tempomaior até repetir uma comunicação em casode erro, atrasando a transferência de dados.

Após a análise dos testes, concluiu-se quea operadora utilizada para o serviço GPRS fazuma significativa diferença no desempenho das



comunicações. A qualidade do serviço e dainfraestrutura oferecida pela operadora afetadiretamente todos os testes realizados. Gran-des valores de tempo de tráfego podem causaruma taxa de transferência reduzida, e a maiorinstabilidade verificada na operadora A dificul-ta a determinação dos parâmetros de comuni-cação, bem como um cálculo estimado de tem-pos de resposta e envio de dados.

Para finalizar, cabe relembrar que a arqui-tetura utilizada para os testes foi uma combi-nação de rede GPRS e Internet. A qualidade daconexão com a internet também deve ser obser-vada de modo que não interfira significativa-mente nos testes. Nos testes relatados, foi utili-zada uma conexão com taxa de transferênciamuito superior à do enlace GPRS, o que permi-te pressupor que a conexão Internet não dete-riora o desempenho do enlace GPRS. Esta tesefoi comprovada pela realização dos testes emlocais e momentos diferentes, com conexõesde internet distintas, sendo possível verificar arepetibilidade dos resultados e, neste caso, ga-rantir que a o enlace Internet não influenciousignificativamente os testes.

ReferênciasBENKO, Peter; MALICSKO, Gabor; VERES,Andras. A Large-scale, passive analysis ofend-to-end TCP performance over GPRS. In:INFOCOM, 23, 2004, Hong Kong. Procee-

ding… Boston: IEEE, 2004. Disponível em:<http://www.ieee.infocom.org/2004/Papers/39_2.pdf>.

ERONEN, Pasi. TCP Wake-up: reducing keep-

alive traffic in mobile IPv4 and IPsec NAT

traversal. Nokia Research Center, 2008. Dis-ponível em: <http://research.nokia.com/files/NRCTR2008002.pdf>.

European Telecommunications StandardsInstitute (ETSI). Digital cellular telecommu-

nications system (Phase 2+) – AT Command

set for GSM Mobile Equipment (ME). 3GPPTS 07.07 version 7.8.0, 1998; ETSI TS 100916 V7.8.0, 2003.

______. Digital cellular telecommunications

system (Phase 2+) – General Packet Radio

Service (GPRS) – Mobile Station (MS) sup-

porting GPRS. 3GPP TS 07.60 version 7.2.0,1998; ETSI TS 101 356 V7.2.0, 2001.


system (Phase 2+) – General Packet Radio

Service (GPRS) – Service description – Stage

2. GSM 03.60 version 7.4.1, 1998; ETSI EN301 344 V7.4.1, 2000.


system (Phase 2+) – Radio transmission and

reception. 3GPP TS 45.005 version 7.13.0Release 7; ETSI TS 145 005 V7.13.0, 2008.

MISHRA, Amitabh. Performance and Archi-tecture of SGSN and GGSN of General PacketRadio Service (GPRS). In: GLOBAL TELE-COMMUNICATIONS CONFERENCE, 2001,San Antonio, TX. Proceedings… San Antonio,TX: IEEE, 2001. v. 6, p. 3494-3498.

PAGONIS, John. GPRS Facts for the Internet

Application Developer – Part I. Symbian,2003. Disponível em: <http://developer.symbian.com/main/downloads/papers/GPRS/GPRSFactsInternetApplicationDeveloper_pt1.pdf>.

PIROTTI, Rodolfo; ZUCCOLOTTO, Marcos.Transmissão de dados através de telefonia ce-lular: arquitetura das redes GSM e GPRS. Re-

vista Liberato, Novo Hamburgo, v. 10, n. 13,jan./jun. 2009.

STUCKMANN, Peter; EHLERS, Niels; WOU-TERS, Bianca. GPRS Traffic PerformanceMeasurements. In: VEHICULAR TECHNO-LOGY CONFERENCE, 2002. Proceedings…IEEE 2002. v. 2, p. 1289-1293.

SVERZUT, José Umberto. Redes GSM, GPRS,

EDGE e UMTS. Editora Afiliada, 2005.

Documents

Transmissão de dados através de telefonia celular ... · Transmissão de dados através de telefonia ... Rua Inconfidentes, 395, Primavera, 93340-140, Novo Hamburgo, RS, Brasil