|
|
|
|
|
|
|
|
|
| There are many factors involved when calculating the bandwidth required
through a network. This white paper aims to explain these factors, and to offer a
simple means of making such calculations. It starts with a basic 'rule of thumb',
and then expands this to take specific voice coding algorithms into account. There are
many ways to reduce the bandwidth requirements, and these can be particularly important in
the wide area network. These include silence suppression, RTP header compression
and RTP multiplexing. These methods are not considered in this document.
You can try out the calculations described in this white paper by visiting our free Lines to IP Bandwidth Calculator. It
can be used online, now. |
|
|
| In our white paper Voice
over IP Protocols for Voice Transmission, we concluded that the standard method
of transporting voice samples through an IP based network required the addition of three
headers; one for each layer. These headers are IP, UDP and RTP. An IPv4 header
is 20 octets; a UDP header is 8 octets and an RTP header is 12 octets. The total length
of this header information is 40 octets (bytes), or 320 bits, and these headers are sent
each time a packet containing voice samples is transmitted. The additional bandwidth
occupied by this header information is determined by the number if packets which are sent
each second. |
|
|
| For the purposes of this document, we define packet frequency as the
number of packets containing voice samples which are sent per second. The packet
frequency is the inverse of the duration in seconds represented by the voice
samples. For example, if the voice samples in one packet represent a duration of 50
milliseconds, then 20 of these samples would be required each second. The packet
frequency would therefore be 20. The selection of this payload duration is a compromise
between bandwidth requirements and quality. Smaller payloads demand higher bandwidth
per channel band, because the header length remains at forty octets. However, if
payloads are increased, the overall delay of the system will increase, and the system will
be more susceptible to the loss of individual packets by the network.
We know of no recommendations concerning packet duration. In RFC1889, the
Internet Engineering Task Force include an example where the duration is 20ms, but they do
not suggest this as a recommended value.
There is no absolute answer to this question, but for the remainder of this document,
we will assume that voice samples representing 20ms are sent in each packet. |
 |
 |
Simple
bandwidth calculation
|
|
|
|
| If one packet carries the voice samples representing 20 milliseconds, the
50 such samples are required to be transmitted in every second. Each sample carries
a IP/UDP/RTP header overhead of 320 bits. Therefore, in each second, 16,000 header
bits are sent. Therefore, as a general rule of thumb, it can be assumed that header
information will add 16kbps to the bandwidth requirement for voice over IP. For
example, if an 8kbps algorithm such as G.729 is used, the total bandwidth required to
transmit each voice channel would be 24kbps. |
|
|
Effects
of coding algorithms
|
|
|
|
| The designer of any network convergence solution that includes voice will need to
decide upon which coding algorithm to use. CODECs perform the conversion
from an analogue voice waveform to a digital stream of information. They sample
the analogue signal at regular intervals (125 microseconds is a typical value), and
convert the measured analogue value into a numeric representation (known as quantising).
The resultant output comprises discreet blocks of information sent at regular intervals. The
method suggested in the previous section offers a simplistic view of the bandwidth
calculation process. It is valid for most coding algorithms, however, it assumes
that voice samples can be transmitted within a 20ms datagram. For coding algorithms
which use much smaller sampling periods, multiple samples can be sent within each packet,
and the samples can be buffered for up to 20ms. However, some algorithms do not
produce samples which can be fitted exactly into 20ms datagrams, and for those algorithms,
the 16kbps rule of thumb becomes invalid.
The following tables shows the relevant characteristics of the most common coding
algorithms.
| Coding algorithm |
Bandwidth |
Sample |
IP bandwidth |
| G.711 |
PCM |
64kbps |
0.125ms |
80kbps |
| G.723.1 |
ACELP |
5.6kbps |
30ms |
16.27kbps |
| MP-MLQ |
6.4kbps |
17.07kbps |
| G.726 |
ADPCM |
32kbps |
0.125ms |
48kbps |
| G.728 |
LD-CELP |
16kbps |
0.625ms |
32kbps |
| G.729(A) |
CS-ACELP |
8kbps |
10ms |
24kbps |
The algorithms listed which do not fit into the 16kbps rule of thumb are the
two G.723.1 systems (highlighted on the table). As their sample duration is 30ms
rather than 20ms, only 33 frames are sent each second. This reduces the header
overhead to 10.66kbps.
Detailed consideration of each coding method is beyond the scope of this document, but
it should be understood that the various coding methods vary in the levels of complexity,
delay characteristics and quality. The CODECs which are expected to become prevalent
within the Voice over IP arena are G.729A and G.723.1. |
|
|
| This document has offered a quick method of calculating the bandwidth
requirement for individual calls being transmitted through an IP network. As a rule
of thumb, it is suggested that 16kbps be added to the compressed voice bandwidth to
calculate the total bandwidth required. This assumes a packet duration of 20
milliseconds. G.723.1 requires special treatment, because its packet duration is
30ms. For a typical 8kbps compression scheme, the overhead is 16kbps (or 200%).
Methods exists, or are being developed, which reduce this overhead. These include
silence suppression, RTP header compression and RTP multiplexing. These will be the
subject of further documents published at this Web site.
You can try out the calculations described in this white paper by visiting our
free Lines to IP Bandwidth Calculator.
It can be used online, now.
Why not try our Voice
over IP Forum? It is an interactive newsgroup which you can use to exchange ideas
about network convergence.
Return
to the technical document index
|
| This document
should not be viewed as a consultative document. It is the readers' responsibility to
ensure that the most appropriate telecommunications strategy is applied to his or her
business. No liability is accepted by the authors for omission or error. |
|
|
|
