Cálculo da banda de voz e vídeo em uma rede IP

Prévia do material em texto

Unidade III
Cálculo da banda de voz e vídeo em 
uma rede IP
• Ao se trabalhar com redes de voz (packet 
voice networks) deve-se projetar um capacity 
planning.
• Com o capacty planning é possível 
conhecer o comportamento da rede, suas 
demandas, desing e projetar mecanismos de 
troubleshoot para se garantir o 
funcionamento do sistema e a melhor 
qualidade do serviço.
Cálculo da Banda de Voz
Unid. III.1
Tamanho dos datagramas IP 
(quantidade de amostras) para os
serviços real time
Taxa necessária para encapsular fluxos de voz em 
frames Ethernet (interface LAN)
Unid. III.2
Tamanho dos cabeçalhos RTP, UDP e 
IP e quadros da camada 2
• These protocol header assumptions are used for the
calculations:
40 bytes for IP (20 bytes) / User Datagram Protocol 
(UDP) (8 bytes) / Real-Time Transport Protocol (RTP) (12 
bytes)
headers.
Compressed Real-Time Protocol (cRTP) reduces the
IP/UDP/RTP headers to 2 or 4bytes (cRTP is not available
over Ethernet).
VoIP – Per Call Bandwidth
• These protocol header assumptions are used for the
calculations:
6 bytes for Multilink Point-to-Point Protocol (MP) or 
Frame Relay Forum (FRF).12 Layer 2 (L2) header.
1 byte for the end-of-frame flag on MP and Frame Relay
frames.
18 bytes for Ethernet L2 headers, including 4 bytes of 
Frame Check Sequence (FCS) or Cyclic Redundancy Check 
(CRC).
 Fórmula para se calcular a banda utilizada 
por uma chamada de voz:
Banda utilizada (bits por segundo) = 
tamanho pacote voz (bits por pacotes) x Taxa 
de pacotes por segundo (pacotes por segundo 
ou PPS), onde:
- Taxa de pacotes por segundo= Taxa do
CODEC utilizado / tamanho amostra de voz
Cálculo da Banda de Voz
- Tamanho pacote voz= amostra do sinal de voz +
cabeçalho RTP + cabeçalho UDP + cabeçalho IP +
cabeçalho enlace
- Tamanho do cabeçalho RTP+UDP+IP= 12+8+20= 40 
bytes
- Para o Codec G711 PCM temos que a taxa do Codec é 64 
Kbps e temos 160 bytes por amostra.
- Portanto, temos que:
- PPS = 64 Kbps / 160 bytes = 64.000 / 160 x 8 = 
8.000 / 160 = 50 pacotes por segundo
Informações para cálculo da banda de voz
- Tamanho cabeçalho (RTP+UDP+IP) comprimido –
compressed RTP = 2 a 4 bytes (para cálculo de banda, foi 
utilizado cabeçalho de 2 bytes).
- A taxa de amostragem do sinal de voz e
conseqüentemente, a banda utilizada pelo canal,
depende do codificador utilizado para a compressão.
- Para cada método de compressão utilizado temos 
uma taxa de qualidade, medida pelo valor de MOS 
(Mean Opinion Score). O MOS varia de 1 a 5, sendo 1 a 
pior qualidade e 5, a melhor.
1) G 711: 160 bytes
• IP/UDP/RTP: 40 Bytes
• FR: 4 Bytes
- Total: 204 Bytes * 50 pps * 8 bits = 81,6 kbps
2) G 711: 160 bytes
• IP/UDP/RTP/ Header compression: 5 Bytes
• FR: 4 Bytes
- Total ?
3) G 711: 240bytes
• IP/UDP/RTP: 40 Bytes
• FR: 4 Bytes
- Total: ?
Cálculo de Banda
• G 711: 160 bytes
• IP/UDP/RTP: 40 Bytes
• FR: 4 Bytes
- Total: 204 bytes * 50 pps * 8 bits = 81,6 kbps
-Largura de banda= taxa do cabeçalho + taxa do Codec
-Taxa do cabeçalho= 44 bytes * 50 pps * 8 bits = 17,6 
Kbps
- Taxa do Codec G711= 64 Kbps
Largura de banda= 17,6 Kbps + 64 Kbps = 81,6 Kbps
Cálculo de Banda – Outra forma de calcular
Tabela MOS (Codec)
• O MOS varia de 1 a 5, sendo 1 a 
pior qualidade e 5, a melhor.
Utilização de Banda
• Considerar as características dos Codes e 
métodos de encapsulamento e compressão.
Cálculo de Banda
Quadros com conteúdo de voz
Para o cálculo da banda ocupada pelo 
transporte dos serviços na rede IP, pode ser usado 
como exemplo o serviço de VoIP (Voz sobre IP).
Supondo que o tráfego de voz analógico seja 
digitalizado por um codificador G.711 (PCM), a taxa 
de saída desse codificador é de 64 kbps. 
Para esse codificador, é usual o transporte do 
sinal digitalizado feito por um datagrama IP com 
160 bytes de payload e duração de 20ms.
A carga útil gerada pelo CODEC G.711 no 
período de 20 ms de amostragem é de 160 octetos. 
Somados com os 40 dos cabeçalhos RTP/UDP/IP, 
significam 200 octetos ou 1600 bits transmitidos 50 
vezes em um segundo, o que gera uma banda 
necessária de 80.000 bits por segundo (sem considerar 
os bits de controle na camada de enlace).
Taxa necessária para encapsular fluxos de voz em 
frames ethernet/fast-ethernet (nas interfaces LAN)
No caso dos frames Ethernet/Fast-ethernet, a 
sobrecarga dos cabeçalhos fica em 8 octetos de 
preâmbulo, mais seis de endereço destino, seis de 
endereço fonte, 2 octetos para o tamanho da unidade de 
dados e 4 de detecção de erros. Somados com 12 octetos 
de espaçamento entre os frames, o total é de 38 octetos. 
A carga gerada pelo CODEC G.711 é de 64000/50= 
160 octetos. Somados com os 40 octetos dos cabeçalhos 
RTP/UDP/IP, enviados 50 vezes por segundo, totaliza 
uma banda necessária de (160+40+38) x 50 x 8 = 95.200 
bits por segundo .
Se a codificação utilizada for G.729a padrão, a 
banda necessária é menor:
- Um pacote é emitido a cada 10ms, sendo que cada 
quadro Ethernet porta 2 pacotes de 10 bytes.
- O fluxo é de 8Kbps, ao invés de 64Kbps do G.711.
- O tamanho da amostra de voz padrão para o G729a é 20 
bytes (2 x 10 bytes). Somados aos 40 dos cabeçalhos 
RTP/UDP/IP e 38 do Ethernet, tem-se 98 bytes.
- O PPS= 8000/20 bytes= 8000/(20 x 8)= 50 
pacotes/segundo.
- A banda necessária para o fluxo de voz é de 98 x 50 x 
8=39.200 bits por segundo. 
Pode ser observado que a relação entre os bytes 
de serviço (do payload) e os bytes de controle (header) é 
mais eficiente no caso do uso do codificador G.711. 
Porém, ainda com a ineficiência da relação, o uso 
do codificador G.729 gera uma taxa de bits muito menor 
que o uso do codificador G.711.
Não deve deixar de ser considerado que o uso do 
codificador G.729 pode introduzir maior retardo de 
encapsulamento que o uso do codificador G.711.
Ou seja, há um compromisso entre taxa de bits de 
operação e retardo de encapsulamento (codificação e 
decodificação).
Compressão dos cabeçalhos IP/UDP/RTP
No caso dos enlaces PPP, a compressão dos 
cabeçalhos IP/UDP/RTP em um pacote cRTP pode 
reduzir com eficiência a requisição de banda, pois os 
cabeçalhos deixam de ocupar 40 bytes para ocupar 
somente 2 (sem checksum) ou 4(com checksum).
O uso do cRTP em links PPP de grande atraso e 
altas taxas de perdas foi especificado na RFC 3545, 
de 2003 (Enhanced Comprested RTP (CRTP) for 
Links w ith High Delay, Packet Loss and Reordering).
Embora não seja comum ainda, o uso do cRTP 
será difundido nas redes móveis 3G.
O cRTP está descrito na RFC 2508, de 1999 
(Compressing IP/ UDP/ RTP Headers for Low -Speed 
Serial Links).
Compressão e enfileiramento dos pacotes RTP
- Processo de enfileiramento dos pacotes cRTP: a 
entrada na fila é anterior a compressão. O dispositivo 
determina quais pacotes são RTP, e encaminha para a 
compressão. A seguir, todos os pacotes passam para 
a interface de saída.
Taxa necessária para encapsular fluxos de voz em 
frames PPP (interface WAN)
Quando a camada de enlace utiliza PPP como 
protocolo, as taxas necessárias devem considerar o 
cabeçalho de 6 octetos, totalizando (para CODEC G.729a):
• Carga=8000/50 = 160 bits (20 octetos)
• Cabeçalhos RTP/UDP/IP = 40 octetos
• Cabeçalho PPP = 6 octetos
Total = 66 octetos
Essa carga deve ser enviada 50 vezes por segundo, 
totalizando 50 x 8 x 66=26.400 bps (26.4 Kbps).
Pode-se perceber que a taxa fica como a calculada 
por sobre ethernet, que precisa de 27.2 Kbps.
Exercícios
1) Qual é a taxa de operação de um canal de VoIP com um 
codificador G.711 sobre PPP com os pacotes sendo 
gerados a cada 30ms?
2) Na situação da questão anterior, o que é mais eficiente 
em termos de relação header/payload,pacotes gerados a 
20ms ou a 30ms?
3) Na mesma situação da primeira questão, qual é a 
desvantagem de se usar pacotes sendo gerados a cada 
30ms?
4) Supondo um enlace PPP de 1152 kbps, transportando 
1 canal de vídeo a 384kbps e que apenas 50% da taxa 
total é usada para serviços em tempo real (voz e vídeo), 
quantos canais de voz codificados a G.729 podem ser 
transportados no enlace?
5) Nas mesmas condições da questão anterior, se for 
usada a cRTP, quantos canais poderão ser transportados?
Largura de banda do sinal de vídeo 
não comprimido
O padrão digital mais difundido para sinais de 
TV de resolução convencional é o CCIR-601. A taxa 
de bits correspondente para este padrão é de:
(13,5 x 8) + (2 x 6,75 x 8) M bit/s = 216 M bit/s. 
• Usando: 
 Codificação em 8 bits
 Taxa de amostragem de luminância 13,5MHz
 Taxa de amostragem de crominância de 
6,75MHz (metade da taxa de luminância)
A taxa do sinal digital de TV colorida
A taxa do sinal digital de TV colorida (expressa 
em bps), composto de um sinal de luminância e de 
dois sinais de crominância, pode ser representada 
pela seguinte equação:
T = (taxa de amostragem de luminância + 2 x taxa 
de amostragem de crominância) x log2 2 K
, onde k é o número de bits em que os sinais são 
codificados.
A taxa do sinal digital de TV colorida -
Exemplo:
Considere um sinal digital de TV colorida composto de 
um sinal de luminância e de dois sinais de crominância. O sinal 
de crominância é amostrado com taxa de 10MHz. Cada um 
dos dois sinais de luminância é amostrado com taxa de 5MHz. 
Cada um dos sinais de luminância e de crominância são 
codificados com 10 bits. Qual a taxa do sinal digital de TV 
colorida?
A) 100 Mbps.
B) 125 Mbps.
C) 150 Mbps.
D) 175 Mbps.
E) 250 Mbps.
Para HDTV, a taxa atinge cerca de 1 Gbit/s 
(codificação em 10 bits).
Esta taxa é compatível com transmissão via 
cabo coaxial a curtas distâncias, como ocorre na 
maioria dos estúdios de produção digital. No entanto, 
é inviável para radiodifusão, cujo canal é de 6 MHz.
The total bit-rate resulting from this process is
13,5×8+2×6,75×8 = 216 Mb/s. With a quantization 
of 10 bits, the bit-rate becomes 270 Mb/s!
However, if one takes into account the 
redundancy involved in digitizing the inactive part of 
the video signal (horizontal and vertical blanking 
periods), the useful bit-rate goes down to 166 Mb/s 
with 8 bits per sample.
These horizontal and vertical blanking periods 
can be filled with other useful data, such as digital 
sound, sync, and other information.
Largura de banda do sinal de vídeo comprimido
Quadros com conteúdo multimídia MPEG
O padrão MPEG-2 contempla a transmissão 
através de canais sujeitos a erros; para isso, define 
um Fluxo de Transporte na forma de Pacotes 
Elementares (PES - Packetized Elementary Stream) de 
comprimento fixo, igual a 188 bytes.
Os PES carregam fragmentos de áudio, vídeo 
ou dados, possuindo um cabeçalho (figura) que traz 
informações de sincronismo e criptografia, além de 
um campo de identificação de programa (PID).
Packetized Elementary Streams (PES)
Transport Stream (TS)
Exemplo de cálculo de banda para um 
stream de vídeo de saída do H.264
Calculating the amount of actual bandwidth 
consumed by an MPEG stream is very important. It is also 
somewhat tricky. Let’s look at how one manufacturer 
(HaiVision Systems of Montreal, Quebec) does this
for one H.264 product (the hai200 TASMAN video encoder).
As in most MPEG devices, the hai200 user is given 
control over the rate of the raw MPEG stream. For this 
device, the video bit rate can be set anywhere from 150 
kbps to 2 Mbps. The user can also set the audio stream 
rates over a range from 64 kbps to 256 kbps. For the 
purposes of our example, we will use a video bandwidth 
of 2 Mbps and an audio bandwidth of 128 kbps.
CALCULATING NETWORK BANDWIDTH
Since we are going to be transporting these raw 
streams over a network, the first thing we want to do is 
convert the raw MPEG streams (in MPEG-2 these are known 
as elementary streams, in H.264 these are known as NAL units)
into a transport stream (TS).
Since fractional TS packets aren’t allowed, so each 
video frame will occupy 46 TS packets and each audio 
frame will occupy 2 TS packets. For audio, this adds 9.3 
percent overhead to the raw bandwidth and for video 3.8 
percent is added. So our original audio stream is nowa 
140-kbps TS, and our video TS nowoccupies 2.076 
Mbps.Wealso need to add 46.5 kbps to these streams to 
provide room for the PMT and the PCR (program map table 
and program clock reference).
The next step is to calculate the IP and Ethernet 
overhead. Since the hai200 TASMAN uses RTP over UDP, 
we must allow for a 12-byte RTP header and an 8-byte 
UDP header. Then we must add a 20-byte IP header and a
26-byte Ethernet header,2 bringing the total of all the 
headers to 66 bytes.
We can accommodate anywhere from two to seven 
TS packets (which are always 188 bytes long) in each Ethernet 
frame. For our example, let’s use seven TS packets (or 
1316 bytes) per Ethernet frame, because this gives us the 
highest ratio of data to headers. With 66 bytes of header 
for 1316 bytes of data, we have an overhead of 
approximately 5 percent. So our total bandwidth for both 
the audio and video streams comes out to 2.376 Mbps. 
This calculates to 11.6 percent overhead on the original 
rawstreams (2 Mbps plus 128 kbps). In terms of packets, 
this equates to roughly 215 packets per second.
Unid. III.3
Banda Ocupada para o Transporte de 
Voz e Vídeo em uma Rede IP
Banda ocupada em função da aplicação
Largura de banda de vídeo
Como já foi mencionado, o tipo de compactação de 
vídeo usado é um dos fatores que afetam o espaço de 
armazenamento necessário. 
O formato de compactação H.264 é de longe a 
técnica mais eficiente de compactação de vídeo disponível 
hoje em dia. 
Sem comprometer a qualidade de imagem, um 
codificador H.264 pode reduzir o tamanho de um arquivo 
de vídeo digital em até 50% mais do que o padrão MPEG-
4. 
Isso significa que serão necessários muito menos 
largura de banda de rede e espaço de armazenamento 
para um arquivo de vídeo H.264.
Como diversas variáveis (movimentação 
nas cenas) afetam os níveis médios de taxa de 
bits, os cálculos não são tão diretos para os 
formatos H.264 e MPEG-4. 
Os números são baseados em muita 
movimentação em uma cena. Se houver 
menos mudanças em uma cena, os números 
podem ser 20% menores.
Windows Media and VC-1
Obrigado pela atenção !
	Unidade III��Cálculo da banda de voz e vídeo em uma rede IP
	Número do slide 2
	Número do slide 3
	Número do slide 4
	Unid. III.2��Tamanho dos cabeçalhos RTP, UDP e IP e quadros da camada 2
	• These protocol header assumptions are used for the�calculations:�� 40 bytes for IP (20 bytes) / User Datagram Protocol (UDP) (8 bytes) / Real-Time Transport Protocol (RTP) (12 bytes)�headers.�� Compressed Real-Time Protocol (cRTP) reduces the�IP/UDP/RTP headers to 2 or 4bytes (cRTP is not available�over Ethernet).
	• These protocol header assumptions are used for the�calculations:�� 6 bytes for Multilink Point-to-Point Protocol (MP) or Frame Relay Forum (FRF).12 Layer 2 (L2) header.�� 1 byte for the end-of-frame flag on MP and Frame Relay�frames.�� 18 bytes for Ethernet L2 headers, including 4 bytes of Frame Check Sequence (FCS) or Cyclic Redundancy Check (CRC).
	 Fórmula para se calcular a banda utilizada por uma chamada de voz:��	Banda utilizada (bits por segundo) = tamanho pacote voz (bits por pacotes) x Taxa de pacotes por segundo (pacotes por segundo ou PPS), onde:��- Taxa de pacotes por segundo= Taxa do�CODEC utilizado / tamanho amostra de voz�
	Número do slide 9
	Número do slide 10
	Número do slide 11
	Número do slide 12
	Número do slide13
	Número do slide 14
	Número do slide 15
	Quadros com conteúdo de voz
	Número do slide 17
	Número do slide 18
	Taxa necessária para encapsular fluxos de voz em frames ethernet/fast-ethernet (nas interfaces LAN)
	Número do slide 20
	Número do slide 21
	Compressão dos cabeçalhos IP/UDP/RTP
	Número do slide 23
	Compressão e enfileiramento dos pacotes RTP
	Taxa necessária para encapsular fluxos de voz em frames PPP (interface WAN)
	Número do slide 26
	Número do slide 29
	Número do slide 30
	Número do slide 31
	Número do slide 32
	Número do slide 33
	Largura de banda do sinal de vídeo comprimido�Quadros com conteúdo multimídia MPEG
	Número do slide 35
	Packetized Elementary Streams (PES)
	Exemplo de cálculo de banda para um stream de vídeo de saída do H.264
	Número do slide 38
	Número do slide 39
	Número do slide 40
	Unid. III.3��Banda Ocupada para o Transporte de Voz e Vídeo em uma Rede IP
	Banda ocupada em função da aplicação
	Largura de banda de vídeo
	Número do slide 44
	Windows Media and VC-1
	Obrigado pela atenção !