|
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. |
