| Voice-Over-WLAN
/ Voice-over-IP (VoIP) Bandwidth
Requirements Provisioning Calculator |
|
This is actually
true even if you select the 802.3 standard
for calculations (802.3 is simply provided
as a general purpose reference point for
comparison.) By way of contrast, wireline PDH
and SDH (Telco T1/E1 and SONET fiber) networks
experience very little bit loss and never have
packet collisions. Wired 802.3 Ethernet has
almost no packet corruption and, in a switched
infrastructure, almost never experiences significant
numbers of collisions. 802.11 Wi-Fi, by its
nature, is exposed to a potential for significant
packet corruption by noise and other environmental
RF influences. The definitions in the IEEE
802.11 standards change the transmission
bitrate in response to both function and to
signal quality aspects. The WLAN "hidden node"
problem can increase collisions and packet
corruption when stations that are out of each
other's reception range attempt to transmit
to a third station somewhere in the middle.
As a result, you're going to get calculated
maximum circuit values that apply to the 802.11
Wi-Fi environment and which do not 'convert'
for application in a wired network system.
A codec (compressor / decompressor)
is a module (software or hardware) that uses
a mathematical algorithm to compress, and decompress,
the bit stream that is the digital representation
of the analog sound signal. The various codecs
output the digitized audio at different bitrates.
The digitized output of the codec is carried
in an 802.11 frame containing an IP/UDP and
RTP packet header. Codecs configured to operate
with smaller sample times must send more
IP packets than those configured to operate
with large sample times. More IP packets means
more overhead and a resulting overall greater
bandwidth requirement (all other things being
equal.) On the other hand, large samples introduce
the potential for call quality degradation
when packets are lost (since a larger 'chunk'
of the voice signal is lost when a single
packet carries a long sample time.)
BACK TO TOP OF PAGE
A codec must apply
its compression algorithms on a fixed block
of bits. During each Sample Period this block
of bits is gathered by the codec from the digitizing
(quantizing) hardware. Then (during a period
of processing delay) the bit block is compressed.
This compression delay is in a range of roughly
10ms to as much as 45 ms. Humans begin to become
annoyed when the delay reaches roughly 250
ms. Decompression, by the way, typically takes
roughly 10 ms; it's easier than the compression
phase. It's faster for a
codec to compress a 10ms sample than it is
for a 30ms sample and this fact speaks in favor
of using small sample periods. On the contrary,
however, smaller samples may result in increased
overhead if only one compressed sample is carried
in each IP/UDP/RTP data packet. If this were
the case then using 10ms samples would cause
three times more fixed bandwidth overhead (IP/UDP/RTP
header information) than using 30ms samples.
A codec will construct
a Real Time Protocol (RTP) payload consisting
of one or more compressed samples. If multiple
samples are carried as a single IP/UDP/RTP
payload then the same packet overhead is required
for 3 10ms samples as would be required for
1 30ms sample. Carrying a greater number of
samples as a single RTP payload reduces overhead
and results in a lower bandwidth requirement.
On the contrary, however, when many samples
are carried as a single RTP payload the variable
IP packet delay through the IP network impacts
all samples equally. Hence there is an increased
chance of 'jitter" that will degrade voice
quality. Moreover, the loss of a single IP
packet will result in the loss of the entire
multi-sample payload; again reducing call quality.
Normally VoIP data is the
payload carried by Real Time Protocol (RTP).
RTP is carried on top of IP and UDP resulting
in 40-bytes of fixed header length that is
overhead in every VoIP packet. RFC 2508 specifies
methods whereby the UDP and RTP portion of
the payload header can be compressed into as
little as 5% of its normal length. Since
the UDP/RTP header information is a fixed overhead
in every VoIP packet that's transmitted the
use of cRTP (compressed RTP) can significantly
reduce bandwidth requirements. RFC 2508 specifies
compression to 2-bytes (with no UDP checksum)
and compression to 4-bytes (retaining the UDP
checksum).
BACK
TO TOP OF PAGE
Digitized sound (voice and background
noise), compressed through the codec,
is constantly transmitted across a VoIP connection.
Typical voice conversations can contain
as must as 35% to 50% silence. When Voice
Activity Detection is enabled for a transmitter
fully digitized and compressed RTP data
payloads are only sent when voice
is detected. In the absence of a voice
sound the RTP packet contains a 2-byte
Comfort Noise payload. A Comfort Noise
Generator (CNG) introduces a slight amount
of background "hiss" into the receiver's
phone set. The alternative would be for the
receiver's phone to become completely silent
during periods when the transmitter's VAD detected
silence. Because this is perceived as a "dead
line" by the listener the CNG creates enough
low-level background noise to maintain a psychological
comfort level. When used, VAD reduces the
bandwidth required for the VoIP connection
by as much as 35% or more.
BACK
TO TOP OF PAGE
| Frame Control Field |
2-bytes |
| Duration Field |
2-bytes |
| Receiver Address |
6-bytes |
| Transmitter Address |
6-bytes |
| Service Set ID |
6-bytes |
| Sequence Number |
2-bytes |
| Additional Address |
6-bytes |
| IP (and other) data |
variable length |
| Frame Checksum |
4-bytes |
| Frame Control Field |
2-bytes (Indicates that this
is an ACK frame) |
| Duration Field |
2-bytes |
| Receiver Address |
6-bytes |
| Frame Checksum |
4-bytes |
| Short PLCP Header |
24-bytes |
| 802.11 Packet Header |
30-bytes |
| 802.11 Packet Checksum |
4-bytes |
| InterFrame Gap Time |
Equal to 12-bytes |
| ACK PLCP Header |
24-bytes |
| ACK Packet |
14-bytes |
| |
|
| |
|
BACK
TO TOP OF PAGE
DISCLAIMER:
Information obtained from using this wireless
VoIP Bandwidth Provisioning Calculator is believed
to be accurate. Nonetheless, Connect802 makes
no guarantee that the results will provide
any particular level of accuracy. Results obtained
from using this calculator should be considered
and evaluated as part of a complete VoIP network
system design and should not be relied upon
as a sole source of information.
|
LITERATURE 
