WirelessBR

WirelessBr é um site brasileiro, independente, sem vínculos com empresas ou organizações, sem finalidade  comercial,  feito por voluntários, para divulgação de tecnologia em telecomunicações 

Série de artigos sobre VoIP (4)
VoIP

Dimensionamento VoIP (WAN)   - Parte 04

José de Ribamar Smolka Ramos


Série
de artigos sobre VoIP
Quarto artigo - Parte 04

Série VoIP (4) – Dimensionamento VoIP (WAN)

(Continuação)

Calculando Kbps e pps:

Agora, vamos caracterizar o tráfego entregue à rede, em HMM, na forma de um array de interesse de tráfego, como na figura 6. 

Como podem existir diversos tipos de encoding convivendo no mesmo site, este também será um array tridimensional. Os índices i e j denotam os roteadores de origem e destino do tráfego, e a dimensão k indica o volume de tráfego para cada tipo de encoding utilizado. 

Para nosso exemplo, vamos considerar o caso mais extremo, que é o conhecimento apenas dos valores de intensidade de tráfego (por origem, destino e tipo de encoding) em Erlangs. Se você já dispuser de estatísticas de tráfego em pps e kbps geradas pelas fontes de tráfego VoIP nos sites, você pode ir direto para as considerações da figura 8. 

É muito importante para o método que as informações sobre o tráfego estejam segmentadas desta maneira. Se os dados de tráfego não existirem desta forma, consiga-os, ou faça estimativas.  

 

 

Tráfego em HMM (Erl)

Roteadores

G.711, 2 frames/pacote, com VAD
(k=1)

G.729, 3 frames/pacote, com VAD
(k=2)

i

j

1

1

0

0

1

2

6

5

1

3

3

2

1

4

2

7

2

1

1

3

2

2

0

0

2

3

4

2

2

4

4

8

3

1

6

1

3

2

3

3

3

3

0

0

3

4

7

2

4

1

2

4

4

2

1

4

4

3

3

2

4

4

0

0

Figura 6 - Array de interesse de tráfego (Erlangs)

Em cada “plano” i-j do array, os elementos da diagonal principal são iguais a zero, porque não existe tráfego originado e destinado ao mesmo roteador. Nosso exemplo considera a utilização de dois tipos de encoding nos sites, conforme mostra o cabeçalho da figura 6. 

A partir deste array, calculamos o número de circuitos convencionais de telefonia seriam necessários para escoar esta intensidade de tráfego, de acordo com a fórmula Erlang B, assumindo um fator de perda (GoS) de 5%. 

Embora isto pareça alto, para os padrões convencionais de uma rede telefônica, lembre-se que a rede TCP/IP não é um sistema de perda, e sim um sistema de espera. As chamadas “perdidas”, segundo esta fórmula, sofrerão um delay um pouco maior, devido a enfileiramento, que iremos calcular mais tarde. 

Se você pretende implementar este método na forma de um programa de computador (hipótese que, suspeito, a maioria dos leitores já está considerando), você precisará definir um função que calcule N(A,B) conforme a fórmula Erlang B. 

Para o nosso exemplo, esta conversão de Erlangs (figura 6) para circuitos está apresentada na figura 7. 

 

 

Tráfego em HMM (Circuitos)

Roteadores

G.711, 2 frames/pacote, com VAD
(k=1)

G.729, 3 frames/pacote, com VAD
(k=2)

i

j

1

1

0

0

1

2

6

5

1

3

3

2

1

4

2

7

2

1

1

3

2

2

0

0

2

3

4

2

2

4

4

8

3

1

6

1

3

2

3

3

3

3

0

0

3

4

7

2

4

1

2

4

4

2

1

4

4

3

3

2

4

4

0

0

Figura 7 - Array de interesse de tráfego (circuitos)

O cálculo dos valores no array da figura 7 foi feito a partir dos dados já apresentados, da seguinte forma: 

frame físico = voice payload + overhead RTP/UDP/IP + overhead físico 

Kbps = N(A,5%) . 8 . frame físico. pps / 1000 

Os valores na figura 7 nos dizem apenas quanto de tráfego, de cada tipo de encoding, flui na rota entre os roteadores i e j, de forma unidirecional. Precisamos agora alocar este tráfego ao longo das rotas, nos links que são utilizadas no encaminhamento do tráfego desta rota. O procedimento é simples: 

a)   Construa um array com a mesma estrutura do mostrado na figura 7, mantendo os valores de frame físico já encontrados, e com os valores de Kbps e pps zerados. Acrescente a este array uma ocorrência adicional da dimensão k, toda zerada, para uso posterior; 

b)   Para cada tipo de encoding, e para cada par i-j de roteadores no array da figura 7, percorra a rota de i até j conforme o array de rotas (figura 3): 

- Considere, inicialmente, previous_hop ¬ i, e next_hop ¬ ocorrência (i,j,1) do array de rotas; 

- Acumule o valor de Kbps e pps da ocorrência (i,j,encoding) do array da figura 7 na ocorrência (previous_hop,next_hop,encoding) do array criado no passo (a); 

- Se next_hop = j, pare (chegamos ao final da rota). Senão, incremente o índice da dimensão k do array de rotas, salve next_hop ¬ previous_hop, faça next_hop ¬ ocorrência (i,j,k) do array de rotas, e volte ao passo anterior. 

c)   Para cada link i-j acumulado no passo (b), calcule os componentes da última ocorrência da dimensão k – acrescentada ao array criado no passo (a), da seguinte forma: 

- frame físico médio: 

- Kbps total unidirecional:

      - pps total unidirecional:

     

 Onde m é o número total de encodings utilizados na rede. 

No final, nosso array terá os valores de frame físico, Kbps acumulado e pps acumulado por tipo de encoding, mais frame físico médio, Kbps total unidirecional e pps total unidirecional para cada link i-j da topologia. 

Como exemplo, vamos considerar os cálculos para o link 1-2 do nosso exemplo. Através dele (de acordo com a figura 3), passam as rotas entre os roteadores 1-2, 1-3 e 4-2. Usando os dados na figura 7, para o encoding G.723.1 temos: 

E, para o encoding G.729 a carga de tráfego será: 

E a carga total (unidirecional) no link é:

 

A figura 8 apresenta o resultado final dos cálculos para nosso exemplo.

 

Frames, Kbps e pps no link

Roteadores

G.723.1 (k=1)

G.729 (k=2)

Total (k=3)

i

j

1

1

0; 0; 0

0; 0; 0

0; 0; 0

1

2

34; 125,6; 66

40; 154,9; 66

37; 280,5; 132

1

3

0; 0; 0

0; 0; 0

0; 0; 0

1

4

34; 29,9; 22

40; 77,4; 22

37; 107,3; 44

2

1

34; 23,9; 22

40; 49,3; 22

37; 73,2; 44

2

2

0; 0; 0

0; 0; 0

0; 0; 0

2

3

34; 137,7; 66

40; 161,9; 66

37; 299,6; 132

2

4

0; 0; 0

0; 0; 0

0; 0; 0

3

1

0; 0; 0

0; 0; 0

0; 0; 0

3

2

34; 41,9; 22

40; 49,3; 22

37; 91,2; 44

3

3

0; 0; 0

0; 0; 0

0; 0; 0

3

4

34; 173,5; 66

40; 154,9; 66

37; 328,4; 132

4

1

34; 113,6; 66

40; 140,8; 66

37; 254,4; 132

4

2

0; 0; 0

0; 0; 0

0; 0; 0

4

3

34; 41,9; 22

40; 35,2; 22

37; 77,1; 44

4

4

0; 0; 0

0; 0; 0

0; 0; 0

Figura 8 - Array total de frames,  Kbps e pps por link


Agora, com mais algumas pequenas considerações, podemos responder a duas das quatro perguntas iniciais. Quantos Kbps devem ser reservados, por interface WAN, para o PHB EF e qual a carga de pps de tráfego VoIP que cada roteador terá que suportar. 

Até agora, consideramos todo o tráfego como unidirecional. Entretanto, para cada fluxo de pacotes em um sentido, existe um fluxo de pacotes de resposta. Como, no caso das aplicações VoIP, o fluxo de volta tende a ser simétrico com o fluxo de ida (o que definitivamente não é verdade para outros tipos de aplicação), O tráfego total (Em Kbps e pps) em cada link i-j, neste caso, vai ser dado pela soma do tráfego no sentido i-j com o tráfego de resposta, na mesma intensidade, do tráfego no sentido j-i

Efetuando estas somas para o nosso exemplo, temos o resultado mostrado na figura 9.  

Figura 9 – Kbps e pps totais por interface


Então, arredondando para o número de Kbps inteiro imediatamente superior aos encontrados na figura 9, a banda para tráfego do PHB EF em cada interface dos roteadores do nosso exemplo são:

Interface de R1 no link de interligação com R2: 354 Kbps

Interface de R1 no link de interligação com R4: 362 Kbps

Interface de R2 no link de interligação com R1: 354 Kbps

Interface de R2 no link de interligação com R3: 391 Kbps

Interface de R3 no link de interligação com R2: 391 Kbps

Interface de R3 no link de interligação com R4: 406 Kbps

Interface de R4 no link de interligação com R1: 362 Kbps

Interface de R4 no link de interligação com R3: 406 Kbps

Para calcular o número total de pps que cursam através do roteador x, vamos somar, na figura 9, os pps de todos os elementos (i,j) onde i = x ou j = x, o que equivale a somar todos os elementos da linha x e da coluna x. O resultado então é:

 Roteador 1: 704 pps

Roteador 2: 704 pps

Roteador 3: 704 pps

Roteador 4: 704 pps

Os valores de Kbps obtidos devem ser comparados com a capacidade efetiva dos links utilizados (1920 Kbps líquidos – ver figura 2), para verificar se não está havendo sobrecarga. Da mesma forma, cada roteador tem de ser avaliado para verificar se a carga de pps não vai sobrecarregá-lo.


Home WirelessBR                    Anterior                    Próxima