Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > RF/Microwave
?
?
RF/Microwave??

Run VoIP through your wireless LAN (cont)

Posted: 08 Jun 2005 ?? ?Print Version ?Bookmark and Share

Keywords:wi-fi? design basics? phone system? 802.11b? phy?

Continuation

As codecs improve, the job of providing Telco-quality voip service over WLAN becomes easier. There's less motivation to add complex timing and synchronization methods to Wi-Fi just to benefit a codec. However, the VoIP handset still has a problem: it's important to put the Wi-Fi subsystem into sleep mode between VoIP packets. That means the device can't send or receive packets when in this mode. That in turn means the access point (AP) must not transmit downlink VoIP frames to the handset whenever they arrive at the AP. Instead, the AP must know when the handset is in sleep mode and transmit only when the handset is ready.

The need for power-save synchronization makes the all-synchronous network look seductive again. Not to worry. Either the HCCA extension to Wi-Fi or the EDCA extension can be used with emerging power-save signaling methods to achieve the desired goal of synchronizing CBR transfers between an AP and a station without morphing Wi-Fi into a completely synchronous system.

HCCA scenario

Using HCCA polling, once a station is accepted by the AP as a polled client (using protocol handshakes not described here), the station in normal operation sleeps until the expected arrival time for a downlink poll or poll-plus-VoIP frame from the AP (Fig. 1). The station immediately responds in the mandatory time (9 ?s) with uplink VoIP data (or a QoS-NULL) frame. The AP will respond with an ACK if the station sent uplink data.

1. HCCA polling is illustrated is this view of high-level timing.

The station must come out of sleep mode before the expected downlink poll from the AP. This occupies 0.1ms to 1ms depending on the hardware design. Then there will be some waiting time until the downlink poll arrives. The poll can be delayed by many factors, including interference, a long duration frame on the channel, an internal schedule conflict within the AP (polling another station), a higher-priority operation (AP must transmit a Beacon), the previous frame exchange took longer than expected, or relative clock drift between the AP and the STA. All these factors will right-shift the schedule. Once the downlink poll arrives, things are predictable. The uplink/downlink frame exchanges should occur in less than 1ms, depending on the choice of codec and PHY rate. The main sources of timing uncertainty are from a right-shift of the schedule, possible retries after failure, and variable transmission times if variable PHY rates are used. This leads to a high-level estimate of 15ms to 18ms for sleep time for a 20ms codec period, or an efficiency factor of 75 percent or better.

Some subtle effects that should be mentioned: the CBR schedule, and the effects of variable PHY rates, non-uniform codec intervals, and packet arrival bursts (bunching) and retransmissions. The CBR schedule is communicated from AP to station when the CBR request is accepted by the AP (via a TSPEC request). It's generally accepted that the average cellular call duration is about 100 seconds. If the AP is provisioned for 20 active calls, we can expect a call setup/teardown every 5 seconds. If we weren't worried about synchronizing the AP polling schedule with the STA, then there would be no effect on the polling schedule. However, the AP must maintain the advertised schedule with each station even though stations will be frequently entering and leaving the polling list. This means that the AP designer must maintain a schedule with fixed time slots.

In this context, a slot is a channel time period earmarked for the polled frame exchange sequence with a particular station. But unless all uplink and downlink frames are sent at the same PHY rate, taking the exact same amount of channel time, then the slots will have variable duration. That contradicts maintaining the fixed timing relationship needed for effective power-save synchronization.

Some vendors prefer to operate all the stations at a fixed rate (6Mps) to avoid this problem. But, if variable rates are used, then either the schedule must be changed and communicated reliably to each associated stationnot a good idea because of extra overhead and reliability issuesor the AP must transmit something in the unused time of each slot so that non-polled stations won't fill in the dead air with Wi-Fi packets, thus further perturbing the attempt to make a synchronous schedule.

Lastly, suppose that an AP is supporting a mix of handsets using different codec intervals, a likely scenario. In this situation, it may be impossible to construct a polling schedule that doesn't include periodic and frequent timing conflicts between different CBR clients, leading to a right-shift of the schedule.

Other effects that will perturb the ideal HCCA schedule are the occasional need to send more than one downlink VoIP frame to a station. This happens when packets arrive in bunches at the AP because of Internet or routing queuing behavior. When this happens, the AP must transmit multiple downlink frames instead of the usual single frame. This will right-shift the schedule unless every conceptual slot has sufficient extra time budget. The same right-shift happens if there's an uplink retransmission. It's doubtful that the AP designer will reserve extra slot time for every station in every slot. That wastes channel time. Instead, the likely decision is to allow the schedule to shift to the right at the expense of extending the power-on time for each affected downlink station.

next page

previous page





Article Comments - Run VoIP through your wireless LAN (...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top