The 802.11 standard has cometo be somewhat of an “umbrella protocol” due to the numerousenhancements (e, g, h, k, etc.) that have been ratified (or are beingdiscussed) to improve the base standard, which was ratified in 1997.
Given this situation, it is very difficult to determine what kind of802.11 deployment is being discussed when someone uses the generic termof WLAN or VoWLAN. (LAN here meansstrictlyLAN. VLANs are notincluded in this definition. In fact, VLANs are one of the primaryusers of Layer-2 qualityof service (QoS) mechanisms. )
Voice over IP (VoIP) comes inmany flavors. At a high level, we can distinguish between these flavorsby considering where in the overall architecture voice transitions fromthe PSTN to the IP network. At one extreme is the traditional PSTN model, where one blackphonecalls another black one and the voice call is established entirelyusing the PSTN. There is no IP and hence no VoIP in this scenario.
At the other end of the extreme is the end-to-end VoIP model wherean IP “phone” (which may be a soft-phone application running on a PC oran actual physical entity) calls another IP phone without the voicecall ever transitioning to the PSTN. Somewhere in the middle of thesetwo extremes lies the concept of gateways, which connect the IP worldto the PSTN.
Note how the discussion of VoIP is restricted to the wired domain.Sure, it is possible to install a media gateway that carries callsfrom/to wireless cellularsubscribers over an IP network, and it is also possible to use cordlessphone technology in VoIP architectures, but the VoIP end-device itselfis restricted to being a wired device.
In other words, IP phones (soft or hard) are always wired devices.This limited deployment of VoIP in “mobile” scenarios. This is whereVoWLAN comes in. The wide-scale deployment of 802.11 networks meansthat it is now possible to implement a VoIP solution over a WLANinstead of a wired LAN like Ethernetand VoIP can, for the first time become a wireless solution.
At the face of it, the solution of running VoIP implementations over802.11 instead of 802.3 (Ethernet) seems like a simple proposition. After all, one of theprimary design criterion for the OSI-layered architecture was tominimize the interdependence between layers. Arguably, since VoIP isimplemented at Layer 3 andabove, a change in the layer-2protocol should be trivial.
However, this is far from the case. At the outset, let us realizethat the 802.11 standard was designed primarily for data communication.However, voice communication is inherently very different from datacommunication. Unlike data, voice traffic is characterized by smallpackets transmitted periodically and symmetrically in both directions.
Voice traffic also has its own constraints in that it is extremelysensitive to delay and jitter. Furthermore, the quality of a voice callis also dependent on the packet-loss characteristics: while smalllosses can be tolerated, large gaps (bursty packet losses) will causeserious degradation in voice quality. To use 802.11 for voicecommunication therefore poses some major challenges..
5.3 System Capacity and QoS
This section deals with system capacity and quality of service (QoS)issues inVoWLAN. We start with system capacity. Defining system capacity is atricky issue. It is often described in terms of channel bandwidth(Mbps). However,this can be a misleading parameter.
Here, we just want to emphasize that, for VoWLAN systems, thesimplest and most useful definition of system capacity would simply bethe number of simultaneous voice calls that can exist in a BSS (basic service set).This is the definition we use.
Even though it may not be clear at first why the topics of systemcapacity and QoS are clubbed together, a little analysis will revealthat these two topics are inherently linked together. In VoIP, the termQoS is usually used to refer to the real-time requirements (low delay,low jitter and loss-characteristics, etc.) of voice, video and soforth. The basic approach to achieving QoS is to “mark” real-timepackets so they get prioritized access to network resources likebandwidth.
This may or may not involve reserving resources in the network forreal-time traffic. However, the basic philosophy is that, since networkresources are limited, real-time traffic should have prioritized accessto it. Note that if there are “enough” network resources available forall traffic, there is no need to prioritize real-time traffic.
Hence, the concept of system capacity and QoS are inherently linked.If we have enough system capacity, there is no need for QoS mechanisms.This is, for example, the case when making VoIP calls within a LAN1that uses 100 Mbps or Gigabit Ethernet. This is one of the reasons whyQoS has traditionally been a Layer-3 (or above) issue in VoIP.
Another reason for treating QoS in the higher layers is because mostVoIP implementations simply treat the IP network as a “cloud” withoutany information about the underlying link layer, since the VoIPendpoints do not know about what happens (for example, what Layer 2technology is used) in the cloud.
This is not to say that VoIP implementations never use Layer-2 QoS.There are scenarios where VoIP endpoints are aware of the Layer-2technology being used and Layer-2 bandwidth is at a premium.
In such scenarios (VoCable,for example) Layer-2 QoS (DOCSIS inVoCable) has been used in VoIP deployments. Since in VoIP over WLAN wealso know the characteristic of the underlying link layer, QoS becomesrelevant at Layer 2. The following subsections discuss why systemcapacity and QoS are important issues in VoWLAN.
5.3.1 Packet Sizes.
Given that the bandwidth requirement of a VoIP stream can be minimizedto about 10 kbps (e.g., through the use of a high-compression codecsuch as those discussed in Chapter 3), an 802.11b WLAN could, inprinciple, support hundreds of VoIP sessions. In reality, no more thana handful of sessions can be supported by an 802.11b WLAN due tovarious overheads.
|Figure5.1 Throughput Vs Packet Size|
As Figure 5.1 above shows,the effective throughput in an 802.11b network has a large dependencyon the payload size that is used. Even though this is not an issue fordata applications (since they will most likely use large payloadsizes), this does not bode well for VoWLAN where the packet size needsto be kept short to minimize end-to-end delay.
VoIP (and hence VoWLAN) uses packetization periods of the order of10″40 ms leading to payload sizes of the order of 100″300 bytes. As isclear from Figure 5.1 , thislimits the effective bandwidth available for VoWLAN to about 1″2 Mbpsin a BSS.
Realize also from Figure 5.1 that using higher transmission rates helps improve system capacity, butthis increase in system capacity is most significant at higher payloadsizes and the gain at lower payloads is comparatively small.Applications like VoWLAN, which use small payloads, see only a smallincrease in system bandwidth since they lie in the bottom left cornerof the graph.
To understand why the system capacity is a factor of the payloadsize, realize that the 802.11 MAC does not take into account the transmission time (for which the stationwould use the media once it captures it) when competing for mediaaccess. Instead, it concentrates only on making the number oftransmission opportunities fair among stations.
In other words, the MAC protocol ensures that, once a station getsaccess to the media and finishes its transmission, it must againcompete with other stations to transmit its next packet.
However, the MAC does not take into account how long the stationwould stay on the media once it gets access to it. So, once a stationgets access to the channel, it may transmit a packet with a payload of10 bytes or a payload of 2300 bytes; this difference is not taken intoaccount when stations compete for access to the media.
In effect, a station that transmits 2300-byte payloads on gettingaccess to the media can pump much more data through the network than astation that transmits only 10 bytes of payload when it finally gainsaccess to the media. Therefore, in VoWLAN systems, stations that usesmall payload sizes must spend a considerable amount of time backingoff in the MAC protocol to avoid collisions, and this leads to limitedsystem capacity.
5.3.2 Packetization Overheads
Another reason for the limited capacity of VoWLAN is the packet headeroverhead that is added as the short VoIP packets traverse the variouslayers of the standard protocol stack. The payload of a voice packetwith a 10-ms packetization period, as generated by the voice codec,ranges from 10 to 80 bytes, depending on the codec used. This voicepayload then passes down the stack via the RTP , UDP and IP layers.
These three layers add headers of a total size of 40 bytes. Next,the IP layer hands over this packet to the 802.11 MAC protocol, whichadds a header of 34 bytes. Note that, at this stage, the total packetsize (assuming a 30-byte voice payload) is 104 bytes, out of which only30 bytes is the actual voice payload. That is an efficiency of lessthan 30%.
Next, when the packet is handed over to the 802.11b PHY layer, aPLCP header and a PLCP preamble are added to it. Eventhough the size of these together is 15 bytes (short preamble) or 24bytes (long preamble), the PHY overhead is significantly large sincethe transmission rate is limited to 1 or 2 Mbps.
|Figure5.2. PHY headers for 802.11b|
Assuming that the rest of the packet gets transmitted at the maximum802.11b rate of 11 Mbps, this means that it takes 96 microseconds(short preamble) or 192 microseconds (long preamble) just to transmitthe PHY layer overheads. From a VoWLAN perspective, this means that totransmit 22 microseconds (30 bytes) of voice payload, it takes a totaltime of 172 µs (short preamble) or 268 microseconds (longpreamble). That is an efficiency of about 9 to 13%, which means we arealready down from 500 VoWLAN sessions to about 50 VoWLAN sessions in aBSS.
5.3.3 DCF Overheads
In order to protect against nodes hogging the channel once they getaccess to it, the 802.11 MAC data count field (DCF) requires that astation must wait between consecutive packet transmissions.
This waiting period allows other stations to compete for channelaccess if needed and thus ensures that a station does not hog thechannel once it gets access to it. However, this waiting period alsomeans additional overheads. Let us calculate the time it takes totransmit a voice packet using DCF (Figure5.3 below ).
|Figure5.3 DCF Timing|
From Figure 5.2 earlier ,the total time it takes to transmit a voicepacket can be calculated as:
Pkt_TxTime= DIFS + BO + PHY_TxTime + MAC_TxTime + Payload_TxTime + SIFS +ACK_TxTime.
For 802.11b, even in the best-case scenario (short preamble, maximumtransmission rate, an aggressive BO time and a 30-byte payload packet),we have:
DIFS =50 µs
BO = Slot Time * CWavg = 20 * 31/2 =310 µs assuming CWavg = (CWmin “1)/2
PHY_TxTime = 96 µs assumingshort preamble
MAC_TxTime = 34 * 8/11=25 µsassuming the maximum
Payload_TxTime = 70 * 8/11=51 uSecwhere “payload” includes RTP, UDP and IP headers
SIFS = 10 µs
ACK_TxTime = PHY_TxTime + (34 * 8/11)+ (14*8/11) = 131 µs since the 14-byte ACK also comes with 802.11MAC and PHY headers.
Therefore Pkt_TxTime = 673 µs
Continuing our calculations of the number of simultaneous voicecalls in a BSS from section 5.3.2, from a VoWLAN perspective this meansthat to transmit 22 µs (30 bytes) of voice payload, it takes atotal time of 673 µs, which reduces the efficiency to 3%.
Note the effect of ACKing each packet. The 802.11 MAC requires eachdata packet to be explicitly acknowledged (ACKed) to cope withoperating in the (hostile) wireless environment. ACKing each packetalso reduces the system capacity significantly.
5.3.4 Transmission Rate
Note that section 5.2.2 is a best-case estimate given the assumptionswe made. For example, we assumed the transmission rate to be 11 Mbpsbut we know that the transmission rate used is often a factor ofchannel conditions (which is also a factor of distance between thecommunicating stations).
Transmitting at lower data rates would means that the transmissiontime for each packet increases and the system is occupied for moretime, thus reducing system capacity even further for VoWLAN.
|Figure5.4. System capacity versus range|
Figure 5.4 above uses a verysimple radio channel model to illustrate the effect of transmissionrate on system capacity in VoWLAN. We know that the strength of thesignal decreases as the distance between the communication stationsincreases.
In Figure 5.3 earlier ,with the AP at the center of the figure, assuming a constant noisefloor, the received signal strength (and hence the SNR) decreases as wemove away from the AP. Therefore, the “optimum” transmission ratedecreases as we move away from the AP.
With a decrease in the transmission rate, the number of voice callsthat can be supported also decreases as we move away from the AP. Notethat Figure 5.3 is not drawn to scale and is for illustration purposesonly.
Transmitting at higher data rates means that the transmission timefor each packet decreases and the medium is freed up for use for morepackets, thus increasing system capacity.
However, transmitting at higher data rates means using more complexmodulation schemes, which are more susceptible to channel noise.Therefore, using higher data rates in adverse channel conditions (highchannel noise -i.e., lower SNR) can actually lead to higher BER – i.e.,higher packet loss, which may require more retransmissions and thuseffectively reduce system capacity.
The goal, therefore, is to dynamically adjust the transmission rate.The concept of rate adaptation is to select the appropriatetransmission rate based on channel conditions and performance. Therate-adaptation algorithm is not specified in the 802.11 standards andthis is expected to be one of the product differentiators among variousvendors.
It is important to realize that a rate-adaptation algorithmoptimizedfor data may not yield thebest results for real-time applications like voice. The primary reasonfor this is that voice is extremely sensitive to delay and jitter. Weshall see how this affects the rate-adaptation algorithms.
In order to decide which rate is optimal at any specific moment, therate-adaptation algorithm needs information about the current linkconditions. Since it is difficult to get this information directly,most algorithms use some form of statistics-based feedback.
The statistic most often used in such feedback schemes is theuser-level throughput. This means that these algorithms aim to maximizethe application-layer throughput.
To achieve this, typical 802.11 rate-adaptation algorithms are”aggressive” in attempting to switch to a higher PHY data rate, theunderlying theory being that if packet error rate increases at higherdata rates, the 802.11 algorithm will cope with such drop-outs by usingframe retransmissions.
This approach works fine for data communication since the extra (andvariable) delay introduced by this retransmission-dependent approach isacceptable to data applications. However, this increase in (average)packet delay and jitter (due to variations in the number ofretransmissions) can cause serious degradation for voice communication.
Consequently, rate-adaptation algorithms optimized for datacommunication often perform poorly for VoWLAN (Here, VoWLAN refersto WLAN using the infrastructure BSS. ).
Realize also that there will be times in an 802.11 network wheretemporary network conditions will prevent the successful transmissionof a packet under any rate adaptation. For example, the STA may havemoved into an RF blind spot, or near a jamming device such as amicrowave oven.
In these cases, a voice-friendly rate-adaptation algorithm wouldwant to give up on the current voice packet instead of delaying theentire voice packet stream trying to get the current voice packetthrough.
Since VoIP packet-loss concealment algorithms can hide the loss ofone or two packets but cannot mask a large drop-out, there is no pointin taking pains to deliver a voice packet if it is so late that thereceiver jitter buffer has underflowed. Again, the rate-adaptationalgorithms are expected to be another product differentiator amongvendors.
Next in Part 2: Inherent FairnessAmong All Nodes
Used with the permission of the publisher,Newnes/Elsevier, this two part series is based on material from “Wi-FiTelephony: Challenges and Solutions for Voice over WLANs,” byPraphul Chandra and David Lide.
PraphulChandra is currenty senior research scientist at HP Labs, India, which focuseson “technological innovation for emergining countries.” David Lide iscurrently a senior member of the Technical Staff at Texas Instruments, Inc., and has workedon various aspects of Voice Over IP for the past eight years.