Seção: Tutoriais VoIP

Esta seção mostra os cálculos para se obter o número de chamadas que um link pode ter e a simulação VoIP propriamente dita. Para os cálculos e simulação foi considerada uma banda de 5436 Kbit/s (~5.4 Mbit/s).

Cálculos de Chamadas

Nesta seção são mostradas as fórmulas e informações sobre os cabeçalhos de cada camada e codecs que foram de grande importância para os cálculos realizados neste trabalho. A Tabela 4 mostra as fórmulas para calcular quanto cada conexão VoIP ocupa em cada parte do cenário.

Como, para a realização dos cálculos, é importante saber detalhes sobre os cabeçalhos das camadas envolvidas nos experimentos, a Tabela 5 mostra o tamanho (em bytes) dos cabeçalhos destas camadas.

Como exemplo, mostram-se aqui os cálculos para o codec G.711 que possui as seguintes características (Tabela 6). Mais adiante são mostrados detalhes dos outros codecs abordados neste trabalho.

Caso não se tenha essas informações, podem-se obter algumas delas com base em algumas informações do codec como bit rate e payload. Para isso, utiliza-se a Equação 4 abaixo, isto é efetivo apenas para cálculos de consumo de banda:

Bit Rate do Codec = tamanho do payload de Voz (bytes) / tempo do payload de Voz (ms) (Eq. 4)

Como se tem todas as informações sobre o codec, os cálculos para se ter o quanto é consumido do link por este codec são realizados a seguir.

É importante lembrar que são mostrados três cálculos. O primeiro cálculo informa o quanto do link é consumido de fato; o segundo revela este valor quando o meio envolve a camada 2 tendo como meio o padrão IEEE 802.3 (Ethernet); e o terceiro que também considera a camada 2, mas agora tendo-se como meio o padrão IEEE 802.11(Wi-Fi). Estes cálculos se baseiam na Equação 5 abaixo.

Banda consumida = [((Camada 2+Cabeçalhos IP+UDP+RTP) + payload) * 8 bits / byte] * pps (cobre) (Eq. 5)

Cálculo 1: Não considerando a camada 2 e cabeçalhos IP+UDP+RTP:

• Banda consumida = [(40 bytes + 160 bytes) * 8 bits por byte] * 50 pps;
• Banda consumida = 80000 bit/s = 80 Kbit/s.

Cálculo 2: Considerando a camada 2 IEEE 802.3 e cabeçalhos  IP+UDP+RTP:

• Banda consumida =  [(66 bytes + 160 bytes) * 8 bits por byte] * 50 pps;
• Banda consumida = 90400 bit/s = 90,4 Kbit/s.

Cálculo 3: Considerando a camada 2 IEEE 802.11 e cabeçalhos IP+UDP+RTP:

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

O cálculo 3 informa exatamente quanto o codec G.711 utiliza do link em uma rede que tem como meio o padrão IEEE 802.11, e, conseqüentemente, quantas conexões VoIP pode-se ter utilizando esse codec:

Link = 5.4 Mbit/s => Número de Chamadas =  5436 Kbit/s / 93,6 Kbit/s = ~58.08 = 58 caminhos / 2 = 29 chamadas.

Logo, há 29 conexões VoIP, pois no cálculo realizado é considerado apenas um stream, ou seja, para se ter uma conversão, o usuário do outro lado da comunicação também é considerada como um stream, assim, para se ter para uma conexão são necessários 2 streams. Daí a necessidade de se dividir por 2 o resultado para obter o número exato de conexões no link.

O arredondamento é sempre feito para baixo, pois não é correto arredondar de maneira estatística, já que assim pode-se ultrapassar o limite de 5436 Kbit/s (~5.4 Mbit/s), o qual foi fixado como o máximo possível a ser atingido pelo link de rede sem fio. A Tabela 6 mostra os resultados dos cálculos para os codecs.

Simulação VoIP

Para realizar a simulação VoIP, foi necessário criar um programa para gerar o tráfego necessário, pois o iperf, que era o gerador utilizado, infelizmente não funcionou satisfatoriamente na geração de tráfego quando era usado conexões paralelas, e tinha um limite virtual de 30 conexões; se este limite fosse excedido, o teste não poderia ser executado.

Entretanto, para somente uma conexão ocorreram problemas. Então, foram utilizados os seguintes softwares em conjunto para realizar o teste: voip traffic generator (de autoria do grupo), ping e iperf. O voip traffic generator gerava o tráfego de acordo com as necessidades dos codecs e quantas conexões fossem necessárias, o ping registrava o round-trip time e o iperf analisava o jitter e a perda de pacotes.

Com essas ferramentas, os testes foram realizados e obtivemos os resultados mostrados nos gráficos a seguir. O Gráfico 1 mostra o número de chamadas VoIP que cada codec por oferecer de acordo com uma dada utilização da banda; o Gráfico 2 mostra a variação do jitter pela utilização da banda; o Gráfico 3 mostra a variação do RTT nestas diferentes cargas utilizadas da banda; e, o Gráfico 4 revela a perda de pacotes que cada codec tem nas diferentes cargas testadas.

É importante ressaltar que as métricas avaliadas são mostradas com base na carga que cada codec impõe na banda (~5.4Mbit/s), ou seja, de acordo com a utilização que os mesmos fazem da banda. Nestes testes foram considerados que os codecs utilizam toda banda disponível (100%), metade (50%) e, também, um quarto (25%) da mesma.

Deve-se entender o limite que aparece nos gráficos como o ponto máximo das métricas avaliadas nestes testes onde, quando obedecido, não haverá problemas com os padrões de qualidade explicados anteriormente.

Foram calculadas as médias (Gráficos 2, 3 e 4) com 95% de confiança e através do teste visual (JAIN, 1991) pode-se perceber que estas médias são diferentes. Por exemplo, considerando o codec G.711 utilizando 100% da banda, obteve-se como resultado o seguinte: 29 chamadas (Gráfico 1), 3.78 ms de jitter (Gráfico 2), 243.492 ms de RTT (Gráfico 3) e 13,9 % de perda de pacotes (Gráfico 4).

Pode-se ver pelos gráficos que o limite (ponto máximo para manter qualidade) de chamadas da maioria dos codecs (Gráfico 1) foi o mesmo (12 chamadas), ou seja, é necessário considerar as demais métricas para ver aquele que pode ser classificado como o melhor dentre eles.

Observando os limites dos Gráficos 2, 3 e 4, pode-se concluir que o codec GSM 6.10 é o melhor codec, pois apesar de ter uma perda de pacotes de quase 5% esta ainda se encontra dentro do limite proposto por BOGER (1999).

Mas, durante os testes, foi notado no gerador de tráfego que o ponto de acesso, em um período de 5 minutos, recebeu em média 317000 pacotes, permitindo calcular a capacidade média de roteamento do ponto de acesso. Assim, descobriu-se que o ponto de acesso só conseguia rotear aproximadamente 1056 pacotes por segundo, desta maneira limitando radicalmente os testes.

Isso explica o porquê do limite de chamadas ter ficado entre 10 e 12 chamadas VoIP. Mesmo que exista banda disponível suficiente, o equipamento não consegue rotear um número maior de pacotes, começando, então, a se livrar dos pacotes que excedam este limite, provavelmente por falta de poder de processamento.

Logo, dizer qual é o melhor ou o pior codec é uma tarefa não muito fácil, pois além das interferências que influenciaram no ambiente tiveram-se, também, os limites impostos pelos próprios equipamentos utilizados. Mas mesmo com as interferências e limites os codecs ainda mantiveram seus limites dentro daqueles propostos anteriormente.

Apontar o melhor ou o pior codec vai depender de onde se quer utilizar os mesmo, além, logicamente, de considerar os testes deste trabalho. Também é válido explicar o motivo de não aparecerem os protocolos SIP (SCHULZRINNE e ROSENBERG, 1998) e H.323 (TRILLIUM, 1999) nos testes. Somente os codecs foram testados, pois são eles que realmente ocupam o link da rede e é neles que está a qualidade da voz.

Os protocolos SIP e H.323 são utilizados para o setup (início e finalização da conexão e outras funcionalidades), mas não para o transporte de dados. Logo, não existe uma necessidade de testar esses protocolos, pois os mesmos não irão apresentar uma grande diferença na comunicação e só são utilizados no inicio da comunicação, ou seja, o overhead que eles criam na rede é mínimo, logo só é interessante simular as conexões já em andamento que é onde elas realmente ocupam a rede.

Apesar dos resultados terem sido visivelmente prejudicados pela falta de equipamentos e programas que atendessem a demanda do trabalho, o limite não ultrapassou de 12 chamadas simultâneas, onde deveria se obter uma média muito melhor que esta apresentada. Acredita-se que esta média deveria estar entre 25% e 50% com total certeza que não excederia os padrões de qualidade apresentados.