sempre habilita a retransmissão no caso de perdas. Já o escalonador inteligente, criado visando a diminuição do throughput e do payload da rede, permite definir uma tolerância a erros na qual a retransmissão só ocorrerá após um valor definido. Caso seja definida uma tolerância de dois erros, por exemplo, só ocorrerá a retransmissão do pacote a cada dois descartes sucessivos do mesmo (em rounds seguidos). A Figura 3.3 ilustra o exemplo de funcionamento do escalonador inteligente com a retransmissão imediata com tolerância a dois erros consecutivos.
Figura 3.3: Exemplo da operação da escalonador inteligente com a
retransmissão imediata.
Conforme a Figura 3.3, o pacote de dado 1 da estação 1 obteve um erro em sua trans- missão em dois rounds consecutivos, sendo assim retransmitido logo após o segundo erro.
É importante ressaltar que mesmo com a utilização das estratégias de retransmissão, independente do escalonador de tráfego utilizado, o deadline (limite de tempo) do pacote não é excedido devido ao valor do intervalo de serviço (definido pelo usuário) permitir que os pacotes sejam retransmitidos sem ultrapassar tal limite.
3.2
Ambiente de Simulação
Simulação de redes é um recurso bastante utilizado em análise de desempenho de redes de comunicação, pois permite criar abstrações de cenários reais para que atributos, teorias ou novas propostas possam ser avaliados de forma rápida e sem demandar cus- tos com equipamento [HANLEY, 2005]. Na área de redes de comunicação há inúmeros simuladores disponíveis para uso [FALL, 2001], entretanto a maioria são pouco utilizados devido à complexidade, documentação escassa ou por abranger poucos recursos de si- mulação [HANLEY, 2005]. O mais difundido atualmente é o Network Simulator 2 (NS-2) [NS-2, 2008], que por ser um simulador de código livre, possui uma boa documentação e consequentemente uma boa aceitação.
O NS-2 é um simulador de eventos discretos orientado a objetos desenvolvido em linguagem C++ em conjunto com a linguagem de script OTcl (Object Tool Command Lan-
de execução e a linguagem OTcl é utilizada para interpretar os scripts criados pelo usuário sem que seja necessário alterar diretamente o código do simulador [HANLEY, 2005].
Segundo MÜLLER (2006), o NS-2 é um simulador conhecido por pesquisadores na área de redes por sua eficiência e também complexidade. Principalmente esta última característica, onde é considerado uma ferramenta complicada de se utilizar, difícil de aprender, pouco amigável e carente de uma interface gráfica para o usuário (sem con- siderar o limitado Nam7). MÜLLER (2006) acrescenta ainda que para utilizar o NS-2 é necessário estar preparado para gastar muito tempo resolvendo problemas de implemen- tação e também para correr o risco do modelo desenvolvido pelo usuário não funcionar livre de erros.
Além dessas questões, há ainda a ausência de suporte nativo ao padrão IEEE 802.11e. Apesar de existirem extensões do padrão IEEE 802.11e para o NS-2, nomeadamente do mecanismo HCCA, criadas por CICCONETTI et al. (2005b) e DEMARCH (2006), estas apresentam algumas falhas de implementação, tais como erros de sincronismo, sequên- cia desordenada de troca de pacotes, incoerência no funcionamento dos mecanismos de retransmissão, entre outros, gerando resultados em desconformidade com as especifica- ções da norma IEEE 802.11e [IEEE, 2005; IEEE, 2007], sem contar com o fato de que praticamente não possuem documentação.
Embora o desenvolvimento deste trabalho tenha se iniciado com a utilização do NS-2 em conjunto com as extensões do padrão IEEE 802.11e, devido a problemas de imple- mentação, demanda por inúmeras adaptações e dificuldade em expandir o código fonte, optou-se por desenvolver um simulador próprio visando uma melhor compreensão e do- mínio da especificação do padrão em questão, bem como a simplificação do processo de simulação. Além disso, as principais razões que levaram à criação do novo simulador fo- ram a necessidade por adaptabilidade e flexibilidade do sistema para que novos recursos pudessem ser facilmente agregados e expandidos. Desta forma, foi criado o HCCA Si-
mulator (HCCASimu), o qual engloba exclusivamente as funcionalidades do mecanismo
de acesso ao meio HCCA do padrão IEEE 802.11e, juntamente com os algoritmos de retransmissão de dados propostos.
3.2.1
Introdução aoHCCA Simulator
O HCCASimu foi desenvolvido em linguagem C++, tomando como base os parâme- tros das camadas física do padrão IEEE 802.11b8e de acesso ao meio do padrão IEEE 802.11e, através do uso do mecanismo HCCA, conforme apresenta a Tabela 3.1. Além disso, alguns recursos e funções presentes nas extensões do padrão IEEE 802.11e de- senvolvidas para o NS-2 foram incorporadas ao simulador criado. O simulador foi vali- dado através de testes práticos tomando como base a norma do padrão IEEE 802.11e [IEEE, 2005] e também as extensões do padrão criadas para o NS-2.
7Nam é uma ferramenta de animação, baseada em Tcl/TK, para visualização dos dados simulados no
NS-2.
8Apenas foram consideradas as taxas de transmissão e tamanho de quadros desta camada, sendo
3.2. AMBIENTE DE SIMULAÇÃO 33
Tabela 3.1: Parâmetros do padrão IEEE 802.11b com IEEE 802.11e
implementados no HCCASimu. Parâmetro Valor Parâmetro Valor Maximum PHY Rate 11 Mbit/s CF_End 20 bytes
Minimum PHY Rate 1 Mbit/s CF_Poll 36 bytes
QoS Header 11e 36 bytes SIFS 10µs
PLCP Header 24 bytes PIFS 30µs
ACKlength 14 bytes aSlotTime 20µs Beacon 79 bytes9 TXOPLimit 8160µs
Devido à natureza não determinística do período de contenção (CP), o HCCASimu contempla somente a implementação do período livre de contenção (CFP) do mecanismo HCCA. Além disso, agrega novos recursos à simulação, como a introdução dos algorit- mos de retransmissão, e corrige as falhas (apresentadas anteriormente) presentes nas extensões do padrão IEEE 802.11e criadas para o NS-2.
O funcionamento do simulador desenvolvido é similar ao do NS-2, onde o usuário de- fine os parâmetros de entrada, executa o simulador e aguarda os resultados da simulação nos arquivos de saída. Assim, no HCCASimu há um arquivo de entrada em que o usuário define a duração da simulação, o número de estações, o tamanho do quadro, a taxa de envio dos pacotes, o intervalo de serviço, o sentido do tráfego, se o canal é ruidoso ou limpo, se a fila é randômica, a taxa de chegada na fila e a de perda de pacotes, e por fim o tipo de algoritmo de retransmissão que será utilizado. De acordo com esses dados de entrada as TSPECs e as TXOPs são criadas internamente e atribuídas às estações de forma que a transmissão possa iniciar. Por convenção, não foi imposto limite à duração do CFP (CFPMaxDuration) e nem à da CAP (CAPLimit), tampouco definido o valor de Delay
Bound, entretanto atribuiu-se o valor máximo de 8160 µs para as TXOPs (TXOPLimit),
conforme especifica a norma IEEE 802.11e [IEEE, 2005].
Além da entrada de dados, o HCCASimu possui dois tipos de saída de dados, sendo um trace out personalizado, de fácil visualização e entendimento para o usuário onde é mostrada toda a sequência de pacotes transmitidos, descartados e/ou retransmitidos, bem como suas durações, e uma outra saída que é um arquivo de log com os valores de atraso, jitter, throughput, e outros, a serem submetidos a um programa para análise e geração de gráficos.
O foco principal do desenvolvimento do HCCASimu é avaliar o desempenho dos al- goritmos de retransmissão propostos. O Subitem 3.2.1.1 apresenta alguns detalhes de funções e recursos implementados no simulador.
3.2.1.1 Detalhes de implementação do simuladorHCCASimu
Uma vez que o funcionamento dos algoritmos de retransmissão já foi apresentado no detalhamento da proposta, este subitem é focado principalmente na forma de implemen- tação do escalonador de referência e do controle de admissão do tráfego no simulador.
De acordo com os dados de entrada definidos pelo usuário, tomando como base as equações do escalonador de referência do HCCA, apresentadas no Capítulo 2, a primeira tarefa a ser realizada pelo HCCASimu é calcular o número de pacotes admitidos por esta- ção. Assim, este número é determinado em função da taxa de envio em um determinado SI, conforme apresenta a Equação 3.1.
NU MPackets= SI × MeanDataRate NominalMSDU × 8 (3.1) Onde, • SI é o intervalo de serviço;
• MeanDataRateé a taxa de envio de pacotes e
• NominalMSDU é o tamanho do dado.
Em seguida, com base na extensão do padrão IEEE 802.11e desenvolvida por DE- MARCH (2006), é calculado o tempo de transmissão para o tamanho nominal e máximo do quadro de dados, dado, respectivamente, pelas Equações 3.2 e 3.3 abaixo:
MeanTime= TData+ 2 × Propagation Delay + 2 × SIFS + TAck (3.2)
MaxTime= TMaxData+ 2 × Propagation Delay + 2 × SIFS + TAck (3.3)
Onde,
• TData é o tempo de transmissão de um quadro de dados com tamanho nominal; • TMaxDataé o tempo de transmissão de um quadro de dados com tamanho máximo;
• Propagation Delay é o atraso de propagação, definido pelo usuário, mas por pa-
drão possui o valor de 2µs10e
• TData é o tempo de transmissão do quadro de confirmação.
Para determinar a duração da transmissão dos quadros de gerenciamento (beacon,
polling e CF_End) e de confirmação, utiliza-se a Equação 3.4 abaixo, tomando como
referência os valores dos parâmetros apresentados na Tabela 3.1.
Tx= Quadro + PLCPHeader MinimumPHY Rate × 8 (3.4) Onde,
• Txé o tempo para transmitir o quadro;
• Quadro é o valor em bytes de algum dos parâmetros apresentados na referida
tabela. No caso de ser oPLCPHeader, o valor doQuadroé zero;
• PLCPHeaderé o tamanho do cabeçalho PLCP e
• MinimumPHY Rateé a taxa mínima do canal.
10Conforme explicitado anteriormente, a camada física do padrão IEEE 802.11b foi abstraída na imple-
mentação do simulador. Desta forma, foi considerado um atraso de propagação fixo, uma vez que a distân- cia entre as estações da rede é fixa.
3.2. AMBIENTE DE SIMULAÇÃO 35
Com base na Equação 3.4 é possível determinar os tempos de transmissão de todos os quadros presentes na transmissão do mecanismo HCCA. Desta forma, a Tabela 3.2 apresenta a duração da transmissão dos quadros de gerenciamento e confirmação. Vale ressaltar que todos estes quadros são transmitidos à taxa mínima do canal.
Tabela 3.2: Tempo de transmissão dos quadros de gerenciamento e
confirmação.
Parâmetro Tempo Parâmetro Tempo THeader11e 26µs TCF_End 352µs
TPLCPHeader 192µs TCF_Poll 480µs
TBeacon 824µs TACK 304µs
Entretanto, para calcular a duração de transmissão de um quadro de dados, a Equa- ção 3.4 sofre algumas alterações, pois a duração varia de acordo com o tamanho do dado. Desta forma, a Equação 3.5 apresenta o cálculo de tempo de transmissão de um dado:
TData= NominalMSDU + Header11e MaximumPHY Rate + PLCPHeader MinimumPHY Rate × 8 (3.5) Onde,
• NominalMSDUé o tamanho do quadro de dados;
• Header11eé o tamanho do cabeçalho do padrão IEEE 802.11e e
• MaximumPHY Rateé a taxa máxima do canal.
É importante ressaltar que todos os quadros transmitidos, sejam eles de dados, de confirmação ou de gerenciamento, são acrescidos do cabeçalho PLCP (PLCP Header) transmitido à taxa mínima do canal. Já o quadro de dados é transmitido à taxa máxima. No caso do pacote ser nulo (QoS Data Null), o NominalMSDU é zero, sendo apenas
transmitido o cabeçalho do padrão 802.11e.
Após o cálculo da duração nominal e máxima de transmissão de um dado, Equações 3.2 e 3.3, é calculado o overhead do quadro de interrogação através da Equação 3.6, onde se resume ao tempo de transmissão do cabeçalho 802.11e acrescido de um SIFS e um atraso de propagação.
PollOverhead = THeader11e+ Propagation Delay + SIFS (3.6)
Aplicando-se os valores obtidos através das Equações 3.1, 3.2, 3.3 e 3.6 à Equação 2.6, do escalonador de referência do HCCA, as TXOPs são calculadas para os tráfegos nos sentidos uplink e downlink, conforme apresentam as Equações 3.7 e 3.8 abaixo:
T X OPup= max(NUMPackets × MeanTime) + PollOverhead,
MaxTime+ PollOverhead
(3.7)
T X OPdw = max(NUMPackets × MeanTime),MaxTime
Vale ressaltar que para o tráfego no sentido downlink não há interrogação, portanto o
overhead de polling não é acrescido ao cálculo.
Em seguida é calculada a duração da fase de acesso controlado, a qual é determinada de acordo com o número de estações multiplicado pela soma das TXOPs em ambos os sentidos do tráfego, conforme apresenta a Equação 3.9.
CAP= NUMStations × (T XOPup+ T XOPdw) (3.9) Assim, caso os valores das TXOPs não superem o valor do TXOPLimit e nem façam com que a CAP seja superior ao SI, o tráfego especificado é admitido pelo escalonador e a simulação é iniciada.
Embora o CFP varie de acordo com o número de retransmissões, a duração do mesmo pode ser representada pela Equação 3.10 abaixo:
CFP= TBeacon+ PIFS + (Nup×T X OPup) + (Ndw×T X OPdw) + SIFS + TCF_End (3.10)
Onde,
• NupeNdw são o número de TXOPs no sentido uplink e downlink, respectivamente;
Caso o valor do CFP supere o valor de SI, o simulador interrompe a simulação e notifica o usuário. Desta forma, o mesmo terá que alterar os parâmetros de entrada para poder simular o cenário desejado.
Além das funções do escalonador de referência e do controle de admissão, o HCCA-
Simu conta ainda com funções responsáveis pelo envio dos pacotes, geração do erro,
gerenciamento da fila de pacotes, além de funções de controle do tempo de execução, de cálculo de atributos de atraso, jitter e outros, e da saída de resultados.