Estudo do impacto de handover vertical sobre TCP New Reno e TCP Vegas

Andriy Mazayev Faculdade de Ciências e Tecnologia, Universidade do Algarve

E-mail:andre_maz90@hotmail.com

Resumo: Neste artigo será feito um estudo da performance do protocolo TCP New Reno e TCP Vegas durante o handover vertical, isto é, durante a transferência de uma conexão entre duas tecnologias de

comunicação diferentes. Serão abordados os mecanismos que compõem o protocolo TCP, as suas

características únicas, as vantagens e desvantagens referentes às variações deste do protocolo da camada de transporte. A análise da performance das diferentes variações do TCP será feita a partir de

um modelo virtual que simula o procedimento de handover à diferentes velocidades.

Palavras chave: Protocolo, TCP, TCP New Reno, TCP Vegas, Nodes, AdHoc, FTP, Atraso, Taxa de

entrega, Taxa de perda de pacotes, Pacotes, Topologia, Simulação, NS2, Fonte, Destino, cwnd, ssthresh,

RTT, handover vertical, nó, célula, rede.

1. Introdução ao Problema

As tecnologias de comunicação sem fios oferecem uma série de vantagens ao utilizador, a

principal é a inexistência de fios que limitam a área de acesso a rede. Desta forma é possível aceder a rede

em qualquer lugar que tenha a cobertura de rede. Outra grande vantagem das redes sem fios é a

possibilidade de mobilidade sem a perda de conexão, ou seja, as redes sem fios permitem que um

utilizador em movimento, mesmo contante, tenha acesso a rede. No entanto a mobilidade tem as suas

limitações, a principal é a transferência da conexão entre duas redes cujas arquiteturas são diferentes. O

processo de transferência entre duas redes diferentes é chamado vertical handover.

O processo de transferência da conexão entre duas arquiteturas diferentes é um processo bastante

delicado, principalmente para os protocolos orientados a conexão como é o caso do protocolo TCP. O

principal obstáculo durante o vertical handover é a deteção e recuperação de pacotes perdidos, entrega

ordenada de pacotes e entrega de dados num espaço de tempo delimitado. Para além disso a mudança de

arquitetura e a consequente mudança do caminho da ligação entre a fonte e o destino pode possuir

diferentes características do caminho original, como por exemplo a largura de banda, a latência, o

tamanho das filas, o tempo de processamento dos dados, entre outros. É necessário ter em conta todos

estes fatores para garantir uma conexão estável aos utilizadores.

A camada de transporte tem um papel vital na transferência eficiente e confiável de dados. TCP é

o protocolo predominante da camada de transporte visto que a maioria das aplicações exigem

transferência segura de dados. No entanto existem várias implementações do protocolo TCP e cada uma

destas implementações tem as suas particularidades e formas de lidar com o congestionamento e a perda

de pacotes.

Neste relatório será avaliado o desempenho de duas variações do protocolo TCP, nomeadamente

TCP New Reno e TCP Vegas, durante a ocorrência do vertical handover.

2. Software Utilizado

2.1 Software de simulação

A realização do estudo das variações do TCP e dos respetivos mecanismos de controlo de

congestionamento foi feita recorrendo ao software NS-2 (Network Simulator 2) com modulo WiMax.

Este simulador suporta os protocolos mais utilizados tanto em redes cabeadas com as redes sem fio, por

essa razão este software é largamente utilizado para fins académicos.

Network Simulator foi desenvolvido usando as linguagens C++ e script TCL. Os scripts são

utilizados para a modelação do problema, nomeadamente o ambiente a ser simulado, a configuração de

nós, a sua posição e etc. O Network Simulator interpreta o script e utiliza as bibliotecas C++ para o

scheduling de eventos e elementos de rede.

A arquitetura de NS-2 permite aos utilizadores desenvolver simulações de forma muito eficiente

e em caso de necessidade de implementação de um novo algoritmo ou elemento de simulação basta

adicionar esse elemento na biblioteca de C++.

O modulo WiMax implementa o padrão 802.16 que contem os protocolos, e as características

únicas desta tecnologia de comunicação. Este módulo pode ser encontrado na página do seu developer,

National Institute of Standards and Technology.

A instalação do Network Simulator 2 em ambiente Linux é bastante fácil, bastando introduzir o

comando apt-get install ns2 no terminal.

2.2 Software de análise

A análise do trace produzido pelas simulações foi feita com recurso à NSWireless. Esta aplicação

reconhece todos os formatos de trace produzidos pelo Network Simulator, tanto em formato antigo como

em formato novo.

Esta ferramenta é capaz de calcular os atrasos na entrega dos pacotes, o número de pacotes

entregues e perdidos, a velocidade de transferência ao longo do tempo, entre outros.

3. Estrutura do Relatório

O relatório está dividido em quatro partes sendo que a primeira irá focar-se nas características

gerais e nos mecanismos do controle de congestionamento do protocolo TCP, será feita também uma

abordagem aprofundada ao funcionamento de TCP New Reno e TCP Vegas. A segunda parte do relatório

ira abordar o procedimento de handover. A terceira parte do relatório terá como o principal foco a

simulação construída para a medição de performance das variações de TCP. Nesta parte serão abordados

os aspetos de programação, as características da simulação e do ficheiro trace que a simulação produz.

Por fim, na quarta parte será feita uma análise dos resultados obtidos da simulação.

4. Camada de Transporte

O protocolo TCP é um protocolo da camada de transporte da arquitetura TCP/IP (Transmission Control

Protocol/Internet Protocol). Este protocolo tem as seguintes características:

Orientado à conexão, ou seja, a aplicação envia um pedido de conexão para o destinto e usa uma

conexão segura para a transferência de dados.

Confiável pois utiliza varias técnicas para proporcionar uma entrega confiável e sequencial de

pacotes de dados

Handshake, mecanismo de estabelecimento e finalização de conexão que permite testar a

conexão entre a fonte e o destino antes do envio de dados. Através do handshake o TCP garante

que no final da transmissão todos os pacotes sejam entregues ao destino.

Entrega ordenada, todos os pacotes TCP têm um número de sequência que em caso de perda de

pacotes permite ao protocolo TCP reenviar aos pacotes necessários para completar a

transferência fiável de dados.

Controle de fluxo – o cabeçalho do TCP possui um campo chamado window para controlar o

fluxo de dados para enviar ao destino. Por cada pacote recebido o destino emite uma mensagem

ACK, confirmando a receção do pacote. Com base nestas mensagens o protocolo TCP pode

calcular o congestionamento e utilizar varias técnicas para evitar congestionamento.

A principal vantagem do TCP em relação aos outros protocolos da camada de transporte é a

utilização de mecanismos avançados de controlo de congestionamento, os mais importantes são Slow

Start, Congestion Avoidance, Fast Retransmit e Fast Recovery. Estes mecanismos de controlo de

congestionamento certificam-se de que a rede é capaz de transportar trafego, lidando com o mesmo

ponto-a-ponto entre a fonte e o destino. O processo de certificação de entrega confiável de dados é

diretamente relacionada com a alocação de recursos existentes na rede.

O controlo de congestionamento pode ser definido como um conjunto de algoritmos que tentam

evitar a sobrecarga de dados na rede baseando-se no envio dos mesmos de acordo com uma janela de

congestionamento mantida pelo transmissor. Esta janela varia de acordo com as informações recebidas a

partir da rede na qual os dados circulam.

Para entender como funciona o mecanismo de congestionamento é necessário analisar a transferência

de dados a partir do início da comunicação.

Uma vez iniciada uma conexão TCP o algoritmo de controlo de congestionamento entra na

primeira fase que utiliza o mecanismo slow start, onde valor unitário é atribuído a janela de

congestionamento (cwmd). À medida que os segmentos são enviados o valor da janela de

congestionamento aumenta exponencialmente até um certo limite (ssthresh). No caso de ocorrência de

perda de dados durante o slow start o processo é reiniciado.

A segunda fase, congestion avoidance, inicia-se no momento em que o valor de cwnd deixa de

aumentar, ou seja, quando o cwnd atinge o limite máximo. Neste caso o valor de cwnd é reduzido de

modo a prevenir a perda de pacotes e evitar o congestionamento e consequente perda de pacotes. Após a

redução o valor de cwnd aumenta de forma linear até ao limite.

Em caso de ocorrência de perda de um pacote durante a fase de congestion avoidance, o

algoritmo TCP reduz o tamanho da janela do valor atual de modo a prevenir perdas de pacotes adicionais.

Nesta fase entra o mecanismo de fast retransmission que retransmite os pacotes perdidos, esta fase

também é acompanhada pelo aumento linear de cwnd.

Por fim, existe ainda um mecanismo chamado fast recovery que evita que o protocolo TCP entre

em modo slow start impedindo assim a redução drástica da janela de congestionamento. Fast recovery entra em ação logo depois da ocorrência de fast retransmission, fast recovery considera que quando o

emissor recebe três ACK duplicados apenas um segmento é perdido, os restantes são considerados como

entregues com sucesso. Deste modo é provável que não haja congestionamento na rede e é desnecessário

recorrer ao mecanismo slow start. Fast recovery reduz o valor de sstresh par metade do valor da janela de

congestionamento e o cwnd recebe o mesmo valor de sstresh.

Todas as variações de TCP utilizam alguns ou mesmo todos mecanismos de congestionamento

acima descritos, no entanto cada um deles tem as suas particularidades e ligeiras alterações de

funcionamento que lhes permite dar mais prioridade a entrega de dados, aumentando assim o atraso entre

o nó fonte e destino ou dar prioridade a velocidade de entrega de dados que por consequência aumenta o

Ilustração 1 - Evolução da Janela de congestionamento TCP

número de pacotes perdidos. As características de TCP New Reno e TCP Vegas serão descritas abaixo

com maior detalhe.

4.1. TCP New Reno

Antes de abordar TCP New Reno é necessário recuar no tempo para entender as versões prévias

de TCP, o seu funcionamento, as suas vantagens e desvantagens. A primeira versão aprimorada do

protocolo TCP chama-se TCP Tahoe. Este algoritmo utiliza apenas o mecanismo slow start e congestion

avoidance descritos anteriormente. A utilização dos mecanismos acima descritos melhorou a performance do protocolo TCP, no

entanto na implementação TCP Tahoe não são considerados os ACKs duplicados, ou seja, sempre que

ocorre uma perda de pacote o algoritmo entra em modo slow start. O facto de entrar sempre em slow start

em caso de ocorrência de pedra de pacotes torna o TCP Tahoe num protocolo limitado sendo assim foi

necessário desenvolver uma nova versão do protocolo TCP que fosse capaz de considerar os ACKs

duplicados, assim surgiu o TCP Reno.

A implementação de TCP Reno é em grande parte baseada em TCP Tahoe visto que esta também

utiliza o mecanismo slow start e congestion avoidance. A novidade foi a implementação dos algoritmos

de fast recovery e fast retransmission. A utilização destes algoritmos permitiu resolver o problema

existente na implementação TCP Tahoe, ou seja, evitar a entrada do protocolo TCP em modo slow start

sempre que ocorre uma perda de dados. Obstantes as melhorias apresentadas pelo TCP Reno, este

algoritmo possui uma limitação pois é incapaz de tratar de forma eficiente de múltiplas perdas de dados.

Para resolver este problema foi desenvolvido o protocolo TCP New Reno.

À semelhança do TCP Reno, New Reno também utiliza o mecanismo de retransmissão rápida

quando recebe pacotes duplicados, no entanto, ao contrário de Reno esta implementação não para de

utilizar o mecanismo de retransmissão rápida até que toda a informação que foi retransmitida seja

entregue ao destino. Desta forma o problema de redução constante de cwnd é evitado.

A desvantagem apresentada por esta implementação é o facto de demorar um RTT para detetar a

perda de pacote, a perda do segmento apenas é detetada no momento em que o ACK do segmento anterior

é recebido.

4.2 TCP Vegas

O TCP Vegas é a versão mais recente do protocolo TCP. Vegas é construído com base num

mecanismo proactivo de encontro de congestionamento que normalmente é muito mais eficiente em

relação aos mecanismos reactivos. Para além do aspecto proactivo Vegas altera também o funcionamento

dos mecanismos de gestão de congestionamento.

Ao contrário do mecanismo slow start nas versões anteriores de TCP em Vegas não existe um

limite superior do tamanho da janela. O aumento do cwnd também é exponencial no entanto ocorre em

certos intervalos de tempo. Entre os aumentos do valor de cwnd o TCP Vegas calcula o limite máximo da

janela, este cálculo é feito com base nas informações recolhidas da rede na qual os pacotes circulam.

O mecanismo congestion avoidance difere completamente das implementações anteriores.

Enquanto nas implementações prévias o mecanismo congestion avoidance entra em ação quando ocorre

uma perda de pacotes originando assim uma redução da janela em TCP Vegas o controlo da janela é feita

com base na diferença entre a taxa de emissão actual e esperada. Esta técnica não só evita

congestionamento e consequente perda de pacotes como também utiliza de forma correcta os recursos

existentes na rede.

Por fim TCP Vegas utiliza um novo mecanismo de retransmissão rápida. Este mecanismo tenta estimar o RTT com base no envio e receção de ACKs. A deteção da perda de pacote é feita da seguinte

forma, quando é recebido um ACK duplicado o algoritmo verifica se o tempo de transmissão do ACL é

superior ao RTT estimado. Caso esta condição se verifique o TCP Vegas irá considerar o pacote como

pedido e irá proceder a sua retransmissão. Esta nova técnica de retransmissão rápida permite detetar

perdas de pacotes quando a janela é demasiado pequena e os ACKs não são recebidos.

A principal vantagem de TCP Vegas em relação ao TCP New Reno é a sua robustez para lidar

com múltiplos pacotes para além disso o seu algoritmo de congestion avoidance utiliza de forma muito

eficiente os recursos da rede.

5. Handover

Handover é um procedimento empregado em redes sem fios para realizar a transição de uma

unidade móvel de uma célula para outra de forma transparente para o utilizador. Este processo de

transferência de ligação de uma célula para outra representa um fator muito importante em QoS. Existem

dois tipos de hanover, horizontal e vertical. Handover horizontal é a transferência de uma célula para uma

outra mas ambas apresentam a mesma arquitetura. No caso de handover vertical a troca é feita entre

células que utilizam arquiteturas diferentes. Este tipo de handover é mais complexo e exige utilização de

algoritmos de transferência de conexão avançados.

5.1 Handover vertical

Handover vertical refere-se a transição de um nó de uma rede para outra com uma arquitetura

diferente. Por exemplo, vamos considerar um computador portátil que tenha capacidade de se ligar às

redes WLAN e as redes de telefones para obter acesso a internet. Normalmente as redes WLAN

apresentam velocidades maiores quando comparadas com as redes de telefones no entanto WLAN

apresentam um alcance bastante menor em relação às redes telefónicas. Nestas condições o portátil

referido anteriormente irá executar constantemente um algoritmo de modo a avaliar qual das redes

apresenta o melhor sinal e consequentemente irá ligar-se a ela.

6. Simulação

A melhor forma para estudar a performance das variações de TCP é através da construção de um

modelo virtual que consiga descrever de forma precisa o funcionamento tanto de TCP New Reno como

de TCP Vegas.

Um modelo permite construir variados casos e situações que podem ocorrer durante uma

comunicação sem fios. Um modelo evita elevados custos de experiencias diretas e é capaz de fornecer

toda a informação necessária para o estudo da performance realizado neste relatório.

6.1 Descrição do modelo

O estudo do desempenho dos protocolos durante o handover será baseado numa rede composta

por 5 nós. O cenário da comunicação será o seguinte.

Área do terreno de testes é de 1000 metros por 1000 metros

O trafego é enviado de um nó estático para um nó móvel

Nó móvel possui duas interfaces, uma WiFi e outra á WiMax

Alcance da base station com interface WiFi é de 20 metros

Alcance da base station com interface WiMax é de 500 metros

O nó móvel percorre 100 metros durante a simulação

Ilustração 2 - Representação gráfica da simulação

Com base nestes dados é possível construir, simular e extrair informações relativas ao protocolo

TCP New Reno e TCP Vegas.

6.2 Construção do modelo

A construção do modelo é feita com recurso ao Network Simulator 2, uma ferramenta bastante

simples de ser utilizada. Abaixo serão descritos alguns passos da construção do modelo.

Antes da definição dos nós é necessário definir o tereno onde os nos serão colocados, esta tarefa é

feita da seguinte forma:

set topo [new Topography] $topo load_flatgrid $val(x) $val(y)

Após a definição do terenro já é possível criar e posicionar os nós do modelo. A criação dos nós

pode ser feita da seguinte forma:

set node_($i) [$ns node]

O posicionamento dos nós é feito com recurso às coordenadas cartesianas:

$node_(0) set X_ 100.0 $node_(0) set Y_ 700.0 $node_(0) set Z_ 0.0

Como se pode ver para declarar um nó é necessário definir as suas coordenadas.

Após a criação dos nós é necessário estabelecer a ligação entre o nó fonte e destino, esta tarefa é

feita da seguinte forma:

Primeiro é necessário definir um nó como o emissor, nó responsável pela emissão dos pacotes

durante a simulação

set tcp [new Agent/TCP] $ns attach-agent $node_(0) $tcp

Depois é necessário definir um nó recetor, nó responsável pela receção dos pacotes enviados pela

fonte.

set sink [new Agent/TCPSink] $ns attach-agent $node_(1) $sink

Por fim é necessário estabelecer entre os nós definidos anteriormente, este processo é feito

através do seguinte comando

$ns connect $tcp $sink Neste momento já a camada de transporte esta definida falta apenas definir a camada de

aplicação, que neste caso será do tipo FTP.

set ftp [new Application/FTP] $ftp attach-agent $tcp

Por fim é necessário definir o comportamento dos nós ao longo da simulação. Neste modelo o

comportamento é bastante simples apenas é necessário definir o intervalo de tempo em que o trafego será

gerado, esta tarefa é feita com recurso aos seguintes comandos:

$ns_ at 3.0 "$ftp start" $ns_ at 120.0 "stop"

Juntando todas as peças do puzzle e executando a simulação obtém-se o seguinte modelo.

Ilustração 3 - Interface gráfica da simulação

Esta interface gráfica permite visualizar todos os eventos que ocorrem durante a simulação para

além de oferecer controlo sobre a mesma.

6.3 Analise do trace produzido

A simulação apresentada acima produz um ficheiro de extensão. tr que contém toda informação

sobre os eventos que ocorreram durante o tempo de execução da simulação. Uma típica linha do ficheiro

é apresentada abaixo.

r 69.498182775 _6_ AGT --- 1208 tcp 1020 [13a 6 4 800] ------- [1:0 6:0 29 6] [564 0] 4 0

• Primeiro campo indica o que se passa com o pacote, este campo pode tomar seguintes valores:

r, s, f e D, para “received”, “sent”, “forward” e “dropped”, respectivamente.

• Segundo campo é o tempo do evento

• Terceiro campo é o número do nó onde ocorreu o evento

• Quarto campo indica a camada em que ocorre o evento. Pode tomar valores MAC se o pacote

está na camada de ligação, AGT se o pacote está na camada de transporte, RTR se o pacote é

direcionado ou IFQ se existem interferências na fila de prioridades.

• Quinto campo indica o número de sequência do pacote

• Sexto campo indica o tipo de pacote (tcp, ack ou udp)

• Sétimo campo indica o tamanho do pacote

• Oitavo campo contém informação sobre a camada de ligação, neste relatório esta informação é

irrelevante

• Nono campo indica o endereço IP de origem e destino e o respectivo time to live.

• Décimo campo indica informações relativas ao TCP, o número de sequência e o número de

ACK.

Com base nos dados que o ficheiro trace fornece é possível fazer o estudo completo de todos os

eventos que ocorreram durante a simulação. Basta apenas organizar os dados de forma que facilite mais a

percepção dos eventos.

7. Análise de Resultados

Um das formas de organizar os dados do ficheiro trace é através de um script que executa

simples operações como a diferença do tempo de chegada e envio do pacote de modo a calcular o atraso

da mensagem. Outra operação essencial para o estudo é o cálculo do número de pacotes perdidos. Com

recurso à esta informação é possível efetuar um estudo da performance das variações de TCP, neste caso

de TCP New Reno e TCP Vegas.

Outra forma, mais simples, de analisar os ficheiros de trace produzidos pelas simulações é

executando o NSWireless. Este programa foi desenvolvido para facilitar o calculo dos dados relativos ao

desempenho de cada simulação. Este programa é capaz de calcular o atraso dos pacotes, o número de

pacotes gerados, a taxa de entrega de pacotes, o troughput e etc.

Uma vez que o objetivo deste relatório é estudar a performance das variações do protocolo TCP

durante o processo de handover à diferentes velocidades, todas as variáveis mantêm-se constantes exceto

a velocidade que varia entre 1 e 20 metros por segundo. Desta forma apenas a velocidade é capaz de

alterar o desempenho dos protocolos. Assim em todos os cenários o trafego começa a ser gerado aos 3

segundos sendo que o nó móvel permanece estático até aos 10 segundos da simulação a 20 metros da

torre WiFi após esse tempo o nó móvel começa a mover-se na horizontal percorrendo 100 metros.

Durante a viagem o nó móvel percorre zonas que são cobertas pelo WiFi e pelo WiMax sendo que

durante a sua deslocação ocorre o handover vertical.

Ao executar as simulações com diferentes velocidades obtém-se a seguinte tabela de dados.

Vegas

Velocidade (m/s) NumGerados NumPerdidos Taxa de Entrega Atraso Médio (s) Troughput (KB/s)

1 21870 107 0,995107453 0,048735585 182

2,5 21079 67 0,996821481 0,049078022 175

5 20974 45 0,997854487 0,049160686 173

7,5 20744 46 0,997782491 0,04919344 173

10 20634 47 0,997722206 0,049219082 172

12,5 20576 36 0,998250389 0,49227051 171

15 20643 53 0,997432544 0,049233703 170

17,5 20648 52 0,997481596 0,04923017 169

20 20622 51 0,997526913 0,049242003 169 Tabela 1 – Desempenho de TCP Vegas

New Reno

Velocidade (m/s) NumGerados NumPerdidos Taxa de Entrega Atraso Médio (s) Troughput (KB/s)

1 24020 112 0,995337219 0,04895863 208

2,5 24004 78 0,996750542 0,049247641 208

5 23973 51 0,997872607 0,049373644 208

7,5 23982 49 0,997956801 0,049397322 208

10 23980 45 0,998123436 0,049420503 208

12,5 23970 40 0,998331247 0,04943337 208

15 23979 56 0,997664623 0,049433825 208

17,5 23986 57 0,997623614 0,049838252 208

20 23980 58 0,997581318 0,049447281 208 Tabela 2 – Desempenho de TCP Vegas

Analisar os dados a partir das tabelas é uma tarefa morosa e complicada por isso vamos fazer o

estudo dos dados a partir dos gráficos feitos com dados obtidos da simulação.

7.1 Taxa de entrega

Fazer um estudo dos protocolos com base nos pacotes pedidos é ineficaz pois nesta comparação o

número de pacotes gerados não é tido em conta. Devido a essa razão é necessário ter outra métrica que

consiga apresentar de forma representativa o desempenho de cada um dos protocolos em causa. Sendo

assim, o estudo da eficiência dos protocolos será feito através de taxa de entrega de pacotes, que é

calculada da seguinte forma:

A taxa de entrega representa a eficiência dos protocolos TCP na entrega de pacotes. Este cálculo

normaliza os dados num intervalo de 0 até a 1 que facilita a análise de desempenho das variações do

protocolo da camada de transporte. O gráfico resultante dos dados obtidos da simulação tem o seguinte

aspeto:

Ilustração 4 - Taxa de entrega de TCP New Reno e TCP Vegas

0,9945

0,995

0,9955

0,996

0,9965

0,997

0,9975

0,998

0,9985

0 5 10 15 20 25

Eficiência

Velocidade (m/s)

Taxa de Entrega

Vegas

New Reno

A partir dos dados do gráfico podemos observar que a taxa de entrega dos dois protocolos da

camada de transporte apresenta comportamento semelhante, ou seja, ambos tem a tendência de melhorar a

eficiência da entrega com o aumento da velocidade. À primeira vista este resultado pode parecer

contraditório, no entanto existe uma explicação simples para estes dados. Com o aumento da velocidade o

nó percorre a distância num intervalo de tempo menor, desta forma o fator velocidade entra “em jogo”

durante períodos de tempo cada vez menores. Assim com o aumento da velocidade o nó passa mais

tempo estático portanto as interferências relacionadas com o movimento do nó desaparecem, melhorando

assim a eficiência na entrega dos pacotes

7.2 Atraso médio

O atraso médio representa o tempo médio que um pacote demora a chegar desde a fonte até ao

destino. Logicamente quanto menor é o atraso melhor é a conexão e consequentemente melhores são os

serviços que a comunicação oferece aos seus utilizadores. Por outro lado, um atraso maior torna a

comunicação mais lenta, dificultando assim a execução de certas aplicações como é o caso de streaming

de vídeo.

A ilustração seguinte mostra em forma de gráfico os atrasos de cada uma das ligações que

utilizam diferentes protocolos da camada de transporte.

Ilustração 5 - Atraso médio de TCP New Reno e TCP Vegas

Tal como se pode ver na figura acima, o TCP Vegas apresenta menores atrasos na entrega dos

pacotes quando comparado com TCP New Reno. Esta melhoria é notável ao longo do eixo dos x do

gráfico que representa a velocidade. Um aspeto importante de notar é que em ambos os protocolos existe

um grande aumento do tempo na entrega dos pacotes quando a velocidade passa de 1 metro por segundo

para 2.5 metros por segundo. Outra conclusão que podemos tirar é que a partir dos sensivelmente 7

metros por segundo o atraso na entrega dos pacotes, tanto no caso de Vegas como no caso de New Reno,

estabiliza, ou seja, mantem-se na mesma faixa de tempo.

A primeira vista parece existir uma grande disparidade entre TCP Vegas e TCP New Reno mas

na prática esta diferença é muito pequena, localizando-se na faixa de 0.0002 segundos. Um utilizador

comum é incapaz de notar a diferença entre dois protocolos.

0,0487

0,0488

0,0489

0,049

0,0491

0,0492

0,0493

0,0494

0,0495

0 5 10 15 20 25

Tempo (s)

Velocidade (m/s)

Atraso Médio

Vegas

New Reno

7.3 Throughput

Throughput representa a quantidade e dados transferidos da fonte até ao destinto durante um

determinado intervalo de tempo. Assim quanto maior for o throughput mais rapidamente será feita a

transferência de um determinado ficheiro ou documento.

A ilustração seguinte mostra em forma de gráfico o throughput que TCP New Reno e TCP Vegas

fornecem consoante o aumento da velocidade.

Ilustração 6 - Troughput médio de TCP New Reno e TCP Vegas

Analisando o gráfico, podemos observar que o troughtput de TCP Vegas deteriora-se a medida

que a velocidade aumenta, começando em 182 KB/s com a velocidade de 1 metro por segundo e

terminado em 169 KB/s quando a velocidade é de 20 metros por segundo. Ao contrário de TCP Vegas,

TCP New Reno apresenta um comportamento totalmente estável, o troughput médio mantem-se

inalterável com o aumento da velocidade do nó. Desta forma é notável que, no modelo estudado, o

melhor protocolo à utilizar para a transferência de dados é o protocolo TCP New Reno.

8. Conclusão

Este relatório fez uma abordagem sobre o processo de handover, foi demonstrada a sua utilidade

para os utilizadores finais e as dificuldades que este processo de transferência de comunicação possui.

Foi feita também uma descrição do funcionamento dos mecanismos de controlo de

congestionamento implementados pelas variações de TCP, nomeadamente TCP New Reno e TCP Vegas.

Abordamos e analisamos o funcionamento de mecanismos como, slow start, congestion avoidance, fast

recovery e fast retransmission. Sendo que cada um deste mecanismos desempenha um factor importante

na entrega correcta de pacotes e gestão de congestionamento da rede.

A partir dos resultados obtidos da simulação podemos concluir que ambos os algoritmos

apresentam comportamento semelhante na taxa de entrega de pacotes, sendo que TCP New Reno

apresenta resultados ligeiramente superiores. Em relação ao atraso na entrega de pacotes, TCP Vegas

apresenta melhores resultados, isto é, o tempo de entrega dos pacotes é inferior ao tempo necessário para

o TCP New Reno. No entanto, tal como no caso da taxa de entrega de pacotes, esta diferença é

insignificativa para o utilizador comum. A diferença significativa entre os protocolos, neste caso de estudo, nota-se no troughput onde TCP Vegas apresenta constantemente resultados inferiores ao TCP

New Reno. Esta situação destaca-se ainda mais com o aumento da velocidade do nó móvel.

Contrariamente, TCP New Reno apresenta sempre o mesmo desempenho independentemente da

165

170

175

180

185

190

195

200

205

210

215

0 5 10 15 20 25

Troughput (KB/s)

Velocidade (m/s)

Troughput médio

Vegas

New Reno

velocidade do nó. Assim podemos considerar o TCP New Reno como o protocolo da camada de

transporte mais robusto e com melhor desempenho apresentado na comunicação entre o nó estático e nó

móvel durante o processo de handover.

9. Referências

[1] Berqia, A. (07 de Março de 2013). WIMAX. Universidade do Algarve.

[2] (12 de Janeiro de 2013). Install ns2 in ubuntu. Obtido em 28 de Fevereiro de 2013, de Linux Vipul:

http://vipullinux.wordpress.com/tag/install-ns2-in-ubuntu/

[3] History of awk and gawk. (s.d.). Obtido em 16 de Março de 2013, de The GNU Awk User's Guide:

http://www.gnu.org/software/gawk/manual/html_node/History.html

[4] Manicka, N. (10 de Novembro de 2005). TCP Variations. Computer & Information Sciences:

University of Delaware.

[5] Amer, P. D. (s.d.). TCP Variations: Tahoe, Reno, New Reno, Vegas, Sack. Computer & Information

Sciences: University of Delaware.

[6] Banks, J. (1998). Handbook of Simulation: Principles, Methodology, Advances, Applications, and

Practice. Georgia Institute of Technology: John Wiley & Sons, Inc.

[7] Altman, E., & Jiménez, T. (4 de Dezembro de 2003). NS Simulator for beginners: Lecture notes,

2003-2004. Sophia-Antipolis, França.

[8] Autores, V. (26 de Janeiro de 2010). NS-2 Trace Formats. Obtido em 12 de Março de 2013, de

http://nsnam.isi.edu/nsnam/index.php/NS-2_Trace_Formats

[9] Corrêa, M. E., & Gonçalves, L. C. (Julho de 2005). Tutorial de NS-2. Obtido em 10 de Março de

2013, de Universidade Federal Luminense: Redes de Computadores I:

http://www.midiacom.uff.br/~debora/redes1/pdf/tutorial-ns2.pdf

[10] Wang, J. (2004). NS-2 Tutorial (1). Obtido em Março de 11 de 2013, de Multimedia Networking

Group, The Department of Computer Science, UVA: http://www.cs.virginia.edu/~cs757/slidespdf/cs757-

ns2-tutorial1.pdf

[11] Wang, J. (2004). NS-2 Tutorial (2). Obtido em 11 de Março de 2013, de Multimedia Networking

Group, The Department of Computer Science, UVA: http://www.cs.virginia.edu/~cs757/slidespdf/cs757-

ns2-tutorial2.pdf

[12] Fall, K., & Varadhan, K. (4 de Novembro de 2011). The ns Manual (formerly ns Notes and

Documentation).

[13] Kurose, J. F., & Ross, K. W. (2010). Computer Networking: A top-Down Approach (5ª ed.).

Addison-Wesley.

[14] Hossain, E., & Issariyakul, T. (2009). Introduction to Network Simulator NS2. Springer.

[15] STEVENS, W., 1997, RFC 2001: TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast

Recovery Algorithms.

[16] Prete, L. R., & Shinoda, A. A. (s.d.). Análise do Comportamento das Variações do Protocolo TCP.

[17] The Network Simulator - ns-2, http://www.isi.edu/nsnam/ns/

[18]IEEE 802.21, “IEEE Standard for 802.21 Media Independent Handover Services,” 2008.

[19]Tools for generating TCL Scripts . (s.d.). Obtido em 12 de Abril de 2013, de Tutorials Web:

http://www.tutorialsweb.com/ns2/NS2-5.htm

[20] Autores, V. (26 de Janeiro de 2010). NS-2 Trace Formats. Obtido em 12 de Março de 2013, de

http://nsnam.isi.edu/nsnam/index.php/NS-2_Trace_Formats

[21] History of awk and gawk. (s.d.). Obtido em 16 de Março de 2013, de The GNU Awk User's

Guide: http://www.gnu.org/software/gawk/manual/html_node/History.html

[22] Altman, E., & Jiménez, T. (4 de Dezembro de 2003). NS Simulator for beginners: Lecture notes,

2003-2004. Sophia-Antipolis, França.

[23] Amer, P. D. (s.d.). TCP Variations: Tahoe, Reno, New Reno, Vegas, Sack. Computer &

Information Sciences: University of Delaware.

[24] Bhosale, S. K., & Dr. Daruwala, R. D. (s.d.). Simulation of Vertical Handover between WiFi and

WiMAX and its Performance Analysis – An Installation Perspective. Department of Electrical

Engineering, Veermata Jijabai Technological Institute (VJTI) Mumbai, India.

[25] Bhosale, S., & Dr. Daruwala, R. D. (s.d.). Experimental Analysis of Horizontal and Vertical

Handovers in Wireless Access. India, 2011 World Congress on Information and Communication

Technologies.

[26] Breqia, A. (28 de Março de 2013). GSM. Universidade do Algarve. Obtido de Universidade do

Algarve.

[27] Chih-Heng, K. (25 de Abril de 2004). How can you set the communication radius in wireless

nodes? Obtido em 16 de Abril de 2013, de http://hpds.ee.ncku.edu.tw/~smallko/ns2/range_en.htm

[28] NIST. (Janeiro de 2007). The Network Simulator NS-2 NIST add-on: IEEE 802.21 model (based

on IEEE P802.21/D03.00).

[29] NIST. (Janeiro de 2009). The Network Simulator NS-2 NIST add-on: IEEE 802.16 model

(MAC+PHY).