Embed Size (px)
Citation preview
Universidade Federal do Ceará
Departamento de Engenharia de Teleinformática
Programa de Pós-graduação em Engenharia de Teleinformática
Análise de Desempenho Conjunta dos
Protocolos TCP, RLC e MAC-hs em Redes
Celulares HSDPA
Marcone Lopes de Carvalho
Fortaleza – Ceará
2009
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
Universidade Federal do Ceará
Departamento de Engenharia de Teleinformática
Programa de Pós-graduação em Engenharia de Teleinformática
Análise de Desempenho Conjunta dos
Protocolos TCP, RLC e MAC-hs em Redes
Celulares HSDPA
Autor
Marcone Lopes de Carvalho
Orientador
Prof. Dr. Francisco Rodrigo Porto Cavalcanti
Dissertação de Mestrado apresentada
à Coordenação do Programa de
Pós-graduação em Engenharia de
Teleinformática da Universidade
Federal do Ceará como parte dos
requisitos para obtenção do título
de Mestre em Engenharia de
Teleinformática.
Fortaleza – Ceará
2009
Resumo
Nos últimos anos ocorreu um grande crescimento no acesso à Internet através
de dispositivos móveis como notebooks, palmtops e celulares. Neste contexto
evolutivo, esforços têm se somado no que diz respeito à melhoria de qualidade da
conexão para este tipo de usuário. Diante disso, o cenário de estudo conjunto dos
protocolos especializados em lidar com o meio sem fio e a pilha de protocolos TCP/IP
ganha atenção especial.
Neste trabalho é dado enfoque ao contexto de retransmissões que acontecem em
três diferentes pontos da comunicação entre o transmissor e o receptor de dados
quando se utilizam redes celulares HSDPA, englobando os protocolos TCP, RLC
e a MAC-hs situada no Node B. Baseado em simulações computacionais, é feita
uma análise de interações entre estes protocolos, procurando-se observar um cenário
otimizado de comunicações entre os usuários do sistema HSDPA. Devido à política
simples de descarte de quadros da RLC quando seu buffer está cheio, é evidenciada
uma queda de desempenho na rede a partir de uma certa configuração do número
de retransmissões.
A MAC-hs possui algoritmos muito eficientes para minimizar os efeitos de uma
conexão ruim. O estudo das retransmissões a nível de MAC-hs é feito conjuntamente
com as retransmissões da RLC e do TCP.
Apresentamos quantitativamente as configurações que a RLC e a MAC-hs devem
possuir para otimizar o desempenho da rede HSDPA quando utilizamos, sob tráfego
de web browsing, o TCP New Reno como protocolo de transporte.
Palavras-chave: Controle de congestionamento, TCP/IP, RLC, HSDPA,
UMTS.
Abstract
Over the last years there has been a large growth on Internet accesses through
mobile devices such as notebooks, palmtops and cell phones. Based on this
technological growing context, there has been a big improvement regarding wireless
access users. Grounded on that, studies concerning specific protocols related to
wireless devices and TCP/IP protocols gains special attention.
This work focus on the retransmission that take place in three different spots of
communication between the transmitter and the data receiver when HSDPA cellular
networks are used regarding TCP, RLC and MAC-hs protocols located on the Node
B. An analysis of the interaction among these protocols is made based on computer
simulations, through that it’s possible to observe an optimized view on the process
of communication among the users of HSDPA system. Because of RLC discard
protocol policy when the buffer is full, there is a decrease on the network process
performance due to a certain configuration of the number of retransmissions.
The algorithms implemented on the MAC-hs effectively contribute to minimize
the effects of a bad wireless connection. This minimization is grounded on the
interaction of the whole set of retransmissions which act together with RLC and
TCP.
The configurations that the RLC and the MAC-hs may get to optimize the
HSDPA network performance when we use them under web browsing and having
the TCP New Reno as the transport protocol are presented quantitatively.
Key words: Congestion Avoidance, TCP/IP, RLC, HSDPA, UMTS.
Dedicatória
Dedico este trabalho a meu pai Francisco Pereira de Carvalho que, embora não
tendo frequentado a Academia, ensinou a mim e a meus irmãos tudo sobre
dignidade e humildade, além de muitas outras lições que levarei sempre comigo. À
minha querida mãezinha, Albetiza Lopes de Carvalho, por seu incondicional amor
de mãe, que sempre cuidou com esmero e dedicação de mim e de meus irmãos.
Aos meus irmãos: Rejane, Livonete, Ronaldo, Francisco, Arlete, Ivonildes, Zilmar e
Edilson, fundamentais em minha vida. Aos meus sobrinhos queridos, em especial a
Felipe, Nara, Gabriel e Arthur, crianças que tornam nossa existência mais feliz. À
minha esposa, Adriana, por seu amor, paciência e dedicação a mim. E a meu filho
João Victor, uma bênção que Deus nos enviou e a quem tanto amamos.
Agradecimentos
Agradeço primeiramente a Deus, fonte de toda a sabedoria, que permitiu a
conclusão deste trabalho, a todos os amigos do GTEL, em especial a meu
orientador Francisco Rodrigo Porto Cavalcanti, a Tarcisio Maciel, Yuri Silva e a
Leonardo Ramon que foram fundamentais na elaboração deste trabalho por suas
contribuições e palavras de apoio em momentos de maior dificuldade.
Sumário
Lista de Figuras viii
Lista de Tabelas ix
Lista de Siglas x
1 Introdução 11.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 A grande Rede Internet . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Camadas do modelo TCP/IP . . . . . . . . . . . . . . . . . . . . . . 4
1.3.1 Camada de Aplicação . . . . . . . . . . . . . . . . . . . . . . . 41.3.2 Camada de Transporte . . . . . . . . . . . . . . . . . . . . . . 51.3.3 Camada Inter-redes . . . . . . . . . . . . . . . . . . . . . . . . 61.3.4 Camada Host/rede . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 O Protocolo TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71.5 Universal Mobile Telecommunications System (UMTS) . . . . . . . . 9
1.5.1 Arquitetura do UMTS . . . . . . . . . . . . . . . . . . . . . . 91.6 A tecnologia da rede celular HSDPA . . . . . . . . . . . . . . . . . . 111.7 O protocolo RLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.8 Apresentação do Problema e Objetivo . . . . . . . . . . . . . . . . . . 171.9 Metodologia Utilizada . . . . . . . . . . . . . . . . . . . . . . . . . . 181.10 Estrutura da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . 18
2 O TCP e seus problemas em redes sem fio 202.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 Cabeçalho TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 Mecanismo de retransmissão . . . . . . . . . . . . . . . . . . . . . . . 222.4 Controle de Fluxo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.5 Controle de Congestionamento . . . . . . . . . . . . . . . . . . . . . . 242.6 Versões do TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.1 Old Tahoe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272.6.2 TCP Tahoe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
v
2.6.3 TCP Reno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.6.4 TCP New Reno . . . . . . . . . . . . . . . . . . . . . . . . . . 292.6.5 TCP SACK (Selective Acknowledgement Options) . . . . . . . 292.6.6 TCP Vegas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.7 O TCP operando em redes sem fio . . . . . . . . . . . . . . . . . . . 312.7.1 Longos tempos de resposta na rede . . . . . . . . . . . . . . . 32
2.8 Mitigando os problemas do TCP em redes sem fio . . . . . . . . . . . 322.8.1 Abordagem split-connection . . . . . . . . . . . . . . . . . . . 332.8.2 Abordagem baseada na camada de enlace . . . . . . . . . . . . 342.8.3 Abordagem fim-a-fim . . . . . . . . . . . . . . . . . . . . . . . 34
2.9 Desempenho Ilustrativo do TCP sobre uma rede sem fio . . . . . . . 352.9.1 Cenário Geral da Simulação . . . . . . . . . . . . . . . . . . . 352.9.2 Modelo do Canal . . . . . . . . . . . . . . . . . . . . . . . . . 362.9.3 Geração do Tráfego . . . . . . . . . . . . . . . . . . . . . . . . 382.9.4 Critérios específicos da simulação . . . . . . . . . . . . . . . . 382.9.5 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.9.6 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3 Análise de Desempenho Conjunta dos Protocolos TCP, RLC eMAC-hs em Redes Celulares HSDPA 423.1 Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423.2 Tráfego TCP sobre HSDPA . . . . . . . . . . . . . . . . . . . . . . . 423.3 Cenário de simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1 Geração de tráfego . . . . . . . . . . . . . . . . . . . . . . . . 443.3.2 Descrição das principais características do UTRANSim . . . . 443.3.3 Parâmetros de simulação utilizados . . . . . . . . . . . . . . . 47
3.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.4.1 Resultados de Integração . . . . . . . . . . . . . . . . . . . . . 483.4.2 Influência do número de retransmissões da RLC e MAC-HS . 54
4 Conclusões e Perspectivas 594.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 594.2 Perspectivas de Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . 60
Referências Bibliográficas 65
vi
Lista de Figuras
1.1 Impacto da perda de pacotes devido ao emprego do TCP sobre umaconexão sem fio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Modelos OSI e TCP/IP. . . . . . . . . . . . . . . . . . . . . . . . . . 51.3 Protocolos presentes em cada camada do modelo TCP/IP. . . . . . . 71.4 Arquitetura simplificada de uma rede UMTS. . . . . . . . . . . . . . 101.5 Principais melhorias e extensões do WCDMA pelo HSDPA. . . . . . . 121.6 Arquitetura do HSDPA. . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1 Cabeçalho do protocolo TCP. . . . . . . . . . . . . . . . . . . . . . . 212.2 Mecanismo de janela deslizante. . . . . . . . . . . . . . . . . . . . . . 252.3 Ilustração dos mecanismos de controle de congestionamento. . . . . . 262.4 Observação dos tempos de resposta em redes com e sem fio. . . . . . 322.5 Célula de transmissão. . . . . . . . . . . . . . . . . . . . . . . . . . . 362.6 Modelo do canal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372.7 Desempenho do TCP para um canal ideal (ε = 0). Tempo de
simulação: 135, 23s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392.8 Desempenho do TCP para um canal pouco ruidoso (ε = 0.14). Tempo
de simulação: 158, 73s. . . . . . . . . . . . . . . . . . . . . . . . . . . 402.9 Desempenho do TCP para um canal muito ruidoso (ε = 0.55). Tempo
de simulação: 327, 87s. . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.1 Diversos níveis de retransmissões. . . . . . . . . . . . . . . . . . . . . 433.2 Estrutura funcional do UTRANSim. . . . . . . . . . . . . . . . . . . 453.3 Camadas e protocolos do UTRANSim incluindo o TCP. . . . . . . . . 463.4 Gráficos de convergência da admissão de usuários no sistema. . . . . . 493.5 Distribuição da vazão de dados variando o tempo de chegada entre
usuários. Simulador utiliza o TCP integrado com HSDPA. . . . . . . 503.6 Distribuição da vazão de dados variando o tempo de chegada entre
usuários. Simulador com TCP desligado. . . . . . . . . . . . . . . . . 513.7 Distribuição da vazão de dados comparativa para um tempo de
chegada entre usuários de 0.333 segundos. . . . . . . . . . . . . . . . 523.8 Taxa de estabelecimento de sessão WWW versus satisfação do usuário. 533.9 Eficiência espectral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
vii
3.10 Diversos percentis de atraso de entrega de pacotes com e sem TCP. . 543.11 Variação das retransmissões da RLC (RLC RTX) com zero
retransmissões da MAC-hs (MAC-hs RTX = 0). Décimo percentilda vazão de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.12 Variação das retransmissões da RLC (RLC RTX) com duasretransmissões da MAC-hs (MAC-hs RTX = 2). Décimo percentilda vazão de dados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.13 Variação das retransmissões da MAC-hs com RLC RTX = 4. Décimopercentil da vazão de dados. . . . . . . . . . . . . . . . . . . . . . . . 56
3.14 Variação das retransmissões da MAC-hs com RLC RTX = 3. Décimopercentil da vazão de dados. . . . . . . . . . . . . . . . . . . . . . . . 57
3.15 Variação das retransmissões da RLC com MAC-hs RTX = 0.Quinquagésimo percentil da vazão de dados. . . . . . . . . . . . . . . 57
3.16 Variação das retransmissões da MAC-hs com RLC RTX = 4.Quinquagésimo percentil da vazão de dados. . . . . . . . . . . . . . . 58
viii
Lista de Tabelas
3.1 Modelo de tráfego de web browsing implementado. . . . . . . . . . . . 443.2 Parâmetros de simulação. . . . . . . . . . . . . . . . . . . . . . . . . 48
ix
Lista de Siglas
16QAM 16 Quadrature Amplitude Modulation
2G 2rd Cellular Generation
3G 3rd Cellular Generation
3GPP 3rd Generation Partnership Project
ACK Acknowledgement
AM Acknowledge Mode
AMC Adaptive Modulation and Coding
ARPANET Advanced Research Project Agency Network
ARQ Automatic Repeat Request
ATM Asynchronous Transfer Mode
CN Core Network
CQI Channel Quality Indicator
CWND Congestion Window
DARPA Defense Advanced Research Projects Agency
DCH Dedicated Channel
DNS Domain Name System
DSCH Downlink Shared Channel
EDGE Enhanced Data Rates for GSM Evolution
EGPRS Enhanced General Packet Radio Service
FACH Foward Access Channel
FEC Forward Error Correct
FIN Finalize
FTP File Transfer Protocol
GPRS General Packet Radio Service
GSM Global System for Mobile Communications
x
GTEL Grupo de Pesquisa em Telecomunicações sem Fio
H-ARQ Hybrid Automatic Repeat Request
HSDPA High Speed Downlink Packet Access
HS-DPCCH High Speed Dedicated Physical Control Channel
HS-DSCH High Speed Downlink Shared Channel
HS-SCCH High Speed Shared Control Channel
HTTP Hypertext Transfer Protocol
IMT International Mobile Telecommunications-2000
ICMP Internet Control Message Protocol
IP Internet Protocol
I-TCP Indirect-TCP
ITU International Telecommunication Union
ISO International Standards Organization
MAC-hs Medium Access Control - High Speed
ME Mobile Equipment
MSC Mobile Switching Center
MSR Mobile Support Router
M-TCP Mobile TCP
MTU Maximum Transmission Unit
MSS Maximum Segment Size
OSI Open Systems Interconnection
PDU Packet Data Unit
PSH Push
QoS Quality of Service
RFC Request For Comments
RLC Radio Link Control
RNS Radio Network Subsystem
RRC Radio Resource Control
RST Reset
RTO Retransmission Time Out
RTT Round Trip Time
RXWND Receiver Window
SACK Selective Acknowledgement
SDU Service Data Unit
SF Spreed Factor
xi
SMTP Simple Mail Transfer Protocol
SYN Synchronize
TCP Transmission Control Protocol
TFCI Transport Format Combination Indicator
TTI Transmission Time Interval
TXWND Transmission Window
UDP User Datagram Protocol
UMTS Universal Mobile Telecommunications System
UE User Equipment
UFC Universidade Federal do Ceará
URG Urgent pointer
USIM User Service Identity Module
UTRAN UMTS Terrestrial Radio Access Network
VLR Visitor Location Register
VoIP Voice over Internet Protocol
WCDMA Wideband Code Division Multiple Access
WWW World Wide Web
xii
Capítulo 1Introdução
1.1 Motivação
O conjunto de protocolos TCP/IP (do inglês Transmission Control Protocol
/ Internet Protocol) é sem dúvida o padrão mais popular e mais largamente
adotado para transmissões de dados por pacotes sobre diversos tipos de redes de
computadores. Atualmente, seu uso está sendo também difundido entre as redes de
dados sem fio, tais como sistemas celulares, redes locais sem fio e redes por satélites.
A demanda por novos serviços orientados a pacotes tem levado as operadoras
de serviços celulares a voltar esforços no sentido de prover esses serviços de forma
competitiva e atraente para o usuário final. Para isso, as conexões TCP devem ser
otimizadas dentro da estrutura oferecida pelo sistema de comunicação sem fio, por
ser este um protocolo confiável e de utilização tradicional no transporte de dados
dentro do conjunto de protocolos que formam a pilha TCP/IP.
A otimização no estabelecimento de conexões em ambientes sem fio via TCP
impulsionaria enormemente a oferta de serviços sofisticados e de alto desempenho,
gerando um produto final de qualidade e potencial fonte de receita para as
operadoras destes serviços, melhorando sua posição competitiva no mercado de
telecomunicações e evitando a troca de operadora pelo assinante.
Com o avanço da telefonia celular e o crescente número de usuários da
Internet o mercado de serviços de dados sem-fio para terminais móveis torna-se um
investimento bastante atraente, uma vez que disponibiliza o acesso para os usuários
em qualquer lugar e a qualquer momento. Com a demanda por serviços sem fio
2
crescendo a cada dia, em poucos anos o acesso à Internet móvel com alto desempenho
será requisitado mais e mais pelos usuários. Este é o cenário para as comunicações
móveis de terceira geração (3G) em processo de implantação, sucessora dos padrões
de segunda geração (2G) ainda centradas na oferta de serviços de comunicação de
voz tradicionais.
Para os sistemas de rádio móveis de terceira geração as taxas de transmissão
podem chegar ao máximo de 2Mbps. As aplicações multimídia usam vários serviços,
como voz, áudio/vídeo, gráficos, dados, acesso à Internet e e-mail, todos ao mesmo
tempo. Os serviços, comutados por pacotes e por circuitos, devem ser suportados
pela interface de rádio e pelo subsistema de rede. Para que todos esses serviços,
taxas de transmissão e seus futuros avanços possam ser praticados, os protocolos de
transmissão que operam em ambientes sem fios, bem como as técnicas empregadas
na manipulação desses protocolos, devem ser otimizados.
Com o crescimento das tecnologias de comunicação rádio-móveis, especialmente
em telefonia celular (de acordo com o fórum do UMTS - do inglês Universal Mobile
Telecommunication System - haverá cerca de 1,8 bilhões de assinantes em 2010)
faz-se necessário a adequação de novas técnicas de transporte de dados, aproveitando
a base plantada pelos protocolos da família TCP/IP.
As conexões fim-a-fim de TCP/IP são frequentemente pedidas pelos clientes
móveis que desejam ter o acesso aos conteúdos de WWW (do inglês World Wide
Web), transferência de arquivos, ao e-mail, e a demais serviços da Internet. Não
obstante, há alguns aspectos que podem prejudicar o desempenho do TCP/IP para
estes usuários, tais como a mobilidade e a não confiabilidade da conexão via rádio,
uma vez que o protocolo foi projetado originalmente para funcionar sobre redes fixas
e confiáveis. A figura 1.1 ilustra o problema que pode ocorrer quando os pacotes são
perdidos pela conexão sem fio.
O protocolo TCP interpreta erroneamente estes pacotes não entregues como um
congestionamento da rede e ativa seu mecanismo de controle de congestionamento,
que resulta em uma degradação do desempenho do sistema.
Em ambientes sem fio, é comum que alguns eventos que não sejam propriamente
um congestionamento (tal como a interferência e a perda devido ao handoff ) façam
com que os pacotes não cheguem em seu destino. Caso o TCP interprete todos estes
3
1 542 3
1
NACK
543
NACK
21
2
Rec�eptor
Pacotes
INTERNET
Figura 1.1: Impacto da perda de pacotes devido ao emprego do TCP sobre uma conexãosem fio.
eventos como congestionamento, causará a degradação no desempenho da camada
de transporte e da comunicação como um todo [1, 2].
1.2 A grande Rede Internet
No início dos anos 60, uma associação entre o DARPA (do inglês Defense
Advanced Research Projects Agency), um grupo de universidades e algumas
instituições, criou a ARPANET (do inglês Advanced Research Project Agency
Network). Em 1969, a rede ARPANET entrou em operação, consistindo inicialmente
de quatro nós e utilizando comutação de pacotes para efetuar a comunicação visando
à continuidade de operação mesmo que alguns deles fossem destruídos por ataques
de aviões de guerra [3]. Este foi o projeto que deu origem à Internet. Após um
longo período restrito a órgão governamentais e de pesquisas, o acesso à Internet foi
oferecido comercialmente para a população mundial.
Para facilitar o processo de padronização e obter interconectividade entre
máquinas de diferentes fabricantes, a ISO (do inglês International Standards
Organization) aprovou, no início dos anos 80, um modelo de referência para permitir
a comunicação entre máquinas heterogêneas, denominado OSI (do inglês Open
Systems Interconnection). Esse modelo serve de base para qualquer tipo de rede,
seja de curta, média ou longa distância e é considerado o padrão de juri. Em
4
1980, o DARPA começou a implementar o TCP/IP na ARPANET, dando origem
à Internet. Em 1983, o DARPA finalizou a conversão de todos seus computadores
e exigiu a implementação do TCP/IP em todos os computadores que quisessem se
conectar à ARPANET. Além disso, o DARPA também financiou a implementação
do TCP/IP como parte integral do sistema operacional Unix, exigindo que este
fosse distribuído de forma gratuita. Dessa forma o Unix e, consequentemente, o
TCP/IP, difundiram-se, cobrindo múltiplas plataformas. Assim, o modelo TCP/IP
ficou sendo utilizado como o padrão de fato para interconectar sistemas de diferentes
fabricantes, não apenas na Internet, mas em diversos ramos de negócios que
requerem tal forma de comunicação.
Atualmente, a Internet é uma imensa rede de redes de computadores que trocam
informações entre si. Estes computadores podem ser de qualquer porte, arquitetura,
marca ou modelo. Podem usar qualquer processador, sistema operacional e qualquer
software que permita comunicação entre servidores e clientes. Existem diversas
formas de interligação entre estes computadores tais como linha comum de telefone,
linhas privadas de comunicação, cabos submarinos ou mesmo canais de comunicação
sem fio como canais de satélite e redes celulares. Essas inúmeras formas de
conexão configuram a independência de hardware e software, uma das principais
características da Internet e que garante o seu notável sucesso.
1.3 Camadas do modelo TCP/IP
No modelo TCP/IP as diversas camadas de software interagem somente com as
camadas acima e abaixo. Há diversas semelhanças com o modelo conceitual OSI
da ISO, mas o TCP/IP é anterior à formalização deste modelo e portanto possui
algumas diferenças. A figura 1.2 mostra a equivalência dos níveis entre os modelos
OSI e TCP/IP.
Na sequência será mostrada sucintamente uma descrição da função de cada
camada do modelo TCP/IP.
1.3.1 Camada de Aplicação
Na camada de aplicação estão presentes os protocolos de nível mais alto da
pilha TCP/IP, como por exemplo, o TELNET, FTP (do inglês File Transfer
Protocol), SMTP (do inglês Simple Mail Transfer Protocol). Estes protocolos
5
Aplicação
Física
Enlace de dados
Rede
Transporte
Sessão
Apresentação
Aplicação
Host - rede
Inter-redes
Transporte ���������Modelo OSI Modelo TCP/IP
Figura 1.2: Modelos OSI e TCP/IP.
acessam os serviços disponíveis nas camadas inferiores da pilha. As aplicações
presentes nesta camada interagem com a camada de transporte para enviar e receber
dados, utilizando os serviços orientados à conexão oferecidos pelo TCP ou aqueles
não orientados à conexão através do UDP (do inglês User Datagram Protocol).
Os protocolos de aplicação são específicos para cada programa que faz uso da
rede. Desta forma existe um protocolo para a conversação entre um servidor web
e um web browser, um protocolo para a conversação entre um cliente TELNET e
um servidor (daemon) TELNET, e assim por diante. Cada aplicação de rede tem o
seu próprio protocolo de comunicação, que utiliza os protocolos das camadas mais
baixas para poder atingir o seu destino.
1.3.2 Camada de Transporte
A função básica da camada de transporte é permitir a comunicação fia-a-fim entre
aplicações. Os protocolos desta camada são o TCP e o UDP. Se o protocolo utilizado
for o TCP, os seguintes serviços são oferecidos: controle de erro, controle de fluxo,
sequenciação e multiplexação do acesso ao nível de inter-redes. O UDP por ser um
protocolo mais simples, oferece somente o serviço de multiplexação/demutiplexação
6
do acesso ao nível de rede.
Na camada de transporte, os dados são agrupados em pacotes e encaminhados
à camada inter-redes.
Os protocolos de transporte do modelo TCP/IP, o UDP e o TCP, conectam dois
programas. Pode-se ter em um mesmo computador vários programas trabalhando
com a rede simultaneamente, por exemplo um web browser e um leitor de e-mail.
Os protocolos de transporte atribuem a cada programa um número de porta, que é
anexado a cada pacote de modo que o TCP/IP saiba para qual programa entregar
cada mensagem recebida pela rede.
1.3.3 Camada Inter-redes
A camada inter-redes é responsável pela transferência de dados desde a máquina
de origem até a máquina de destino. A camada inter-redes define sua unidade
básica de transferência de dados: o datagrama de interligação em redes, datagrama
IP ou simplesmente datagrama. O pacote recebido da camada de transporte, é
encapsulado em um datagrama IP, o qual é submetido a algoritmos de roteamento
para decidir se sua entrega deverá ser feita para o nível de transporte local ou se
deve ser repassado adiante através de uma das interfaces de rede.
Na camada inter-redes está o protocolo IP, responsável por fazer com que as
informações enviadas por um computador cheguem a outros computadores mesmo
que eles estejam em redes fisicamente distintas, ou seja, não exista conexão direta
entre eles. O IP realiza a conexão entre redes, sendo capaz de rotear pacotes por
outro caminho quando uma parte da rede está fora do ar, buscando uma rota
alternativo para a comunicação.
1.3.4 Camada Host/rede
O modelo TCP/IP não faz nenhuma restrição às redes que são interligadas para
formar a inter-rede. Portanto, qualque tipo de rede pode ser ligada, bastando para
isso que seja envolvida por uma interface que compatibilize a tecnologia específica
da rede com o protocolo IP. Essa compatibilização é a função da camada host/rede.
Dessa forma, a camada host/rede é responsável pela aceitação de datagramas IP e
por sua transmissão através de uma rede específica. Esta camada não possui um
protocolo definido.
7
Observando a equivalência das camadas nos modelos OSI e TCP/IP a camada
host/rede equivale às camadas física e de enlace. Esta última, em sistemas celulares
multi-usuário se subdivide em MAC (do inglês Medium Access Control), responsável
pelo uso eficiente dos canais de transporte e pela seleção apropriada do formato de
transporte, e RLC (do inglês Radio Link Control) descrito na seção 1.7.
1.4 O Protocolo TCP
O TCP, juntamente com o UDP, é um dos protocolos da camada de transporte
do modelo TCP/IP, como mostrado na figura 1.3. Diferentemente do UDP
(basicamente o IP acrescido de um pequeno cabeçalho), o TCP é um protocolo
orientado a conexão e trabalha a partir de uma negociação de parâmetros entre
as partes envolvidas. Foi proposto originalmente na RFC (do inglês Request For
Comments) 793 e com o passar do tempo passou por mudanças e sofisticações que
lhe deram a robustez e confiabilidade que ostenta nos dias de hoje. O detalhamento
de alguns de seus problemas e soluções são abordados nas RFC’s 1122 e 1323. O TCP
é responsável por manter a comunicação fim-a-fim, baseando-se em um mecanismo
de entrega confiável com a finalidade de oferecer um fluxo de bytes em uma inter-rede
não-confiável ser robusto diante de falhas [3, 4].
Aplicação
Host / rede
Inter-redes
Transporte
ETHERNET TOKEN RING
FRAME RELAY
ATM
IP ICMP
TCP UDP
TELNET FTP SMTP DNS
CAMADAS DO MODELO TCP/ IP PROTOCOLOS
Figura 1.3: Protocolos presentes em cada camada do modelo TCP/IP.
8
O TCP garante a entrega de dados ao seu receptor e na sequência correta.
A camada inter-redes não oferece qualquer garantia de que os datagramas serão
entregues adequadamente, por isso o TCP tem a função de administrar a
retransmissão destes datagramas sempre que for necessário. Pode ocorrer que alguns
deles cheguem fora de ordem. Caso isso ocorra cabe ao TCP organizá-los de forma
correta. Portanto, o TCP fornece, através de seus mecanismos, a confiabilidade que
não é oferecida pelo protocolo da camada inter-redes, o IP [3].
Os principais tarefas executadas pelo TCP são a segmentação, estabelecimento
e liberação de uma conexão, multiplexação e controle de congestionamento. O TCP
executa tudo isso independente da tecnologia de rede e do hardware, possibilitando a
comunicação de qualquer par de hosts (qualquer máquina na rede capaz de executar
as aplicações do usuário).
O serviço TCP ocorre quando o transmissor e o receptor criam pontos terminais,
estabelecendo uma conexão full-duplex e ponto a ponto. As entidades envolvidas
trocam fluxos de dados que são divididos em partes de no máximo 64KB (na prática
é cerca de 1.5KB) e enviadas em datagramas IP. Quando estes datagramas chegam
à outra extremidade, a entidade TCP daquela máquina recebe os datagramas e
restaura o seu conteúdo.
O TCP possui a implementação de mecanismos capazes de assegurar a
confiabilidade na transmissão por requerer que o transmissor confirme os dados
recebidos à medida que eles cheguem ou mediante um determinado tempo de atraso
para a confirmação de blocos maiores de dados.
A rede na qual trafegam os dados não é perfeita e uma pequena porção destes
dados pode ser perdida devido a erros no percurso ou mesmo a problemas de
congestionamento na rede (o que causa a perda de pacotes nas filas internas de
roteadores). Em redes com fio, para as quais o TCP foi originalmente implementado,
as perdas devido a erros aleatórios na rede é inferior a 1% [3, 5], por isso o TCP
interpreta a perda de pacotes como congestionamento nos buffers de roteadores
intermediários. Assim, torna-se muito importante a ação do protocolo para a
redução do congestionamento.
Quando um congestionamento é identificado o TCP reduz o valor de sua janela
de congestionamento (CWND) para dar continuidade ao processo de transmissão
9
de novos segmentos e por isso a eficiência da rede pode ser reduzida. Tendo em
vista esse problema, foram desenvolvidos algoritmos para executar o controle de
congestionamento do TCP tais como o Slow Start, Congestion Avoidance, Fast
Retransmit e Fast Recovery, todos abordados no Capítulo 2.
1.5 Universal Mobile Telecommunications System (UMTS)
Atualmente, a terceira geração de redes de telefonia móvel vem sendo alvo de
diversas pesquisas. Pela ITU (do inglês International Telecommunication Union), as
redes de terceira geração são denominadas IMT-2000 (do inglês International Mobile
Telecommunications-2000 ), e pela Europa como UMTS. Esta nova tecnologia,
promove uma grande variedade de serviços, especialmente relacionados a multimídia
e à alta taxa de transmissão. Nesse contexto, o WCDMA (do inglês Wideband Code
Division Multiple Access) emerge como a principal solução para interface aérea de
terceira geração [1].
UMTS é o termo adotado para designar o padrão de terceira geração (3G),
estabelecido como evolução para operadoras de GSM (do inglês Global System for
Mobile Communications) e que utiliza como interface de rádio o WCDMA ou o
EDGE (do inglês Enhanced Data Rates for GSM Evolution), além de ser uma
tecnologia de dados de alta velocidade, fazendo parte dos padrões sem fio da família
IMT-2000 da ITU.
1.5.1 Arquitetura do UMTS
A UMTS reutiliza investimentos anteriores, especialmente a infra-estrutura de
rede de pacotes de dados implementada para a GPRS (do inglês General Packet
Radio Service). Dependendo do fabricante, a atualização pode ser facilmente
executada adicionando cartões de canais e software UMTS à infra-estrutura de
rádio existente de GSM/GPRS/EDGE, que continua a prover serviços para clientes
utilizando essas tecnologias.
Uma rede UMTS é formada pelo núcleo da rede (CN, do inglês Core Network),
pelo UTRAN (do inglês Universal Terrestrial Radio Access Network), que é a Rede
de Acesso de Rádio Terrestre do UMTS, pelo equipamento do usuário (UE, do
inglês User Equipment) e pelas interfaces entre essas entidades chamadas de Uu,
Cu, Iu, Iub e Iur, descritas adiante. Dessa forma, a arquitetura do UMTS pode ser
10
representada simplificadamente pela figura 1.4.
UE
UTRAN
USIM
ME
CN
MSR VLR
SGSN
RNS
Node B
RNS
RNC
Node B
Uu Iu Iub Cu
Node B
RNC
Node B
Iur
Figura 1.4: Arquitetura simplificada de uma rede UMTS.
A principal função do CN é prover chaveamento, roteamento e tráfego do usuário,
além de possuir a base de dados e funções de gerenciamento da rede. O chaveamento
pode ser divido em chaveamento por circuito ou por pacote.
Entre os elementos chaveados por circuito temos a MSC (do inglês Mobile
Switching Center) e o VLR (do inglês Visitor Location Register). Como elemento
chaveado por pacote temos o SGSN (do inglês Service GPRS Support Node), por
exemplo. O UTRAN tem a função de prover a interface aérea para o UE, tendo como
tecnologia de múltiplo acesso o WCDMA. É composto pelas seguintes entidades:
◮ A RNS (do inglês Radio Network Subsystem) gerencia os recursos de rádio
necessários à conexão do UE à UTRAN. Cada RNS é composta por uma RNC
(do inglês Radio Network Controller);
◮ A RNC é o nó lógico da RNS responsável pelo controle do uso e integridade
dos recursos de rádio;
◮ Node B é a entidade responsável pela transmissão e recepção dos dados em
uma célula.
O UE é simplesmente o equipamento móvel do usuário. Esse equipamento móvel
é composto pelo aparelho propriamente dito, representado por ME (do inglês Mobile
11
Equipment) e pelo USIM (do inglês User Service Identity Module). As interfaces
mostradas na figura 1.4 são definidas como sendo:
◮ Uu - Interface entre o UTRAN e o UE sendo a interface de rádio WCDMA
onde o equipamento do usuário acessa a parte física do sistema;
◮ Cu - Interface entre o ME e o USIM do UE que segue um formato padrão para
pequenos cartões;
◮ Iu - Interface entre o UTRAN e a CN dando aos operadores UMTS a
possibilidade de adquirirem o UTRAN e a CN de diferentes fabricantes;
◮ Iub - Interface entre os Nodes B e a RNC do UTRAN, onde no HSDPA requer
um mecanismo de controle de fluxo para assegurar que os buffers sejam usados
corretamente no Node B e que não haja perda de dados devido a um estouro
nos buffers ;
◮ Iur - Interface entre duas RNC’s do UTRAN, permitindo a troca entre estações
rádio-base ou sotf handover, como é mais conhecido.
1.6 A tecnologia da rede celular HSDPA
Esta seção tem como enfoque principal o sistema HSDPA (do inglês High
Speed Downlink Packet Access) [6–10]. Aqui será dada uma abordagem genérica
dos fundamentos que norteiam o emprego desse sistema sem, no entanto,
aprofundar o assunto em seus pormenores. Os testes e investigações da dissertação
foram conduzidos, utilizando o simulador UTRANSim que modela as principais
características desse sistema de comunicação sem fio de terceira geração.
No sistema WCDMA já existem vários métodos para a transmissão de pacotes
de dados no enlace direto de acordo com o Release 99 do 3GPP (do inglês
3rd Generation Partnership Project), de forma que o WCDMA pode alcançar
velocidades de até 384 Kbps para grandes áreas e de até 2 Mbps para áreas de
hot spot, ou seja, o WCDMA já fornece velocidades suficientes para a maioria das
aplicações de pacotes de dados. No entanto, apenas um número limitado de usuários
pode ser suportado simultaneamente nessas altas velocidades.
Para lidar com taxas cada vez maiores houve um aprimoramento do WCDMA
que ficou conhecido como HSDPA e foi introduzido a partir do Release 5 do 3GPP
12
relativo à norma do WCDMA. O conceito por trás do HSDPA consiste de um novo
canal compartilhado no downlink que suporta a transmissão de múltiplos códigos,
menor intervalo de transmissão (TTI, do inglês Transmission Time Interval),
adaptação de enlace e uma rápida forma de retransmissão. A figura 1.5 mostra
uma visão das principais melhorias acrescidas com a inclusão do HSDPA e algumas
excluídas do projeto.
TTI DE 2msAMCH-ARQ
Melhorado como HSDPA
WCDMA
Controle deSofthandover
Excluidos com o HSDPA
Incluído no HSDPA
EP no Node B
Operação
multicódigo
potênciaSF variável
Figura 1.5: Principais melhorias e extensões do WCDMA pelo HSDPA.
Dentre as características incluídas estão o H-ARQ (do inglês Hybrid Automatic
Repeat Request) que permite retransmitir blocos de transporte perdidos. É um
esquema de adaptação de enlace no qual as confirmações de blocos na camada
de enlace são usadas para decisões de retransmissão no UTRAN. No Release
99 do 3GPP a funcionalidade da retransmissão é parte da RLC, porém esse
esquema é muito lento para o HSDPA, no qual os buffers de retransmissão são
localizados perto da camada física e logo acima desta, na MAC-hs (do inglês
Medium Access Control - High Speed). É empregada a redundância incremental,
ou seja, quando uma transmissão falha, os dados corrompidos ainda são mantidos
no buffer. Retransmissões sucessivas incluirão mais redundância e estes dados serão
13
combinados no receptor com aqueles antigos anteriormente recebidos. Isso é repetido
até que os dados no buffer do receptor sejam considerados recebidos com sucesso ou
que o número máximo de retransmissões seja atingido.
Com o emprego da técnica AMC (do inglês Adaptive Modulation and Coding)
o esquema de modulação e a taxa de código dependem da qualidade do canal que
é monitorada constantemente. Com isso, o formato do canal de transporte usado
pode ser mudado a cada frame transmitido. As informações sobre a qualidade do
canal são enviadas aos Nodes B da rede através dos canais de controle no uplink.
Caso as condições estejam boas o UTRAN pode utilizar modulações de altas ordens
e menos redundância, enquanto que em condições ruins do canal um esquema de
modulação mais robusto pode ser empregado, podendo haver mais redundância nos
pacotes de dados.
No HSDPA, uma das principais modificações na arquitetura comparadas ao
Release 99 do 3GPP é a mudança do escalonador de pacotes (EP na figura 1.5)
da RNC para o Node B. A rápida informação das condições do canal permitem
ao escalonador de pacotes servir ao usuário somente quando suas condições são
favoráveis. Este rápido mecanismo e a natureza de tempo compartilhado do
HS-DSCH (do inglês High Speed Downlink Shared Channel) possibilitam explorar a
diversidade multiusuário [11] com importantes benefícios para a vazão na célula.
O TTI no H-ARQ é de apenas 3 time slots, ou seja, 2ms ao invés de 15 time slots
(10ms) empregados em outros canais físicos. Com isso o móvel pode informar na
rede UTRAN em apenas 2ms se houve falha na transmissão. Um TTI curto também
significa que o sistema pode responder rapidamente a mudanças nas condições do
canal.
No HSDPA foram excluídos o soft handover pois não é suportado pelo canal
HS-DSCH, o controle de potência por loop fechado, dentre outros motivos, por
criar picos de potência de transmissão que reduzem a capacidade total da rede.
Isso é compensado pelos mecanismos de adaptação de enlace vistos anteriormente
(H-ARQ e AMC). O uso desses mecanismos também justificam a ausência do fator
de espalhamento variável (SF na figura 1.5, do inglês Spreading Factor) [10].
A transmissão de múltiplos códigos de Walsh também é usada no processo de
adaptação de enlace melhorando a aplicação do processo.
14
A vazão máxima teórica no HSDPA é de 14,4 Mbps, isso com a utilização do
esquema de modulação 16QAM (do inglês 16 Quadrature Amplitude Modulation) e
uma taxa de codificação de 1.
Os procedimentos de retransmissão para dados no WCDMA estão localizados
na RNC (do inglês Radio Network Control), que também gerencia a conexão de um
dado usuário para o núcleo da rede. Com a introdução do novo canal compartilhado
do HSDPA, o HS-DSCH, um módulo adicional de inteligência foi instalado no Node
B na forma de uma nova MAC para o HSDPA, a chamada MAC-hs. Desta forma,
as retransmissões podem ser controladas diretamente pelo Node B, que pode efetuar
retransmissões mais rápidas e assim encurtar o atraso de transmissão de pacotes
de dados quando retransmissões forem necessárias. A funcionalidade chave da nova
MAC do HSDPA é o gerenciamento do ARQ (do inglês Automatic Repeat Request)
e também das funções de escalonamento.
O objetivo com o HSDPA consiste em aumentar a vazão de dados utilizando
métodos já conhecidos dos padrões GSM. Dessa forma, mudanças de arquitetura
são necessárias para permitir essa retransmissão rápida e para trazer o controle
da adaptação de enlace mais para perto da interface aérea. A figura 1.6 ilustra a
arquitetura do HSDPA.
Nos release 99/release 4 do WCDMA existem três diferentes canais que podem
ser usados por pacotes no downlink que são o DCH (do inglês Dedicated Channel), o
DSCH (do inglês Downlink Shared Channel) e o FACH (do inglês Forward Acess
Channel). O DCH pode ser usado basicamente para qualquer tipo de serviço.
Ele possui um fator de espalhamento constante no enlace direto. Assim reserva
a capacidade de código de acordo com o valor de pico da taxa de dados para a
conexão.
O DSCH foi desenvolvido para trabalhar junto com o DCH. Desta maneira, as
propriedades do DSCH podem ser definidas para as taxas de pacotes de dados mais
convenientes enquanto os dados com requisitos rígidos de atraso, como fala e vídeo,
são deixados para serem transmitidos através do DCH. O DSCH, diferentemente do
DCH, tem um SF variando dinamicamente baseado em frames de 10ms com TFCI
(do inglês Transport Format Combination Indicator) transportado junto ao DCH.
Os recursos de códigos do DSCH podem ser compartilhados com vários usuários e
15
RLC
MAC-d
MAC-hs
PHY
RLC
MAC-d
L1
HS-DSCHFrame
L2
L1PHY
Protocol
HS-DSCHFrame
Protocol
L2
MAC-hs
de camadassuperiores
protocolos
de camadassuperiores
protocolos
UE
Uu Iub
Node B RNC
Figura 1.6: Arquitetura do HSDPA.
o canal pode empregar transmissão em código simples e em múltiplos códigos. O
DSCH pode utilizar o controle rápido de potência com o DCH associado, mas não
suporta soft handover.
O FACH, transportado no S-CCPCH (do inglês Secondary Common Control
Physical Channel) pode ser usado no enlace direto. O FACH normalmente opera
sozinho, ele é enviado com um SF fixo e tipicamente de preferência com altos níveis
de potência para alcançar todos os usuários na célula devido à restrição de potência
da camada física no enlace reverso.
O HSDPA acrescentou três novos canais, o HS-DSCH, o HS-SCCH (do inglês
High Speed Shared Control Channel) e o HS-DPCCH (do inglês High Speed Dedicated
Physical Control Channel). O HS-SCCH é o canal que indica quando existe dados a
serem recebidos no HSDSCH atual. Ele também carrega informações de configuração
para o HS-DSCH, como por exemplo, o formato de transporte e informações
relacionadas aos recursos, informações relacionadas com o H-ARQ, a identidade
de UE (do inglês User Equipment, o dispositivo móvel propriamente dito), entre
16
outras informações.
Uma vez que os dados foram recebidos e processados pela MAC-hs, o UE envia
de volta para a rede uma confirmação via HS-DPCCH. Este por sua vez, também
pode carregar CQIs (do inglês Channel Quality Indicators) que são baseadas nas
medidas do canal de downlink.
O HS-DSCH é o canal de transporte que carrega os dados do usuário com
operação HSDPA. Todos os canais HS-DSCH usam um fator de espalhamento igual a
16. Entretanto para aumentar a vazão percebida pelo usuário, o UTRAN pode alocar
vários códigos de espalhamento para um usuário. O número máximo de multicódigos
que um UE pode suportar depende da capacidade do próprio equipamento, podendo
ser 5, 10 ou 15. O HS-DSCH não suporta soft handovers [7].
O HSDPA não é adequado para todo tipo de serviço. O canal é compartilhado
entre todos os usuários da célula. Essa característica indica que o atraso máximo
não é facilmente garantido e com isso as aplicações que têm requisitos de tempo real
deveriam usar canais dedicados e não o HSDPA. O sistema fornece um adequado
conjunto de ferramentas, oferecendo uma forma de aumentar a capacidade de tráfego
de dados em hot spots.
1.7 O protocolo RLC
O protocolo RLC, que pertence à camada de mesmo nome, provê serviços de
segmentação e retransmissão tanto para dados de controle como para dados do
usuário. A camada RLC procura oferecer um serviço praticamente sem erros para
as camadas situadas acima dela. O protocolo pode operar em três modos distintos:
no modo não confirmado ou UM (do inglês Unacknowledgement Mode), no modo
transparente ou TM (do inglês Transparent Mode), e no modo confirmado ou AM
(do inglês Acknowledgement Mode). No modo transparente nenhum overhead é
adicionado aos dados da camada superior. Quando ocorre um erro na transmissão
de uma PDU (do inglês Packet Data Unit), esta pode ser simplesmente descartada
ou apenas marcada como uma PDU com erros. As transmissões neste modo podem
ser do tipo streaming de dados, na qual não é segmentada nas camadas superiores.
No caso em que uma segmentação ou reagrupamento seja efetuado, isso deve ser
negociado no procedimento de configuração da portadora de rádio. No modo
não-confirmado nenhum protocolo de retransmissão é utilizado e, com isso, a entrega
17
não é garantida. As PDUs com erros são apenas marcadas ou então descartadas,
o que vai depender da configuração. No outro par da comunicação é aplicado um
descarte baseado em tempo, assim as SDUs (do inglês Service Data Unit) da RLC
que não forem transmitidas dentro de um certo tempo serão removidas do buffer de
transmissão. A estrutura da PDU inclui números de sequência para que a integridade
de PDUs das camadas superiores sejam mantidas. A segmentação e concatenação
são obtidas através de campos de cabeçalho adicionados aos dados. Esse modo de
transmissão é adequado para serviços de broadcast na célula e também para o serviço
de voz sobre IP ou VoIP (do inglês Voice over IP) [6, 10].
No modo confirmado um mecanismo ARQ é utilizado para a correção de erros. O
número máximo de retransmissões configurado na RLC estabelece um compromisso
entre a qualidade do enlace de rádio e o atraso percebido no processo de retransmitir
blocos perdidos. Este modo é o mais adequado quando o tráfego de dados é do
tipo melhor esforço, como é o caso do tráfego de WWW utilizado neste trabalho.
Quando o número máximo de retransmissões estabelecido é atingido, a camada
superior é notificada e a SDU da RLC é descartada. Neste ponto, caso o TCP
esteja presente nas camadas superiores, este assume o procedimento de reenvio do
pacote que teve alguma parte sua perdida, ativando seus mecanismos de controle
de congestionamento, o que leva fatalmente a uma perda de desempenho. A RLC
pode ser configurada para entrega de dados em sequência ou fora dela. Quando os
dados são entregues em sequência a ordem das PDUs da camada superior é mantida
enquanto que em entregas fora de sequência, tão logo as PDUs seja recebidas vão
sendo transmitidas para cima.
1.8 Apresentação do Problema e Objetivo
O TCP, originalmente desenvolvido para ambientes de rede com fio, atua de
forma pouco eficiente em ambientes de rede sem fio. Embora em alguns sistemas
diversos mecanismos como retransmissões rápidas, curtos tempos de envio e recepção
de segmentos e melhores algoritmos de escalonamento sejam empregados, ainda
assim o meio sem fio apresenta problemas de frequentes perdas de pacotes. O
desempenho dos algoritmos dessas redes são exigidos ao máximo para diminuir os
reflexos na camada de transporte e perda de desempenho geral da transmissão.
Os segmentos TCP a serem retransmitidos a nível da RLC apresentam um
18
aumento considerável do RTT (do inglês Round Trip Time) devido ao processo
de retransmissão. De acordo com [8], o enfileiramento médio no Node B pode ser
muito significativo, da ordem de segundos, quando a janela de congestionamento
atinge o limite imposto pelo buffer do receptor. Em [12] e [13] os autores fazem um
estudo da interação entre o TCP e a RLC, abordando a influência do número de
retransmissões, o modelo de erros e a influência da janela de recepção no tamanho
do buffer da RLC. No primeiro, além da interação entre o TCP e a RLC, propõe-se o
estudo com a MAC-hs do HSDPA. No segundo, é proposto um estudo de parâmetros
ótimos, porém considerando somente o TCP e a RLC. Em [10] é feito um estudo
de integração do TCP sobre redes HSDPA focado nos algoritmos de escalonamento
Proportional Fair e Round Robin.
O objetivo deste trabalho é a análise das interações entre estes protocolos
e com isso estabelecer um cenário onde se configure um melhor conjunto de
parâmetros como os tamanhos de buffers de retransmissão da RLC e da MAC-hs
atuando conjuntamente com o TCP. Esta forma de abordagem não foi encontrada
anteriormente na literatura acadêmica.
1.9 Metodologia Utilizada
A partir da delimitação do problema a ser avaliado, a metodologia utilizada segue
com o emprego de simulações computacionais dinâmicas de nível sistêmico através de
simuladores implementados no decorrer do estudo, modelados com uma boa riqueza
de detalhes pertinentes tanto ao funcionamento do protocolo TCP quanto à uma rede
móvel do UTRAN, no caso o HSDPA, procurando-se obter um número grande de
amostras que evidenciem os resultados obtidos, observando sempre o compromisso
entre o custo computacional, no que compete ao tempo de simulação, e a acuidade
dos resultados obtidos.
1.10 Estrutura da Dissertação
Os próximos capítulos deste trabalho estão organizados de acordo com a
sequência:
Capítulo 2 - neste capítulo é introduzido a interação do TCP com ambientes sem
fio, ressaltando os problemas que ocorrem com essa interação e diversas propostas
pesquisadas na literatura que mostram inúmeras formas de lidar com o problema,
19
bem como resultados ilustrativos de um simulador simplificado.
Capítulo 3 - aqui é apresentada a ferramenta de simulação, no caso o
UTRANSim, o cenário e parâmetros utilizados bem como os resultados do
funcionamento conjunto entre o módulo que implementa o TCP e o simulador de
HSDPA.
Capítulo 4 - neste capítulo são apresentadas as conclusões sobre o trabalho e
perspectivas de continuidade.
Capítulo 2O TCP e seus problemas em redes
sem fio
2.1 Introdução
O TCP tem particularidades que o tornam robusto e confiável. Essas
características são implementações dos mecanismos de controle de fluxo e de
congestionamento, mas em muitas vezes não são adequados às redes sem fio.
Neste capítulo serão abordados além destes, outros mecanismos particularizados
por algumas versões deste protocolo e também outros detalhes não expostos no
Capítulo 1. No final do capítulo serão apresentados alguns resultados ilustrativos do
seu funcionamento em uma rede sem fio a partir da implementação de um simulador
simplificado.
2.2 Cabeçalho TCP
A figura 2.1 exibe as partes do cabeçalho TCP.
Segue a descrição dos campos do cabeçalho TCP vistos na figura 2.1 de acordo
com a referência [3].
◮ source port/destination port : identificam as portas das camadas de
aplicação da origem e do destino.
◮ sequence number: normalmente especifica o número assinalado para o
primeiro byte de dados na mensagem corrente. Na fase de estabelecimento
de uma conexão, pode ser usado como uma identificação da transmissão.
21
Figura 2.1: Cabeçalho do protocolo TCP.
◮ acknowledgement number: contém o número sequencial do próximo byte
de dados que o dispositivo de origem espera receber.
◮ header length : número de palavras de 32 bits do cabeçalho TCP. Essa
informação é necessária porque o campo options é variável.
◮ reserved : reservado para uso futuro.
◮ flags : usado para uma variedade de informações de controle. Segue a descrição
sucinta de cada um deles:
• URG : Quando setado em 1 indica que o urgent pointer está sendo
utilizado.
• ACK : é atribuído o valor 1 quando acknowledgement number é válido.
Caso seja setado em zero, indicará que o segmento não contém uma
confirmação e, nesse caso, o campo acknowledgement number é ignorado.
• PSH : indica dados com o flag PUSH. Com este bit setado, o receptor é
solicitado a entregar os dados para a aplicação mediante sua chegada.
• RST : é utilizada para reiniciar uma conexão em que tenha ocorrido uma
falha. Também é usado para rejeitar um segmento inválido ou para
recusar uma conexão.
22
• SYN : é utilizado para estabelecer uma conexão.
• FIN : é utilizado para encerrar uma conexão.
◮ window : indica quantos bytes podem ser enviados a partir do byte
confirmado. O valor zero para este campo é válido e indica que todos os
dados até aknowledgement number - 1, inclusive, foram recebidos mas que o
receptor precisa de tempo para poder aceitar novos dados, ocasião em que um
valor diferente de zero é atribuído ao campo.
◮ checksum : verificação da integridade do cabeçalho.
◮ urgent pointer : é usado para indicar um deslocamento de bit no número de
sequência no qual os dados urgentes deverão estar.
◮ options: Campo utilizado para carregar informações adicionais não previstas
nos outros campos do cabeçalho TCP.
◮ data : contém cabeçalho e dados da camada de aplicação. O seu comprimento
é variável, podendo ser zero ou mais bytes.
2.3 Mecanismo de retransmissão
Para o adequado funcionamento do TCP o tempo total de ida e volta,
o RTT, deve ser medido a cada envio de pacote, uma vez que esse valor
certamente irá mudar durante o tempo. Esta medição é fundamental para atualizar
adequadamente o timeout de retransmissão, o RTO (do inglês Retransmission
Timeout). Primeiramente, o TCP deve monitorar o RTT entre o envio de um
segmento e o recebimento de sua confirmação. De posse desse valor o RTT (denotado
na fórmula por R) é atualizado de acordo com a equação 2.1, onde M representa
o antigo valor do RTT medido após a confirmação anterior e α é um fator de
amortização que determina o peso dado a M . Normalmente α = 7/8.
R = α ∗ R + (1 − α) ∗ M (2.1)
Esse valor amortizado do RTT é atualizado sempre que uma nova medida é
feita. Após o cálculo da estimativa do RTT, o RTO será modificado de acordo com
23
a equação 2.2, como recomendado na RFC 793, onde β é um fator de variância do
atraso com valor recomendado de 2 [14].
RTO = R ∗ β (2.2)
2.4 Controle de Fluxo
O mecanismo de controle de fluxo evita que um receptor lento seja sobrecarregado
por fluxos de dados maiores do que ele pode lidar. Consequentemente, um
transmissor que envia dados em uma taxa consideravelmente rápida deve ajustar sua
transmissão de dados para uma taxa conveniente para ambos os pontos da conexão.
Na prática, o fluxo de dados deve sempre operar na menor taxa oferecida entre as
duas extremidades de comunicação, o que diz respeito aos buffers de recepção e
transmissão e também à capacidade de vazão da rede que os separa.
O protocolo de janela deslizante é o mecanismo que implementa o controle de
fluxo, e todas as versões do TCP devem ser compatíveis com este protocolo. Com o
emprego desta técnica obtém-se uma transmissão confiável, uma melhor utilização
da largura de banda da rede e uma melhor vazão dos dados [15].
O TCP da entidade transmissora dispara um temporizador sempre que um
segmento da janela é enviado. Ao chegar no destino, a entidade TCP receptora
retorna um segmento com um número de confirmação igual ao próximo número de
sequência que espera receber. Se o temporizador do transmissor expirar antes que a
confirmação seja recebida, o segmento será retransmitido e uma nova temporização
para aquele segmento é iniciada.
Como os segmentos podem ser fragmentados, é possível que uma parte do
segmento chegue e seja confirmada pela entidade TCP receptora enquanto o restante
é perdido. Os segmentos também poderão perder tanto tempo em trânsito que
o temporizador do transmissor pode acabar expirando sendo necessário enviar os
segmentos outra vez. Se um segmento retransmitido seguir uma rota diferente da
original, e for fragmentado de outra forma, partes do segmento original e de sua
duplicação poderão chegar esporadicamente exigindo uma administração criteriosa
para se conseguir um fluxo de dados confiável. Com tantas redes diferentes formando
24
a Internet, é possível que um segmento encontre uma rede congestionada ou fora do
ar em seu caminho [3, 14].
Portanto, ao enviar um ACK ao transmissor, o receptor indica o número de
bytes que ele pode receber além do último segmento recebido do TCP, sem causar
sobrecarga nos seus buffers.
Além disso, o tamanho da janela é determinado pelo receptor quando a conexão
é estabelecida podendo ainda ser ajustado durante a transferência de dados [5].
Na figura 2.2 está representado o mecanismo de janela deslizante. Em (a), o
transmissor usa uma janela deslizante de seis segmentos. Em (b), os segmentos 1,
2 e 5 são recebidos. O ACK da recepção dos segmentos 1 e 2 é enviado e a janela
desliza dois segmentos, permitindo com isso, a transmissão dos segmentos 7 e 8. Em
(c), os segmentos de 3 a 6 são retransmitidos quando seus timeouts expiram. Já em
(d), o ACK de recebimento dos segmentos de 1 a 7 é enviado e os segmentos de 8 a
13 podem ser transmitidos.
2.5 Controle de Congestionamento
Quando uma carga oferecida a qualquer rede excede sua capacidade, acontece
um congestionamento. Tradicionalmente, o congestionamento é tratado através da
redução da taxa de transmissão, tarefa esta realizada pelo TCP.
No momento em que uma conexão é estabelecida, deve-se escolher um tamanho
de janela adequado. O receptor pode especificar uma janela a partir do tamanho de
seu buffer. Se o transmissor se mantiver dentro do tamanho da janela especificada
pelo receptor, não haverá problemas de sobrecarga dos buffers na extremidade
receptora, mas eles ainda podem ocorrer devido a congestionamentos internos na
rede.
Com isso, percebe-se que existem dois problemas: a capacidade da rede e a
capacidade do receptor. Por isso o TCP trabalha com as janelas de transmissão
(TXWND), recepção (RXWND) e de congestionamento (CWND). O transmissor
mantém a janela fornecida pelo receptor e a janela de congestionamento, onde, em
um dado momento, o número de bytes que o transmissor pode enviar é o valor
mínimo entre as janelas de recepção e congestionamento, ou seja:
TXWND = min(CWND, RXWND) (2.3)
25
1 2 3 4 5 6 7 8 9 10 11 12
Origem Destino
1 2 3 4 5 6
1 2 3 4 5 6 7 8 9 10 11 12
Origem Destino
7 8
1 2 3 4 5 6 7 8 9 10 11 12
Origem Destino
3 4 5 6
1 2 5
1 2 3 4 5 6 7 8 9 10 11 12 13
Origem Destino
8 9 10 11 12 13
ACK 3
ACK 8
1 2 5
1 2 3 4 5 6 7
( a )
( b )
( c )
( d )
Figura 2.2: Mecanismo de janela deslizante.
Quando uma conexão é estabelecida, o transmissor ajusta a janela de
congestionamento ao tamanho do segmento máximo ou MTU (do inglês Maximum
Transmission Unit) em uso na conexão. Em seguida, ele envia um MTU e se
esse segmento for confirmado antes de ocorrer um timeout, o transmissor incluirá o
número de bytes de um segmento na janela de congestionamento de modo que ela
tenha capacidade equivalente a dois MTU e enviará dois segmentos. à medida que
cada um desses segmentos for confirmado, a janela de congestionamento é aumentada
em um tamanho de segmento máximo. Quando a janela de congestionamento chegar
a n segmentos em tamanho e se todos os n segmentos forem confirmados a tempo,
a janela de congestionamento será aumentada no número de bytes correspondentes
aos n segmentos [14].
A janela de congestionamento mantém seu crescimento exponencial até que
ocorra um timeout ou que a janela do receptor seja alcançada. Esse algoritmo é
26
conhecido como inicialização lenta (Slow Start) e todas as implementações TCP
devem ser compatíveis com ele.
O algoritmo de controle de congestionamento da Internet utiliza um limitante,
além das janelas de congestionamento e do receptor. Quando há um timeout, o
valor do limitante é definido como metade da janela de congestionamento atual
e a janela de congestionamento é reinicializada para um MTU. Em seguida , o
mecanismo de Slow Start é reiniciado, resultando em um crescimento exponencial
da janela de transmissão até atingir o limitante. A partir daí, as transmissões
bem sucedidas proporcionam um crescimento linear à janela de congestionamento
(Congestion Avoidance) em vez de dobrar o valor da janela a cada segmento. [3].
Na figura 2.3 estão indicados os mecanismos de Slow Start e Congestion
Avoidance.
0 5 10 15 20 25 30 350
10
20
30
40
50
60
70
limitante 1
limitante 2
Jane
la d
e co
nges
tiona
men
to
N° da transmissão
Slow start
Congestion avoidance
Figura 2.3: Ilustração dos mecanismos de controle de congestionamento.
2.6 Versões do TCP
Seguem algumas das principais versões do TCP com suas evoluções a fim
de minimizar os problemas ocasionados pelo congestionamento e controle da
banda disponível, destacando-se as diferenças entre as versões. Para esta seção
abordaremos as versões mais tradicionais na linha evolutiva do TCP a saber: Old
Tahoe, Tahoe, Reno e New Reno como abordado em [16] e implementadas durante
os estudos de mestrado, e também SACK [17] e Vegas [17–19], incluídos devido à
27
sua relevância para o tema abordado.
2.6.1 Old Tahoe
A primeira versão tratada aqui é a Old Tahoe [20]. Nesta versão do TCP
estão implementados as estratégias básicas de controle de fluxo e controle de
congestionamento através de algoritmos que futuramente foram modificados e
caracterizaram outras versões, porém as similaridades são mantidas com a versão
original do protocolo.
O protocolo TCP originalmente se baseia no estabelecimento e término de uma
conexão, num mecanismo de controle de fluxo, no uso de uma sequência de números
de forma confiável, na entrega ordenada dessa sequência e em um timeout baseado
em uma estratégia de retransmissão.
2.6.2 TCP Tahoe
O TCP Tahoe [14, 21] acrescentou um novo mecanismo de retransmissão
denominado Fast Retransmit.
Fast Retransmit
Modificações no algoritmo de Congestion Avoidance foram propostas em 1990
por Jacobson. O TCP é obrigado a gerar uma confirmação imediata (um ACK
duplicado ou DUPACK) quando um segmento fora de ordem é recebido. A finalidade
deste DUPACK é indicar ao emissor que um segmento foi recebido fora de ordem e
qual o número de sequência esperado.
Partindo do fato que não se sabe se um DUPACK foi causado por um segmento
perdido ou somente uma reordenação de segmentos, espera-se que um pequeno
número de ACK’s duplicados sejam recebidos antes que qualquer atitude seja
tomada. É assumido que, se for somente uma reordenação de segmentos, só serão
recebidos um ou dois ACK’s duplicados antes do segmento fora de ordem alcançar
o destino e ser processado, o que implicará em um novo ACK.
Se três ou mais ACK’s duplicados forem recebidos em seguida, é um forte indício
que um segmento foi perdido. Com a implementação do Fast Retransmit, o TCP
realiza, então, a retransmissão imediata do que aparenta ser o segmento perdido,
sem esperar que o cronômetro de retransmissão expire (timeout).
28
2.6.3 TCP Reno
O Reno foi criado para resolver o problema de longa espera do emissor para
retransmissão quando um segmento era perdido no Tahoe. Assim como o Tahoe,
ele atribui um segmento para sua janela de congestionamento até que um certo
tempo seja expirado (timer). Aqui, o mecanismo de retransmissão rápida tem o
objetivo de disparar a transmissão de um segmento perdido e é executado quando
três ACK’s duplicados para um segmento são recebidos antes da ocorrência de um
timeout. Nesta versão do TCP, um novo mecanismo é adicionado chamado Fast
Recovery, que cancela a fase de início lento após uma retransmissão rápida. Esta é a
versão mais difundida atualmente na Internet e que está implementada na maioria
dos sistemas operacionais.
O TCP Reno não diferencia as confirmações recebidas durante o funcionamento
do Fast Recovery, sejam elas parciais ou não e sim reconhece todos os dados
pendentes no início do algoritmo de recuperação rápida, prejudicando o seu
desempenho, pois sua janela é reduzida repentinamente, ao invés de só uma redução
ser suficiente para contornar a situação de congestionamento.
Fast Recovery
Após o Fast Retransmit, ao invés do TCP executar o Slow Start, ele entrará na
fase de Congestion Avoidance. Este é o algoritmo de Fast Recovery.
A razão pela qual não se faz Slow Start nesse caso é que o recebimento de ACKs
duplicados diz mais do que simplesmente se um segmento foi perdido. Sabe-se que
o destino só pode gerar ACKs duplicados quando outro segmento for recebido, isto
é, o segmento deixou a camada física e está no buffer do destino. Logo, ainda
temos dados trafegando entre os dois nós. Então, não é aconselhável reduzir o fluxo
abruptamente usando o Slow Start.
Fast recovery só é executado se um pacote perdido tiver sido detectado pelo
Fast Retransmit. O recebimento de confirmações duplicadas indica que ainda
existem alguns pacotes pela rede, o que é visto como um estado moderado de
congestionamento.
Após o Fast Retransmit, o TCP Reno deduz que há congestionamento na rede e
reduz sua CWND pela metade mais três segmentos e seta o valor do limitante para
a metade do valor atual da CWND. Nesse momento, para cada ACK duplicado
29
que chegar, o transmissor aumenta a CWND em um segmento e procura enviar
um novo segmento. Um RTT após a retransmissão do segmento perdido, o ACK
é então recebido (considerando que este segmento não tenha sido perdido). O
Fast Recovery é finalizado quando a primeira nova confirmação chegar e o Reno
executará diretamente o Congestion Avoidance a partir da metade da janela de
congestionamento da perda anterior.
2.6.4 TCP New Reno
Fast Recovery Extended
No TCP New Reno, quando K ACK’s são recebidos, a estratégia do Fast
Retransmit é aplicada da mesma forma que no TCP Reno, porém o processo de
recuperação de falhas é diferente. Quando uma perda de pacote é detectada usando
o Fast Retransmit, o maior número de sequência transmitido é armazenado, e logo
em seguida o Fast Recovery é iniciado. O Fast Recovery é somente finalizado
quando uma confirmação para o maior número de sequência enviado antes da perda
é recebido.
Durante a fase de Fast Recovery do New Reno, perdas adicionais são detectadas
pela recepção de ACK’s parciais. Um ACK parcial é uma confirmação para novos
dados, porém com número de sequência menor do que o do maior pacote de dados
transmitido antes da perda.
Pelo uso do mecanismo do New Reno é possível recuperar múltiplos pacotes
perdidos por janela de congestionamento sem que ocorra um timeout. Uma perda
de pacote é retransmitida a cada RTO. Este comportamento modificado melhora a
vazão de dados se comparado com o TCP Reno porque o Reno inicia várias vezes o
Fast Recovery se múltiplos pacotes por janela são perdidos, diminuindo várias vezes
a janela de congestionamento. O Reno é incapaz de se recuperar mesmo após um
segundo pacote ser perdido, enquanto o New Reno se recupera de todas as perdas
de pacotes [17].
2.6.5 TCP SACK (Selective Acknowledgement Options)
O TCP com Selective Acknowledgments [17] (SACK) é uma extensão das versões
Reno e New Reno. O uso de SACK permite ao receptor adicionar diversos pacotes de
dados que foram recebidos fora de ordem dentro de uma confirmação duplicada, ao
30
invés de só colocar no último pacote recebido em ordem. Esta informação permite ao
transmissor retransmitir pacotes perdidos mais rápido do que um pacote por Round
Trip Time. Na estratégia do SACK, o receptor envia de volta ao transmissor pacotes
de reconhecimento contendo informação de todos os segmentos já recebidos, ainda
que fora de ordem, possibilitando ao TCP condições de inferir com maior rapidez
quantos e quais segmentos foram perdidos ou mesmo atrasados na rede.
O mecanismo de reconhecimento seletivo do SACK utiliza o campo "Options"do
TCP para transportar as informações de sequência de segmentos recebidos. No
estabelecimento da conexão TCP, o pacote de sincronismo SYN informa se o
reconhecimento seletivo está habilitado, o que diz ao receptor que a origem é
capaz de lidar com pacotes de reconhecimento SACK. Esta indicação será lembrada
pelo receptor, que, caso também esteja preparado, utilizará o SACK sempre que
necessário em seus pacotes de reconhecimento.
2.6.6 TCP Vegas
O TCP Vegas [17] propõe suas próprias e originais estratégias de controle de
congestionamento e retransmissão. O objetivo principal do seu mecanismo de
controle de congestionamento é detectar o começo do congestionamento e diminuir a
taxa de transmissão antes que as perdas ocorram. Para conseguir isto, uma medida
para o congestionamento na rede é necessário.
O TCP Vegas mede o congestionamento de rede comparando uma vazão de
dados prevista à vazão real da conexão, ou seja, monitorando a diferença entre a
taxa esperada e a taxa medida. Para a vazão esperada, um RTT base é definido,
no qual é o menor RTT que a conexão experimentou durante o seu tempo de vida.
O Vegas assume que este é o RTT de uma rede descongestionada. Uma vez que
o RTT Vegas computa a vazão esperada da conexão, o TCP Vegas atualiza sua
janela de congestionamento baseado no resultado desta comparação de vazão. A
maneira como esta atualização é executada é mais uma vez dependente da fase
atual do mecanismo de controle de congestionamento do TCP Vegas (Slow Start e
Congestion Avoidance).
Durante o Slow Start, o TCP Vegas só dobra sua janela de congestionamento a
cada segundo de RTT, ao contrário de cada RTT para outras variações do TCP. Em
RTTs alternativos, a janela é mantida em seu tamanho anterior para poder fazer as
31
medidas de vazão mencionadas anteriomente. Depois que a vazão prevista e a real
são computadas, o Vegas executa a diferença entre a vazão de dados que é esperada
e a vazão atual. Se esta diferença for maior que o limitante predefinido, o Vegas
muda de Slow Start para Congestion Avoidance.
A atualização da janela durante o Congestion Avoidance também é baseada na
diferença entre a vazão atual e a vazão esperada. Se a diferença estiver abaixo de
um limitante α, a janela de congestionamento é aumentada linearmente durante
o próximo RTT enquanto está no Congestion Avoidance do TCP tradicional.
Se a diferença de vazão estiver acima de um outro limitante β, a janela de
congestionamento é diminuída linearmente durante o RTT seguinte. A janela de
congestionamento não muda para o RTT seguinte se a diferença estiver entre aqueles
dois limitantes.
Para atualizar a janela quando a rede não está congestionada a vazão de dados
deve aumentar proporcionalmente ao aumento da CWND. Se isto não for muito
longo, então a conexão tem muitos pacotes nos buffers dos roteadores intermediários
e a rede está próxima de um estado congestionado. Para aliviar o congestionamento,
a taxa de transmissão deve ser reduzida, o que é medido pelo limitante β. De outra
forma, se a vazão real for muito próxima da prevista, então a conexão não tem
muitos pacotes extras no buffer para tomar vantagem de um aumento repentino na
largura de banda da rede. A taxa de transmissão deve ser aumentada de α. Os dois
limitantes definem o número ideal de pacotes que a conexão deve ter nos buffers da
rede.
2.7 O TCP operando em redes sem fio
Em ambientes de redes sem fio, é comum que alguns eventos, que não
correspondam propriamente a um congestionamento (tal como perdas de blocos
devido a ruídos no canal), façam com que os pacotes não cheguem ao seu destino,
uma vez que os enlaces de dados das transmissões sem fio são, por natureza, muito
mais susceptíveis a erros. Nesse caso, a melhor estratégia para lidar com pacotes
perdidos é enviá-los novamente o mais rápido possível [6, 22–24].
Com frequência, o caminho entre transmissor e receptor é formado por diversas
redes diferentes. Parte do caminho pode ser controlada por uma rede com fio e
outra por uma rede sem fio. Nessas circunstâncias, é mais difícil ainda tomar uma
32
decisão em relação ao timeout, pois é necessário saber onde ocorreu o problema. A
seguir serão discutidos diversos pontos que limitam o desempenho do protocolo TCP
quando este opera em ambientes sem fio.
2.7.1 Longos tempos de resposta na rede
Em geral o meio sem fio apresenta RTT’s bem maiores do que os meios com
fio o que afeta diretamente a vazão final atingida pela conexão e percebida por
usuários finais. A figura 2.4 ilustra uma configuração típica de comunicação
cliente/servidor que mostra as diferenças entre os tempos de acesso a um servidor
remoto em meios diferentes de acordo com [6]. Na parte superior está mostrada
uma conexão que trafega por uma rede com fio com tempo de resposta (RTT) entre
transmissor/receptor da ordem de 70ms. Como podemos observar na parte inferior
da figura o meio agora é sem fio e o tempo de atraso é cerca de quatro vezes maior que
o anterior. Se assumirmos que dois usuários das duas redes acessem simultaneamente
o mesmo servidor remoto requisitando algum objeto HTTP (do inglês Hypertext
Transfer Protocol), por exemplo, fatalmente observaremos um cenário em que o
crescimento das janelas de congestionamento serão bem diferentes atingindo assim
níveis de vazão com muito pouca similaridade.
1 ms
1 ms
33 ms
33 ms
105 ms
Receptoresmoveis
Receptorfixo
Servidor
Figura 2.4: Observação dos tempos de resposta em redes com e sem fio.
2.8 Mitigando os problemas do TCP em redes sem fio
Existem inúmeras propostas para adequar o TCP às características inerentes ao
ambiente de redes sem fio [25–30]. Esta seção descreve várias abordagens que foram
propostas para atacar o problema de desempenho do TCP nas redes sem fio.
33
2.8.1 Abordagem split-connection
A abordagem split-connection [31–33] propõe a divisão de uma conexão entre
duas redes distintas na estação-base em partes pertencentes ao enlace com fio
e a outra ao enlace sem fio. A ideia básica é que um protocolo especializado
em ambientes sem fio (ou mesmo o TCP modificado) poderia ser utilizado neste
enlace para reagir apropriadamente à perda de pacotes. Uma possibilidade na
modificação do TCP para adequá-lo a um ambiente com muitos erros seria que
ao invés de disparar os mecanismos de controle de congestionamento tradicionais,
a nova abordagem enviaria o mais breve possível os pacotes supostamente perdidos
na rede.
Muitas propostas já foram feitas em cima da abordagem do split-connection
como em [34] onde os autores propõem o Indirect-TCP (I-TCP) que usa um roteador
especial que dá suporte a mobilidade, o MSR (do inglês Mobile Support Router), para
separar os dois enlaces e que ficaria na estação-base. Os controles de fluxos das duas
partes da conexão são distintos, ou seja, as janelas de congestionamento são mantidas
separadas. Quando um móvel da parte sem fio passa para o controle de uma outra
estação-base, o MSR desta assume a conexão anterior de forma continuada.
O I-TCP possui algumas desvantagens como, por exemplo, a manipulação de
handoffs não é tão eficiente como deveria, pois esse processo pode levar muitas
centenas de milissegundos, tempo suficiente para degradar a performance do TCP.
Além do mais, um problema no handoff acarretaria falha na comunicação como um
todo. Outro fato é que o I-TCP não é apropriado quando o último enlace não é
o sem fio porque a separação deveria ocorrer várias vezes entre os dois terminais
e diferentes combinações de subredes seriam envolvidas acarretando muita perda
de desempenho. O problema da perda de semântica do TCP, que é um dos mais
importantes para as abordagens split-connection, é outra desvantagem dessa solução
pois os ACK’s são individualizados para cada uma das partes envolvidas uma vez
que quem faz o papel do emissor seria o roteador intermediário e não a outra ponta.
Outra proposta é o M-TCP (do inglês Mobile TCP) [35] que também separa a
conexão TCP em duas partes, porém preserva a semântica do protocolo e trabalha
melhor em ambientes com altas taxas de erros, roamings ou desconexões. Este
protocolo necessita de melhorias na camada de enlace para prover seus serviços de
34
forma satisfatória.
2.8.2 Abordagem baseada na camada de enlace
Observou-se que a principal causa do baixo desempenho de protocolos confiáveis
da camada de transporte como o TCP é justamente as diferentes características
dos ambientes com e sem fio, dado que aquele foi desenvolvido originalmente para
ambientes com fio. Com base nessa observação uma boa forma de atacar o problema
é saná-lo logo na sua raiz, ou seja, empregar técnicas que trabalhem nas camadas
inferiores como na de enlace. Ao invés de se modificar o TCP, pode-se esconder dele
as perdas na rede sem fio. Os protocolos que trabalham no topo da camada física
tem imediato conhecimento dos quadros perdidos e com isso podem responder bem
mais rápido a esse comportamento do que os protocolos de camadas de maior nível
na pilha. Concomitante a este fato, os protocolos da camada de enlace têm maior
controle sobre o aqueles da camada física e com isso podem prover aos protocolos
da camada de transporte um meio similar àquele da rede com fio [36, 37]. Dessa
forma, a heterogeneidade do meio inserida na rede é compensada pela camada de
enlace e deixa o meio sem fio transparente à infra-estrutura de hardware e software
empregadas, não sendo preciso qualquer modificação nos protocolos da camada de
transporte como o TCP [33,38, 39].
Os protocolos da camada de enlace deverão assegurar uma relativa confiabilidade
na entrega de pacotes, o que é geralmente feito com esquemas de Automatic Repeat
Request (ARQ) e Foward Error Correct (FEC)
2.8.3 Abordagem fim-a-fim
Nas soluções baseadas em split-connection um roteador intermediário precisa
abrir o pacote TCP e processá-lo antes que seja realmente repassado para o destino
final, quebrando com isso a semântica original do protocolo. Na abordagem fim-a-fim
apenas os nós finais participam do processo de controle de fluxo preservando assim a
semântica do TCP. Baseado nas informações do receptor o transmissor toma decisões
que refletem na dinâmica de janelamento dos pacotes trocados entre as partes, ou
seja, executa as ações de controle de congestionamento [40–42].
Nas abordagens fim-a-fim quanto melhor for a interpretação do estado da rede,
mais otimizado será a execução dos algoritmos de controle de congestionamento,
35
uma vez que estes dependem das informações repassadas pelo receptor sobre o
estado da rede. De acordo com [43] essa abordagem pode ter seus mecanismos
de controle de congestionamento realizadas de duas formas que são a reativa e a
proativa. A forma reativa é utilizada pelos algoritmos da família Reno em que
a janela de congestionamento e ajustada de acordo com as mensagens de ACKs
e DUPACKs enviados pelo receptor. O transmissor testa continuamente a rede
enviando sempre uma determinada quantidade de pacotes seguidos sem a exigência
de ACK de sua contra parte receptora. Uma vez que a capacidade da rede é
atingida haverá uma retração do tamanho da janela de transmissão de acordo com
os algoritmos apropriados e o processo reinicia de forma menos agressiva, sempre
tentando aumentar a taxa de envio quando possível. Os algoritmos de Fast Recovery
discutido nas sessões 2.6.3 e 2.6.4 melhoram consideravelmente o desempenho dessa
forma de controle reativo. A forma de controle de congestionamento proativo
procura ajustar proativamente a janela de congestionamento para um valor ótimo
baseado nas informações recebidas via ACK do receptor.
2.9 Desempenho Ilustrativo do TCP sobre uma rede sem fio
Como exposto neste capítulo, o TCP sofre com a constante perda de pacotes das
redes sem fio. Esta seção tem como objetivo mostrar esses efeitos de forma gráfica
através do uso de um simulador simplificado que procura modelar os principais
mecanismos do TCP além, servindo como precursor para as versões do TCP
implementadas no simulador dinâmico apresentado no capítulo seguinte. A rede
sem fio utilizada foi baseada apenas em parâmetros de RTT da rede e tamanhos
de bloco transmitidos em um sistema celular do tipo EGPRS (do inglês Enhanced
General Packet-switched Radio Service) [44, 45].
2.9.1 Cenário Geral da Simulação
Será apresentado o ambiente e a forma como foi feita a modelagem do problema
para a simulação. Mostra-se a idealização de alguns pontos sem, no entanto,
prejudicar a avaliação final dos resultados devido às simplificações do modelo
proposto.
Com o intuito de fornecer uma melhor visão dos problemas do TCP operando
sobre enlaces de rádio, foi criado um cenário de simulação que considera um canal
36
sem fio com a taxa de erros do canal controlada por probabilidades relativas à
transição de estados BOM e RUIM, ou seja, a probabilidade do canal mudar de um
estado bom para um ruim e vice-versa.
A modelagem do problema sugere um cenário simplificado de uma única célula
com a antena de transmissão (antena da base) localizada em seu centro. A
transmissão se faz na direção da base para o móvel (enlace direto) e as confirmações
de recebimento (acknowledgements) no sentido contrário (enlace reverso).
São elementos da modelagem deste problema uma entidade transmissora, a
Internet, uma estação-base como entidade receptora intermediária e uma estação
móvel, que recebe os dados emitidos pela estação-base de acordo com regras
específicas da rede sem fio.
Na figura 2.5, está representado um canal de comunicação entre a base e um
terminal móvel. O terminal possui uma conexão TCP/IP com a Internet. Os dados
vêm da Internet até a estação base de onde são transmitidos para o terminal móvel
usando os protocolos próprios da rede sem fio.
Figura 2.5: Célula de transmissão.
2.9.2 Modelo do Canal
A comunicação através do canal sem fio é altamente sujeita a erros devido à
atenuação da potência do sinal com a distância (perda de percurso), obstáculos
existentes no meio do percurso (sombreamento), interferência destrutiva entre as
ondas de rádio do próprio sinal (desvanecimento rápido) e interferência de outros
sinais (interferência co-canal).
Uma forma de modelar estes erros de forma bem simples é utilizar um canal
modelado sobre uma cadeia de Markov de dois estados, BOM e RUIM, com
probabilidades específicas de transição entre eles, como proposto em [46]. Ajustando
as probabilidades, diferentes perfis de erro podem ser simulados.
37
PBR
PRB
PRRPBB BOM RUIM
Figura 2.6: Modelo do canal.
No modelo considerado:
◮ PBB é a probabilidade de permanecer no estado BOM.
◮ PBR é a probabilidade de transição do estado BOM para o estado RUIM.
◮ PRR é a probabilidade de permanecer no estado RUIM.
◮ PRB é a probabilidade de transição do estado RUIM para o estado BOM.
Onde:
0 ≤ PBB, PBR, PRR, PRB ≤ 1
PBB = 1 − PBR
PRR = 1 − PRB
Variando as probabilidades de transição entre os estados, PBR e PRB, podemos
emular o comportamento de diversos canais sem fio. O modelo de erros é descrito
pela matriz de transição de estados como mostrado na equação 2.4.
M =
PRR PRB
PBR PBB
(2.4)
De acordo com [46], dada a matriz M , as propriedades do canal estão completamente
caracterizadas e a probabilidade média de erro no canal é calculada como na equação
2.5.
ε =PBR
(PBR + PRB)(2.5)
38
Convencionou-se que o canal sempre iniciará no estado BOM e para cada
transmissão realizada, sorteia-se uma variável aleatória uniformemente distribuída
entre 0 e 1 para determinar o próximo estado do canal.
2.9.3 Geração do Tráfego
O tráfego a ser considerado é de FTP e será considerado um modelo de tráfego
heurístico e bastante simplificado. Cada usuário deseja receber um arquivo de 500
kilobytes. O arquivo deverá ser segmentado de acordo com as características dos
protocolos TCP e IP.
Cada datagrama IP é então dividido em blocos de tamanho fixo de 74 bytes,
considerando que cada bloco da rede sem fio está sujeito a erros oriundos do canal,
sendo transmitido a cada 20ms. A equação 2.6 mostra como é calculada a taxa
máxima no canal sem fio, onde Lbloco é o tamanho (em bytes) do bloco a ser
transmitido e Tbloco é o tempo (em segundos) de transmissão daquele bloco na rede
sem fio.
R =Lbloco
Tbloco
=74 × 8
0.02= 29, 6kbit/s (2.6)
Os blocos são transmitidos e confirmados imediatamente na rede sem fio, isto é,
não há atraso ou erro no envio dos acknowledgements nesse segmento da rede. No
entanto, existem atrasos no segmento representando o caminho entre a rede sem fio
e a Internet. Quando um datagrama IP é completamente transmitido pela rede sem
fio, ele é considerado como transmitido com sucesso. Vale destacar que os atrasos
causados pelas altas taxas de erro do canal sem fio podem, eventualmente, disparar
os mecanismos de controle de congestionamento do TCP.
2.9.4 Critérios específicos da simulação
A seguir será apresentada uma série de gráficos que ilustram a transmissão em
um cenário como o descrito anteriormente. Para efeito de simplificação neste texto,
adotaremos como probabilidades de um canal mudar de um estado bom para um
estado ruim e vice-versa como o par ordenado Pch(PBR,PRB), onde as probabilidades
são dadas em termos percentuais. Foram escolhidos os seguintes canais:
◮ Canal ideal, ou seja, Pch( 0 , 100 ) ou Pch( 0 , * ), onde * representa um valor
39
qualquer;
◮ Pch( 10 , 90 ) equivalente a ε = 0.1;
◮ Pch( 10 , 60 ) equivalente a ε ≃ 0.14;
◮ Pch( 50 , 60 ) equivalente a ε ≃ 0.55;
2.9.5 Resultados
Na figura 2.7, percebe-se os processos de Slow Start e Congestion Avoidance
ocorrendo sem interrupções de timeout. A transmissão do arquivo de 500 KB é
iniciada e atinge uma vazão máxima de 29,58 Kbps. Ao final da transmissão, ocorre
uma queda no tamanho da janela de congestionamento, porém isso denota apenas
o ajuste para uma quantidade de segmentos restantes inferior ao tamanho de janela
corrente.
As figuras 2.8 e 2.9 ilustram o desempenho do TCP em um canal não-ideal. Nelas
são mostrados diversos pontos de ocorrência de timeouts durante uma simulação da
transmissão do mesmo arquivo anterior, causando uma queda significativa da taxa
de transmissão.
0 2 4 6 8 10 12 14 16 18 200
10
20
30
40
50
60
70
80
Limitante
Throughput: 29,58 Kbps Tamanho do arquivo: 500 KB
Envio da última janela restante
Canal ideal
Jane
la d
e co
nges
tiona
men
to
N° da transmissão
Figura 2.7: Desempenho do TCP para um canal ideal (ε = 0). Tempo de simulação:135, 23s.
40
0 10 20 30 40 50 60 70 800
10
20
30
40
50
60
70
timeout
limitante
limitante
Throughput: 25,20 Kbps Tamanho do arquivo: 500 KB
Jane
la d
e co
nges
tiona
men
to
N° da transmissão
Canal : Pch (10,60)
Figura 2.8: Desempenho do TCP para um canal pouco ruidoso (ε = 0.14). Tempo desimulação: 158, 73s.
0 100 200 300 400 500 600 7001
1.5
2
2.5
3
3.5
4
4.5
5
5.5
6Canal : Pch (50,60)
Jane
la d
e co
nges
tiona
men
to
N° da transmissão
Janela máxima Throughput: 12,20 Kbps Tamanho do arquivo: 500 KB
Figura 2.9: Desempenho do TCP para um canal muito ruidoso (ε = 0.55). Tempo desimulação: 327, 87s.
41
2.9.6 Conclusões
Os resultados apresentados nesta seção, mostram como a variação de parâmetros
do link sem fio interfere no desempenho do TCP. Observa-se que, variando a
qualidade do canal, ocorre uma maior quantidade de timeouts e, em consequência,
há uma queda significativa da vazão de dados final.
A ferramenta, apesar de simplificada, pôde demonstrar os diversos pontos
onde ocorrem os ajustes de janela de transmissão do TCP, contribuindo para as
implementações mais precisas utilizadas no simulador dinâmico apresentado no
Capítulo 3.
Capítulo 3Análise de Desempenho Conjunta
dos Protocolos TCP, RLC e MAC-hs
em Redes Celulares HSDPA
3.1 Introdução
A confiabilidade provida pelo protocolo de transporte TCP é muito interessante
para as aplicações devido à entrega de mensagens livres de erros. Como exposto no
Capítulo 1, a grande maioria do tráfego na Internet é baseado na pilha de protocolos
TCP/IP, por isso é importante o estudo do TCP quando se avalia o comportamento
de aplicações em redes sem fio como o HSDPA. O efeito do controle de fluxo do
TCP tem forte impacto tanto para os usuários finais quanto para o desempenho da
rede sem fio e por isso deve ser seriamente considerado, principalmente na análise
de serviços de tempo não-real (do inglês NRT - Non Real Time) [8].
3.2 Tráfego TCP sobre HSDPA
Com o intuito de aumentar o desempenho na transmissão de pacotes em redes
UMTS baseadas em WCDMA foi desenvolvido um conceito de altas velocidades
no acesso de pacotes através do canal direto em transmissões celulares (o
HSDPA propriamente dito). O HSDPA oferece mais um canal de transporte
compartilhado, o HS-DSCH. As características do canal de transporte HS-DSCH
foram implementadas para aumentar o desempenho na entrega de pacotes de dados
43
atingindo uma significante vazão na célula, características estas devidas a uma
combinação de modulações de altas ordens e um rápido escalonamento de pacotes
[47].
Do ponto de vista do TCP, um dos mais relevantes mecanismos do HSDPA é
o Hybrid Automatic Repeat Request ou H-ARQ. A inclusão do mecanismo H-ARQ
adiciona uma outra camada que executa retransmissões atuando contra o problema
de transmissões sem sucesso ao longo do enlace de rádio. Na figura 3.1 são
mostrados os três níveis de retransmissões que se observam quando o TCP atua
juntamente com o HSDPA. Ao nível TCP, as retransmissões ocorrem sempre que são
detectados pacotes perdidos na camada de transporte devido à ação dos algoritmos
de controle do TCP descritos no Capítulo 1. Na RLC, as retransmissões também
ocorrem prevenindo perdas não corrigidas no nível físico que por sua vez executa
retransmissões através do H-ARQ. Uma vez que as retransmissões do H-ARQ são
feitas a nível físico, ou seja, no próprio Node B, o atraso de retransmissão geral é
bem menor do que nas retransmissões da RLC que são executadas na RNC. Além
do mais, a utilização dos mecanismos de soft combining e redundância incremental
melhoraram o desempenho dos mecanismos ARQ convencionais.
INTERNET & CN
RNC
Servidor
Node B Receptor
TCP RTX
RLC RTX
MAC-hs RTX
Figura 3.1: Diversos níveis de retransmissões.
3.3 Cenário de simulação
O simulador dinâmico utilizado daqui em diante é bem diferente daquele
primeiro, mostrado no Capítulo 2, que modelava simplificadamente alguns
44
parâmetros de uma rede sem fio. Neste simulador existem vários usuários em diversas
células. Os usuários chegam, são servidos pelo sistema e deixam de interagir com o
mesmo posteriormente, em um ciclo de nascimento e morte das conexões.
3.3.1 Geração de tráfego
O tipo de tráfego utilizado nas simulações foi o de web browsing por ser este o
serviço mais popular na Internet hoje em dia. De fato, a navegação por páginas de
hipertexto é essencial para o sucesso da Internet. Este sucesso também é refletido
no domínio de redes sem fio onde representa uma fração substancial da carga total
de dados oferecida aos sistemas. Este tipo de tráfego pode ser eficientemente
manipulado por redes sem fio, uma vez que é um tipo de serviço interativo com
modestos requisitos de QoS (do inglês Quality of Service).
O modelo de tráfego implementado segue as especificações baseadas na referência
[48] e pode ser sumarizado na tabela 3.1.
Tabela 3.1: Modelo de tráfego de web browsing implementado.
Descrição Distribuição Parâmetros
Número de chamadas de pacotes por sessão Geométrica 10 (média)
Número de pacotes por chamada de pacote determinístico 1
Tempo de leitura por chamada de pacote Pareto trucada α = 1, 4
k = 3, 45
m = 120s
Tamanho da chamada de pacote (byte) Lognormal µ = 4.100
σ = 30.000
Tamanho máximo do pacote determinístico 100.000bytes
3.3.2 Descrição das principais características do UTRANSim
A ferramenta de simulação utilizada nesta Dissertação de Mestrado é o
UTRANSim. A seguir será feita uma breve descrição de suas principais
características.
O simulador UTRANSim é uma nova ferramenta de simulação desenvolvida
pelo GTEL (Grupo de Pesquisas em Telecomunicações sem Fio sediado no campus
do Pici da Universidade Federal do Ceará) que simula o funcionamento em
sistema multicelular e multiusuário baseado nos padrões WCDMA e HSDPA. Esta
45
Parâmetros de
Configuração
Interfaces de
Acesso de Rádio
Interface
WCDMA
Interface
HSDPA
Tráfego de
Dado
Modelos de
Tráfego
Pilha de
Protocolo
Interface
Link to
System
Funcões de
RRM
Figura 3.2: Estrutura funcional do UTRANSim.
ferramenta foi validada confrontando seus resultados com resultados de outras
ferramentas de simulação semelhantes e outros trabalhos existentes na literatura
acadêmica. Uma descrição mais detalhada pode ser encontrada em [49].
No UTRANSim, as interfaces aéreas dos sistemas WCDMA e HSDPA são
incorporadas em um bloco funcional comum, onde podem operar separada ou
conjuntamente. A parte WCDMA opera através do canal DCH enquanto que a
parte HSDPA implementa o novo canal compartilhado HS-DSCH. A interface aérea
do WCDMA pretende principalmente cobrir o tráfego conversacional do UMTS,
enquanto os usuários de altas taxas de dados serão conectados principalmente à
rede servida através do canal HS-DSCH.
A figura 3.2 apresenta a estrutura funcional do UTRANSim. A entrada de
dados corresponde aos parâmetros de configuração que são passados ao programa
procurando-se configurar e controlar a execução das simulações, como por exemplo,
a carga de usuários no sistema, perfis de tráfego e mobilidade, interface de acesso
de rádio, e assim por diante. A parte de acesso de rádio compreende as interfaces
aéreas WCDMA e HSDPA e suas especificidades de implementações.
A parte de tráfego de dados corresponde aos diversos modelos de tráfego
suportados pelo simulador (WWW, FTP, e-mail, entre outros) e a pilha de
46
protocolos, que constitui a principal diferença entre os módulos WCDMA e HSDPA,
uma vez que o primeiro implementa um canal dedicado e o último implementa um
canal compartilhado.
A pilha de protocolos modelada no UTRANSim está composta atualmente pelas
camadas RLC, MAC e a camada física como mostrada na figura 3.3, além das
camadas superiores. O simulador foi construído para ser flexível de tal forma que
permita a inclusão de novas camadas no topo da RLC, como por exemplo, a camada
de transporte contendo os protocolos TCP/IP que foi implementada e anexada
para efetuarmos as simulações apresentadas mais adiante neste trabalho. A pilha é
alimentada por pacotes criados na entidade de sessão que modela as características
do tráfego desejado. Como mencionado anteriormente, foi utilizado aqui o tráfego
de web browsing, ou seja, de WWW.
Pacotes da sessão
RLC RRC
MAC
PHY
TCP
Figura 3.3: Camadas e protocolos do UTRANSim incluindo o TCP.
Uma vez que o HSDPA e o WCDMA compartilham a mesma estrutura de rede,
a camada RLC para o HSDPA é modelada de forma idêntica à do WCDMA. As
principais funções desta camada estão listadas brevemente abaixo.
◮ Segmentação e reagrupamento;
◮ Concatenação;
◮ Padding ;
47
◮ Controle de fluxo, que gerencia o transporte de dados entre o buffer da RLC
e o da MAC-hs.
Os tipos de serviços que a RLC provê para as camadas de cima são os seguintes:
◮ Transferência de dados em modo transparente;
◮ Transferência de dados em modo confirmado (acknowledged);
◮ Manutenção de QoS como definido pelas camadas superiores.
Para as simulações realizadas com tráfego WWW é utilizado o modo
acknowledged.
3.3.3 Parâmetros de simulação utilizados
No simulador dinâmico apresentado brevemente na seção anterior foi configurado
a operação para o HSDPA. No sistema há um gerenciamento do tráfego gerado por
cada usuário. Esse tráfego atravessa toda a pilha de protocolos sendo entregue para
a MAC-hs do HSDPA.
No módulo TCP implementado, a camada de rede onde atua o protocolo IP
(considerado aqui o IP versão 4) foi abstraída, sendo incluído somente o cabeçalho
deste protocolo que é de 20 bytes. Um sumário dos principais parâmetros de
simulação é feito na tabela 3.2. A versão do TCP utilizada para a obtenção
dos resultados foi a New Reno, uma vez que nessa versão do TCP múltiplas
perdas de pacotes por janela são detectadas minimizando os efeitos do esquema
de gerenciamento do buffer aplicado pela RLC em certas situações de fading do
canal sem fio [13].
3.4 Resultados
Neste Capítulo, o foco está na análise do conjunto de interações entre o TCP, a
RLC e a MAC-HS , procurando observar um cenário onde se configure um melhor
conjunto de parâmetros como os tamanhos de buffers de retransmissão da RLC e
da MAC-hs atuando conjuntamente com o TCP.
48
Tabela 3.2: Parâmetros de simulação.
Parâmetro Valor
TCP
Versão utilizada New Reno
Cabeçalhos TCP e IP juntos 40 bytes
RTO inicial 1,5 seg.
RTT inicial 0,75 seg.
MSS (Maximum Segment Size) 1460 bytes
Buffer do TCP receptor 30 MSS
CWND inicial 1 MSS
Limitante inicial 30 MSS
HSDPA
Timestep 1 Slot (0.667ms)
TTI 3 Slots (2ms)
Quantidade de Nodes B 16
Quantidade de Setor/Célula 48
Interferentes 1/célula
Desvio padrão de sombreamento 8dB
Taxas de chegada de usuário 0.333, 0.4, 0.5, 0.667, 1 usuário/s
Carga de WWW oferecida 32 Kbps
Tipo de mobilidade Pedestre (3 Km/h)
Intervalo de pooling da RLC 300ms
Payload da RLC 320bits
Esquema H-ARQ Chase combining
Algoritmo de escalonamento Round Robin
3.4.1 Resultados de Integração
Os segmentos TCP a serem retransmitidos a nível da RLC apresentam um
aumento considerável do RTT devido ao processo de retransmissão. De acordo
com [8], o enfileiramento médio no Node B pode ser muito significativo, da ordem
de segundos, quando a janela de congestionamento atinge o limite imposto pelo
buffer do receptor.
As versões do TCP implementadas neste trabalho fazem parte da camada
49
TCP/IP situada conforme mostrada na figura 3.3. Dessa forma, quando
adequadamente conectadas à pilha do UTRANSim estas versões formam um módulo
funcional, podendo ser configurado qualquer uma delas para interagir com o sistema,
bastando que se passe a informação pertinente à versão desejada no conjunto de
parâmetros de início de simulação.
As figuras desta seção foram obtidas após a etapa de integração da camada que
simula o TCP e o restante do simulador UTRANSim. A partir do momento em que
se inicia a simulação, os usuários vão acessando os recursos da rede e oportunamente
deixam de interagir com o sistema. Na figura 3.4 podem ser vistas as curvas de
convergência da chegada de usuários no sistema HSDPA para quatro intervalos de
chegada (1, 0.5, 0.667 e 0.333 segundos).
0 2 4 6 8 10 12 14
x 105
0
500
1000
1500
2000
2500
3000
3500
Núm
ero
deus
uári
osno
sist
ema
Iteração
(a) 1s entre usuários
0 2 4 6 8 10 12
x 105
0
500
1000
1500
2000
2500
3000
3500
Núm
ero
deus
uári
osno
sist
ema
Iteração
(b) 0.667s entre usuários
0 2 4 6 8 10
x 105
0
500
1000
1500
2000
2500
3000
3500
Núm
ero
deus
uári
osno
sist
ema
Iteração
(c) 0.5s entre usuários
0 2 4 6 8 10
x 105
0
500
1000
1500
2000
2500
3000
3500
Núm
ero
deus
uári
osno
sist
ema
Iteração
(d) 0.333s entre usuários
Figura 3.4: Gráficos de convergência da admissão de usuários no sistema.
Para intervalos maiores entre a chegada de usuários, o sistema se estabiliza com
um número menor de usuários. A coleta de amostras para os resultados deste
50
Capítulo é feita após a relação entre a quantidade de usuários que chegam e os
que deixam o sistema se tornar aproximadamente constante. As figuras 3.5 e 3.6
mostram as curvas de vazão de pacotes com e sem a influência do TCP para diversos
tempos de chegada entre usuários.
0 200 400 600 800 1000 1200 1400 1600 18000
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
CD
F
Vazão de dados de sessão (Kbps)
1 seg
0.667 seg
0.5 seg
0.4 seg
0.333 seg
Figura 3.5: Distribuição da vazão de dados variando o tempo de chegada entre usuários.Simulador utiliza o TCP integrado com HSDPA.
Já na figura 3.7 são mostradas duas CDF’s para melhor visualizar o impacto na
vazão obtida quando se inclui o TCP. Pode-se perceber uma diminuição da vazão
quando o TCP é adicionado ao sistema. Essa retração se deve aos mecanismos
de controle de congestionamento do TCP que diminuem o tamanho da janela de
congestionamento ao se deparar com perdas de pacotes e também devido à inclusão
de cabeçalhos próprios do protocolo que diminuem a carga útil repassadas para
as camadas inferiores. Sem a inclusão da camada TCP, o UTRANSim encaminha
diretamente os pacotes gerados pela sessão de tráfego para a RLC que os processa
de acordo com seus mecanismos internos, sem o overhead de mais um nível de
segmentação e inclusão de cabeçalhos.
A figura 3.8 mostra a influência entre a taxa de chegada de usuários e a satisfação
51
Figura 3.6: Distribuição da vazão de dados variando o tempo de chegada entre usuários.Simulador com TCP desligado.
do usuário, definida conforme a equação 3.1.
SATS =NUSRSATS
USRBLCOD + USRBLPOT + USRNOBL∗ 100 (3.1)
Onde:
◮ SATS : satisfação do usuário;
◮ NUSRSATS: número de usuários que terminaram suas sessões com taxa de
sessão maior que 128 Kbps;
◮ USRBLCOD: usuários bloqueados por código;
◮ USRBLPOT: número de usuários bloqueados por potência;
◮ USRNOBL : número de usuários que não foram bloqueados, ou seja, todos
os usuários que terminaram suas sessões, independente de terem obtido uma
taxa de sessão maior ou menor que 128 Kbps (satisfeito ou insatisfeito).
52
Figura 3.7: Distribuição da vazão de dados comparativa para um tempo de chegada entreusuários de 0.333 segundos.
Com a inclusão do TCP a satisfação do usuário diminui pelos motivos já expostos
anteriormente. Para uma taxa de chegada de 1 segundo entre usuários a satisfação
no sistema sem o TCP é de 95% e com sua inclusão a satisfação para a mesma taxa
cai para menos de 92%. Para o pior caso a satisfação cai para menos de 80% em
relação aos 85% no caso de ausência da camada TCP. Já na figura 3.9 a satisfação
agora é confrontada com a eficiência espectral, porém os valores de satisfação do
usuário não diferem do gráfico anterior.
As curvas apresentadas na figura 3.10 ilustram dois percentis de atraso, o
nonagésimo e o quinquagésimo percentil, visando a traçar os perfis de atraso também
para os casos com e sem TCP. Pode ser notado que a inclusão do TCP aumenta
consideravelmente o atraso geral na entrega de pacotes pelo sistema HSDPA.
53
1 1.5 2 2.5 378
80
82
84
86
88
90
92
94
96sem TCPcom TCP
Satisfação do usuário
Sati
sfaç
ão(%
)
Taxa de sessão WWW (1/seg)
Figura 3.8: Taxa de estabelecimento de sessão WWW versus satisfação do usuário.
0.03 0.04 0.05 0.06 0.07 0.08 0.0978
80
82
84
86
88
90
92
94
96
sem TCPcom TCP
Eficiência espectral (bps/Hz/setor)
Sati
sfaç
ão(%
)
Satisfação do usuário
Figura 3.9: Eficiência espectral.
54
1 1.5 2 2.5 30
50
100
150
200
250
50o¯ perc. (TCP)
90o¯ perc. (TCP)
50o¯ perc.
90o¯ perc.
Taxa de sessão WWW (1/seg)
Atr
aso
depa
cote
s(m
ilise
gund
os)
Figura 3.10: Diversos percentis de atraso de entrega de pacotes com e sem TCP.
3.4.2 Influência do número de retransmissões da RLC e MAC-HS
A figura 3.11 mostra o décimo percentil de quatro curvas para 1, 3, 4 e 5
retransmissões da RLC fixando-se em zero (0) as retransmissões da MAC-hs. O
gráfico mostra que a configuração de quatro níveis de retransmissões na RLC fornece
uma melhor vazão ao sistema. Na mesma figura observamos que um valor acima
de quatro para o parâmetro das retransmissões o sistema apresenta uma queda de
desempenho. Isto se dá devido à baixa eficiência do esquema de gerenciamento de
buffer da RLC que pode causar consecutivas perdas de pacotes em certas situações
de atenuação do sinal, conforme descrito em [13].
O mesmo comportamento pode ser visto na figura 3.12 onde simulamos o mesmo
conjunto de retransmissões da RLC, porém fixando em dois (02) o parâmetro que
indica o número de retransmissões da MAC-hs.
A figura 3.13 ilustra o décimo percentil de seis curvas: 0, 1, 2, 3, 4 e 5
retransmissões da MAC-hs fixando-se em quatro (04) as retransmissões da RLC.
55
1 1.5 2 2.5 3 3.550
55
60
65
70
75
80
85
90
95
Vaz
ãode
dado
sde
sess
ão(K
bps)
1 RLC RTX
3 RLC RTX
4 RLC RTX
5 RLC RTX
Taxa de sessão WWW (1/seg)
Figura 3.11: Variação das retransmissões da RLC (RLC RTX) com zero retransmissõesda MAC-hs (MAC-hs RTX = 0). Décimo percentil da vazão de dados.
1 1.5 2 2.5 3 3.595
100
105
110
115
120
125
130
135
140
Vaz
ãode
dado
sde
sess
ão(K
bps)
1 RLC RTX
3 RLC RTX
4 RLC RTX
5 RLC RTX
Taxa de sessão WWW (1/seg)
Figura 3.12: Variação das retransmissões da RLC (RLC RTX) com duas retransmissõesda MAC-hs (MAC-hs RTX = 2). Décimo percentil da vazão de dados.
Quando se simula sem nenhuma retransmissão da MAC-hs a camada RLC tem
que lidar com todas as retransmissões que sejam necessárias. Como a RLC trabalha
56
1 1.5 2 2.5 3 3.560
70
80
90
100
110
120
130
140
150
Vaz
ãode
dado
sde
sess
ão(K
bps)
0 MAC-hs RTX
1 MAC-hs RTX
2 MAC-hs RTX
3 MAC-hs RTX
4 MAC-hs RTX
5 MAC-hs RTX
Taxa de sessão WWW (1/seg)
Figura 3.13: Variação das retransmissões da MAC-hs com RLC RTX = 4. Décimopercentil da vazão de dados.
na RNC, o processo de retransmissão se torna mais lento e, com isso, há uma queda
na medida da vazão de dados observada. De acordo com aquele gráfico, à medida
que se aumentam os níveis de retransmissões da MAC-hs, o sistema ganha em vazão
até o limite de duas retransmissões, a partir do qual não se observam mais ganhos
significativos.
De forma análoga, podemos verificar a mesma tendência na figura 3.14, sendo
que o parâmetro que indica o número de retransmissões da RLC foi configurado
para três (03).
As figuras 3.15, configurada com zero (0) retransmissões da MAC-hs e
3.16, configurada com quatro (04) retransmissões da RLC trazem as respectivas
informações anteriores, porém para o quinquagésimo percentil.
57
1 1.5 2 2.5 3 3.550
60
70
80
90
100
110
120
130
140
Trh
ough
put (
kbps
)
0 MAC-hs RTX
1 MAC-hs RTX
2 MAC-hs RTX
3 MAC-hs RTX
4 MAC-hs RTX
5 MAC-hs RTX
Taxa de sessão WWW (1/seg)
Figura 3.14: Variação das retransmissões da MAC-hs com RLC RTX = 3. Décimopercentil da vazão de dados.
1 1.5 2 2.5 3 3.5160
170
180
190
200
210
220
230
Vaz
ãode
dado
sde
sess
ão(K
bps)
1 RLC RTX
3 RLC RTX
4 RLC RTX
5 RLC RTX
Taxa de sessão WWW (1/seg)
Figura 3.15: Variação das retransmissões da RLC com MAC-hs RTX = 0.Quinquagésimo percentil da vazão de dados.
58
1 1.5 2 2.5 3 3.5160
180
200
220
240
260
280
300
Vaz
ãode
dado
sde
sess
ão(K
bps)
0 MAC-hs RTX
1 MAC-hs RTX
2 MAC-hs RTX
3 MAC-hs RTX
4 MAC-hs RTX
5 MAC-hs RTX
Taxa de sessão WWW (1/seg)
Figura 3.16: Variação das retransmissões da MAC-hs com RLC RTX = 4.Quinquagésimo percentil da vazão de dados.
Capítulo 4Conclusões e Perspectivas
4.1 Conclusões
O objetivo de estudo desse trabalho foi atingido capturando a dinâmica de
retransmissões que acontecem em três diferentes pontos da comunicação entre o
transmissor e o receptor de dados, os quais englobam, na camada de transporte o
TCP e na camada de enlace a RLC e a MAC-hs, funcionalmente ligada ao HSDPA.
O TCP apresenta significativa perda de desempenho quando utilizado sobre redes
sem fio, mesmo em sistemas que procuram minimizar as perdas percebidas pelas
camadas superiores da pilha de protocolos, como é o caso do HSDPA. Os resultados
de integração obtidos com a inclusão do módulo TCP demonstram que a ferramenta
de simulação se comportou de acordo com os resultados esperados.
Com base nos resultados apresentados no Capítulo 3 podemos concluir que,
utilizando-se o TCP Reno sobre redes HSDPA e sob tráfego de web browsing,
alcançamos um melhor desempenho quando a RLC está configurada com quatro
níveis de retransmissões funcionando conjuntamente com uma configuração da
MAC-hs de duas ou mais retransmissões.
Através dos gráficos podemos perceber que uma configuração da RLC com mais
de quatro retransmissões degrada o desempenho do sistema. Isto se dá devido à
baixa eficiência do esquema de gerenciamento de buffer da RLC que pode causar
consecutivas perdas de pacotes em certas situações de atenuação do sinal, conforme
descrito em [13], onde os autores evidenciam que o buffer da RLC é gerenciado por
uma política simples de descarte de quadros quando completamente preenchido. Os
60
autores mostram também que este estouro de buffer na RLC (em inglês: buffer
overflow) é um dos principais problemas para a camada de transporte. Dessa
forma, como o RTT do TCP mantêm-se ligado, o atraso devido às tentativas de
retransmissão da RLC aliado com a política de simples descarte de quadros pela
RLC afetam o desempenho da rede.
Na MAC-hs, a variação do parâmetro do número de retransmissões mostra
ganho até certo ponto (duas retransmissões), a partir do qual não se nota mais
influência no desempenho do sistema. Isso acontece devido à eficência dos algoritmos
implementados na MAC-hs. Juntamente com as demais técnicas, a redundância
incremental, por exemplo, é de fundamental importância neste processo por manter
armazenados no buffer os dados corrompidos que serão utilizados como itens
redundantes nas próximas tentativas de transmisão. Isso é repetido até que os dados
no buffer sejam considerados recebidos com sucesso ou que o número máximo de
retransmissões seja atingido. A técnica AMC utiliza esses dados redundantes para
adaptar o esquema de modulação e a taxa de código utilizada nas retransmissões.
Com isso, a partir da segunda retransmissão já não se observam mais ganhos com o
aumento do número máximo de retransmissões.
4.2 Perspectivas de Trabalhos Futuros
Estuda-se a implementação e reprodução dos resultados para as versões SACK e
Vegas do TCP, além de avaliarmos a influência de parâmetros do TCP como a janela
inicial de tranmissão e o buffer do TCP receptor em uma rede HSDPA. Conforme
visto no Capítulo 2, O TCP SACK permite ao receptor adicionar diversos pacotes de
dados que foram recebidos fora de ordem dentro de uma confirmação duplicada, ao
invés de só colocar no último pacote recebido em ordem. Esta informação permite
ao transmissor retransmitir pacotes perdidos mais rápido do que um pacote por
Round Trip Time. Dessa forma, espera-se avaliar esse comportamento e indicar o
quanto de recursos de buffer pode ser suficiente alocar tanto na RLC quanto na
MAC-hs. Com o TCP Vegas, no qual é proposto uma forma original de controle de
congestionamento, monitorando a diferença entre a taxa esperada e a taxa medida
da rede, seria interessante podermos avaliar o cenário proposto neste trabalho.
Referências Bibliográficas
[1] T. S. Rappaport, Wireless Communications - Principles and Practice, 2th ed.
Prentice-Hall, 2002.
[2] F. Anjum e L. Tassiulas, “Comparative Study of Various TCP Versions over
a Wireless Link with Correlated Losses,” IEEE/ACM TRANSACTIONS ON
NETWORKING, vol. 11, pp. 370 – 383, Junho 2003.
[3] A. S. Tanenbaum, Computer Networks, 4th ed. Prentice Hall, 2002.
[4] A. Karnik e A. Kumar, “Performance of TCP Congestion Control with Explicit
Rate Feedback,” Networking, IEEE/ACM Transactions, vol. 13, pp. 108–120,
Fevereiro 2005.
[5] D. E. Comer, Interligação em Rede com TCP/IP. Editora Campus, 1998.
[6] H. Holma e A. Toskala, WCDMA for UMTS - Radio Access for Third
Generation Mobile Communications, 3th ed. Artech House, 2004.
[7] J. Korhonen, Introduction to 3G Mobile Communications - 2nd ed. Artech
House, 2003.
[8] P. J. A. Gutierrez, “Packet Scheduling and Quality of Service in HSDPA,”
Tese de doutorado, Departament of Communication Technology, Institute of
Eletronic Systems, Aalborg University, Denmark, Outubro 2003.
[9] W. S. Jeon, D. G. Jeong e B. Kim, “Packet Scheduler for Mobile Internet
Services Using High Speed Downlink Packet Access,” IEEE Transactions on
Wireless Communications, vol. 3, no. 5, pp. 1789–1801, 2004.
61
62
[10] M. Assaad e D. Zeghlache, TCP Performance over UMTS-HSDPA Systems.
Auerbach Publications, 2007.
[11] R. Knopp e P. A. Humblet, “Information Capacity and Power Control in
Single Cell Multiuser Communications,” Proc. IEEE International Conference
Communications, pp. 331–335, 1995.
[12] F. Lefevre e G. Vivier, “Optimizing UMTS Link Layer Parameters for a TCP
Connection,” Motorola Labs, 2001.
[13] J. J. Alcaraz, F. Cerdan e J. García-Haro, “Optimizing TCP and RLC
Interaction in the UMTS Radio Access Network,” IEEE Network Magazine,
vol. 20, pp. 56–64, Abril 2006.
[14] W. R. Stevens, TCP/IP Illustrated, Volume 1: The Protocols. Addison - Wesley
Professional Computing Series, 1994.
[15] A. Rodriguez, J. Gatrell, J. Karas e R. Peschke, TCP/IP Tutorial and Technical
Overview. Prentice Hall PTR, 2001.
[16] M. Rossi, R. Vicenzi e M. Zorzi, “Accurate Analysis of TCP on Channels
with Memory and Finite Round-Trip Delay,” IEEE Transactions on Wireless
Communications, vol. 3, pp. 627–640, Março 2004.
[17] T. Lang, “Evaluation of Different TCP Versions in non-Wireline
Environments,” Tese de doutorado, 2002.
[18] J. Mo, R. J. La, V. Anantharam e J. Walrand, “Analysis and Comparison of
TCP Reno and Vegas,” INFOCOM ’99. Eighteenth Annual Joint Conference of
the IEEE Computer and Communications Societies. Proceedings. IEEE, vol. 3,
pp. 1556–1563, Março 1999.
[19] L. S. Brakmo e L. L. Peterson, “TCP Vegas: End to End Congestion Avoidance
on a Global Internet,” IEEE Journal on Selected Areas in Communications,
vol. 13, Outubro 1995.
[20] J. Postel, “Transmission Control Protocol, DARPA Internet Program Protocol
Specification,” RFC 793, 1981.
63
[21] V. Jacobson, “Congestion Avoidance and Control,” Proc. ACM Symp.
Communications Architectures and Protocols, SIGCOMM, pp. 314–329, Agosto
1988.
[22] R. Ramani e A. Karandikar, “Explicit Congestion Notification (ECN) in TCP
over Wireless Network,” ICPWC 2000, pp. 495–499, 2000.
[23] Y. Easwaran e M. A. Labrador, “Evaluation and Application of Available
Bandwidth Estimation Techniques to Improve TCP Performance,” 29th Annual
IEEE International Conference, pp. 268 – 275, Novembro 2004.
[24] Z. Jin, M. Yu e Y. Shu, “Improving Wireless TCP Performance by Link
Probing,” IEEE CCECE 2003. Canadian Conference, vol. 2, pp. 885 – 888,
Maio 2003.
[25] B. S. Bakshi, P. Krishna, N. H. Vaidya e D. K. Pradhan, “Improving
Performance of TCP over Wireless Networks,” Proceedings of the 17th
International Conference, pp. 365 – 373, Maio 1997.
[26] J. Arhuz, S. Banerjee e P. Krishnamurthy, “MAITE: A Scheme for Improving
the Performance of TCP over Wireless Channels,” VTC 2001 Fall. IEEE VTS
54th, vol. 13, pp. 252 – 256, Agosto 2001.
[27] M. C. Chan e R. Ramjee, “TCP/IP Performance over 3G Wireless Links with
Rate and Delay Variation,” Wireless Networks, vol. 11, no. 1-2, pp. 81–97, 2005.
[28] ——, “Improving TCP/IP Performance over Third Generation Wireless
Networks,” Mobile Computing, IEEE Transactions on, vol. 7, no. 4, pp.
430–443, 2008.
[29] Y. Easwaran e M. A. Labrador, “Evaluation and Application of Available
bandwidth Estimation Techniques to Improve TCP Performance,” 29th Annual
IEEE International Conference on Local Computer Networks, 2004.
[30] Y. Fukuda, H. Koga, T. Ikenaga e Y. Oie, “Performance Evaluation of
TCP under Dynamic Allocation Scheme for Downlink Transmission Rate in
WCDMA Systems,” Wireless Communications and Mobile Computing, vol. 4,
pp. 223–232, 2004.
64
[31] R. Prasad e M. Ruggieri, Technology Trends in Wireless Communication.Artech
House, 2003.
[32] H. Balakrishnan, V. N. Padmanabhan, S. Seshan e Randy, “A Comparison
of Mechanisms for Improving TCP Performance over Wireless Links,”
IEEE/ACM Transactions on Networking, vol. 5, no. 6, pp. 756–769, 1997.
[33] K. Pentikousis, “TCP in Wired-Cum-Wireless Environments,” IEEE
Communications Surveys, vol. 3, no. 4, pp. 2–14, 2000.
[34] A. Bakre e B. R. Badrinath, “I-TCP: Indirect TCP for Mobile Hosts,” Proc.
15th Int. Conf. Distributed Computing Systems, 1995.
[35] K.Brown e S. Singh, “M-TCP: TCP for Mobile Cellular Networks,” ACM
SIGCOMM Computer Communications Review, vol. 27, no. 5, pp. 19–42, 1997.
[36] C. Parsa e J. Garcia-Luna-Aceves, “Improving TCP Performance over Wireless
Networks at the Link Layer,” Baltzer Science Publishers BV, vol. 3, no. 4, pp.
2–14, 2000.
[37] H. Lin e S. K. Das, “ARLP: an Adaptive Link Layer Protocol to Improve TCP
Performance over Wireless Fading Channels,” Wireless Communications and
Mobile Computing, vol. 4, pp. 655–668, 2004.
[38] G. Xylomenos e G. C. Polyzos, “TCP Performance Issues over Wireless Links,”
IEEE Communications Magazine, vol. 39, no. 4, pp. 52–58, 2001.
[39] S. Hadjiefthymiades, S. Papayiannis e L. Merakos, “Using Path Prediction
to Improve TCP Performance in Wireless/Mobile Communications,” IEEE
Communications Magazine, vol. 40, no. 8, pp. 54–61, 2002.
[40] A. Capone, L. Fratta e F. Martignon, “Bandwidth Estimation Schemes for
TCP over Wireless Networks,” IEEE Transactions on Mobile Computing, vol. 3,
no. 2, pp. 129–143, Junho 2004.
[41] S. Floyd e K. Fall, “Promoting the Use of End-to-End Congestion Control in
the Internet,” IEEE/ACM Transactions on Networking, vol. 7, no. 4, pp. 458 –
472, Agosto 1999.
65
[42] C.-L. Lee, C.-F. Liu e Y.-C. Chen, “On the Use of Loss History for Performance
Improvement of TCP over Wireless Networks,” IEICE TRANS. COMMUN.,
no. 11, 2002.
[43] Y. Tian, K. Xu e N. Ansari, “TCP in Wireless Environments: Problems and
Solutions,” IEEE Communications Magazine, vol. 43, no. 3, pp. S27–S32, 2005.
[44] T. Halonen, J. Romero e J. Melero, GSM, GPRS and EDGE Performance:
Evolution Towards 3G/UMTS, 2nd Edition, 2002.
[45] M.-J. Lin e L. F. Chang, “A Linux-based EGPRS Real-time Test Bed
Software for Wireless QoS and Differentiated Service Studies,” ICC 2002. IEEE
International Conference on Communications, pp. 1039–1044, Abril 2002.
[46] M. Zorzi, R. R. Rao e L. B. Milstein, “On the Accuracy of a First-Order Markov
Model for Data Transmission on Fading,” 1995 Fourth IEEE International
Conference, pp. 211–215, Novembro 1995.
[47] N. Möller, Åke Arvidsson, J. Petersson, C. Fischione, R. Skog, P. Karlsson
e K. H. Johansson, “Supporting End-to-End Applications over HSDPA
by Cross-Layer Signalling,” Proc. of IEEE Wireless Communication and
Networking Conference 2007 (IEEE WCNC 07), Hong Kong, Março 2007.
[48] C. Johansson, L. D. Verdier e F. Khan, “Performance of Different Scheduling
Strategies in a Packet Radio System,” IEEE International Conference on
Universal Personal Communications, vol. 1, pp. 267–271, Outubro 1998.
[49] A. R. Braga, “Controle de Congestionamento para Voz sobre IP em HSDPA,”
Dissertação de mestrado, Universidade Federal do Ceará - UFC, 2006.
Livros Grátis( http://www.livrosgratis.com.br )
Milhares de Livros para Download: Baixar livros de AdministraçãoBaixar livros de AgronomiaBaixar livros de ArquiteturaBaixar livros de ArtesBaixar livros de AstronomiaBaixar livros de Biologia GeralBaixar livros de Ciência da ComputaçãoBaixar livros de Ciência da InformaçãoBaixar livros de Ciência PolíticaBaixar livros de Ciências da SaúdeBaixar livros de ComunicaçãoBaixar livros do Conselho Nacional de Educação - CNEBaixar livros de Defesa civilBaixar livros de DireitoBaixar livros de Direitos humanosBaixar livros de EconomiaBaixar livros de Economia DomésticaBaixar livros de EducaçãoBaixar livros de Educação - TrânsitoBaixar livros de Educação FísicaBaixar livros de Engenharia AeroespacialBaixar livros de FarmáciaBaixar livros de FilosofiaBaixar livros de FísicaBaixar livros de GeociênciasBaixar livros de GeografiaBaixar livros de HistóriaBaixar livros de Línguas
Baixar livros de LiteraturaBaixar livros de Literatura de CordelBaixar livros de Literatura InfantilBaixar livros de MatemáticaBaixar livros de MedicinaBaixar livros de Medicina VeterináriaBaixar livros de Meio AmbienteBaixar livros de MeteorologiaBaixar Monografias e TCCBaixar livros MultidisciplinarBaixar livros de MúsicaBaixar livros de PsicologiaBaixar livros de QuímicaBaixar livros de Saúde ColetivaBaixar livros de Serviço SocialBaixar livros de SociologiaBaixar livros de TeologiaBaixar livros de TrabalhoBaixar livros de Turismo
