Estimativa do Atraso

Segundo apresentado na seção anterior, a ferramenta Wimanager a ser utilizada nos experimentos fornece, entre os parâmetros de desempenho fixados como de interesse do presente trabalho, a vazão, o jitter, e o percentual da perda de pacotes. Entretanto, não fornece o atraso que precisa ser obtido a partir dos outros parâmetros.

Uma possível abordagem para obtenção do atraso é através de cálculos baseados no cálculo do jitter fundamentado na RFC 1889, conforme ilustrado na Figura 3.8, onde o Ti, Tj, Tk, representam os atrasos para os pacotes i, j, k, enquanto o Si, Sj e Sk indicam simultaneamente o timestamp RTP, dos pacotes i, j e k. Os Ri, RJ e Rk representam o tempo de chegada em unidades de timestamp RTP do pacote i, j e k.

Figura 3. 8 – Modelo para o cálculo do atraso.

No item (b) é apresentada uma sistematização de uma solução para obter o atraso associado a cada medida de vazão, onde os pacotes mesmo tendo comprimentos distintos, podem ser pensados todos iguais com um tamanho médio de duração Ts segundos, sendo observado no item (a) que os pacotes têm comprimentos diferentes. Segundo a RFC 1889, os

pacotes possuem timestamps diferentes, onde o timestamp enquanto unidade de medida está vinculada à taxa de amostragem.

Assim, nessas condições, a taxa de transmissão em um canal ideal (sem atrasos) seria tx = m/Ts (bits, por segundo), sendo “m” o número de bits contidos nos “Ts” segundos. Isto é, Ts é o tempo de transmissão de um pacote. Como os canais, por várias razões, não são ideais, pode-se associar para cada pacote idealizado (tamanho médio) um tempo de transmissão virtual, “Tv”. Assim, a taxa de transmissão nesse canal imperfeito é S = m/Tv (bits/seg), sendo S < tx, onde S, com as considerações feitas, representa, então, a vazão do canal. Como em “Tv”, temos duas parcelas, “Ts” e o atraso, “T” segundos, então S = m/(Ts +T) bits por segundo. Assim, conhecidos, “m” e “Ts”, é possível obter “T”, o atraso médio associado à vazão.

O “m” e o “Ts”, podem ser obtidos respectivamente a partir do tamanho de um pacote VoWiFi e do tempo de transmissão desse pacote de acordo com o codec utilizado na conexão VoWiFi. Segundo Moreira et al. (2009), para se obter o tamanho do pacote de voz de uma conexão VoWiFi, é necessário considerar o somatório dos tamanhos dos cabeçalhos dos protocolos envolvidos na conexão, juntamente com o tamanho do payload do codec usado nas conexões VoWiFi. Essas considerações são apresentadas respectivamente nas Tabelas 3.1 e 3.2, referentes ao codec PCMU, que é uma das versões do G.711 conforme foi explanado no item 2.4.1, referente a esse trabalho de pesquisa.

Tabela 3.1- Camadas e seus respectivos cabeçalhos. Cabeçalhos Tamanho (bytes)

Ethernet camada 2 26

WiFi camada 2 (com FCS) 34

IP 20 UDP 8

RTP 12

Tabela 3.2 -Informações sobre o codec G.711. G.711

Bit Rate 64 Kbit/s

Payload de voz 160 bytes

PPS 50

Diante do contexto das Tabelas 3.1 e 3.2, de acordo com Moreira et al. (2009), para se obter o tamanho de um pacote de voz de uma conexão VoWifi, é necessário realizar o somatório do cabeçalho da camada 2 do WiFi, com os cabeçalhos dos protocolos IP, UDP e RTP, juntamente com o payload de voz do codec da conexão VoWiFi. Para se obter o tempo de transmissão de um pacote, também será considerado o tempo de transmissão do codec da conexão VoWiFi. Em se tratando do presente trabalho, a referência utilizada é o codec G.711, obtendo-se um tamanho de 234 (de duzentos e trinta e quatro) bytes, o equivalente a 1.872 (mil oitocentos e setenta e dois) bits.

Segundo Moreira et al. (2009), para se obter o quanto é consumido do link pelo codec G.711 no padrão 802.11 é necessário a partir da camada 2 IEEE 802.11 e dos cabeçalhos IP, UDP e RTP, calcular a equação 3.4.

Banda consumida = [(74 bytes + 160 bytes) * 8 bits por byte] * 50 pps32 (3.4) Banda consumida = 93600 bit/s = 93,6 Kbit/s.

Onde a partir do valor da banda consumida é possível obter o tempo de duração de um pacote VoWiFi, de acordo com os seguintes procedimentos:

Se 160 bytes equivalem a 1,25 Kbits, ou seja, 160 bytes * 8 bits /1024 = 1,25 Kb, considerando a banda consumida pelo 802.11 igual a 93,6 Kbit/s da Equação 3.4, a duração para transmitir este pacote é efetuada, dividindo 1,25 Kbits por 93,6 Kbps , que corresponde a 0,013s ou 13,33 ms.

3.3 Metodologia dos Experimentos

Os ambientes indoor e outdoor são realizados em dias e horários diferentes, sendo configurados de acordo com as especificidades de cada experimento. No ambiente indoor, a proposta é a montagem de um ambiente de referência em condições próximas a ideal, supondo o mínino de efeitos externos que possam interferir nos resultados do objeto em estudo. No ambiente outdoor a finalidade é obter resultados de acordo com a realidade desses ambientes na UFRN, levando em consideração todos os possíveis fatores externos que possam interferir de forma significativa nas análises da pesquisa em questão.

Os experimentos em ambiente indoor são realizados em duas etapas em ambiente não controlado, ou seja, sem o domínio da situação do tráfego da rede no período dos experimentos. A primeira etapa é executada com o auxílio do softphone Ekiga entre uma estação fixa em rede FastEthernet localizada na Diretoria de Redes da SINFO e uma estação em mobilidade em rede 802.11b deslocando-se entre a sala da Diretoria de Redes e o AUDITÓRIO da SINFO, conforme ilustrado na Figura 3.9.

A estação em mobilidade utiliza além da ferramenta Ekiga, o Sistema Operacional Windows XP. A estação fixa utiliza softphone Ekiga, o Sistema Operacional Linux e o analisador de desempenho Wimanager. O uso do Sistema operacional Linux se deve ao fato do aplicativo Wimanager ser projetado para ser executado apenas nesse sistema.

32

Figura 3. 9 – Ambiente indoor sem adição de tráfego controlado.

A segunda etapa dos testes é concretizada da mesma forma que a primeira. O diferencial é que nessa etapa os experimentos são executados através da injeção de tráfego no sistema por meio do gerador de tráfego, Iperf, conforme é apresentado na Figura 3.10. O Iperf injeta tráfego a partir da estação móvel no modo cliente em destino à estação fixa em modo servidor.

Figura 3.10 - Ambiente indoor com adição de tráfego controlado.

Os experimentos em ambiente outdoor são executados em duas fases nas redes da SINFO, assim como nas redes externas ao prédio da SINFO, especificamente as redes e instalações do NEPEGN. Nesse ambiente são realizadas comunicações VoWiFi através da aplicação Ekiga entre uma estação móvel na rede 802.11b e uma estação fixa em rede FastEthernet.

A primeira fase desses testes representa os experimentos realizados caminhando com a estação móvel entre os departamentos do NEPEGN e da SINFO. A segunda fase indica os

experimentos executados com a estação móvel dentro de um automóvel de vigilância da UFRN em mobilidade.

A primeira fase é dividida em duas etapas. A primeira etapa trata da análise de desempenho das comunicações VoWiFi através da ferramenta Wimanager sem injeção de tráfego controlado como se apresenta na Figura 3.11, enquanto que a segunda etapa representa os experimentos executados com a injeção de tráfego controlado, segundo ilustração da Figura 3.12.

O objetivo dessas etapas é verificar, no ambiente outdoor, qual a influência do aumento do tráfego na rede concorrendo com a comunicação VoWiFi.

Figura 3. 11- Ambiente outdoor sem adição de tráfego controlado.

A segunda fase dos experimentos outdoor refere-se aos mesmos experimentos realizados na primeira etapa da primeira fase dos testes realizados em ambiente outdoor, onde não ocorre à injeção de tráfego controlado. Nessa fase, a estação móvel participa dos experimentos dentro de um automóvel em mobilidade. Isso pode ser observado na Figura 3.13.

Figura 3.13 –Ambiente outdoor dentro de um automóvel.

O objetivo desses experimentos realizados dentro de um automóvel é verificar o impacto na qualidade da comunicação VoWiFi considerando velocidades do automóvel variando no intervalo de 10km a 40km entre os departamentos da SINFO e do NEPEGN. É considerado esse intervalo pelo fato de serem as velocidades utilizadas pelos vigilantes da UFRN em condições normais de trabalho, ou seja, sem nenhuma situação de emergência. Ao final dos experimentos concretizados nos ambientes indoor e outdoor são obtidas as métricas de desempenho, capturadas pelo Wimanager, que são armazenadas em arquivos do tipo “.txt” e em seguida processadas pelos Scripts em Bash Shell e transformadas no padrão Comma-separated values – CSV, para que possam ser interpretadas pelo Microsoft Office Excel e, em seguida, comparadas com os parâmetros ideais de QoS presentes na literatura para uma comunicação VoIP.