pablo andres pilo-pais albuja - unicamp€¦ · pilo-pais albuja, pablo andres, 1987- p647a...

Pablo Andres Pilo-Pais Albuja

Avaliação de Desempenho do Protocolo TCP-NACKem Canais com Desvanecimento Rayleigh.

CAMPINAS2015

i

Ficha catalográficaUniversidade Estadual de Campinas

Biblioteca da Área de Engenharia e ArquiteturaRose Meire da Silva - CRB 8/5974

Pilo-Pais Albuja, Pablo Andres, 1987- P647a PilAvaliação de desempenho do protocolo TCP-NACK em canais com

desvanecimento Rayleigh / Pablo Andres Pilo-Pais Albuja. – Campinas, SP : [s.n.],2015.

PilOrientador: Celso de Almeida. PilDissertação (mestrado) – Universidade Estadual de Campinas, Faculdade de

Engenharia Elétrica e de Computação.

Pil1. TCP/IP (Protocolo de rede de computação). 2. Sistemas de comunicação

sem fio. 3. Redes de computadores. I. Almeida, Celso de,1957-. II. UniversidadeEstadual de Campinas. Faculdade de Engenharia Elétrica e de Computação. III.Título.

Informações para Biblioteca Digital

Título em outro idioma: Performance evaluation of TCP-NACK protocol over Rayleigh fadingchannelsPalavras-chave em inglês:TCP/IP (Computer network protocol)Wireless communicationComputer NetworksÁrea de concentração: Telecomunicações e TelemáticaTitulação: Mestre em Engenharia ElétricaBanca examinadora:Celso de Almeida [Orientador]Gonzalo Fernando Olmedo CifuentesLee Luan LingData de defesa: 14-01-2015Programa de Pós-Graduação: Engenharia Elétrica

Powered by TCPDF (www.tcpdf.org)

iv

Resumo

Os enlaces sem fio são propensos a gerar mais erros e perdas de segmentos devido à naturezado desvanecimento neste canal de comunicação. A falta de um mecanismo no protocolo TCP Renoque permita distinguir as perdas por erros aleatórios das perdas por congestionamento, resultana redução da vazão de dados e um desempenho inferior ao esperado. A fim de melhorar odesempenho do protocolo TCP sobre redes sem fio, uma variante do protocolo TCP que utilizauma confirmação negativa, NACK, foi proposta previamente em [1] para informar ao transmissoracerca do recebimento de um segmento com erro para sua retransmissão instantânea sem reduzira janela de congestionamento. Na presente dissertação será avaliado o desempenho do algoritmoTCP-NACK sobre um cenário de provas com desvanecimento Rayleigh. Os resultados mostramque o protocolo TCP-NACK possui melhor desempenho em relação ao protocolo TCP em enlacessem fio.

Palavras-chave: TCP/IP, Sistemas de comunicação sem fio , Redes de computadores.

Abstract

Wireless links are prone to generate more errors and segments loss due to the fading nature ofthe communication channel. The lack of a mechanism in TCP Reno to distinguish random errorsfrom congestion losses, results in throughput reduction and performance lower than expected. Inorder to improve TCP over wireless networks, a negative acknowledgment, NACK, was earlierproposed [1] to inform the transmitter about the reception of a segment with error for its re-transmission without reducing the congestion window. In this thesis we are going to evaluate theTCP-NACK algorithm over a scenario with Rayleigh fading. The results show that TCP-NACKhas better performance over TCP Reno in wireless links.

Keywords: TCP/IP, Wireless Communication , Computer Networks

vii

Sumário

Dedicatória xiii

Agradecimentos xv

Lista de Ilustrações xvii

Lista de Abreviaturas e Siglas xxi

Lista de Símbolos xxiii

1 Introdução 11.1 Evolução da Internet e TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Crescimento da Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Tendências da Internet Sem Fio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.5 Alcance da Tese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.6 Visão do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Conceitos Básicos 72.1 Esquemas de Modulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Modulação PAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 Modulação BPSK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Modulação QPSK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.4 Modulação QAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Perdas do Canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.1 Perdas por Percurso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.2 Sombreamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.3 Modelos de Canal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.1 Canal com Ruído . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3.2 Canal com Desvanecimento . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4 Técnicas de Diversidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.1 Diversidade Espacial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.2 Diversidade em Frequência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.4.3 Diversidade Temporal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

ix

x Sumário

2.4.4 Combinação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5 Arquitectura de Rede . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.5.1 Modelo de Interconexão de Sistemas Abertos . . . . . . . . . . . . . . . . . . 152.6 Modelo TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.7 Simulação de Monte Carlo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3 Protocolo de Controle de Transmissão (TCP) 193.1 Desenvolvimento do Protocolo TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.2 Características do Protocolo TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.2.1 Orientado à Conexão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.2 Confiabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.2.3 Envio de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3 Formato do Cabeçalho TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.4 Controle de Fluxo de Dados TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.5 Controle de Congestionamento TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5.1 Incremento-Linear, Decremento-Multiplicativo . . . . . . . . . . . . . . . . . 253.5.2 Partida Lenta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263.5.3 Prevenção de Congestionamento . . . . . . . . . . . . . . . . . . . . . . . . . 263.5.4 Recuperação e Retransmissão Rápida . . . . . . . . . . . . . . . . . . . . . . 26

3.6 Versões do Protocolo TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6.1 TCP Tahoe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.6.2 TCP Reno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283.6.3 TCP New-Reno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.6.4 TCP Confirmação Seletiva . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

3.7 TCP em Meios sem Fio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4 Melhorias para o Protocolo TCP Sem Fio 314.1 Protocolos de Conexão-Dividida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.1.1 TCP Indireto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.2 Protocolo de Conexão-Dividida com Repetição Seletiva . . . . . . . . . . . . 324.1.3 Protocolo de Transporte Ponto-Móvel . . . . . . . . . . . . . . . . . . . . . . 334.1.4 TCP-Móvel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.1.5 Protocolo de Transporte Móvel de Conexão-Dividida . . . . . . . . . . . . . 334.1.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.2 Protocolos da Camada de Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.2.1 Protocolo Snoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.2 Protocolo TCP-Adaptativo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.3 Protocolo AIRMAIL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2.4 Protocolo de Rádio Enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.5 Protocolo TULIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.2.6 D-Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2.7 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.3 Notificação Explícita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Sumário xi

4.3.1 Notificação Explícita de Congestionamento . . . . . . . . . . . . . . . . . . 384.3.2 Notificação Explícita de Perda . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.3 Mensagens ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.3.4 Síndrome . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.5 Confirmações Múltiplas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.3.6 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.4 Protocolos de Ponto-a-Ponto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.4.1 SMART Ponto-a-Ponto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4.2 TCP Westwood . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4.3 TCP-Congelado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.4.4 Confirmações Duplicadas com Retardo . . . . . . . . . . . . . . . . . . . . . 424.4.5 Protocolo de Controle de Transmissão Sem Fio . . . . . . . . . . . . . . . . 424.4.6 TCP Eiffel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.7 TCP Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.4.8 Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5 Algoritmo TCP-NACK 455.1 Confirmação Negativa (NACK) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Janela de Congestionamento TCP com NACKs . . . . . . . . . . . . . . . . . . . . 465.3 Modelamento do Protocolo TCP-NACK . . . . . . . . . . . . . . . . . . . . . . . . 505.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5.4.1 Desempenho do Protocolo TCP NACK em Canal AWGN . . . . . . . . . . . 515.4.2 Desempenho do Protocolo TCP NACK em Canal com Desvanecimento . . . 625.4.3 Desempenho do Protocolo TCP NACK com Diversidade . . . . . . . . . . . 73

6 Conclusões 796.1 Contribuições da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806.2 Propostas para Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Referências 83

Aos meus pais, Edisson e Verónica,e meus irmãos, Chesco e July,

por seu amor e apoio constante.

xiii

Agradecimentos

Aos meus pais, Edisson e Verónica por seu amor incondicional, o apoio aos meus projetospessoais e amparo nos momento difíceis durante o desenvolvimento do meu mestrado.

Agradeço pela oportunidade de estudar no Brasil e realizar este trabalho de pesquisa ao Prof.Dr. Celso de Almeida, por sua orientação, ajuda e conhecimentos transmitidos que contribuíramna conclusão desta dissertação.

Aos meus colegas equatorianos Juan, Carito, Henry e Nathy por seus conselhos e conhecimen-tos compartilhados durante as aulas, no desenvolvimento das nossas pesquisas e pelas alegriasvivenciadas fora do ambiente acadêmico.

Aos professores Reginaldo Palazzo, Renato Baldini Filho, Michel Daoud Yacoub, José CandidoSilveira Santos Filho e Gustavo Fraidenraich por compartilharem seu conhecimento e experiênciaem suas aulas.

À CAPES pelo apoio financeiro durante o último ano do projeto de pesquisa. À FUNCAMPpelo apoio financeiro durante a apresentação do artigo técnico no congresso LATINCOM 2013 emSantiago do Chile.

Por fim, quero agradecer a Deus por me oferecer a força e persistência para alcançar esteobjetivo e desenhar o caminho da minha vida de tal forma que pude conhecer a todas as pessoasque de uma ou outra maneira influenciaram em mim com seus conhecimentos e ensino.

A todos, muito obrigado!

xv

Lista de Ilustrações

1.1 Crescimento dos Usuários da Internet no Mundo. . . . . . . . . . . . . . . . . . . . 31.2 Porcentagem de Usuários de Banda Larga no Mundo. . . . . . . . . . . . . . . . . . 3

2.1 Modulação 2-PAM ou BPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Constelações de Modulação QPSK e 16-QAM. . . . . . . . . . . . . . . . . . . . . . 92.3 Modelo Discreto de um Canal AWGN. . . . . . . . . . . . . . . . . . . . . . . . . . 112.4 Modelo Discreto de um Canal com Desvanecimento Rayleigh. . . . . . . . . . . . . . 122.5 Modelo de Referência OSI [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6 Modelos OSI e TCP/IP [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

3.1 Estabelecimento de uma Conexão TCP. . . . . . . . . . . . . . . . . . . . . . . . . . 213.2 Formato de um Segmento TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 Janela Deslizante no Transmissor e no Receptor TCP. . . . . . . . . . . . . . . . . . 243.4 Algoritmo de Controle de Congestionamento TCP. . . . . . . . . . . . . . . . . . . . 27

4.1 Conexão TCP Dividida em Conexões Diferentes. . . . . . . . . . . . . . . . . . . . . 324.2 Esquema para melhorar o desempenho do Protocolo TCP utilizado Protocolos da

Camada de Enlace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.3 Bits ECN no Cabeçalho TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.4 Protocolos de Ponto-a-Ponto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Formato do Cabeçalho TCP-NACK. . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2 Envio e Recepção de Segmentos com TCP-NACK. . . . . . . . . . . . . . . . . . . . 475.3 Comportamento da Janela de Congestionamento na Presença de Erros. . . . . . . . 485.4 Janela de Congestionamento no Tempo. . . . . . . . . . . . . . . . . . . . . . . . . 495.5 Modelo da Vazão de Dados entre Cliente e Servidor TCP. . . . . . . . . . . . . . . . 505.6 Probabilidade de Erro de Bit para as Modulações BPSK, QPSK e 16-QAM sobre

um Canal AWGN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 525.7 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Ta-

manhos de Segmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN.Modulação BPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

5.8 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tama-nhos da Janela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN. ModulaçãoBPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

xvii

xviii Lista de Ilustrações

5.9 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Atra-sos de Propagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal AWGN.Modulação BPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.10 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Ta-manhos de Segmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN.Modulação QPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.11 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tama-nhos da Janela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN. ModulaçãoQPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.12 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Atra-sos de Propagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal AWGN.Modulação QPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

5.13 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tama-nhos de Segmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN. . . . 59

5.14 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tama-nhos da Janela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN. Modulação16-QAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5.15 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Atra-sos de Propagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal AWGN.Modulação 16-QAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.16 Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para as ModulaçõesBPSK, QPSK e 16-QAM, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal AWGN.Modulação 16-QAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

5.17 Probabilidade de Erro de Bit para as Modulações BPSK, QPSK e 16-QAM em umCanal com Desvanecimento Rayleigh. . . . . . . . . . . . . . . . . . . . . . . . . . . 63

5.18 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhos deSegmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com DesvanecimentoRayleigh. Modulação BPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

5.19 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhosda Janela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com DesvanecimentoRayleigh. Modulação BPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.20 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Atrasos dePropagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits,sobre um Canal com Desvaneci-mento Rayleigh. Modulação BPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

5.21 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhos deSegmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com DesvanecimentoRayleigh. Modulação QPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.22 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhosda Janela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com DesvanecimentoRayleigh. Modulação QPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.23 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Atrasos dePropagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal com Desvaneci-mento Rayleigh. Modulação QPSK. . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Lista de Ilustrações xix

5.24 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhos deSegmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com DesvanecimentoRayleigh. Modulação 16-QAM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.25 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhosda Janela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com DesvanecimentoRayleigh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

5.26 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Atrasos dePropagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal com Desvaneci-mento Rayleigh. Modulação 16-QAM. . . . . . . . . . . . . . . . . . . . . . . . . . 72

5.27 Vazão de Dados Normalizada em função da Relação 𝛾𝑏 para as Modulações BPSK,QPSK e 16-QAM, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal com Desvane-cimento Rayleigh. Modulação 16-QAM. . . . . . . . . . . . . . . . . . . . . . . . . . 73

5.28 Probabilidade de Erro de Bit em Função da Relação 𝛾𝑏 para as Modulações BPSK,QPSK e 16-QAM em um Canal com Desvanecimento Rayleigh utilizando Técnicasde Diversidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

5.29 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏, para 𝑊=20 segmentos,𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal com Desvanecimento Rayleigh utilizando Técnicasde Diversidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

5.30 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏, para 𝐿=2, 𝑊=20 seg-mentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal com Desvanecimento Rayleigh utilizandoTécnicas de Diversidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

5.31 Vazão de Dados Normalizada em Função da Relação 𝛾𝑏, para 𝐿=4, 𝑊=20 seg-mentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal com Desvanecimento Rayleigh utilizandoTécnicas de Diversidade. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Lista de Abreviaturas e Siglas

ARPA Agência de Projetos de Pesquisa Avançada. 1ARPANET Rede da Agência de Projetos de Pesquisa Avançada. 1ARQ Requisição Automática de Repetição. 31, 32ASK modulação por variação de amplitude. 7AWGN ruído aditivo gaussiano branco. 9,

BER taxa de erro de bit. 4, 28BPSK Variação de Fase Binário. 7BSD Berkeley Software Distribution. 26

CID Identificação de Conexão. 31,CWND Janela de Congestionamento. 23, 77

ECE ECN-Echo.ECN Notificação Explícita de Congestionamento. 20, 36ELN-ACK Notificação de Perda Explícita com Confirmação. 37,ERB Estação Rádio-Base. 29

FEC Códigos Corretores de Erro (Forward Error Correction). 32,FTP Protocolo de Transferência de Arquivos. 17

GSM Global System for Mobile Communications. 32,

HF Host Fixo. 29HM Host Móvel. 29HTTP Protocolo de Transferência de Hipertexto. 2, 17

ICMP Mensagens de Controle do Protocolo de Internet. 37IETF Internet Engineering Task Force. 14IP Protocolo de Internet. 2,

xxi

xxii Lista de Abreviaturas e Siglas

ISO Organização Internacional para Padronização. 14

LOS Linha de Visada. 48,LTE Long Term Evolution. 1,

METP Protocolo de Transporte Ponto-Móvel. 31,MSR Roteadores de Suporte Móvel. 30,MSS tamanho máximo do segmento. 18, 21, 23MTU Unidade Máxima de Transmissão. 19

NACK Confirmação Negativa. viii, 43,

OSI Interconexão de Sistemas Abertos. 14

PAM modulação por amplitude de pulso. 6PDF função densidade de probabilidade. 9

QAM Modulação de Amplitude em Quadratura. 8

RcvWND Janela do Receptor. 23,RFC Request For Comments. 17RLP Protocolo de Enlace de Rádio. 34,RTT Tempo de ida e volta. 23

SACK Confirmação Seletiva. 17, 21, 28SCMTP Protocolo de Transporte Móvel de Conexão-Dividida. 31,SNR Relação sinal-ruído.SRP Protocolo de Repetição Seletiva. 30

TCP Protocolo de Controle de Transmissão. 1, 17TULIP Transport Unaware Link Improvement Protocol.

UDP Protocolo de Datagramas de Usuário. 34,

WiFi Wireless Fidelity. 1,WiMAX Worldwide Interoperability for Microwave Access. 1,WTCP Protocolo de Controle de Transmissão Sem Fio. 40WWW World Wide Web. 2

Lista de Símbolos

1/𝑇𝑠 Taxa de Símbolo. 6𝐸𝑏/𝑁𝑜 Relação Sinal-Ruído. 4, 51, 54, 57, 62𝐸𝑏 Energia por bit.𝐿 Número de Percursos. 12𝑀 Número de Símbolos. 49𝑁𝑜 Densidade espectral de potência do ruído. 9, 48𝑁𝑏𝑖𝑡𝑠 Comprimento do segmento TCP em bits. 48𝑁𝑝𝑎𝑐,𝑡𝑥 Número total de segmentos transmitidos. 48𝑁𝑝𝑎𝑐 Número de segmentos TCP. 48𝑃𝑅 Potência do sinal recebido. 8, 9𝑃𝑇 Potência do sinal transmitido. 8, 9𝑃𝑒,𝑝𝑎𝑐 Probabilidade de Erro de Pacote.𝑅𝑏 Taxa de transmissão em bits por segundo. 48𝑅𝑝 Taxa de transmissão em segmentos por segundo. 48𝑅𝑏,𝑒𝑓 Taxa de transmissão efetiva em bits por segundo. 48𝑇𝑅𝑇 𝑇 Tempo de ida e volta. 48𝑊𝑐 Ciclos da janela de congestionamento. 49𝑊 Janela de congestionamento atual. 23, 48𝜇 Média. 9, 10𝜌𝑘 Desvanecimento. 10𝜎 Desvio padrão. 9, 10𝜏𝑝 Atraso de propagação do canal. 48A Alfabeto de Símbolos. 7𝜗 Vazão de Dados TCP. 49𝜁 Exponente de perda de propagação. 9𝑎𝑘 Símbolos. 7𝑏 Bits por bloco. 7𝑑 Distância entre o transmissor e o receeptor. 9𝑔(𝑡) Pulso Formatador. 6𝑛𝑘 Ruído inserido. 10

xxiii

xxiv Lista de Símbolos

𝑝(𝜌) PDF da variável aleatória 𝜌. 10𝑝(𝑥) PDF da variável aleatória 𝑥. 9𝑟𝑘 Símbolo recebido. 10𝑠𝑘 Símbolo enviado. 10

Capítulo 1

Introdução

A Internet tem revolucionado o mundo das telecomunicações permitindo a interação do fluxode informação entre as pessoas de distintos lugares do mundo. A convergência de novas tecnologiassem fio, como WiFi, WiMAX e LTE, junto com os múltiplos serviços da Internet como o correioeletrônico, mensageiro instantâneo, as redes sociais, etc. mudaram o jeito de nos comunicar,trabalhar e viver. Hoje em dia a Internet é a maior rede de informação do planeta e uma partefundamental da sociedade moderna.

Atualmente o acesso à Internet através de tecnologias sem fio é muito popular e tem geradonovos cenários para o qual o Protocolo de Controle de Transmissão (TCP) não foi concebido. Emmeios não guiados, além das perdas por congestionamento existem perdas por erros gerados pelanatureza do desvanecimento própria de canais sem fio. O protocolo TCP não realiza diferenciaçãonenhuma entre estas perdas e executa o algoritmo de controle de congestionamento mesmo queo meio se encontre livre de tráfego, diminuindo a velocidade da transmissão. Isto nos leva ànecessidade de redesenhar o mecanismo de controle do protocolo TCP para resolver os problemasnão relacionados com congestionamento em ambientes sem fio.

1.1 Evolução da Internet e TCPNo final da década de 1950 todos os sistemas de comunicações utilizavam a rede telefônica

pública. Com o auge da guerra fria e a possibilidade de um ataque nuclear se pôs em evidênciaa vulnerabilidade do sistema telefônico, dado que não tinha redundância e a destruição de algu-mas centrais de comutação poderia inabilitar a rede em vários segmentos desconexos. Os EstadosUnidos criaram então a Agência de Projetos de Pesquisa Avançada (ARPA), encarregada do desen-volvimento de ciência e tecnologia aplicada ao campo militar, onde surge a ideia de construir umarede sem uma unidade central de controle, de modo que o sistema não fosse vulnerável em casode ataque a uma localização específica [2]. Para alcançar seu objetivo, a ARPA decidiu criar umarede de pacotes comutados que consistia de uma subrede e terminais, cada um com seu próprioroteador. Ao final da década de 60, a ARPA logrou conectar computadores das universidades deUtah, UCLA, UCSB e SRI, implementando a primeira rede não centralizada: a Rede da Agênciade Projetos de Pesquisa Avançada (ARPANET).

1

2 Capítulo 1. Introdução

Vários experimentos demonstraram que os primeiros protocolos utilizados na rede ARPANETnão foram adequados para serem executados sobre diferentes tipos de redes (cabo, rádio, satélite).Essa observação levou a uma maior pesquisa sobre protocolos, culminando com a invenção dosprotocolos TCP/IP [3]. Em 1983 a pilha de protocolos TCP/IP converteu-se no padrão oficial daARPANET.

A partir de 1985 novas redes de comutação de pacotes foram criadas ao redor do mundo, todaselas implementando o modelo TCP/IP. A partir de 1990 as diferentes redes iniciaram o processode interconexão entre elas, incluindo a ARPANET [2]. As pessoas começaram a perceber esseconjunto de redes como uma inter-rede e depois como a Internet, cujo crescimento exponencial demáquinas e usuários a converteu na rede global que hoje conhecemos.

1.2 Crescimento da InternetAntes da década dos anos 90, a Internet era usada principalmente por pesquisadores acadêmi-

cos, do governo e da indústria para transferência de arquivos, correio eletrônico e acesso remoto.O desenvolvimento do Protocolo de Transferência de Hipertexto (HTTP), a World Wide Web(WWW) e o navegador web abriram as portas da Internet para milhões de usuários não acadê-micos, pois tornaram mais simples o acesso à informação através de páginas que, além de texto,continham imagens, áudio e vídeo. A Internet se converteu em um novo meio de comunicaçãopopular. A redução de custo dos dispositivos do usuário, as novas redes de acesso e as tecnologiassem fio simplificaram o acesso à Internet, incrementando o número de acessos a cada dia. A Fig. 1.1mostra o crescimento da Internet nos últimos 9 anos [4].

1.3 Tendências da Internet Sem FioA convergência da Internet, a telefonia e as tecnologias sem fio mudaram a forma como nos

comunicamos, trabalhamos e vivemos. As comunicações sem fio prosperaram ao redor do mundointeiro. Nos anos recentes é possível observar um aumento significativo no número de aparelhoscelulares e dispositivos de rede com capacidade de acessar a Internet sem o uso de fio. A Fig. 1.2mostra que nos últimos anos o número de assinantes de banda larga móvel ultrapassou o número deusuários de banda larga fixa e atualmente para cada pessoa que tem acesso fixo à Internet existem3 pessoas que a acessam sem fio [4]. A tendência à internet móvel aumentou notavelmente juntocom a demanda por serviços multimídia, exigindo dos sistemas de comunicação controlar as altastransferências de dados em enlaces sem fio.

1.4 Definição do ProblemaAs redes de multiplexação de pacotes devem lidar com perdas de segmentos devido ao conges-

tionamento, com o tráfego na rede e situações onde a demanda de recursos excede a capacidade

Capítulo 1. Introdução 3

2005 2006 2007 2008 2009 2010 2011 2012 201315

20

25

30

35

40

%d

aP

opu

laca

o

Usuarios da Internet

Figura 1.1: Crescimento dos Usuários da Internet no Mundo.

2005 2006 2007 2008 2009 2010 2011 2012 20130

5

10

15

20

25

30

%d

aP

opu

laca

o

Banda Larga MovelBanda Larga Fixa

Figura 1.2: Porcentagem de Usuários de Banda Larga no Mundo.


disponível. A solução para esse problema consiste na implementação de um algoritmo de controlede congestionamento.

O protocolo TCP utiliza algoritmos de controle de congestionamento que permitem determinara largura de banda da rede e adaptar a taxa de transferência de dados de acordo com o tráfego , oque tem feito do TCP o protocolo de controle mais utilizado em redes de dados como a Internet.

Originalmente o protocolo TCP foi criado para ambientes de rede em meios confinados, ondea taxa de erro de bit (BER) é quase nula ou desprezível e as perdas de segmentos ocorrem nasua maioria pelo congestionamento do meio. Os mecanismos de controle previnem o congestiona-mento enviando segmentos de confirmação ao transmissor toda vez que um pacote for recebido comsucesso. Se um segmento for perdido ou corrompido, nenhum aviso é enviado. Nesse caso, o trans-missor assume que a rota está congestionada e reduz o número de segmentos a serem transmitidospara diminuir o fluxo médio de bits.

Em meios sem fio, além das perdas por congestionamento existem perdas devido ao ruído e de-vido ao desvanecimento. Condições ambientais, reflexões e obstruções terrestres contribuem parao surgimento de desvanecimento [5]. O protocolo TCP não faz diferença entre congestionamento eperdas aleatórias e trata todas elas como congestionamento, embora muitas vezes o enlace se en-contre livre de tráfego. Isto resulta em uma degradação da taxa de transferência e em desempenhopobre.

O protocolo TCP é sensível às perdas e requer uma modificação do algoritmo de controle quepermita sua adaptação para ambientes sem fio. A iniciativa deste estudo consiste em implementare avaliar a proposta de um novo algoritmo de controle, TCP-NACK [1], como solução ao problemaexposto, sendo capaz de distinguir segmentos com erro e as perdas por congestionamento parausar os recursos de forma mais eficiente.

1.5 Alcance da TeseO projeto consiste em implementar o algoritmo de controle TCP-NACK e avaliar seu desempe-

nho em um ambiente sem fio. Foi desenvolvido um cenário de testes que simula o comportamentode um canal sem fio com ruído gaussiano branco e desvanecimento Rayleigh. O critério de ava-liação foi a vazão de dados em função da relação sinal-ruído (𝐸𝑏/𝑁𝑜) para diferentes valores deatraso, número de bits do segmento e número máximo de segmentos transmitidos. Os testes foramrealizados, tanto para o protocolo TCP-NACK, como para o TCP Reno e os resultados foramanalisados para verificar o desempenho do novo algoritmo de controle em redes sem fio.

1.6 Visão do TrabalhoA presente dissertação está organizada da seguinte forma:

• No Capítulo 2 são apresentados esquemas básicos de modulação de sistemas de comunicações.São detalhados os modelos de canal com ruído e desvanecimento que caracterizam um canal

Capítulo 1. Introdução 5

sem fio. Além disso, é feita uma descrição dos modelos de referência utilizados no projeto eimplementação de uma rede de comunicação. Por fim, é mencionada a técnica de simulaçãoutilizada na dissertação

• O Capítulo 3 descreve um pouco da história e funcionamento do Protocolo de Controle deTransmissão (TCP). Suas características principais e o formato das mensagens são descritosjunto com os algoritmos de controle de fluxo, assim como o estabelecimento de uma comuni-cação na camada de transporte. O capítulo também mostra os mecanismos utilizados peloprotocolo TCP para o controle do congestionamento e reafirma os problemas que apresentaTCP quando é utilizado sobre meios sem fio. No Capítulo 4 são mencionadas as múltiplasabordagens que existem para solucionar os problemas que são gerados na presença de umenlace sem fio na rede de comunicação.

• No Capítulo 5 se encontra o ápice desta dissertação, onde é apresentado o algoritmo decontrole TCP-NACK utilizado para melhorar a vazão em ambientes sem fio. O capítulodetalha o funcionamento do algoritmo e o modelamento matemático realizado para avaliarseu desempenho em canais com ruido e desvanecimento, assim como apresenta os resultadosobtidos. As conclusões são apresentadas no Capítulo 6.

Capítulo 2

Conceitos Básicos

Neste capítulo serão apresentados os conceitos básicos de um sistema de comunicação digital, ascaracterísticas de um canal sem fio e outros conceitos utilizados nos próximos capítulos e tambémnas simulações.

2.1 Esquemas de ModulaçãoEm uma comunicação entre computadores ou entre outros dispositivos portáteis de um usuário,

a informação a ser transportada é inerentemente digital. A Internet utiliza a técnica de multiple-xação de pacotes para acomodar uma variedade de fontes de informação, tais como mensagensde correio eletrônico e páginas da web. Embora é desejado transmitir a informação de forma dis-creta no tempo, os meios físicos na natureza são contínuos no tempo. Uma técnica que permitetransmitir a informação digital através de formas de onda contínuas no tempo é conhecida comomodulação [6]. Existem diversos esquemas de modulação e a escolha dependerá básicamente daeficiência espectral e do desempenho.

2.1.1 Modulação PAMO esquema de modulação por amplitude de pulso (PAM) consiste em enviar a informação

alterando as amplitudes de um trem de pulsos, de forma que o sinal transmitido é dado por [6]:

𝑠(𝑡) =∞∑

𝑚=−∞𝑎𝑘𝑔(𝑡 − 𝑘𝑇𝑠) (2.1)

onde 𝑇𝑠 é o tempo de símbolo, 1/𝑇𝑠 é a taxa de símbolo, 𝑔(𝑡) é o pulso formatador que cumpre

com a condição de ausência de interferência intersimbólica:

𝑔(𝑡) =⎧⎨⎩1, 𝑡 = 0

0, 𝑡 = ±𝑇𝑠, ±2𝑇𝑠, ±3𝑇𝑠, . . .(2.2)

7

8 Capítulo 2. Conceitos Básicos

e 𝑎𝑘 é uma variável aleatória que representa as amplitudes dos pulsos.

As amplitudes dos símbolos estão restritas a um alfabeto A que possui 2𝑏 elementos, tal que𝑎𝑘 ∈ A e 𝑏 é o número de bits associados a cada símbolo.

A inclusão de uma portadora senoidal em um esquema PAM resulta em uma modulação debanda passante denominada modulação por variação de amplitude (ASK), ou modulação porvariação de fase binário (BPSK).

2.1.2 Modulação BPSK

A modulação por Variação de Fase Binário (BPSK) é o mais simples dos esquemas de modulaçãode fase. Para implementá-lo é necessário alterar a fase da portadora em função do símbolo a sertransmitido. Para a modulação BPSK o número de bits por símbolo é 𝑏 = 1, pois o alfabeto A ébinário e assim são requeridas duas formas de onda para representar cada bit. As ondas tem umaamplitude 𝐴 e fase de 0° e 180° para representar a transmissão do bit 1 e o bit 0, respectivamente.A Fig. 2.1 mostra a constelação BPSK.

−A A

Figura 2.1: Modulação 2-PAM ou BPSK.

2.1.3 Modulação QPSK

A modulação de variação de fase quaternario (QPSK) ou 4-PSK é equivalente a duas modu-lações BPSK, uma sendo transmitida em fase, e a outra transmitida em quadratura. O alfabetoA possui 4 elementos e assim são requeridas 4 formas de onda para representar os símbolos. Aamplitude das ondas portadoras se mantém constante com uma amplitude

√2𝐴 e fases com uma

diferença de 90° entre elas. Na Fig. 2.2 (a) se apresenta a constelação QPSK com fases de 45°,135°, 225°, e 315°.

Capítulo 2. Conceitos Básicos 9

−A A

A

−A

(a) QPSK.

−3A −A

−A

−3A

A 3A

3A

A

(b) 16-QAM

Figura 2.2: Constelações de Modulação QPSK e 16-QAM.

2.1.4 Modulação QAMA Modulação de Amplitude em Quadratura (QAM) consiste em alterar a amplitude das porta-

doras ortogonais. No esquema 𝑀 -QAM, existem 𝑀 = 2𝑏 formas de onda para 𝑏 bits transmitidospor símbolo. Na Fig. 2.2 se mostram as constelações das modulações QPSK e 16-QAM. As mo-dulações com constelações maiores podem ser construídas aumentando as amplitudes das ondasportadoras ortogonais.

2.2 Perdas do CanalA transferência de informação em canais de comunicação sem fio tem como característica mais

notória a baixa confiabilidade durante a transmissão de sinais. As formas de onda sofrem atenu-ações durante sua propagação no meio por vários fatores do meio, tais como perdas por percurso,sombreamento e desvanecimento.

2.2.1 Perdas por PercursoAs perdas por percurso são observadas como uma atenuação do sinal entre o transmissor e o

receptor. Para caracterizar este fenômeno é usado o seguinte modelo [7]:

𝑃𝑅

𝑃𝑇

= 𝑑−𝜁 (2.3)


onde 𝑃𝑅 é a potência do sinal recebido, 𝑃𝑇 é a potência do sinal transmitido, 𝑑 é a distância entretransmissor e receptor, e 𝜁 é o exponente de perda de propagação. Os valores de 𝜁 podem variarde 3 a 5 para ambientes externos, enquanto que para propagação no espaço livre o valor de 𝜁 é de2.

2.2.2 SombreamentoAlém da atenuação do sinal pela perda de percurso, a presença de obstáculos grandes como

prédios, árvores, morros e veículos em movimento, podem produzir variações na amplitude dosinal. Essas flutuações aleatórias são conhecidas como sombreamento e são caracterizadas por umafunção densidade de probabilidade lognormal definida por [7]:

𝑝(𝑥) = 1𝑥√

2𝜋𝜎exp

[− (ln(𝑥) − 𝜇)2

2𝜎2

](2.4)

onde 𝜇 e 𝜎 são parâmetros da variável lognormal. O sombreamento faz flutuar a potência do sinalrecebido entorno de um valor médio. A flutuação varia lentamente com o tempo e pouco com adistância.

2.3 Modelos de CanalVários fenômenos podem ocorrer entre o transmissor e receptor durante a transmissão de um

sinal. A informação pode sofrer com a adição de ruído, com a multiplicação pelo desvanecimentoe a adição de interferências próprias de um canal de comunicação. Em geral os efeitos provocadospor um canal sem fio tem uma característica aleatória e são modelados matematicamente por umfiltro que modifica o sinal transmitido através de processos estocásticos, conferindo ao canal aspropriedades de um sistema linear variante no tempo.

2.3.1 Canal com RuídoTodo sistema de comunicações é afetado pela presença de ruído e não permite a transmissão

de dados livres de erro. O modelo de canal mais simples é aquele em que o ruído é adicionado aosinal transmitido. Como muitos processos da natureza, o ruído é caracterizado por um processoestocástico do tipo gaussiano, presente em toda a faixa de frequências com densidade espectralde potência 𝑁𝑜/2. Este modelo de canal é denominado de canal AWGN, ruído aditivo gaussi-ano branco. As amostras do ruído são variáveis aleatórias gaussianas, cuja função densidade deprobabilidade (PDF) é dada por [7]:

𝑝(𝑥) = 1√2𝜋𝜎

exp[

− (𝑥 − 𝜇)2

2𝜎2

](2.5)


onde 𝜇 e 𝜎 são denominados média e desvio padrão da gaussiana, respectivamente.

A Fig. 2.3 mostra o modelo de um canal AWGN discreto, cuja amostra do sinal recebido é dadapor:

𝑟𝑘 = 𝑠𝑘 + 𝑛𝑘 (2.6)onde 𝑛𝑘 representa o ruído inserido pelo canal, 𝑠𝑘 o símbolo enviado e 𝑟𝑘 o símbolo recebido, todas

no instante k.

nk

sk rk = sk + nk

Figura 2.3: Modelo Discreto de um Canal AWGN.

2.3.2 Canal com DesvanecimentoEm sistemas sem fio, devido à presença de refletores e espalhadores entre o transmissor e

receptor, sinais com diferentes atrasos são inseridos pelo canal, fazendo com que o sinal transmitidoalcance o receptor através de múltiplos percursos com diferentes fases e amplitudes. Assim, aamplitude e fase do sinal recebido podem mudar abruptamente dentro de pequenos intervalos detempo.

A amplitude resultante dos múltiplos percursos também conhecida como desvanecimento, é umprocesso aleatório multiplicativo ao sinal enviado. Se há muitos caminhos refletidos e não existelinha de visada, a envoltória do sinal recebido pode ser modelada por uma função distribuição deprobabilidade Rayleigh, dada por [7]:

𝑝(𝜌) = 𝜌

𝜎2 exp[

− 𝜌2

2𝜎2

](2.7)

onde 𝜎 é um parâmetro da variável Rayleigh.

A Fig. 2.4 mostra o modelo de um canal com ruído aditivo e desvanecimento Rayleigh, cujaamostra recebida é dada por:

𝑟𝑘 = 𝜌𝑘𝑠𝑘 + 𝑛𝑘 (2.8)onde 𝜌𝑘 é o desvanecimento no instante 𝑘.


nk

rk = ρksk + nk

ρk

sk

Figura 2.4: Modelo Discreto de um Canal com Desvanecimento Rayleigh.

2.4 Técnicas de DiversidadeUm canal que possui desvanecimento e ruído pode gerar uma grande degradação no sinal

transmitido e produzir um grande número de erros na recepção. Uma alternativa para combater odesvanecimento e seus efeitos consiste em transmitir uma mesma informação múltiplas vezes. Estatécnica é conhecida como diversidade.

A eficiência da diversidade é maior quando os desvanecimentos que atacam o sinal nas diversastransmissões forem independentes. Desta forma, ao transmitir um sinal em vários canais inde-pendentes, é de esperar que o desvanecimento não afete todos os canais no mesmo instante. Istofaz com que a probabilidade de ocorrer degradação do sinal em todos os canais seja mínima e ainformação recebida não seja tão corrompida pelo desvanecimento.

Um esquema de diversidade pode ser visto como uma forma de redundância que transmite ainformação simultaneamente por canais independentes que ao chegar no receptor são combinadasde forma que os efeitos do desvanecimento são minimizados.

As técnicas de diversidade são as seguintes: diversidade espacial, diversidade em frequência ediversidade temporal.

2.4.1 Diversidade Espacial

Para conseguir diversidade espacial é necessário um conjunto de antenas receptoras cuja sepa-ração entre antenas adjacentes seja de pelo menos 10 comprimentos de onda [7], para garantir queos canais, assim como os desvanecimentos, sejam independentes.

2.4.2 Diversidade em Frequência

Para conseguir diversidade em frequência é necessário transmitir a informação utilizando porta-doras distintas com uma separação igual ou superior à banda de coerência do canal. Desta formase garante que as informações transmitidas pelas portadoras com diferentes frequências sejamafetadas pelo desvanecimento de forma independente.


2.4.3 Diversidade TemporalPara conseguir diversidade temporal é necessário transmitir a informação em intervalos de

tempo diferentes, com um intervalo de separação maior que o intervalo de tempo de coerência docanal para que os sinais recebidos sejam afetados pelo desvanecimento de forma independente.

2.4.4 CombinaçãoAs técnicas de diversidade apresentadas de modo geral possuem 𝐿 percursos com desvaneci-

mentos independentes. Na recepção é possível utilizar um método de combinação evolvendo ossinais dos 𝐿 receptores [7].

Combinação por Seleção

Neste tipo de combinação somente um dos 𝐿 sinais na saída dos receptores é utilizado. O sinalé escolhido segundo um critério previamente estabelecido, como por exemplo, selecionar o sinalcom maior potência recebida.

Combinação por Ganho

Neste tipo de combinação todos os 𝐿 sinais são utilizados, de forma que o sinal resultante édefinido por:

𝑟 =𝐿∑

𝑖=1𝛼𝑖𝑟𝑖 (2.9)

onde 𝛼𝑖 são os pesos de cada ramo de diversidade. Os pesos são definidos segundo a técnica decombinação deste grupo, que podem ser combinação por ganhos iguais ou combinação por razãomáxima.

No caso da combinação por ganhos iguais o valor dos pesos é igual a 1. Por outro lado, para acombinação por razão máxima, os pesos são calculados a partir das estimativas do desvanecimentode cada canal.

2.5 Arquitectura de RedePara facilitar o projeto, a maior parte das redes encontra-se estruturada como uma pilha de

camadas ou níveis. O objetivo de cada camada consiste em oferecer serviços para as camadassuperiores. A comunicação entre a camada 𝑛 de uma máquina e a camada 𝑛 de outra máquina éestabelecida mediante regras e convenções denominadas protocolos que indicam a forma em que acomunicação deve ser realizada. O conjunto de camadas e protocolos é conhecida como arquiteturade rede. Os modelos de referência mais importantes e conhecidos são o modelo OSI e TCP/IP.


Subrede de comunicação

Apresentação

Sessão

Transporte

Rede

Enlace Dados

Física

Aplicação

Apresentação

Sessão

Transporte

Rede

Enlace Dados

Física

Aplicação

Protocolo de Apresentação

Protocolo de Aplicação

Protocolo de Sessão

Protocolo de Transporte

Rede

Enlace Dados

Física

Rede

Enlace Dados

Física

UnidadeIntercambiada

Dados

Dados

Dados

Segmento

Pacote

Trama

Bits

Camada

7

6

5

4

3

2

1

Figura 2.5: Modelo de Referência OSI [2].


2.5.1 Modelo de Interconexão de Sistemas AbertosA Organização Internacional para Padronização (ISO) propôs o modelo de Interconexão de

Sistemas Abertos (OSI) com a finalidade de padronizar os protocolos utilizados nas diferentescamadas [8]. Como pode ser observado na Fig. 2.5, o modelo OSI é composto por sete camadas,cada uma delas define funções de rede particulares e provem o entorno da comunicação entrecomputadores [2]. A seguir é apresentado um resumo das características de cada camada.

Camada Física: Realiza a transmissão de bits através de um canal de comunicação. Nestacamada são definidas as interfaces mecânicas, elétricas e de temporização.

Camada de Enlace de Dados: Transforma o meio de comunicação em um meio livre de errospara a camada superior. É a camada encarregada do endereçamento físico, distribuição dosquadros e o controle de acesso em meios compartilhados.

Camada de Rede: Controla as operações da subrede, determina os endereços lógicos dos nós eo roteamento dos pacotes através da rede.

Camada de Transporte: Recebe os dados das camadas superiores, realiza processos de frag-mentação e garante que os dados cheguem corretamente ao nó destino. Estabelece umaverdadeira conexão de ponto a ponto entre o dispositivo origem e o destino.

Camada de Sessão: Permite o estabelecimento de sessões, controle de diálogo e sincronização.

Camada de Apresentação: É a camada encarregada da sintaxe da informação transmitida.Representa a informação de maneira abstrata.

Camada de Aplicação: Define os protocolos utilizados pelas aplicações para o intercâmbio dedados.

2.6 Modelo TCP/IPEste modelo foi implementado na rede ARPANET e depois na sua sucessora: a Internet. O

modelo leva o nome dos protocolos mais utilizados e importantes que tem o modelo. O modeloTCP/IP e seus protocolos são mantidos pela Internet Engineering Task Force (IETF). O modeloapresenta quatro camadas cujas concepções são similares às do Modelo OSI, apresentadas na secçãoanterior. A Fig. 2.6 compara as camadas do modelo OSI com o TCP/IP.

No protocolo TCP/IP são utilizadas as seguintes camadas:

Camada de Enlace: É a camada mais baixa do modelo e especifica os requerimentos que osenlaces devem obedecer para servir à camada superior.


Apresentação

Sessão

Transporte

Rede

Enlace Dados

Física

Aplicação

Transporte

Rede

Enlace Dados

Aplicação7

6

5

4

3

2

1

Ausente nomodelo

OSI TCP/IP

Figura 2.6: Modelos OSI e TCP/IP [2].

Camada de Rede: É a camada que mantém junta a arquitetura. Permite entregar e receberpacotes na rede local ou em outras redes externas.

Camada de Transporte: Permite a comunicação direta entre o nó origem e o nó destino. Osprotocolos são de ponto a ponto.

Camada de Aplicação: Define os protocolos utilizados pelas aplicações para o intercâmbio dedados.

2.7 Simulação de Monte CarloO método de Monte Carlo é uma técnica computacional utilizada para se estimar a proba-

bilidade de certos eventos em experimentos aleatórios. O termo Monte Carlo foi nomeado emreferência à cidade de Mônaco, onde as atrações principais são os cassinos e os jogos de azar, poiseles exibem um comportamento aleatório.

Permite explorar modelos complexos como os encontrados nos sistemas financeiros, fenômenosfísicos e os sistemas de comunicações. Os sistemas são modelados e são simulados em laços, comvariações de parâmetros e estatísticas entre as simulações. Os resultados são analisados paradeterminar características do sistema.

Algumas tarefas que requerem o uso da simulação de Monte Carlo:

• Variar parâmetros desconhecidos no modelo.


• Criar simulações dinâmicas para alterar os parâmetros com incerteza estatística.

• Modelamento de sistemas dinâmicos complexos.

• Análise de dados mediante gráficos e métodos estatísticos.

Capítulo 3

Protocolo de Controle de Transmissão(TCP)

A maioria das aplicações de rede, tais como o Protocolo de Transferência de Arquivos (FTP)e o Protocolo de Transferência de Hipertexto (HTTP), comumente utilizados nos navegadoresda Internet, requerem que a informação chegue no destino de forma íntegra. O protocolo dacamada de transporte selecionado para essa tarefa é o TCP. O protocolo TCP foi projetado paraestabelecer uma comunicação ponto-a-ponto de forma confiável e orientada à conexão. O protocoloTCP carrega um registro do estado da conexão em todo momento e administra o fluxo de dadosmediante o intercâmbio de mensagens entre os terminais.

3.1 Desenvolvimento do Protocolo TCPO protocolo TCP foi publicado em 1981 e suas funcionalidades básicas estão definidas em [9].

Desde a sua criação até a atualidade foram realizadas modificações e melhorias do seu desempe-nho [10], mecanismos de Confirmação Seletiva (SACK) [11], entre outros. Porém, o Request ForComments (RFC) de maior importância é o RFC 5681 [12], no qual foram definidos os algoritmosde controle de congestionamento do TCP.

A largura de banda de um enlace, o tamanho do buffer e a velocidade de processamento de umdispositivo são recursos de rede disponíveis, que determinam o fluxo de dados. Quando a demandadesses recursos é superior à disponível, congestionamento e deterioração do desempenho da redesão produzidos. O controle de congestionamento consiste em distribuir os recursos de tal formaque a rede possa operar adequadamente, quando sua capacidade se encontra no limite.

As primeiras manifestações do congestionamento e seus efeitos foram observados nos anos 80durante o desenvolvimento da rede ARPANET. O motivo se devia à retransmissão desnecessáriade segmentos que já haviam sido recebidos pelo receptor, ou que já se encontravam a caminho [13].A implementação original do protocolo TCP usava um controle de fluxo de dados mediante umajanela no receptor, mas não havia ainda uma janela para o transmissor. O problema foi resolvidocom a criação dos temporizadores de retransmissão e do algoritmo de controle de congestionamentoproposto em [14].

19

20 Capítulo 3. Protocolo de Controle de Transmissão (TCP)

O rápido crescimento da Internet nas últimas décadas deu lugar a várias implementações doprotocolo TCP em diferentes dispositivos e sistemas operacionais. Algumas implementações apre-sentaram problemas e interpretações errôneas das especificações como é mostrado em [15]. Oincremento do número de usuários piorou os problemas de congestionamento, levando ao desen-volvimento de princípios do controle e mostrando os perigos de não se fazer um controle de con-gestionamento apropriado [16]. Atualmente as implementações do protocolo TCP contam comalgoritmos de controle e prevenção de congestionamento.

3.2 Características do Protocolo TCPTCP é um protocolo ponto-a-ponto e full-duplex. Um protocolo ponto-a-ponto indica que a

sessão ocorre entre duas partes, o lado do transmissor e o lado do receptor. No entanto, que serfull-duplex indica que o tráfego flui em ambos sentidos ao mesmo tempo, do host de origem ao hostde destino e vice-versa. O protocolo TCP oferece serviços orientados à conexão e confiabilidadeno envio de feixes de dados.

3.2.1 Orientado à ConexãoO envio de dados não pode ser feito de forma imediata, previamente deve estar estabelecida

uma sessão entre a origem e o destino em um processo chamado handshaking de 3 vias. Nesseprocesso, o dispositivo destino precisa estar ativo e são definidos parâmetros como o tamanhomáximo do segmento (MSS) e os números de sequência iniciais. A Fig. 3.1 ilustra o processo dehandshaking, que ocorre assim:

1. O cliente envia um segmento com o bit SYN ativo e um número de sequência 𝑥.

2. O servidor responde com um segmento com os bits ACK e SYN ativos, com valor de confir-mação 𝑥 + 1 e número de sequência 𝑦.

3. O cliente envia outro segmento com o bit ACK ativo e valor de confirmação 𝑦 + 1.

3.2.2 ConfiabilidadeO envio confiável de dados é garantido por vários mecanismos. O protocolo TCP usa avisos

de reconhecimento que confirmam ao transmissor a chegada dos segmentos enviados e mantémum registro dos bytes recebidos, o que permite detectar possíveis segmentos duplicados. Comoas camadas inferiores não cuidam da confiabilidade dos datagramas, os segmentos podem chegarem ordem distinta da qual foram enviados e é dever do protocolo TCP organizar os segmentospara serem utilizados corretamente pela camada de aplicação. Todo segmento TCP possui umasoma de verificação de paridade, checksum, que permite determinar dados com erro. Além disso,

Capítulo 3. Protocolo de Controle de Transmissão (TCP) 21

SYN (seq=x)

SYN,ACK (seq=y, ack=x+ 1)

ACK (seq=x+ 1, ack=y + 1)

Cliente Servidor

Figura 3.1: Estabelecimento de uma Conexão TCP.

o protocolo TCP possui temporizadores para cada segmento enviado, com um período de tempo àespera da confirmação de recepção. O vencimento dos temporizadores obriga uma retransmissãopara garantir a entrega da informação.

3.2.3 Envio de DadosO protocolo TCP realiza uma interface entre a camada de rede e a camada de aplicação e

permite o intercâmbio de dados na forma de bytes. O protocolo TCP divide o fluxo de dadosem segmentos de tamanho menor para serem transmitidos. Dividir em secções menores melhoraa eficiência de transmissão. O tamanho dos dados encapsulados não pode ser superior ao MSS edeve ser limitado pela Unidade Máxima de Transmissão (MTU).

3.3 Formato do Cabeçalho TCPO protocolo TCP intercambia informação na forma de segmentos. Um segmento consta de um

cabeçalho TCP seguido de dados. O cabeçalho contém todas as informações requeridas para ocontrole da transmissão, o estado da conexão e a integridade do segmento [17]. Segundo padrão, ocabeçalho consta de 20 bytes de comprimento, mas pode chegar até 60 bytes se contiver o campode opções. Na Fig. 3.2 é apresentado o formato de um segmento TCP.

Portas: Define os números dos terminais de origem e de destino. Juntos identificam uma conexão.

Número de Sequência: Identifica a posição do segmento no fluxo de bytes enviado pelo trans-missor.


0 4 8 16 31

Porta de Origem Porta de Destino

Número de Sequência

Número de Confirmação

Tamanhodo cabe-

çalho

Reser-vados

CWR

ECE

URG

ACK

PSH

RST

SYN

FIN

Janela

Checksum Ponteiro de Urgência

Opções (opcional)

Dados (opcional)

Figura 3.2: Formato de um Segmento TCP.

Número de Confirmação: Contém o valor do próximo número de sequência que o receptorespera receber.

Tamanho do Cabeçalho: Indica a quantidade de palavras de 32 bits contidas no cabeçalhoTCP.

Campo Reservado: ë composto de 4 bits que não tem uso, foi criado para novas característicase uso futuro.

Bandeiras: Campo de 8 bits com os sinalizadores TCP.

CWR: Ativa quando for recebido um segmento com o bit ECE ativo.ECE: Ativa para realizar Notificação Explícita de Congestionamento (ECN).URG: Indica que o campo Ponteiro de Urgência está ativo.ACK: Indica que o segmento é uma confirmação e o campo Número de Confirmação é

válido.PSH: Indica ao receptor para enviar os dados para a aplicação sem armazená-los no buffer.RST: Restabelece uma conexão devido a uma queda de um host.SYN: É utilizado para estabelecer e aceitar conexões.FYN: Indica que não existem mais dados para transmitir, encerra a conexão.

Janela: Especifica o número de bytes que o receptor é capaz de receber sem confirmação.

Checksum: Contém uma soma de verificação do cabeçalho e dos dados. Permite verificar que osegmento recebido está livre de erros.


Ponteiro de Urgência: Indica o deslocamento em bytes a partir do número de sequência atual,onde existem dados urgentes. É usado junto com o bit URG.

Opções: Permite informar características adicionais como o MSS, a opção de SACK e outros.

3.4 Controle de Fluxo de Dados TCPO controle de fluxo é realizado através do mecanismo da janela deslizante. Os avisos de con-

firmação (ACKs) enviados pelo receptor levam um valor no campo tamanho da janela que indicao número de bytes que o transmissor pode enviar sem a necessidade de confirmação em um dadomomento. Este valor recebe o nome de janela anunciada e corresponde ao tamanho do buffer derecepção disponível no receptor para a comunicação.

O nó transmissor pode transmitir vários segmentos sem esperar confirmação. A quantidadeestá sujeita ao valor da janela anunciada e nunca pode ser maior que o tamanho do buffer derecepção. Caso exista uma janela anunciada com valor zero, entende-se que o buffer receptor estácheio e não deve enviar mais segmentos, já que podem ser rejeitados.

O protocolo TCP divide os segmentos em grupos para determinar quais foram enviados, quaisforam confirmados, quais estão à espera de confirmação e quais ainda não foram enviados. AFig. 3.3 mostra o comportamento da janela deslizante, tanto para a entidade transmissora, comopara a receptora.

3.5 Controle de Congestionamento TCPQuando uma rede atinge o ponto de congestionamento, os recursos encontram-se colapsados e

seu uso não estará disponível para segmentos transmitidos no futuro devido ao tráfego ou buffersestourados. Além disso, são apresentados a seguir os problemas como o aumento do atraso e avariação do atraso (jitter), retransmissões de segmentos, diminuição da vazão de dados e janelasanunciadas com valores menores que os esperados.

As redes de dados precisam possuir um controle de congestionamento para prevenir futurasperdas de pacotes. Caso contrário, podem acontecer os seguintes efeitos negativos:

• Incremento do atraso e jitter na transmissão de segmentos.

• Retransmissão de segmentos por causa de atrasos maiores.

• Diminuição da taxa de transferência.

• Uso pouco eficiente dos recursos da rede.

• Congestionamento intenso pode colapsar os recursos do enlace por congestionamento. Nestecaso, o valor da vazão de dados alcança valores reduzidos, perto do zero [13].


...

Janela no Transmissor

Janela de Transmissão

Buffer de Transmissão

Segmentos confirmados Segmentos enviados à espera de ACK

X X X X X X

...

Janela no Receptor

Janela anunciada

Buffer de Recepção

ACKs enviadosACKs prontos para

enviar ao transmissor

XX X X X X X XX X X X

Figura 3.3: Janela Deslizante no Transmissor e no Receptor TCP.


O objetivo do controle de congestionamento do protocolo TCP consiste em limitar a taxa detransmissão dos segmentos quando a rota ao destino apresenta tráfego mais intenso. O protocoloTCP logra esse controle ao monitorar variáveis como o último byte recebido e o último byte confir-mado. A Janela de Congestionamento (CWND) é a variável que coloca limites na taxa de pacotesinjetados na rede. Indica a quantidade de segmentos sem confirmação que o transmissor podeenviar. A janela de transmissão não deve exceder o mínimo entre a janela de congestionamento(CWND) e a janela do receptor (RcvWND) como expresso em:

UBE − UBC ≤ min(CWND, RcvWND) (3.1)

onde UBE é o último byte enviado, e UBC é o último byte confirmado.

A vazão de dados, ou throughtput é a taxa de dados enviados do transmissor ao receptor.Determina-se em função da janela de congestionamento atual, 𝑊 , e do tempo de ida e volta (RTT).Se a vazão for medida em bytes por segundo com um tamanho de MSS bytes por segmento, entãoa vazão é dada por:

𝜗 = 𝑊MSSRTT (3.2)

O transmissor TCP detecta congestionamento quando ocorrer um evento de perda, quando ostemporizadores TCP expirarem ou quando forem recebidos três ACKs duplicados. Os mecanis-mos do controle de congestionamento são: Incremento-Linear, Decremento-Multiplicativo, PartidaLenta (Slow Start), Prevenção de Congestionamento (Congestion Avoidance), Retransmissão Rá-pida (Fast Retransmit) e Recuperação Rápida (Fast Recovery) e são mostradas na Fig. 3.4.

3.5.1 Incremento-Linear, Decremento-MultiplicativoA entidade TCP transmissora incrementa linearmente o fluxo de dados quando percebe que

o caminho de ponto-a-ponto se encontra livre de tráfego, e decresce multiplicativamente a taxaquando congestionamento é detectado. O incremento da taxa de transmissão ocorre quando não édetectado congestionamento, implicando que possivelmente existe largura de banda que a conexãoTCP poderia ainda utilizar. Nessas circunstâncias, o protocolo TCP incrementa sua janela decongestionamento de forma lenta, testando a disponibilidade de maior largura de banda no canalponto-a-ponto: A cada ACK recebido, a janela aumenta 1 segmento por Tempo de ida e volta(RTT) [12], ou seja:

CWND = CWND + AcksCWND (3.3)

onde 𝐴𝑐𝑘𝑠, é o número de ACKs recebidos no intervalo de um RTT.


O incremento linear do algoritmo de controle do protocolo TCP é conhecido como Prevençãode Congestionamento. O valor da CWND passa por vários ciclos nos quais aumenta linearmente(incremento linear) até ocorrer um evento de perda, quando a janela é diminuída para a metadedo valor atual (decremento multiplicativo) apresentando o padrão dente de serra da Fig. 3.4.

3.5.2 Partida LentaÉ a fase inicial do processo de controle de congestionamento. É utilizada para determinar a

capacidade do canal e calcular a janela de congestionamento até atingir o limiar de congestiona-mento. Ao estabelecer uma conexão, a CWND tem o valor de 1 MSS e o limiar tem um valor de65kB. Toda vez que são recebidas confirmações dos segmentos enviados, a CWND é incrementadade forma exponencial ao duplicar o valor da CWND por RTT, ou seja:

CWND = CWND + 1 (3.4)

O crescimento continua até ocorrer um evento de perda. Nesse caso, o valor da janela é divididopor dois e o limiar de congestionamento adota esse novo valor. Quando a CWND atinge o valordo limiar, o protocolo TCP ingressa na fase de prevenção de congestionamento.

3.5.3 Prevenção de CongestionamentoNesta fase, a capacidade da rede já é conhecida, e assim o protocolo TCP deve evitar ultrapassar

o ponto de congestionamento. Isso é obtido reduzindo o incremento da janela de congestionamento.Nesta fase o incremento é linear, o tamanho da janela cresce com o valor de 1

CWND toda vez queuma confirmação ACK é recebida, e o crescimento da janela ocorre a cada RTT.

O congestionamento é detectado quando um ACK não foi recebido, ou quando um temporizadorvenceu, ou foram recebidos 3 ACKs duplicados. Se ocorrer alguma das situações mencionadas, olimiar adota a metade do valor da CWND, a CWND adota o valor de 1 e o protocolo TCP retornaà fase de partida lenta. Atualmente, com a criação das fases recuperação rápida e retransmissãorápida, este processo não ocorre mais.

3.5.4 Recuperação e Retransmissão RápidaAlguns algoritmos foram projetados para evitar a volta à fase da partida lenta depois de receber

os segmentos de confirmação ACK. A recuperação rápida realiza o mesmo procedimento da fasede prevenção de congestionamento, com a diferença que o valor da CWND é a metade do últimovalor atingido no intervalo de tempo anterior com crescimento linear [12].


A retransmissão rápida é um algoritmo que retransmite os segmentos perdidos antes do ven-cimento dos temporizadores. Ocorre quando chegam segmentos ACKs duplicados solicitando aretransmissão do segmento.

W

Limiar

TRTT

Partida Lenta Prevenção deCongestionamento

Segmento PerdidoSaturação

Recuperação Rápida

Figura 3.4: Algoritmo de Controle de Congestionamento TCP.

3.6 Versões do Protocolo TCPA seguir são apresentados alguns aspectos importantes das diferentes versões do protocolo TCP

associadas ao nome pelo qual são conhecidas.

3.6.1 TCP TahoeFoi a primeira versão do protocolo TCP ao usar os mecanismos de congestionamento propostos

em [14] quando se estabeleciam os fundamentos do controle e prevenção do congestionamento.Implementa a partida lenta, a prevenção de congestionamento e a retransmissão rápida. Um dos


principais conceitos indica que a janela de transmissão dos segmentos deve obedecer a regra de con-servação do pacote: um novo pacote não pode ingressar na rede até ocorrer a confirmação de saídade um pacote antigo na rede. Isto foi conseguido mediante a criação dos segmentos de confirmação,ACK, que permitiu transmitir novos pacotes com a mesma taxa que são recebidas as confirmações.A primeira aparição foi em 1988 no sistema operacional Berkeley Software Distribution (BSD).

Em caso de perda, o protocolo TCP Tahoe retransmitia o segmento perdido e colocava o limiarda partida lenta para o valor CWND/2 e o valor da CWND=1, entrando na fase partida lenta.Mas toda vez que ocorriam várias perdas o algoritmo apresentava sérios problemas no desempenho,dado que o algoritmo era sempre obrigado a entrar na fase lenta.

3.6.2 TCP RenoTem as mesmas características do protocolo TCP Tahoe, mas faz uma diferenciação entre as

perdas detectadas por recebimento de ACKs duplicados daquelas detectadas por vencimento dostemporizadores TCP. A ideia consiste em que uma perda por vencimento dos temporizadores sópoderia ocorrer se o fluxo de segmentos entre as entidades TCP parasse totalmente, indicando umcaso grave de congestionamento, contanto que a chegada de ACKs indica um congestionamentoleve. No último caso, o algoritmo TCP não deveria ingressar na fase partida lenta, dado que aindaexiste um fluxo de dados, e que somente deveria diminuir levemente a taxa de transmissão.

Isto é conseguido mediante a implementação da recuperação e retransmissão rápida, permitindoenviar dados a uma boa taxa de transmissão. Caso existam várias perdas em um mesmo ciclo sóserá possível recuperar a primeira perda de forma rápida. As outras ocasionam o vencimento dostemporizadores e o retorno à fase partida lenta. Esta versão foi implementada no BSD em 1990.

Retransmissão Rápida e Recuperação Rápida do Protocolo TCP Reno

Na recepção de segmentos ACK duplicados, o protocolo TCP Reno envia uma retransmissãodo segmento faltante utilizando o algoritmo de transmissão rápida para evitar o vencimento dostemporizadores. Se a confirmação do segmento retransmitido não for enviada, a fase partida lentaentra em ação. A implementação do protocolo TCP Reno [12] é a seguinte:

1. O limiar da partida lenta é igual a um valor não maior que max(𝐶𝑊𝑁𝐷/2, 2) ao receber oterceiro ACK duplicado.

2. Retransmitir o segmento perdido e definir o valor da CWND = 𝐿𝑖𝑚𝑖𝑎𝑟 + 3 para forçar oingresso na fase prevenção de congestionamento.

3. Incrementar a CWND de um 1 a cada ACK recebido, a fim de refletir no segmento que seráenviado a seguir.

4. Transmitir o novo segmento, se permitido, pelo novo valor da CWND, ou pela janela anun-ciada pelo receptor TCP.


5. Quando chegar o próximo segmento ACK confirmando nova informação, atribuir a janela decongestionamento com o valor do limiar fixado no passo 1.

3.6.3 TCP New-RenoSimilar ao protocolo TCP Reno, exceto por uma modificação no algoritmo de recuperação

rápida, de forma que permita recuperar várias perdas simultâneas [18].

Recuperação Rápida do Protocolo TCP New-Reno

O algoritmo está descrito no RFC 2582 e sua atualização é apresentada em [19], da seguinteforma:

1. Inicializar a variável send_recover com o número de sequência inicial do segmento. Quandofor recebido um terceiro segmento ACK duplicado e se o transmissor ainda não estiver na fasede Recuperação Rápida, é verificado se os números dos segmentos duplicados são maioresque a variável. Caso forem maiores, é atribuido ao limiar o valor max(𝐶𝑊𝑁𝐷/2, 2) e o valordo número de sequência mais alto transmitido é armazenado na variável send_recover.

2. Retransmitir o segmento perdido e definir o valor da CWND = 𝐿𝑖𝑚𝑖𝑎𝑟 + 3 para forçar oingresso na fase Prevenção de Congestionamento.

3. Incrementar o valor da CWND por um MSS a cada ACK duplicado recebido para incrementara janela, a fim de refletir o segmento que será enviado a seguir.

4. Transmitir o novo segmento, se permitido, usando o novo valor da CWND, ou pela janelaanunciada pelo receptor TCP.

5. Quando um novo segmento ACK for recebido confirmando os segmentos de dados incluídosna send_recover, a CWND recebe o valor de min(𝐿𝑖𝑚𝑖𝑎𝑟, 𝐶𝑊𝑁𝐷 + 1), ou o limiar como valor descrito no passo 1 para sair da fase de recuperação rápida. Caso contrário, indicaconfirmações parciais, o protocolo TCP se mantém na fase recuperação rápida e realiza oseguinte:

(a) Retransmitir o primeiro segmento que não recebeu confirmação, reduzir a CWND se-gundo o número de segmentos que foram confirmados, incrementar a janela por umMSS e restabelecer os temporizadores de transmissão.

(b) Tentar o envio do novo segmento dependendo do tamanho da janela CWND e da janelaanunciada.

6. Caso ocorrer o vencimento de um temporizador, o valor do maior número de sequênciatransmitido até o momento é armazenado na variável send_recover, e o protocolo TCP saida fase Recuperação Rápida.


3.6.4 TCP Confirmação SeletivaA modificação do protocolo TCP com confirmação seletiva (SACK) [11] permite ao receptor

TCP confirmar segmentos que chegaram fora de ordem em vez de confirmar acumulativamente oúltimo segmento recebido que chegou em ordem. Este fenômeno é comum nas redes de comutaçãode pacotes como a Internet. O receptor TCP informa ao transmissor que segmentos não contíguosforam recebidos e que estão sendo armazenados no buffer. Para conseguir isso, as duas entidadesTCP tem que negociar a opção SACK durante o estabelecimento da conexão no handshake de 3vias.

A opção pode ser adicionada em qualquer versão do protocolo TCP, como Tahoe e Reno,dado que não muda o funcionamento de cada um dos algoritmos de controle. As informações dossegmentos faltantes são enviadas ao transmissor TCP como blocos SACK no campo opções e o bitACK ativo no cabeçalho TCP. Um estudo [20] mostrou que TCP SACK se recupera rapidamentede múltiplas perdas de segmentos, evitando o vencimento dos temporizadores e melhorando a taxade transferência de 10% a 30%.

3.7 TCP em Meios sem FioEm teoria, os protocolos da camada de transporte devem ser independentes dos protocolos das

camadas de rede inferiores. Na prática, a maior parte das implementações do protocolo TCP foramfeitas com suposições que ocorrem e são cumpridas nas redes com fio, mas não nas redes sem fio[2]. As propriedades dos meios sem fio diferem notavelmente, já que possuem altas BERs e perdasaleatórias por desconexões momentâneas, variações da intensidade do sinal e também por ruído.

Uma das suposições em meios com fio é que o vencimento de um temporizador ocorre pelocongestionamento no meio e não por uma perda ocasional. O prejuízo na taxa de transmissão queapresenta o protocolo TCP sobre enlaces sem fio se deve a essa má interpretação. Uma solução aesse problema é modificar o protocolo TCP para identificar quando o protocolo TCP está sendoexecutado sobre um enlace sem fio, tal que ele possa se adaptar adequadamente.

Capítulo 4

Melhorias para o Protocolo TCP SemFio

Nos últimos anos as redes sem fio se tem convertido em um meio de acesso muito popular nomundo das telecomunicações, compartilhando informação através de várias infraestruturas sem fio.Como foi apresentado na Capítulo 1, um dos principais desafios nas redes de hoje é prover acessoà Internet sem fio aos aplicativos que dependem do protocolo TCP para sua correta comunicação.Porém, como mencionado no capítulo anterior, o protocolo TCP possui falhas em seu planejamentoque impedem a sua adequação para o transporte de segmentos sobre um ambiente sem fio.

A seguir, são descritas algumas melhorias e optimizações propostas na literatura para solucionaro problema do protocolo TCP sem fio. São classificadas em quatro grupos principais, segundo otipo de mecanismos utilizados e a camada de rede na qual atuam. A classificação é a seguinte:conexão-dividida, camada de enlace, notificação explícita e protocolos de ponto-a-ponto.

4.1 Protocolos de Conexão-DivididaA abordagem dos protocolos de conexão dividida consiste em dividir uma conexão TCP em

duas conexões em um ponto intermediário da rede. O primeiro segmento engloba as redes com fiodesde o Host Fixo (HF) à Estação Rádio-Base (ERB), o outro consiste na rede sem fio desde aERB ao Host Móvel (HM). A Fig. 4.1 mostra o esquema deste tipo de protocolo.

A subdivisão dos segmentos oferece algumas vantagens. As características de transmissão noenlace sem fio, como a alta probabilidade de erro e desconexões por sombreamento e handoffs,afetam somente ao segmento sem fio. Com a divisão dos segmentos é possível esconder os efeitosdo canal sem fio das entidades TCP que utilizam a rede com fio. Aliás, permite a utilizaçãode diferentes protocolos de transporte nos segmentos distintos. Porém, as conexões TCP sãoexecutadas na ERB e são necessários buffers de dados fixos, em que toda a informação da conexãoTCP deve ser armazenada na ERB em um esquema de conexão-dividida. O tamanho desses bufferspodem ser fixos ou especificados durante uma conexão TCP.

31

32 Capítulo 4. Melhorias para o Protocolo TCP Sem Fio

HF HMERB

Rede sem fio

Rede com fio confiável

Conexão TCP HF-ERB Conexão TCP ERB-HM

Figura 4.1: Conexão TCP Dividida em Conexões Diferentes.

4.1.1 TCP Indireto

O protocolo TCP Indireto (I-TCP) [21] é uma solução de conexão-dividida que utiliza suportemóvel MSR como ERBs para outorgar comunicação entre usuários móveis e fixos na camada detransporte. Sobre o enlace sem fio é utilizado o protocolo TCP padrão que tenta separar as perdasdo enlace sem fio do enlace por cabo. Seu objetivo consiste de que os erros e atrasos produzidos naparte não confiável da rede não ativem os mecanismos de controle do protocolo TCP, eliminandoa retransmissão de dados no segmento HF-ERB. Experimentos realizados em [22] mostram que aescolha do protocolo TCP no enlace sem fio resulta em uma utilização ineficiente da capacidadedo enlace e cria sobrecarga na ERB.

4.1.2 Protocolo de Conexão-Dividida com Repetição Seletiva

Proposto em [23], os autores sugerem a criação de um novo protocolo na camada de sessãopara compensar as características do enlace sem fio. O protocolo foi projetado para aproveitartodas as características que puderem ser conhecidas no enlace sem fio e compensar por situaçõesimprevisíveis entre os usuários e a estação rádio base. O agente intermediário na ERB atuadirigindo a sessão e reenvia os dados recebidos ao usuário móvel. São utilizados dois protocolos noenlace sem fio: o protocolo TCP padrão e o Protocolo de Repetição Seletiva (SRP).

O protocolo SRP implementa seus próprios mecanismos de fluxo e controle de erros, projetadose otimizados especificamente para combater os efeitos dos enlaces sem fio. Utiliza um algoritmo derepetição seletiva que responde com uma confirmação seletiva, SACK, quando um segmento forade ordem é recebido. O segmento SACK especifica os segmentos perdidos e que inclui o número desequência do último segmento transmitido e o último segmento recebido. Esta abordagem permitea recuperação de várias perdas simultâneas em uma mesma janela de transmissão.

Capítulo 4. Melhorias para o Protocolo TCP Sem Fio 33

4.1.3 Protocolo de Transporte Ponto-MóvelO protocolo de transporte ponto-móvel (METP) apresentado em [24] é uma solução que eli-

mina a pilha de protocolos TCP/IP dos host móveis. Os cabeçalhos da camada de transporte eda camada de rede no segmento sem fio são substituídos por cabeçalhos que contém chaves de-multiplexadas e endereços IP da fonte e do destino. O protocolo METP considera o segmentosem fio como se fosse um nó final no caminho da transferência de dados e prescinde da camadatransporte nos usuários móveis. Todas as conexões TCP são processadas na estação base peloprotocolo METP em lugar do HM, que é encarregado de estabelecer ou fechar as conexões TCP.Na chegada de um segmento TCP para algum dos usuários móveis, o protocolo METP armazena osdados da conexão e responde com um segmento ACK ao transmissor TCP. Desse modo, o controlede congestionamento trabalha unicamente no segmento de rede com fio para o qual foi projetado.

Dado que a conexão TCP não consegue passar do segmento com fio, o protocolo METP devegarantir o envio da informação no enlace sem fio. Para conseguir isso são necessários mais recursosde processamento e maior espaço de armazenamento na ERB, tornando o usuário móvel mais de-pendente da ERB. Aliás, a chegada de um segmento TCP na ERB ocasiona o envio da confirmaçãodesse segmento por parte da ERB indicando que foi recebido com sucesso. Porém, se a ERB nãoconsegue transmitir a informação contida no segmento TCP para o HM, essa informação não serárecebida novamente.

4.1.4 TCP-MóvelProposto em [25], o protocolo TCP-Móvel realiza uma compressão do cabeçalho para reduzir

a quantidade de informação de controle transmitida no enlace sem fio. Leva em consideração quetodos os segmentos passam previamente pela estação rádio base e portanto, não é necessária umacomunicação TCP completa entre o transmissor TCP e o HM. No estabelecimento da conexão, osendereços de cada segmento são associados com uma identificação de conexão (CID) para sua futuratransmissão no enlace sem fio. O CID contém informações mínimas para garantir a comunicação,como os endereços IP de origem e destino e os números das portas utilizadas no protocolo TCP.Quando um usuário móvel necessita transmitir informação sobre a rede, os cabeçalhos TCP sãomapeados a seu correspondente CID e são transmitidos pelo enlace sem fio. Ao chegar na ERB, asinformações da CID são mapeadas novamente no cabeçalho TCP/IP correspondente. O processose repete de forma inversa quando o HF envia os dados solicitados. Os segmentos TCP sãoconfirmados pela estação rádio base apenas quando chegaram com sucesso no HM.

4.1.5 Protocolo de Transporte Móvel de Conexão-DivididaO protocolo de transporte móvel de conexão-dividida (SCMTP) [26] propõe um esquema similar

ao descrito no Protocolo de Transporte Ponto-Móvel. O protocolo SCMTP utiliza o protocolo TCPno segmento de rede com fio e um protocolo de transporte mais leve no segmento de rede sem fio. Adiferença consiste no uso do protocolo requisição automática de repetição (ARQ) para solucionar osproblemas produzidos pelos erros do canal sem fio. Multiplexação por divisão de tempo é utilizada


no enlace direto da ERB à HM para atribuir a capacidade de cada usuário. Acesso múltiplo pordivisão de tempo é empregado pelos hosts móveis no enlace reverso. Algoritmos implementadosna estação rádio base controlam o tráfego entre a ERB e o HM, além do compartilhamento dosenlaces direto e reverso.

4.1.6 ResumoOs esquemas apresentados tentam melhorar o desempenho do protocolo TCP em ambientes

sem fio ao isolar o transmissor TCP dos efeitos do canal sem fio. Nenhum dos esquemas propostospermite informar ao transmissor que o segmento foi perdido por congestionamento ou erros nocanal. As retransmissões dos segmentos continuam da mesma forma, impedindo manter a vazãode dados em níveis altos devido às características de um ambiente que favorece a introdução deerros. Em alguns casos, os protocolos propostos violam a semântica ponto-a-ponto do protocoloTCP.

4.2 Protocolos da Camada de EnlaceOutra alternativa para melhorar o desempenho do protocolo TCP em ambientes sem fio é

conseguido através de protocolos da camada de enlace. Este conceito consiste em disfarçar os errosproduzidos no enlace sem fio para que o protocolo TCP perceba que se encontra sobre um enlacecom fio. Assim, os erros são corrigidos localmente na camada de enlace. Este método é ilustradona Fig. 4.2. As principais técnicas utilizadas são códigos corretores de erro (FEC) e o RequisiçãoAutomática de Repetição (ARQ). Quando um bloco é recebido e erros foram detectados, um ACK-ARQ é enviado para solicitar a retransmissão do bloco. Redes celulares como GSM incorporam oconceito do ARQ para melhorar a vazão de dados em enlaces sem fio [27]. A seguir, são apresentadasalgumas das propostas de protocolos da camada de enlace.

Rede sem fio


ARQ/FEC

Figura 4.2: Esquema para melhorar o desempenho do Protocolo TCP utilizado Protocolos daCamada de Enlace.


4.2.1 Protocolo SnoopO protocolo Snoop [22] permite manter o protocolo TCP em alerta de perdas usando a camada

de enlace. A retransmissão de dados com erro é feita pelas camadas de rede inferiores e ativamenteevita as retransmissões TCP desnecessárias. Para sua implementação é requisitada uma estaçãorádio base equipada com um agente snoop cuja funcionalidade consiste em monitorar os segmentosTCP transmitidos de um usuário fixo a um usuário móvel, e vice-versa. O agente snoop arma-zena localmente as informações de controle dos segmentos TCP para detectar perdas e possíveisvencimentos dos temporizadores TCP. No caso de detectar uma perda causada pelo canal semfio, o agente imediatamente retransmite o segmento armazenado nos seus buffers e suprime o seg-mento de confirmação duplicado para não ativar os mecanismos de controle de congestionamentono transmissor, ocultando assim a perda e melhorando o desempenho do protocolo TCP em canaissem fio.

4.2.2 Protocolo TCP-AdaptativoÉ um protocolo da camada de enlace que conserva a semântica ponto-a-ponto do protocolo

TCP. O conceito básico deste protocolo consiste em tornar um enlace sem fio em um enlace comfio, pelo menos do ponto de vista do protocolo TCP. A implementação se realiza na estação rádiobase utilizando um agente TCP-adaptativo, que é representado por um modelo de host virtual.Este agente cumpre três funções básicas:

• Retransmissões locais.

• Congelamento do transmissor.

• Controle do fluxo para esconder perdas.

A retransmissão local diminui o efeito ocasionado pelas altas taxas de erro. Ao receber segmen-tos ACK duplicados, o agente TCP-adaptativo se comporta como um agente snoop, filtrando ossegmentos que contém ACKs duplicados. Alem disso, mantém um registro dos temporizadores deretransmissão TCP. Ao expirar o tempo deles para um segmento em particular, o agente retrans-mite o segmento. O controle de fluxo feito pelo protocolo TCP-adaptativo é o fator que permite amelhoria no desempenho do protocolo TCP em enlaces sem fio. O agente TCP-adaptativo realizaum mapeamento do campo janela do segmento TCP com o buffer do mesmo tamanho, prevenindoo transbordamento no enlace sem fio.

4.2.3 Protocolo AIRMAILO protocolo airmail garante a confiabilidade da camada de enlace em conjunto com a correção

antecipada de erros. Esta abordagem foi proposta por [28], com a finalidade de preservar a potênciade transmissão quando a estação rádio base envia uma janela inteira de dados antes que umsegmento ACK seja enviado pelo receptor móvel. Como consequência, a correção de erros somente


pode ser efetuada quando toda a janela foi transmitida, o que pode causar o vencimento do tempode retransmissão devido às variações no atraso e do posicionamento onde ocorreu o erro na janelade dados.

4.2.4 Protocolo de Rádio Enlace

O protocolo de enlace de rádio(RLP) é um protocolo que de forma similar ao protocolo TCPpermite o envio de dados de forma confiável e é tipicamente utilizado em redes celulares. Oprotocolo RLP divide o segmento TCP em fragmentos e usa códigos corretores de erro robustosjunto com esquemas de retransmissão para resguardar e ocultar as perdas produzidas no enlacesem fio, evitando a degradação da vazão de dados. A fragmentação é necessária para garantir agranularidade da transmissão. Na ocorrência de um erro somente um fragmento RLP de menortamanho que o segmento TCP original será afetado.

O protocolo RLP usa o mecanismo de recuperação de erros ARQ para recuperar os fragmentosRLP defeituosos. Os avisos de confirmação podem ser positivos ACKS ou negativos NACKs.Dado que o enlace reverso costuma ser mais caro nas redes celulares, a maior parte dos RLPsimplementam um esquema baseado em confirmações negativas, onde o receptor solicita novamenteos fragmentos que apresentaram erro.

O protocolo RLP pode ser configurado para definir o número máximo de retransmissões de umfragmento. Caso o transmissor RLP não consiga transmitir com sucesso depois de certo númerode tentativas, os fragmentos são descartados e tanto o enlace como os números de sequência sãoreinicializados.

4.2.5 Protocolo TULIP

O protocolo TULIP [29] tem um comportamento similar ao protocolo snoop, mencionado ante-riormente, para melhorar o desempenho do protocolo TCP, sem modificar diretamente a camadade transporte em ambientes com altas probabilidades de erro de bit. Porém, este protocolo nãorequer um agente na rádio base que mantenha um histórico das conexões TCP. Outra diferençaé que oferece serviço confiável para o tráfego TCP e além, oferece um serviço não confiável parao protocolo de datagramas de usuario (UDP) e avisos de confirmação TCP. As confirmações nãorecebem um tratamento de entrega confiável, dado que a informação contida nos segmentos ACKperdidos pode ser levada pelos ACKs futuros.

O receptor simplesmente envia os dados em ordem para as camadas superiores, evitando ageração de segmentos TCP duplicados no caso que um segmento esteja faltante na sequênciade segmentos esperados. O protocolo TULIP mantém temporizadores baseados no atraso depropagação ao invés de realizar a estimação do tempo de ida e volta do canal.


4.2.6 D-ProxyD-Proxy [30] é um protocolo da camada de enlace que utiliza um agente proativo e distribuído

que cobre as falhas do protocolo snoop e dos protocolos de conexão-dividida. Uma diferença notávelé que o agente é usado na estação base, assim como no usuário móvel. Cada um deles deve criarbuffers para armazenar os segmentos TCP recebidos e para futuras retransmissões, caso existapresença de erros. O controle de erros e o fluxo de dados está a cargo dos dois agentes. O D-proxydetecta as perdas da mesma forma que o protocolo TCP. O segmento perdido é reconhecido quandoo número de sequência recebido é maior que o esperado. No caso de perda, o agente D-Proxy enviauma confirmação negativa solicitando novamente o segmento perdido. Um dos problemas destaabordagem é que cada agente deve manter um registro com todas as informações da conexão:endereços IP, Portas TCP e suficiente espaço em memória para armazenar os segmentos TCPtransmitidos. Os resultados mostram que o esquema incrementa o desempenho do protocolo TCPem redes sem fio e se apresenta como uma possível substituição do protocolo ARQ.

4.2.7 ResumoA utilização de protocolos da camada de enlace para a retransmissão dos segmentos perdidos

no enlace sem fio possui algumas vantagens:

• A principal é que os esquemas utilizados encaixam perfeitamente na estrutura de camadasdos modelos de rede.

• A camada de enlace opera independentemente dos protocolos das camadas superiores.

• As propostas conservam a semântica TCP de ponto-a-ponto.

Algumas desvantagens:

• Os segmentos transmitidos devem passar pela mesma Estação Rádio Base.

• São necessários mais recursos de processamento e memória nos dispositivos.

• São necessários agentes ou proxys na estação rádio base para controlar o fluxo de dados.

• Interação com outros mecanismos de controle, como retransmissão rápida e variações nostempos de ida e volta, podem gerar um desempenho menor que o esperado.


4.3 Notificação ExplícitaA ideia básica de um esquema de notificação explícita consiste em notificar a presença de

segmentos perdidos por erro para que o protocolo TCP possa realizar ajustes apropriados najanela de transmissão. Vários esquemas de notificação explícita existem. A seguir são apresentadosalguns.

4.3.1 Notificação Explícita de CongestionamentoO método consiste em informar de forma explícita ao transmissor TCP a existência de con-

gestionamento na rede através das bandeiras (flags) do cabeçalho TCP denominado notificaçãoexplícita de congestionamento (ECN). Isto ocorre toda vez que é recebido um segmento com o bitCE ativo no cabeçalho IP. Esta estratégia propõe o monitoramento do tamanho médio da fila nosbuffers de transmissão e os etiqueta baseado nas probabilidades estatísticas em lugar de descartá-los. ECN etiqueta os pacotes antes de ocorrer congestionamento, sendo de muita utilidade para osprotocolos como TCP que são sensíveis às perdas de segmentos.

ECN requer que todos os dispositivos de rede intermediários e estações rádio bases, assimcomo os usuários finais suportem o protocolo implementado. Isto é necessário já que os roteadoressó marcam com o bit ECN aqueles pacotes enviados por usuários ECN. Dois bits do cabeçalhoTCP são utilizados para marcar os segmentos. O bit ECT é ativado pelo transmissor durante oestabelecimento da conexão, se os sistemas suportam ECN. O bit CE dos pacotes que encontramcongestionamento será marcado pelo roteador com uma probabilidade proporcional ao valor médiodo tamanho da fila. Esta estratégia também propõe adicionar duas bandeiras, ECE e reduçãoda janela de congestionamento CWR. A Fig. 4.3 mostra a posição destas bandeiras no cabeçalhoTCP.

O bit ECE é ativado pelo receptor TCP e indica congestionamento na rede. Na recepção deum segmento ACK com o bit ECE ativo, o transmissor ativa o bit CWR para informar ao receptorque reagiu a essa notificação de congestionamento.

0 4 8 16 31



Número de Confirmação

Tamanhodo cabe-

çalho

Reser-vados

CWR

ECE

URG

ACK

PSH

RST

SYN

FIN

Janela


Opções (opcional)

Dados (opcional)

Figura 4.3: Bits ECN no Cabeçalho TCP.


4.3.2 Notificação Explícita de PerdaBaseado na melhoria de desempenho do protocolo TCP obtido pelo protocolo scoop e ECN,

um novo protocolo denominado notificação explícita de perda com confirmação (ELN-ACK) foiproposto em [31]. Nesse esquema, um novo segmento de aviso ACK𝐸𝐿𝑁 é utilizado para comunicara causa da perda do segmento ao transmissor TCP sem armazenar informações na estação rádiobase. O agente ELN-ACK na ERB realiza duas funções principais:

• Julgar e guardar a informação dos segmentos perdidos que foram enviados pelo transmissor.Se a ERB recebe segmentos fora de ordem, eles serão armazenados no segmento de informaçãocorrespondente ELN-ACK.

• Ao receber um segmento ACK𝐸𝐿𝑁 , a estação rádio base analisa os segmentos perdidos ba-seado na informação armazenada. Se concluir que o pacote foi perdido antes de chegar naERB, ativará o bit ELN indicando perda por congestionamento. Caso contrário, desativaráo bit ELN indicando que o segmento foi uma perda por erro.

Quando o transmissor recebe um segmento ACK com o bit ELN ativo, retransmite o segmentomas ignora as ações de controle de congestionamento. Além disso, o transmissor se assegura quecada segmento perdido seja retransmitido uma vez durante o período de um RTT.

4.3.3 Mensagens ICMPO esquema proposto por [32] define um protocolo baseado em Mensagens de Controle do Proto-

colo de Internet (ICMP) para informar ao transmissor TCP da ocorrência de erros no canal sem fio.Duas mensagens são geradas: ICMP-DEFFER e ICMP-RETRANSMISSION. ICMP-DEFFER étransmitida quando a primeira tentativa de transmitir um segmento no enlace sem fio falha. Issogarante que o transmissor TCP recebe um ACK ou uma mensagem ICMP no intervalo de tempode ida e volta. A falta das duas mensagens indicaria perdas por congestionamento. A falta de umadas mensagens indicaria perdas por erros no canal. ICMP-RETRANSMISSION é gerada quandoo segmento foi descartado depois de esgotar todas a retransmissões possíveis.

Na recepção de uma mensagem ICMP-DEFFER, o protocolo TCP adia o temporizador deretransmissão do segmento perdido. Quando recebe uma mensagem ICMP-RETRANSMIT, indicaque um segmento foi perdido no enlace sem fio, retransmite o segmento indicado e força a entradado protocolo TCP na fase de recuperação. Ao receber um segmento ACK confirmando a chegadado segmento retransmitido, o protocolo TCP sai da fase de recuperação e armazena CWND ovalor que tinha antes de ingressar na fase de recuperação. Se não foi recebida uma mensagemICMP-RETRANSMISSION, 3 segmentos ACK duplicados ou ainda se venceu um temporizador,são seguidos os procedimentos do protocolo TCP regular.


4.3.4 SíndromeEm [33] foi proposta uma abordagem mais leve, denominada síndrome para melhorar o desem-

penho do protocolo TCP. Neste esquema, a estação rádio base conta o número de pacotes enviadosem cada conexão TCP para os usuários destino e os inclui como uma parte do cabeçalho TCP nocampo opções. No destino, o contador da síndrome, assim como o número de sequência são utili-zados para determinar se o segmento foi perdido por congestionamento, ou por erros próprios docanal. Espaços vazios na síndrome refletem a perda de segmentos no enlace sem fio, enquanto que,espaços vazios entre os números de sequência, mas não na síndrome, indicam que os segmentos seperderam por congestionamento na parte com fio da rede. Uma vez determinada a causa da perdado segmento, o receptor TCP notifica o transmissor da ação que deve tomar mediante notificaçãode congestionamento explícita. Caso a perda seja ocasionada no enlace sem fio, o transmissor TCPnão reduz a janela de congestionamento.

4.3.5 Confirmações MúltiplasEsta proposta usa dois tipos diferentes de avisos de confirmação para distinguir os diferentes

tipos de perdas. A confirmação adicional, denominada confirmação parcial ACK𝑝 é transmitidapela estação rádio base em resposta aos dados do transmissor TCP. No caso de não existir perdas, otransmissor recebe dois segmentos de confirmação para cada segmento que chegou com sucesso. Oprimeiro é o ACK𝑝 da ERB e o segundo é do usuário móvel. Se somente for recebida a confirmaçãoACK𝑝, implica que o segmento foi descartado no enlace sem fio e não é requerido executar oalgoritmo de controle de congestionamento. Se nenhuma das confirmações chegar, deduz que asperdas foram produzidas pelo tráfego da rede.

4.3.6 ResumoAs propostas baseadas na notificação explícita possuem uma quantidade consideravelmente

menor de cabeçalhos e menor quantidade de recursos são utilizados pela estação rádio base com-parados com os esquemas de conexão-dividida, além de permitir ao protocolo TCP distinguircongestionamento das perdas por erro no canal. As notificações não resolvem na sua totalidade oproblema do protocolo TCP em meios sem fio, mas ao permitir informar ao transmissor que estána presença de um ambiente com alto BER é possível tomar uma decisão bem assessorada.

4.4 Protocolos de Ponto-a-PontoAs implementações do protocolo TCP padrão interpretam a perda de um segmento como um

indicador de congestionamento na rede e carecem de um mecanismo que permita distinguir perdaspor congestionamento daquelas geradas por um canal ruidoso. Em ambientes sem fio a sobreposiçãodos canais de rádio, a atenuação do sinal, ruído e desvanecimento produzem muito impacto na


geração dessas perdas. Como consequência, o protocolo TCP experimenta graves reduções najanela de congestionamento e na vazão de dados. As abordagens por protocolos de ponto-a-pontopermitem ao transmissor TCP resolver as perdas de segmentos ocasionadas por erros, assim comopor congestionamento com um requisito mínimo ou nulo na estação rádio base, como pode-seobservar na Fig. 4.4. Como são esquemas na camada de transporte, a semântica do protocoloTCP é mantida. Algumas propostas são apresentadas a seguir.

Rede sem fio


Ponto-a-Ponto

Figura 4.4: Protocolos de Ponto-a-Ponto.

4.4.1 SMART Ponto-a-PontoA ideia do protocolo SMART é similar às retransmissões seletivas. Consiste em construir

uma máscara seletiva de bits dos segmentos corretamente recebidos no transmissor em lugar detransportá-los nos ACKs do cabeçalho. Cada segmento ACK carrega a informação do ACK acumu-lativo e o número de sequência do segmento que ocasionou o envio da confirmação. A informaçãoadicional que o segmento ACK carrega permite identificar os segmentos que foram recebidos edescobrir os segmentos que foram perdidos permitindo a retransmissão de forma seletiva. Istoocorre no momento em que o receptor detecta espaçamentos na máscara de bits, imediatamenteassume a existência de uma perda e não há possibilidade de ter um segmento fora de ordem. Oesquema troca o ordenamento dos segmentos às custas de uma redução da sobrecarga para gerare transmitir ACKs [22]. O protocolo SMART permite ao transmissor resolver múltiplas perdas deforma eficiente.

4.4.2 TCP WestwoodO protocolo TCP Westwood é uma modificação do protocolo TCP New-Reno no lado do

transmissor, que permite controlar o tamanho da janela de congestionamento usando estimativas davazão de dados de ponto-a-ponto. Esta modificação afeta somente o controle de congestionamento,mantendo as fases de partida lenta e prevenção de congestionamento. O transmissor TCP faz um


monitoramento da taxa de recepção de segmentos com ACKs e realiza estimativas da velocidade daconexão para determinar a largura de banda disponível. No momento que o transmissor percebea presença de congestionamento, recalcula o tamanho da janela de congestionamento e o valor dolimiar baseado nos cálculos realizados. A janela de congestionamento não é reduzida pela metadee se adapta segundo a taxa estimada do enlace. Esta abordagem faz do protocolo TCP Westwoodum protocolo mais robusto às perdas ocasionadas pelos ambientes sem fio.

4.4.3 TCP-CongeladoO protocolo TCP-Congelado é um mecanismo proposto em [34] que coloca o transmissor TCP

em modo de espera prévio à desconexão ao realizar medidas da intensidade do sinal. Neste método,o usuário móvel realiza um monitoramento da intensidade do seu sinal e envia segmentos TCP comvalor de janela anunciada zero ao detectar uma possível desconexão. Como um transmissor TCPque recebe uma janela anunciada com o valor zero não pode transmitir dados, o transmissor TCPfica num estado de espera até a recepção de um segmento com valor de janela diferente de zero.Neste caso, o tamanho da janela de congestionamento não é modificado. Este mecanismo prevêa ativação desnecessária dos mecanismos de controle. Após o usuário móvel ter-se reconectado auma estação rádio base são enviados 3 ACKs confirmando os últimos segmentos recebidos antesda desconexão para desbloquear o transmissor TCP e resumir a transmissão com a mesma taxade transferência.

4.4.4 Confirmações Duplicadas com RetardoConfirmações duplicadas com retardo é um esquema híbrido ponto-a-ponto com camada de

enlace, proposto em [35], que simula o comportamento do protocolo snoop. O receptor coloca umretardo no terceiro e nos segmentos ACKs duplicados seguintes para obter uma janela de tempoonde, a estação radio base possa realizar retransmissões na camada de enlace. Neste instante detempo, o receptor recebe os dados faltantes e realiza a transmissão de segmentos ACK acumulados,descartando aqueles que são duplicados. Quando a janela de tempo expira, os segmentos ACKsduplicados são liberados. O mecanismo realiza isto com a finalidade de impedir a execução dosalgoritmos de controle contanto que a ERB realize as retransmissões. Uma desvantagem ocorrequando os segmentos duplicados são produzidos por congestionamento, dado que ao atrasar osACKs duplicados também se atrasa a recuperação dos segmentos com erro.

4.4.5 Protocolo de Controle de Transmissão Sem FioO Protocolo de Controle de Transmissão Sem Fio (WTCP) é uma abordagem baseada no

esquema proposto no protocolo TCP Westwood para o controle da taxa de transmissão. Paradefinir a taxa de transmissão é calculado um parâmetro como a razão de separação entre segmentosno receptor e transmissor. No protocolo WTCP, o receptor realiza os procedimentos para o controlee calcula a taxa de transferência para o transmissor. O transmissor envia seu valor de separação


temporal entre segmentos. O receptor TCP utiliza a informação recebida e o estado atual paraatualizar a taxa de transmissão. O transmissor deve receber segmentos ACKs contendo informaçãoda confiabilidade e o controle de transmissão periodicamente para reagir à nova taxa e realizar ocontrole de fluxo apropriado. O protocolo WTCP utiliza confirmações seletivas e não são usadostemporizadores de retransmissão para a recuperação de perdas. Tenta manter o protocolo TCPna fase de prevenção de congestionamento ao detectar e reagir ao congestionamento.

4.4.6 TCP EiffelO algoritmo TCP Eiffel descrito em [36] elimina a ambiguidade na retransmissão entre falsos

vencimentos de temporizador e falsas retransmissões rápidas. Permite ao transmissor detectarse o mecanismo de recuperação de erros já foi inicializado, e se precisa continuar monitorando oACK que confirma dados ainda não confirmados. O transmissor utiliza uma opção de carimbo detempo que permite identificar o segmento como uma confirmação original ou como confirmação desegmento retransmitido. Caso o segmento ACK seja do segmento original, o transmissor consideraa retransmissão desnecessária e não reduz a taxa de transmissão.

4.4.7 TCP RealO algoritmo TCP Real [37] é um esquema baseado na taxa de transferência estendida do

protocolo TCP Reno. Nesta abordagem, o receptor controla a taxa do transmissor utilizandomudanças na taxa de chegada dos segmentos para calcular a janela de congestionamento e incluí-la em um segmento de confirmação de volta ao transmissor. A taxa de recepção de segmentos éuma métrica do TCP Real para prever as condições da rede. A diminuição da taxa de chegadados segmentos indica tráfego na rede, e a janela deve ser reduzida. Na ocorrência de uma perda,a CWND é ajustada segundo as condições da rede com maior velocidade que o protocolo TCPReno, dado que a estimativa da janela é enviada junto com o segmento ACK. O algoritmo TCPReal permite um melhor desempenho que o protocolo TCP já que as perdas aleatórias não serãoconfundidas com congestionamento evitando a execução dos algoritmos de controle que reduzema CWND.

4.4.8 ResumoAs propostas Ponto-a-Ponto descritas anteriormente utilizam diferentes ideias ou mecanismos

de controle, assim como diferentes protocolos. SMART controla as múltiplas perdas em uma janelade dados transmitida, que é desejável em ambientes sem fio, mas invoca o algoritmo de controlede congestionamento assumindo que as perdas são todas por congestionamento. As propostasbaseadas na taxa de transmissão tentam prevenir o congestionamento e os segmentos perdidos quesurgirem são ocasionados pelo canal sem fio. Esquemas como TCP Congelado, deixam o transmis-sor TCP em modo de espera para evitar a transmissão de dados durante desconexões e mudanças


da estação rádio base. A principal vantagem dos protocolos Ponto-a-Ponto é a preservação da se-mântica TCP e não requerem o suporte dos equipamentos intermediários, evitando processamentoadicional dos segmentos.

Capítulo 5

Algoritmo TCP-NACK

Como apresentado no final do Capítulo 3, o protocolo TCP não foi projetado para trabalharsobre enlaces sem fio, onde altas taxas de erro diminuem a taxa de transmissão e produzem umavazão menor que a esperada. A redução da velocidade em ambientes sem fio só piora as coisas. Porexemplo, vamos supor que em uma rede sem fio 20% dos segmentos são perdidos. Se o transmissorenvia informação a uma taxa de 100 segmentos por segundo, a velocidade real será de 80 segmentospor segundo. Se a velocidade é reduzida para 50 segmentos por segundo, a velocidade real diminuipara 40 segmentos por segundo. Como mostrado em [22] e [31], o protocolo TCP deveria reconhecera existência de segmentos com erro para evitar a diminuição no fluxo de dados.

Um enfoque adequado para o tratamento dos segmentos em transmissões sem fio consiste noreenvio dos segmentos perdidos, assim que seja possível sem a redução da janela de congestiona-mento [2]. Uma modificação do protocolo TCP que satisfaz essas condições foi proposto em [1],onde a vazão é aumentada mediante o envio de notificações de erro pelo receptor para o transmissornão reduzir a janela de congestionamento.

5.1 Confirmação Negativa (NACK)O conceito de confirmações negativas é similar ao conceito de confirmações positivas (ACKs),

com a diferença que no lugar de informar a chegada dos segmentos TCP, o transmissor é informadoque um segmento com erro foi recebido e é necessária a retransmissão desse segmento.

Para enviar uma confirmação negativa foi considerada a criação de uma nova bandeira TCP-NACK tomando-se um dos bits do campo reservado do cabeçalho TCP. Na Fig. 5.1 é definidoo novo cabeçalho TCP. Toda vez que um segmento corrompido for recebido, o protocolo TCP-NACK enviará uma confirmação negativa com a bandeira NACK ativa e o número de sequência dosegmento que precisa ser retransmitido será colocado no campo Número de Confirmação. Quandoum segmento NACK é recebido, o transmissor TCP sabe que um segmento foi descartado devidoa erros e não por congestionamento. A janela de congestionamento, CWND, permanece com omesmo valor, pois não há necessidade de executar o algoritmo de congestionamento. Na Fig. 5.2é apresentado o esquema do algoritmo de controle do protocolo TCP-NACK no transmissor e noreceptor.

45

46 Capítulo 5. Algoritmo TCP-NACK

0 4 7 16 31



Número de Confirmação/Número de Confirmação Negativa

Tamanhodo cabe-

çalho

Reser-vados

NACK

CWR

ECE

URG

ACK

PSH

RST

SYN

FIN

Janela


Opções (opcional)

Dados (opcional)

Figura 5.1: Formato do Cabeçalho TCP-NACK.

5.2 Janela de Congestionamento TCP com NACKsAo receber uma notificação de confirmação negativa, o transmissor TCP deve retransmitir os

segmentos com erro sem reduzir a janela de congestionamento, mantendo a taxa de transmissãodesse momento. A Fig. 5.3 mostra um exemplo do comportamento da CWND no transmissor com aimplementação do protocolo TCP-NACK e do protocolo TCP Reno. Os segmentos com erro estãoressaltados em negrito e as retransmissões destes segmentos aparecem no próximo intervalo detempo RTT. A linha pontilhada mostra o comportamento esperado da janela de congestionamentoem uma rede com fio. Neste caso, a janela diminui unicamente quando existe congestionamento.Pode-se observar que o protocolo TCP-NACK apresenta janelas maiores, similar ao comportamentoda CWND em ambientes com BER nulo, ou desprezível, embora o protocolo TCP Reno apresenteum desempenho inferior.

Para o novo algoritmo, a presença de bandeiras ACK ou NACK indicarão confirmações desucesso ou de fracasso na recepção dos segmentos. A proposta utiliza o protocolo TCP Renocomo a base para a criação do protocolo TCP-NACK e a compatibilidade com outras versões deTCP existentes. Se os nós TCP receptor e transmissor possuem implementações TCP-NACK, apresença de erros produzirá um envio de segmentos NACK e retransmissões sem reduzir a taxa detransmissão. Caso algum dos nós não tenha a implementação de NACKs, a comunicação poderáser realizada da forma tradicional utilizando a implementação do protocolo TCP Reno, dado queum receptor TCP tradicional não poderia enviar NACKs, e um transmissor TCP convencionalnão poderia interpretar a nova bandeira NACK. A Fig. 5.4 mostra como respondem os diferentesalgoritmos quando existe a perda de um segmento, neste caso o segmento número 5. O fluxo dedados diminui notavelmente para o protocolo TCP Reno, embora só tenha ocorrido a perda de umsegmento.

Capítulo 5. Algoritmo TCP-NACK 47

Transmissor TCPReceptor TCPSegmentoRecebido

ChecksumIncorreto?

Enviar NACK

SegmentoNACK?

Processamento normaldo protocolo TCP

Retransmitir osegmento indicado

Segmento com erro

1

NãoSim SimNão

1

Segmento com dados

2

Enviar ACK

SegmentoRecebido

2

Figura 5.2: Envio e Recepção de Segmentos com TCP-NACK.


11 16 22

3 6

7 10

9 14

15 21

20

2

1 4

5 8

5 12

13 19

18

24

2317

3 6

7

2

1 4

5

5

8

11

10

9

33 37 42

24 27

28 32

31 35

36 41

40

22

19 25

26 30

29 29

34 39

36

44

4338

14

15

12

13

20

19

18

17

16

21

19

24

23

22 22

26

25

11 16 22

3 6

7 10

9 14

15 21

20

2

1 4

5 8

5 12

13 19

18

24

2317

3 6

7

2

1 4

5

5

8

11

10

9

33 37 42

24 27

28 32

31 35

36 41

40

22

19 25

26 30

29 29

34 39

36

44

4338

14

15

12

13

20

19

18

17

16

21

19

24

23

22 22

26

25

4 5 7 8 9 106321c = 4 5 7 8 9 106321c =

4 5 7 8 9 106321c = 4 5 7 8 9 106321c =

W W

W W

(a) TCP-NACK

11 16 22

3 6

7 10

9 14

15 21

20

2

1 4

5 8

5 12

13 19

18

24

2317

3 6

7

2

1 4

5

5

8

11

10

9

33 37 42

24 27

28 32

31 35

36 41

40

22

19 25

26 30

29 29

34 39

36

44

4338

14

15

12

13

20

19

18

17

16

21

19

24

23

22 22

26

25

11 16 22

3 6

7 10

9 14

15 21

20

2

1 4

5 8

5 12

13 19

18

24

2317

3 6

7

2

1 4

5

5

8

11

10

9

33 37 42

24 27

28 32

31 35

36 41

40

22

19 25

26 30

29 29

34 39

36

44

4338

14

15

12

13

20

19

18

17

16

21

19

24

23

22 22

26

25

4 5 7 8 9 106321c = 4 5 7 8 9 106321c =

4 5 7 8 9 106321c = 4 5 7 8 9 106321c =

W W

W W

(b) TCP Reno

Figura 5.3: Comportamento da Janela de Congestionamento na Presença de Erros.


123

4

65

7

8

95

1011

12

1413

151617

123

4

65

7

85

9

1110

1218

ACK1ACK2ACK3

ACK4NACK5

ACK6ACK7

ACK8ACK5ACK9

ACK10ACK11

ACK1ACK2ACK3

ACK4

ACK6ACK7

ACK8ACK5

ACK9ACK10ACK11

ACK12ACK13ACK14

(a) TCP Reno

123

4

65

7

8

95

1011

12

1413

151617

123

4

65

7

85

9

1110

1218

ACK1ACK2ACK3

ACK4NACK5

ACK6ACK7

ACK8ACK5ACK9

ACK10ACK11

ACK1ACK2ACK3

ACK4

ACK6ACK7

ACK8ACK5

ACK9ACK10ACK11

ACK12ACK13ACK14

(b) TCP-NACK

Figura 5.4: Janela de Congestionamento no Tempo.


5.3 Modelamento do Protocolo TCP-NACKO desempenho do protocolo TCP Reno e do protocolo TCP-NACK foram obtidos simulando

uma transferência de dados entre duas entidades TCP, cliente e servidor, apresentado na Fig. 5.5.Foram utilizados dois cenários sem fio. Foi utilizado o método de Monte Carlo, variando-se osvalores da SNR. No primeiro caso, o sinal transmitido é afetado apenas por ruído gaussiano brancocom densidade espectral de potência, 𝑁𝑜. No segundo cenário foi simulado um enlace sem linha devisada (LOS) entre o receptor e o transmissor, onde o sinal recebido é afetado por desvanecimentoRayleigh) [38].

O cliente TCP gera 𝑁𝑝𝑎𝑐 segmentos TCP com comprimento de 𝑁𝑏𝑖𝑡𝑠 bits, os quais são trans-mitidos a uma taxa de segmentos 𝑅𝑝 = 𝑅𝑏/𝑁𝑏𝑖𝑡𝑠 segmentos por segundo, onde 𝑅𝑏 é a taxa de bitsdo enlace.

Antes de ingressar no canal, os bits dos segmentos TCP são preparados para a transmissãoutilizando modulações BPSK, QPSK e 16-QAM. O canal possui um atraso de propagação de 𝜏𝑝

segundos e permite um número máximo de 𝑊 segmentos transmitidos sem ACK. O intervalo detempo de ida e volta, 𝑇𝑅𝑇 𝑇 , entre um segmento enviado e sua confirmação é definida por:

𝑇𝑅𝑇 𝑇 = 1𝑅𝑝

+ 𝜏𝑝 (5.1)

W

Rb

Cliente Servidorτp

Figura 5.5: Modelo da Vazão de Dados entre Cliente e Servidor TCP.

O sistema opera na fase de partida lenta (slow start) até alcançar a máxima taxa de bits docanal, quando muda para a fase de prevenção de congestionamento (congestion avoidance) comoespecificado na Seção 3.5. Durante a simulação foi considerado que os segmentos de confirmação,ACKs e de não confirmação, NACKs, estão livres de erro e apresentam comprimento desprezível.

A taxa de transmissão efetiva 𝑅𝑏,𝑒𝑓 é calculada da seguinte forma:

𝑅𝑏,𝑒𝑓 = 𝑁𝑝𝑎𝑐𝑁𝑏𝑖𝑡𝑠 log2 𝑀

𝑁𝑝𝑎𝑐,𝑡𝑥𝑇𝑝 + 2𝑊𝑐𝜏𝑝

(5.2)


onde 𝑁𝑝𝑎𝑐,𝑡𝑥 é o número total de segmentos transmitidos e 𝑊𝑐 é o número de ciclos da janelade congestionamento requeridos para completar com sucesso o envio de 𝑁𝑝𝑎𝑐 segmentos e 𝑀 é onúmero de formas de onda da modulação.

A vazão de dados normalizada é dada por:

𝜗 = 𝑅𝑏,𝑒𝑓

𝑅𝑏

(5.3)

5.4 Resultados

5.4.1 Desempenho do Protocolo TCP NACK em Canal AWGN

A seguir é apresentado o desempenho das modulações utilizadas na avaliação do protocolo TCPNACK e do protocolo TCP Reno em um canal AWGN. A Fig. 5.6 mostra as probabilidades deerro de bit teóricas e as obtidas por simulação. As expressões teóricas da probabilidade de erro debit média para BPSK e QPSK são dadas por:

𝑃𝑏 = 𝑄

(√2 𝐸𝑏

𝑁𝑜

)(5.4)

Para M-QAM a probabilidade de erro é definida por [7]:

𝑃𝑏 = 4log2 𝑀

√𝑀 − 1√

𝑀𝑄

⎛⎝√3 log2 𝑀

𝑀 − 1𝐸𝑏

𝑁𝑜

⎞⎠ (5.5)

Na Fig. 5.6 é apresentado o desempenho teórico e simulado em termos da probabilidade de errode bit das modulações BPSK, QPSK e 16-QAM.

Nesta seção são apresentados e discutidos os resultados obtidos mediante simulação de um pro-grama de transmissão do protocolo TCP sem fio escrito em Matlab. As curvas foram representadasem termos da vazão de dados normalizada em função da relação sinal-ruído. O desempenho doprotocolo TCP-NACK foi testado sobre canais com ruído AWGN. Diferentes parâmetros foramavaliados, como o tamanho do segmento, 𝑁𝑏𝑖𝑡𝑠, o tamanho máximo da janela, 𝑊 , e o atraso depropagação, 𝜏𝑝.

O desempenho do protocolo TCP-NACK também foi analisado utilizando diferentes esquemasde modulação BPSK, QPSK e M-QAM. Os resultados mostram que modulações de ordem superiorrequerem maior relação sinal-ruído, mas trazem como beneficio uma maior vazão de dados.


7 8 9 10 11 12 13 14 15 1610−9

10−8

10−7

10−6

10−5

10−4

10−3

Eb/No (dB)

Pb

BPSK teor.BPSK sim.QPSK teor.QPSK sim.16QAM teor.16QAM sim.

Figura 5.6: Probabilidade de Erro de Bit para as Modulações BPSK, QPSK e 16-QAM sobre umCanal AWGN.


Modulação BPSK

É possível observar que nas Fig. 5.7–5.9 o protocolo TCP-NACK apresenta maior vazão dedados que o protocolo TCP-Reno. Reduzindo-se o tamanho do segmento aumentam as possibili-dades de que este chegue ao receptor sem danos já que ao ter menor quantidade de bits, menor éa probabilidade de se corromper todo o segmento. A Fig. 5.7 mostra que para valores de 𝐸𝑏/𝑁𝑜

baixos, os segmentos com comprimentos menores podem obter melhorias de 5% a 20%. Ao usaressa técnica junto com o protocolo TCP-NACK foram obtidas melhorias mínimas de 5% e máximasde 45% na vazão de dados.

7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 120

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

Eb/No (dB)

ϑ

TCP-Reno Nbits = 1200TCP-Reno Nbits = 2200TCP-Reno Nbits = 3200TCP-NACK Nbits = 1200TCP-NACK Nbits = 2200TCP-NACK Nbits = 3200

Figura 5.7: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tamanhosde Segmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN. Modulação BPSK.

O parâmetro 𝑊 determina o número máximo de segmentos que a janela de congestionamentopode alcançar antes de ocorrer perdas por congestionamento do canal. Valores baixos de 𝑊 limitamo desempenho do protocolo TCP, pois o congestionamento acontece com maior frequência, comoapresentado na Fig. 5.8. Nesse gráfico também é possível observar a existência de um valor mínimoda relação 𝐸𝑏/𝑁𝑜 para o qual o aumento do valor de 𝑊 não melhora a vazão de dados do protocoloTCP Reno (9,5 dB). Porém, ao utilizar o protocolo TCP-NACK esses valores são menores que osdo protocolo TCP Reno. O ganho observado entre o protocolo TCP-NACK e o protocolo TCPReno é de 10%.

O desempenho do protocolo TCP-NACK e o protocolo TCP Reno em função do atraso depropagação é mostrado na Fig. 5.9. Para o valor de 𝐸𝑏/𝑁𝑜 = 8, 5 dB, a melhoria na vazão


7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 120

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Eb/No (dB)

ϑ

TCP-Reno W = 10TCP-Reno W = 20TCP-Reno W = 50TCP-NACK W = 10TCP-NACK W = 20TCP-NACK W = 50

Figura 5.8: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tamanhosda Janela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN. Modulação BPSK.


de dados entre o TCP-NACK e o TCP Reno é 2,5 vezes maior para 𝜏𝑝 = 10/𝑅𝑝, 2 vezes para𝜏𝑝 = 2/𝑅𝑝, 1,75 vezes maior para 𝜏𝑝 = 1/𝑅𝑝 e 1,1 vezes para 𝜏𝑝 = 0. Isto indica que a razão davazão de dados do protocolo TCP-NACK, comparado com o protocolo TCP Reno, é maior paraenlaces com grandes atrasos de propagação.

7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 120

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

Eb/No (dB)

ϑ

TCP-Reno τp = 0

TCP-Reno τp = 1/Rp

TCP-Reno τp = 2/Rp

TCP-Reno τp = 10/Rp

TCP-NACK τp = 0

TCP-NACK τp = 1/Rp

TCP-NACK τp = 2/Rp

TCP-NACK τp = 10/Rp

Figura 5.9: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Atrasosde Propagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal AWGN. Modulação BPSK.


Modulação QPSK

Das simulações é possível observar que nas Fig. 5.10–5.12 o protocolo TCP-NACK apresentamaior vazão de dados que o protocolo TCP-Reno. A Fig. 5.10 mostra que para valores de 𝐸𝑏/𝑁𝑜

baixos, os segmentos com comprimentos menores podem obter melhorias de 0,2 dB a 0,8 dB. Aomodificar o comprimento do segmento e o protocolo TCP-NACK, foram obtidas melhorias mínimasde 0,3 dB e máximas de 1,1 dB.

7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 120

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

Eb/No (dB)

ϑ


Figura 5.10: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tamanhosde Segmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN. Modulação QPSK.

Valores baixos de 𝑊 limitam o desempenho do protocolo TCP, pois o congestionamento acon-tece com maior frequência, como apresentado na Fig. 5.11. Nesse gráfico também é possívelobservar a existência de um valor mínimo da relação 𝐸𝑏/𝑁𝑜 para o qual o aumento do valor de 𝑊não melhora a vazão de dados do protocolo TCP Reno (9,5 dB). Porém, ao utilizar o protocoloTCP-NACK esse valor é deslocado para a esquerda de 2 a 3 dB em relação ao protocolo TCPReno.

Na Fig. 5.12 é mostrado o desempenho do protocolo TCP-NACK e o protocolo TCP Reno emfunção do atraso de propagação. Para o valor de 𝐸𝑏/𝑁𝑜 = 8, 5 dB, a melhoria no desempenhoentre o TCP-NACK e o TCP Reno é é 2,5 vezes maior para 𝜏𝑝 = 10/𝑅𝑝, o dobro para 𝜏𝑝 = 2/𝑅𝑝,1,75 vezes maior para 𝜏𝑝 = 1/𝑅𝑝 e 1,1 vezes para 𝜏𝑝 = 0. Isto indica que o ganho da vazão dedados do protocolo TCP-NACK, comparado com o protocolo TCP Reno, é maior quando o enlacetem grandes atrasos de propagação.


7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 120

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

Eb/No (dB)

ϑ


Figura 5.11: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tamanhosda Janela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN. Modulação QPSK.


7 7.5 8 8.5 9 9.5 10 10.5 11 11.5 120

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

Eb/No (dB)

ϑ

TCP-Reno τp = 0

TCP-Reno τp = 1/Rp

TCP-Reno τp = 2/Rp


TCP-NACK τp = 0

TCP-NACK τp = 1/Rp

TCP-NACK τp = 2/Rp


Figura 5.12: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Atrasosde Propagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal AWGN. Modulação QPSK.


Modulação 16-QAM

A Fig. 5.13 mostra que para valores de 𝐸𝑏/𝑁𝑜 menores que 14 dB, segmentos com comprimentosmenores podem obter melhorias de 0,2 dB a 0,8 dB para o TCP Reno. Ao usar o protocolo TCP-NACK esses valores aumentam.

10.5 11 11.5 12 12.5 13 13.5 14 14.5 15 15.50

0.5

1

1.5

2

2.5

3

3.5

Eb/No (dB)

ϑ


Figura 5.13: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tamanhosde Segmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN.

As curvas de vazão de dados para diferentes tamanhos da janela de congestionamento sãoapresentadas na Fig. 5.14. Novamente é possível observar a existência de um valor mínimo paraa relação 𝐸𝑏/𝑁𝑜 (13 dB) para o qual o protocolo TCP mantém a mesma vazão independente dovalor de 𝑊 . Porém, ao utilizar o protocolo TCP-NACK esse valor é deslocado para a esquerda de2 a 3 dB em relação ao protocolo TCP Reno.

O desempenho do protocolo TCP-NACK e do protocolo TCP Reno em função do atraso de pro-pagação é mostrado na Fig. 5.15. A razão da vazão de dados do protocolo TCP-NACK comparadocom o protocolo TCP Reno é maior quando o enlace tem alto atraso de propagação.


10.5 11 11.5 12 12.5 13 13.5 14 14.5 15 15.50

0.5

1

1.5

2

2.5

3

3.5

4

Eb/No (dB)

ϑ


Figura 5.14: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Tamanhosda Janela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal AWGN. Modulação 16-QAM


10.5 11 11.5 12 12.5 13 13.5 14 14.5 15 15.50

0.5

1

1.5

2

2.5

3

3.5

4

Eb/No (dB)

ϑ

TCP-Reno τp = 0

TCP-Reno τp = 1/Rp

TCP-Reno τp = 2/Rp


TCP-NACK τp = 0

TCP-NACK τp = 1/Rp

TCP-NACK τp = 2/Rp


Figura 5.15: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para Diferentes Atrasos dePropagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal AWGN. Modulação 16-QAM


Ao utilizar esquemas de modulação de ordem superior foi possível observar que o protocoloTCP-NACK continua a apresentar um melhor desempenho que o protocolo TCP Reno. A Fig. 5.16mostra a vazão de dados dos protocolos TCP Reno e TCP-NACK em função da relação 𝐸𝑏/𝑁𝑜.

7 8 9 10 11 12 13 14 15 160

0.5

1

1.5

2

2.5

3

3.5

4

Eb/No (dB)

ϑ

TCP RenoTCP-NACKBPSKQPSK16-QAMτp = 0

τp = 1/Rp

Figura 5.16: Vazão de Dados Normalizada em Função da Relação 𝐸𝑏/𝑁𝑜 para as ModulaçõesBPSK, QPSK e 16-QAM, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal AWGN. Modulação16-QAM

5.4.2 Desempenho do Protocolo TCP NACK em Canal com Desvane-cimento

A seguir o protocolo TCP NACK é avaliado em um canal AWGN com desvanecimento. AFig. 5.17 mostra uma comparação entre as probabilidades de erro de bit teóricas e as obtidasatravés de simulação. As expressões teóricas da probabilidade de erro de bit média para BPSK eQPSK são dadas por [7]:

𝑃𝑏 ≈ 14𝛾𝑏

(5.6)

para modulação M-QAM com 𝑀 ≥ 16 é dada por [7]:


𝑃𝑏 ≈ 43

𝑀 − 1(log2 𝑀)2

14𝛾𝑏

(5.7)

onde 𝛾𝑏 é a relação sinal-ruído média, dada por:

𝛾𝑏 = 𝛼2 𝐸𝑏

𝑁𝑜

(5.8)

onde 𝛼2 é o segundo momento de uma variável aleatória Rayleigh.

25 30 35 40 45 50 55 6010−7

10−6

10−5

10−4

10−3

10−2

γb (dB)

Pb

BPSK teor.BPSK sim.QPSK teor.QPSK sim.16QAM teor.16QAM sim.

Figura 5.17: Probabilidade de Erro de Bit para as Modulações BPSK, QPSK e 16-QAM em umCanal com Desvanecimento Rayleigh.

Nesta seção são apresentados e discutidos os resultados obtidos mediante simulação do pro-grama TCP sem fio escrito em Matlab R2012b. Diferentes parâmetros foram avaliados como otamanho do segmento, 𝑁𝑏𝑖𝑡𝑠, o tamanho máximo da janela, 𝑊 , e o atraso de propagação, 𝜏𝑝. Ascurvas foram representadas em termos da vazão de dados normalizada em função da relação desinal-ruído média, 𝛾𝑏.

Modulação BPSK

O desempenho do protocolo TCP-NACK foi obtido por simulação para canais com desvaneci-mento Rayleigh. Os resultados mostram que para canais com desvanecimento Rayleigh é necessária


uma maior relação sinal-ruído para obter grandes vazões. Isto pode ser observado na Fig. 5.7 ena Fig. 5.18 para o valor de 𝜏𝑝 = 1/𝑅𝑝, onde para obter 86% da máxima vazão de dados com oprotocolo TCP-NACK foi necessário uma 𝛾𝑏 = 40 dB na presença de desvanecimento. No entanto,para AWGN 𝐸𝑏/𝑁𝑜 = 9 dB.

25 30 35 40 45 50 55 600

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

γb (dB)

ϑ


Figura 5.18: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhosde Segmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com Desvanecimento Rayleigh.Modulação BPSK.

Das simulações é possível observar que nas Fig. 5.18–5.20 o protocolo TCP-NACK apresentamaior vazão de dados que o protocolo TCP-Reno. Como mencionado em secções anteriores, re-duzindo o tamanho do segmento aumentam as possibilidades de que este chegue ao receptor semdanos. A Fig. 5.18 mostra que para valores de 𝛾𝑏 entre 25 dB e 50 dB, segmentos com compri-mentos menores podem obter melhorias de 5% a 20%. Ao usar essa técnica junto com o protocoloTCP-NACK foram obtidas melhorias mínimas de 5% e máximas de 30% na vazão de dados.

Valores baixos de 𝑊 limitam o desempenho do protocolo TCP, pois o congestionamento acon-tece com maior frequência, como apresentado na Fig. 5.19. Nesse gráfico também é possívelobservar a existência de um valor mínimo da 𝐸𝑏/𝑁𝑜 para o qual o aumento do valor de 𝑊 nãomelhora a vazão de dados do protocolo TCP (9,5 dB para AWGN, 40 dB para um canal comdesvanecimento Rayleigh). Porém, ao utilizar o protocolo TCP-NACK esses valores são meno-res que os do protocolo TCP Reno. No caso de um canal com desvanecimento o desempenho éconsideravelmente superior obtendo um ganho de 5 dB.


25 30 35 40 45 50 55 60 65 700

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

γb (dB)

ϑ


Figura 5.19: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhos daJanela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com Desvanecimento Rayleigh. ModulaçãoBPSK.

O desempenho do protocolo TCP-NACK e o protocolo TCP Reno em função do atraso depropagação é mostrado na Fig. 5.20. Para o caso de desvanecimento Rayleigh e para o valorde 𝛾𝑏 = 40 dB, a melhoria no desempenho entre o TCP-NACK e o TCP Reno é de 135% para𝜏𝑝 = 10/𝑅𝑝, 55% para 𝜏𝑝 = 2/𝑅𝑝, 35% para 𝜏𝑝 = 1/𝑅𝑝 e 9% para 𝜏𝑝 = 0. Isto indica que ganho devazão de dados do protocolo TCP-NACK aumenta em enlaces com altos atraso de propagação.


25 30 35 40 45 50 55 60 65 700

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

γb (dB)

ϑ

TCP-Reno τp = 0

TCP-Reno τp = 1/Rp

TCP-Reno τp = 2/Rp


TCP-NACK τp = 0

TCP-NACK τp = 1/Rp

TCP-NACK τp = 2/Rp


Figura 5.20: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Atrasos dePropagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits,sobre um Canal com Desvanecimento Rayleigh.Modulação BPSK.


Modulação QPSK

A seguir são apresentados os resultados do desempenho do protocolo TCP-NACK obtidospara a modulação QPSK. Das simulações é possível observar que nas Fig. 5.21–5.23 o protocoloTCP-NACK apresenta maior vazão de dados que o protocolo TCP-Reno. A Fig. 5.21 mostra quesegmentos com comprimentos menores podem obter ganhos de 2 dB a 5 dB. Ao usar essa técnicajunto com o protocolo TCP-NACK foram obtidas melhorias de 2 dB a 10 dB.

25 30 35 40 45 50 55 600

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

γb (dB)

ϑ


Figura 5.21: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhosde Segmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com Desvanecimento Rayleigh.Modulação QPSK.

Na Fig. 5.22 é apresentado o desempenho do protocolo TCP-NACK e do protocolo TCP Renopara diferentes valores 𝑊 . É possível observar a existência de um valor mínimo da 𝛾𝑏 para oqual o aumento do valor de 𝑊 não melhora a vazão de dados do protocolo TCP (45 dB). Porém,ao utilizar o protocolo TCP-NACK esse valor é deslocado 20 dB para a esquerda em relação aoprotocolo TCP Reno.

Na Fig. 5.23 é mostrado o desempenho do protocolo TCP-NACK e o protocolo TCP Reno emfunção do atraso de propagação. O ganho de vazão de dados do protocolo TCP-NACK, em relaçãocom o protocolo TCP Reno, é maior quando o enlace tem grande atraso de propagação.


25 30 35 40 45 50 55 60 65 700

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

γb (dB)

ϑ


Figura 5.22: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhos daJanela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com Desvanecimento Rayleigh. ModulaçãoQPSK.


25 30 35 40 45 50 55 60 65 700

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

1.8

2

γb (dB)

ϑ

TCP-Reno τp = 0

TCP-Reno τp = 1/Rp

TCP-Reno τp = 2/Rp


TCP-NACK τp = 0

TCP-NACK τp = 1/Rp

TCP-NACK τp = 2/Rp


Figura 5.23: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Atrasos dePropagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal com Desvanecimento Rayleigh.Modulação QPSK.


Modulação 16-QAM

A seguir são apresentados os resultados de desempenho do protocolo TCP-NACK obtidos paraa modulação 16-QAM. O protocolo TCP-NACK apresenta maior vazão de dados que o protocoloTCP-Reno. A Fig. 5.24 mostra que melhorias de 2 dB a 10 dB podem ser obtidas ao utilizarsegmentos de comprimento menor junto com o protocolo TCP-NACK.

30 35 40 45 50 55 600

0.5

1

1.5

2

2.5

3

3.5

γb (dB)

ϑ


Figura 5.24: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhosde Segmento 𝑁𝑏𝑖𝑡𝑠, 𝑊=20 segmentos, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com Desvanecimento Rayleigh.Modulação 16-QAM.

Na Fig. 5.25 é apresentado o desempenho do protocolo TCP-NACK e do protocolo TCP Renopara diferentes valores 𝑊 . O valor mínimo da 𝛾𝑏 para o qual o aumento do valor de 𝑊 não melhoraa vazão de dados do protocolo TCP é de 48 dB. Ao utilizar o protocolo TCP-NACK esse valor édeslocado 22 dB para a esquerda em relação ao protocolo TCP Reno.

Na Fig. 5.26 é mostrado o desempenho do protocolo TCP-NACK e o protocolo TCP Reno emfunção do atraso de propagação. A razão entre a vazão de dados do protocolo TCP-NACK, emrelação ao protocolo TCP Reno, é maior quando o enlace tem alto atraso de propagação.


30 35 40 45 50 55 60 65 700

0.5

1

1.5

2

2.5

3

3.5

4

γb (dB)

ϑ


Figura 5.25: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Tamanhos daJanela 𝑊 , 𝑁𝑏𝑖𝑡𝑠 = 3200 bits, 𝜏𝑝 = 1/𝑅𝑝 sobre um Canal com Desvanecimento Rayleigh.


30 35 40 45 50 55 60 65 700

0.5

1

1.5

2

2.5

3

3.5

4

γb (dB)

ϑ

TCP-Reno τp = 0

TCP-Reno τp = 1/Rp

TCP-Reno τp = 2/Rp


TCP-NACK τp = 0

TCP-NACK τp = 1/Rp

TCP-NACK τp = 2/Rp


Figura 5.26: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏 para Diferentes Atrasos dePropagação 𝜏𝑝, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, sobre um Canal com Desvanecimento Rayleigh.Modulação 16-QAM.


A Fig. 5.27 mostra a vazão de dados dos protocolos TCP Reno e TCP-NACK para um canalcom desvanecimento. O protocolo TCP-NACK apresenta um melhor desempenho que o protocoloTCP Reno. Para um atraso de propagação de 𝜏𝑝 = 1/𝑅𝑝, é possível obter ganhos de 3 dB paravalores de 𝛾𝑏 na faixa de 25 dB a 30 dB. Aparentemente não ocorre um deslocamento para adireita das curvas ao se aumentar a ordem da modulação, como ocorrido na Fig. 5.16 para umcanal AWGN. Porém, o deslocamento existe, mas não é facilmente percebido devido à necessidadede maior 𝛾𝑏.

25 30 35 40 45 50 55 600

0.5

1

1.5

2

2.5

3

3.5

4

γb (dB)

ϑ

TCP RenoTCP-NACKBPSKQPSK16-QAMτp = 0

τp = 1/Rp

Figura 5.27: Vazão de Dados Normalizada em função da Relação 𝛾𝑏 para as Modulações BPSK,QPSK e 16-QAM, 𝑊=20 segmentos, 𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal com Desvanecimento Rayleigh.Modulação 16-QAM.

5.4.3 Desempenho do Protocolo TCP NACK com DiversidadeUma alternativa para se combater o desvanecimento e seus efeitos consiste em se transmitir a

mesma informação múltiplas vezes. Está técnica é conhecida como diversidade. Ao transmitir umsinal em vários canais independentes, é de esperar que o desvanecimento não afete todos os canaissimultaneamente, fazendo que a probabilidade de degradação do sinal seja menor e a informaçãorecebida não seja tão corrompida pelo desvanecimento.

A seguir é apresentado o desempenho do protocolo TCP NACK e o protocolo TCP Reno emum canal com desvanecimento utilizando técnicas de diversidade.


A Fig. 5.28 mostra as probabilidades de erro de bit teóricas e as obtidas por simulação. Asexpressões teóricas para BPSK e QPSK são dadas por [7]:

𝑃𝑏 ≈(

2𝐿 − 1𝐿

)(𝐿

4𝛾𝑏

)𝐿

(5.9)

enquanto que para a modulação M-QAM com 𝑀 ≥ 16 é dada por [7]:

𝑃𝑏 ≈(

2𝐿 − 1𝐿

)(43

𝑀 − 1(log2 𝑀)2

1𝛾𝑏

)𝐿

(5.10)

onde 𝛾𝑏 é a relação sinal-ruído média, dada por (5.8).

10 15 20 25 30 35 40 45 50 55 60

10−7

10−6

10−5

10−4

10−3

γb (dB)

Pb

TeoricosL = 1L = 2L = 4BPSKQPSK16-QAM

Figura 5.28: Probabilidade de Erro de Bit em Função da Relação 𝛾𝑏 para as Modulações BPSK,QPSK e 16-QAM em um Canal com Desvanecimento Rayleigh utilizando Técnicas de Diversidade.


A Fig. 5.29 apresenta a vazão de dados do protocolo TCP Reno e do protocolo TCP-NACKutilizando as modulações BPSK, 4QAM e 16-QAM em canal com desvanecimento Rayleigh ediversidade de ordem 𝐿. É possível observar que o aumento da ordem de diversidade ajuda adiminuir os efeitos do desvanecimento permitindo alcançar taxas de transmissão maiores commenores valores de 𝛾𝑏.

Ao utilizar técnicas de diversidade é possível comprovar que o desempenho do protocolo TCP-NACK se manteve superior ao desempenho do protocolo TCP Reno. Porém, o ganho obtido éinferior ao obtido nas secções anteriores. Na Fig. 5.30 e Fig. 5.31 é apresentada a vazão de dadoscom maiores detalhes. A diferença em relação aos gráficos de vazão anteriores, é que o desempenhodo protocolo TCP-NACK é similar ao produzido pelo protocolo TCP Reno. As regiões onde setem uma melhoria substancial ocorre quando a probabilidade de erro de bit, 𝑃𝑏, está na faixa de10−6 a 10−5.

10 15 20 25 30 35 40 45 50 55 600

0.5

1

1.5

2

2.5

3

3.5

4

γb (dB)

ϑ

TCP RenoTCP-NACKBPSKQPSK16-QAML = 1L = 2L = 4

Figura 5.29: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏, para 𝑊=20 segmentos,𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal com Desvanecimento Rayleigh utilizando Técnicas de Diversidade.


16 18 20 22 24 26 28 30 32 34 36 38 400

0.5

1

1.5

2

2.5

3

3.5

4

γb (dB)

ϑ

TCP RenoTCP-NACKBPSKQPSK16-QAML = 2

Figura 5.30: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏, para 𝐿=2, 𝑊=20 segmentos,𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal com Desvanecimento Rayleigh utilizando Técnicas de Diversidade.


12 14 16 18 20 22 24 260

0.5

1

1.5

2

2.5

3

3.5

4

γb (dB)

ϑ

TCP RenoTCP-NACKBPSKQPSK16-QAML = 4

Figura 5.31: Vazão de Dados Normalizada em Função da Relação 𝛾𝑏, para 𝐿=4, 𝑊=20 segmentos,𝑁𝑏𝑖𝑡𝑠=3200 bits, em um Canal com Desvanecimento Rayleigh utilizando Técnicas de Diversidade.

Capítulo 6

Conclusões

A principal contribuição desta dissertação é avaliar a proposta de um novo algoritmo de con-trole de congestionamento TCP-NACK como solução aos problemas do protocolo TCP Reno emambientes de rede sem fio, permitindo diferenciar as perdas por erro de símbolo das perdas porcongestionamento e alcançar taxas de transmissão maiores. A avaliação do desempenho foi feitamediante o envio de segmentos TCP usando as modulações BPSK, QPSK e 16-QAM, e transmi-tidos através de um canal AWGN ou com desvanecimento Rayleigh.

No Capítulo 5 foi descrito e analisado o algoritmo de controle de congestionamento TCP-NACK junto com a modelagem matemática que permitiu sua simulação. Os resultados mostraramque diminuir o tamanho do segmento melhora as oportunidades de um segmento chegar íntegroao receptor. Dado que basta ter um bit com erro para que todo o segmento seja consideradoerrôneo, reduzir o comprimento do segmento auxilia na redução da perda de pacote. Diminuir otamanho do segmento TCP implica no aumento de segmentos TCP a serem transmitidos, porém,estes segmentos de comprimento menor tem maior probabilidade de chegar ao destino sem seremafetados pelo ruído ou desvanecimento no canal.

Nas simulações do protocolo TCP Reno e do protocolo TCP-NACK foi variado o tamanho dajanela de congestionamento. Foi observado que ao aumentar o valor da janela de congestionamentoa vazão de dados também aumenta, devido a que podem ser transmitidos mais segmentos em umintervalo de tempo RTT. Foi possível determinar que existe um valor de SNR mínimo a partirdo qual a variação do tamanho da janela de congestionamento produz a mesma vazão de dados,independente do valor de 𝑊 . Isto ocorre para valores baixos da relação sinal-ruído, onde a excessivaquantidade de erros é interpretada pelo protocolo TCP como um canal com congestionamento eassim a CWND apresenta sempre valores baixos (1–2 segmentos por RTT). Foi possivel observarque ao usar o algoritmo TCP-NACK esse valor de relação sinal-ruído foi diminuído. O deslocamentodeste ponto é maior ainda quando se trata de um canal com desvanecimento.

Os resultados obtidos mostram que a vazão de dados do protocolo TCP é sensível as variaçõesdo atraso de propagação. Em um canal com uma boa relação sinal-ruído, o aumento do atraso depropagação pode diminuir a vazão de dados em mais de um 40%. Este valor é maior ainda quandoa relação sinal-ruído é baixa. Nas simulações foi possível observar que o protocolo TCP-NACKapresenta uma vazão de dados maior que a produzida pelo protocolo TCP Reno. Aliás, paravalores de SNR baixos, a vazão do protocolo TCP-NACK é pelo menos o dobro que a produzida

79

80 Capítulo 6. Conclusões

pelo protocolo TCP Reno.Ao utilizar esquemas de modulação de ordem superior foi possível observar que a vazão de

dados aumenta consideravelmente, porém, são necessários maiores valores da relação sinal-ruído.Os resultados mostraram que a modulação QPSK é um esquema que vale a pena ser utilizadoquando a SNR é baixa, dado que duplica a vazão de dados produzida pela modulação BPSK coma mesma relação sinal ruído. O protocolo TCP-NACK continuou a apresentar melhor desempenhoque o protocolo TCP Reno.

Os resultados mostram que para canais com desvanecimento Rayleigh é necessária uma relaçãosinal-ruído bem maior para obter resultados similares ao do canal AWGN. Nestes canais foi possívelcomprovar que o protocolo TCP-NACK sempre apresenta uma vazão de dados maior que aquelaproduzida pelo protocolo TCP Reno.

Ao utilizar técnicas de diversidade foi possível diminuir os efeitos produzidos pelo desvaneci-mento, fazendo com que a vazão de dados aumente consideravelmente. Quanto maior for a ordemda modulação utilizada, maior foi a vazão de dados obtida. Das simulações é possível observar queo desempenho do protocolo TCP-NACK é similar ao desempenho do protocolo TCP Reno.

A janela de congestionamento (CWND) controla a taxa de transmissão de segmentos. Estadeve ser controlada adequadamente durante eventos de congestionamento e perdas de segmentospor erro. Os algoritmos TCP deveriam ser projetados para manter a maior CWND possível e aomesmo tempo manter o congestionamento sob controle. Nas simulações foi possível determinarque o algoritmo TCP-NACK consegue realizar essas tarefas de forma efetiva, melhorando a vazãode dados.

O protocolo TCP-NACK é uma solução ponto-a-ponto na camada de transporte que não requerde equipamentos intermediários ou proxies como os mencionados em [5] [39] [40] e [30], permitindoseu funcionamento com independência da infraestrutura da rede. Aliás, possui compatibilidadecom outras versões do protocolo TCP, o que permite sua implementação com qualquer tecnologiasem fio na camada física.

Finalmente, conclui-se que para canais com ruído AWGN ou com desvanecimento Rayleigh,o algoritmo de controle de congestionamento TCP-NACK permite a recuperação da janela decongestionamento de forma efetiva quando ocorrem perdas aleatórias de segmentos e assim evitaa redução da taxa de transmissão. Para todos os parâmetros avaliados foi possível observar queo algoritmo de controle TCP-NACK supera notavelmente o desempenho do algoritmo TCP Reno.Aliás, os resultados mostram que TCP-NACK é ainda adequado para redes sem fio com maioresatrasos de propagação e relação sinal-ruído menores.

6.1 Contribuições da DissertaçãoAs principais contribuições desta dissertação foram:

• A implementação e análise do algoritmo TCP-NACK para canais com ruído AWGN e des-vanecimento Rayleigh.

Capítulo 6. Conclusões 81

• Foi obtida uma expressão da vazão de dados efetiva em função do número de ciclos da janelade congestionamento requeridos para completar uma transmissão TCP.

• A avaliação do desempenho do protocolo TCP-NACK foi realizada para diferentes parâme-tros, como o tamanho do segmento, o número máximo de segmentos da janela e o atraso docanal.

• Foram analisadas as modulações BPSK, QPSK e 16QAM.

• Foi avaliado o desempenho do protocolo TCP-NACK em canais com desvanecimento utili-zando técnicas de diversidade.

• Os resultados apresentados na presente dissertação permitiram a elaboração de um artigotécnico que foi submetido e aceito no WORKSHOP-IEEE LATINCOM 2013 realizado emSantiago, Chile.

6.2 Propostas para Trabalhos FuturosAlgumas propostas para dar continuidade a este trabalho:

• Avaliação do protocolo TCP-NACK em um canal com múltiplos usuários e transmissões TCPsimultâneas.

• Análise do comportamento do algoritmo proposto em canais com linha de visada (desvane-cimento Rice).

• Implementação do algoritmo TCP-NACK junto com sistemas que façam uso de códigoscorretores de erro.

82 Capítulo 6. Conclusões

Referências

[1] Gonzalo Fernando Olmedo Cifuentes. “Controle de congestionamento do protocolo TCP emsistemas de comunicação sem fio CDMA usando estrategia de detecção multiusuario, arranjode antenas e correção de erro FEC”. Tese de doutorado. Universidade Estadual de Campinas. Faculdade de Engenharia Elétrica e de Computação, 2008.

[2] Andrew S. Tanenbaum e David J. Wetherall. Computer Networks (5th Edition). PrenticeHall, 2010. isbn: 0132126958.

[3] V. Cerf e R.E. Kahn. “A Protocol for Packet Network Intercommunication”. Em: Commu-nications, IEEE Transactions on 22.5 (1974), pp. 637–648. issn: 0090-6778.

[4] International Telecommunication Union. ICT Facts and Figures 2013. 2014. url: http://www.itu.int/en/ITU-D/Statistics/Pages/facts/default.aspx.

[5] G. Xylomenos et al. “TCP performance issues over wireless links”. Em: CommunicationsMagazine, IEEE 39.4 (2001), pp. 52–58. issn: 0163-6804. doi: 10.1109/35.917504.

[6] J.R. Barry, E.A. Lee e D.G. Messerschmitt. Digital Communication. 3ª ed. Springer-VerlagGmbH, 2004. isbn: 9780792375487.

[7] Celso de Almeida. Livro não publicado.[8] H. Zimmermann. “OSI Reference Model–The ISO Model of Architecture for Open Systems

Interconnection”. Em: Communications, IEEE Transactions on 28.4 (1980), pp. 425–432.issn: 0090-6778.

[9] Jon Postel. Transmission Control Protocol. RFC 793. RFC Editor, 1981. url: http://www.rfc-editor.org/rfc/rfc793.txt.

[10] V. Jacobson, R. Braden e D. Borman. TCP Extensions for High Performance. RFC 1323.RFC Editor, 1992. url: http://www.rfc-editor.org/rfc/rfc1323.txt.

[11] M. Mathis et al. TCP Selective Acknowledgment Options. RFC 2018. RFC Editor, 1996.url: http://www.rfc-editor.org/rfc/rfc2018.txt.

[12] M. Allman, V. Paxson e E. Blanton. TCP Congestion Control. RFC 5681. RFC Editor, 2009.url: http://www.rfc-editor.org/rfc/rfc5681.txt.

[13] J. Nagle. Congestion Control in IP/TCP Internetworks. RFC 896. RFC Editor, 1984. url:http://www.rfc-editor.org/rfc/rfc896.txt.

83

http://www.itu.int/en/ITU-D/Statistics/Pages/facts/default.aspx

http://www.itu.int/en/ITU-D/Statistics/Pages/facts/default.aspx

http://dx.doi.org/10.1109/35.917504

http://www.rfc-editor.org/rfc/rfc793.txt






84 Referências

[14] V. Jacobson. “Congestion Avoidance and Control”. Em: SIGCOMM Comput. Commun. Rev.18.4 (ago. de 1988), pp. 314–329. issn: 0146-4833. doi: 10.1145/52325.52356. url: http://doi.acm.org/10.1145/52325.52356.

[15] V. Paxson et al. Known TCP Implementation Problems. RFC 2525. RFC Editor, 1999. url:http://www.rfc-editor.org/rfc/rfc2525.txt.

[16] S. Floyd. Congestion Control Principles. RFC 2914. RFC Editor, 2000. url: http://www.rfc-editor.org/rfc/rfc2914.txt.

[17] Sameer Seth e M. Ajaykumar Venkatesulu. TCP/IP Architecture, Design and Implementa-tion in Linux. Wiley-IEEE Computer Society Pr, 2008. isbn: 0470147733.

[18] Janey C. Hoe. “Improving the Start-up Behavior of a Congestion Control Scheme for TCP”.Em: SIGCOMM Comput. Commun. Rev. 26.4 (ago. de 1996), pp. 270–280. issn: 0146-4833.doi: 10.1145/248157.248180. url: http://doi.acm.org/10.1145/248157.248180.

[19] T. Henderson e S. Floyd. The NewReno Modification to TCP’s Fast Recovery Algorithm.RFC 6582. RFC Editor, 2012. url: http://www.rfc-editor.org/rfc/rfc6582.txt.

[20] Kevin Fall e Sally Floyd. “Simulation-based Comparisons of Tahoe, Reno, and SACK TCP”.Em: Computer Communication Review 26 (1996), pp. 5–21.

[21] A. Bakre e B. R. Badrinath. “I-TCP: Indirect TCP for Mobile Hosts”. Em: Proceedings of the15th International Conference on Distributed Computing Systems. ICDCS ’95. Washington,DC, USA: IEEE Computer Society, 1995, pp. 136–. url: http://dl.acm.org/citation.cfm?id=876885.880054.

[22] H. Balakrishnan et al. “A comparison of mechanisms for improving TCP performance overwireless links”. Em: Networking, IEEE/ACM Transactions on 5.6 (1997), pp. 756–769. issn:1063-6692. doi: 10.1109/90.650137.

[23] R. Yavatkar e N. Bhagawat. “Improving End-to-End Performance of TCP over Mobile Inter-networks”. Em: Proceedings of the 1994 First Workshop on Mobile Computing Systems andApplications. WMCSA ’94. Washington, DC, USA: IEEE Computer Society, 1994, pp. 146–152. isbn: 978-0-7695-3451-0. doi: 10.1109/WMCSA.1994.25. url: http://dx.doi.org/10.1109/WMCSA.1994.25.

[24] Kuang-Yeh Wang e Satish K. Tripathi. “Mobile-End Transport Protocol: An Alternative toTCP/IP Over Wireless Links”. Em: IN IEEE INFOCOM. 1998, pp. 1046–1053.

[25] Z.J. Haas e P. Agrawal. “Mobile-TCP: an asymmetric transport protocol design for mobilesystems”. Em: Communications, 1997. ICC ’97 Montreal, Towards the Knowledge Millen-nium. 1997 IEEE International Conference on. Vol. 2. 1997, 1054–1058 vol.2. doi: 10.1109/ICC.1997.610040.

[26] Feng Xie, Joseph L. Hammond e Daniel L. Noneaker. “Evaluation of a Split-connection Mo-bile Transport Protocol”. Em: Wirel. Netw. 9.6 (nov. de 2003), pp. 593–603. issn: 1022-0038.doi: 10.1023/A:1025904417892. url: http://dx.doi.org/10.1023/A:1025904417892.

http://dx.doi.org/10.1145/52325.52356

http://doi.acm.org/10.1145/52325.52356

http://doi.acm.org/10.1145/52325.52356




http://dx.doi.org/10.1145/248157.248180

http://doi.acm.org/10.1145/248157.248180


http://dl.acm.org/citation.cfm?id=876885.880054

http://dl.acm.org/citation.cfm?id=876885.880054

http://dx.doi.org/10.1109/90.650137

http://dx.doi.org/10.1109/WMCSA.1994.25



http://dx.doi.org/10.1109/ICC.1997.610040

http://dx.doi.org/10.1109/ICC.1997.610040

http://dx.doi.org/10.1023/A:1025904417892

http://dx.doi.org/10.1023/A:1025904417892

Referências 85

[27] C. Ladas et al. “Class based selective-ARQ scheme for high performance TCP and UDP overwireless links”. Em: Mobile and Wireless Communications Network, 2002. 4th InternationalWorkshop on. 2002, pp. 311–315. doi: 10.1109/MWCN.2002.1045743.

[28] Ender Ayanoglu et al. “AIRMAIL: A Link-layer Protocol for Wireless Networks”. Em: Wirel.Netw. 1.1 (fev. de 1995), pp. 47–60. issn: 1022-0038. doi: 10.1007/BF01196258. url: http://dx.doi.org/10.1007/BF01196258.

[29] C. Parsa e J.J. Garcia-Luna-Aceves. “TULIP: A link-level protocol for improving TCP overwireless links”. Em: Wireless Communications and Networking Conference, 1999. WCNC.1999 IEEE. 1999, 1253–1257 vol.3. doi: 10.1109/WCNC.1999.796938.

[30] D. Murray, T. Koziniec e M. Dixon. “D-Proxy: Reliability in wireless networks”. Em: Com-munications (APCC), 2010 16th Asia-Pacific Conference on. 2010, pp. 129–134. doi: 10.1109/APCC.2010.5679750.

[31] Wenqing Ding e A. Jamalipour. “A new explicit loss notification with acknowledgment forwireless TCP”. Em: Personal, Indoor and Mobile Radio Communications, 2001 12th IEEEInternational Symposium on. Vol. 1. 2001, B–65–B–69 vol.1. doi: 10.1109/PIMRC.2001.965432.

[32] Samir Goel e Dheeraj Sanghi. “Improving TCP Performance Over Wireless Links”. Em:1998 IEEE Region 10 International Conference on Global Connectivity in Energy, Computer,Communication and Control, Volume: 2 , 1998 Page(s): 332 -335 vol.2. IEEE, 1998, pp. 332–335.

[33] Wei-Peng Chen et al. “Syndrome: a light-weight approach to improving TCP performance inmobile wireless networks”. Em: Wireless Communications and Mobile Computing 2.1 (2002),pp. 37–57. issn: 1530-8677. doi: 10.1002/wcm.32. url: http://dx.doi.org/10.1002/wcm.32.

[34] Tom Goff, James Moronski e D. S. Phatak. “Freeze-TCP: A true end-to-end TCP enhance-ment mechanism for mobile environments”. Em: In Proceedings of IEEE INFOCOM’2000,Tel Aviv. 2000, pp. 1537–1545.

[35] Nitin Vaidya et al. “Delayed Duplicate Acknowledgements: A TCP-Unaware Approach toImprove Performance of TCP over Wireless”. Em: Wireless Communications and MobileComputing. 2002, pp. 59–70.

[36] V. Jacobson, R. Braden e D. Borman. TCP Extensions for High Performance. RFC 3522.RFC Editor, 2003. url: http://www.rfc-editor.org/rfc/rfc3522.txt.

[37] C. Zhang e V. Tsaoussidis. “TCP-real: Improving Real-time Capabilities of TCP over Hete-rogeneous Networks”. Em: Proceedings of the 11th International Workshop on Network andOperating Systems Support for Digital Audio and Video. NOSSDAV ’01. Port Jefferson, NewYork, USA: ACM, 2001, pp. 189–198. isbn: 1-58113-370-7. doi: 10.1145/378344.378371.url: http://doi.acm.org/10.1145/378344.378371.

[38] Nuzhat Tasneem Awon et al. “Effect of AWGN & Fading (Raleigh & Rician) Channels onBER performance of a WiMAX communication System”. Em: CoRR abs/1211.4294 (2012).

http://dx.doi.org/10.1109/MWCN.2002.1045743

http://dx.doi.org/10.1007/BF01196258

http://dx.doi.org/10.1007/BF01196258

http://dx.doi.org/10.1007/BF01196258

http://dx.doi.org/10.1109/WCNC.1999.796938

http://dx.doi.org/10.1109/APCC.2010.5679750

http://dx.doi.org/10.1109/APCC.2010.5679750

http://dx.doi.org/10.1109/PIMRC.2001.965432

http://dx.doi.org/10.1109/PIMRC.2001.965432

http://dx.doi.org/10.1002/wcm.32




http://dx.doi.org/10.1145/378344.378371

http://doi.acm.org/10.1145/378344.378371

86 Referências

[39] Ye Tian, K. Xu e N. Ansari. “TCP in Wireless environments: problems and solutions”. Em:Communications Magazine, IEEE 43.3 (2005), S27–S32. issn: 0163-6804. doi: 10.1109/MCOM.2005.1404595.

[40] D. Murray, T. Koziniec e M. Dixon. “Solving Ack inefficiencies in 802.11 networks”. Em:Internet Multimedia Services Architecture and Applications (IMSAA), 2009 IEEE Interna-tional Conference on. 2009, pp. 1–6. doi: 10.1109/IMSAA.2009.5439494.

http://dx.doi.org/10.1109/MCOM.2005.1404595

http://dx.doi.org/10.1109/MCOM.2005.1404595

http://dx.doi.org/10.1109/IMSAA.2009.5439494

pablo andres pilo-pais albuja - unicamp€¦ · pilo-pais albuja, pablo andres, 1987- p647a...

Documents