How Wireless LANs Handle Video

First and foremost, the advent of 802.11n technology has significantly improved the handling of video over WLAN. 802.11n supports many inherent enhancements in the PHY and MAC layers resulting in higher throughput and overall reliability of wireless transmissions and is ideally suited for handling video applications.

In addition, 802.11e defines the QoS enhancements for multimedia applications. One of the QoS schemes introduced by 802.11e – Enhanced DCF Channel Access (EDCA) (which the Wi-Fi Alliance calls WMM, or Wireless Multi Media) defines four “access categories” of traffic to which prioritization levels can be assigned: Background, Best Effort, Video and Voice. This enables latency-sensitive voice and video traffic to be prioritized over other traffic in the network. EDCA/WMM basically allows for the tuning of minimum and maximum backoff slots for each stream of traffic – thus creating an advantage for a packet marked with higher priority.

Mapping wired side Layer 2 (802.1p) or Layer 3 (Differentiated Services Code Point, or DSCP) traffic priorities to the video access category enables an end-to-end prioritization.

802.11n together with EDCA/WMM QoS enhancements certainly improve the handling of video but by themselves are not sufficient to guarantee reliable delivery under dynamic and heavily loaded RF conditions. Deploying video over wireless requires several network enhancements.

EDCA/WMM, since it is based on a shared access/fairness model, cannot guarantee that low-priority traffic will not be transmitted. It cannot guarantee bandwidth, latency and jitter required for acceptable video performance. It works well in the case where the network is not heavily loaded. It also relies on the wireless client devices and access points to control access to the medium and prioritization.

Some of these limitations can be overcome by implementing admission control mechanisms. The basic idea behind admission control is to limit the number of streams within an access category to preserve bandwidth, limit the latency and protect voice/video streams already in play.

The WMM Transmit Specification (TSPEC) standard specifies a means for the client devices in the network to request bandwidth and priority. The process is for the AP to advertise in the beacon if admission control is mandatory for a particular access category and for the client device and AP to negotiate a TSPEC that basically results in the client getting a TXOP (Transmit Opportunity). The TXOP specifies how long the client device can use the medium without contention. This negotiation helps the client to determine if the AP can provide the required bandwidth.

Motorola WLANs allow the tuning of the WMM backoff parameters to better optimize them for video transmissions.

Motorola also enables bandwidth limits to be placed on specific application traffic to facilitate the coexistence of all applications and to allow enough bandwidth for video.

Multicast video is generally more problematic to handle over wireless LANs, because there is no acknowledgment of packets. This leads to some level of packet loss. Given that, the multicast traffic has to be sent at lower data rates compared to unicast traffic. In general, then, it is desirable to use unicast where possible.

For enterprises wishing to use multicast, Motorola offers enhancements to multicast video that include the following:

• Tuning of Multicast Transmit Speed: Administrator can choose between four policies that determine the multicast transmit speed:
o Lowest basic rate
o Highest basic rate
o Dynamic basic rate: we look at the rate at which unicast frames were sent successfully to all clients associated to a BSSID [basic service set identifier] and choose the rate that would work for all. This is usually higher than the lowest basic rate and is very often equal to the highest basic rate.
o Dynamic rate: same algorithm as above except the range of transmit rates is limited to legacy Wi-Fi connect rates (up to 54Mbps)

• IGMP snooping – This is used to decongest the RF environment by not sending multicast streams that do not have receivers.

• Multicast-to-unicast conversion – Converting incoming multicast streams to unicast for the clients interested in a given stream solves the problem of unreliability of multicast streams in WLANs. This works in conjunction with IGMP snooping.

• Multicast mask configuration – WLAN administrators can configure multicast mask settings so that multicast streams travel over the air without any buffering, thereby removing the delay in multicast stream delivery inherent in WLAN world.

Broadly speaking there are two categories of video: interactive video (like video conferencing) and streaming video. These two types have different latency tolerance levels.

For interactive video such as telepresence, latency is of high importance. WMM sets a 64msec end to end delay. Anything beyond this would degrade the video performance.

For streaming video, latency is of relatively less importance, as the receiver has a buffer and can compensate for late-arriving packets. A delay of 200msec end to end is considered OK in the case of streaming video. It is more important that packets do not get lost. But streamed video still needs a QoS advantage over other background and best-effort network traffic. Streaming video might also contain higher resolution video than video conferencing, and thus might require higher bandwidth.

Motorola distinguishes between these two types of videos and treats them differently. For example, interactive video frames are prioritized over streaming video; the rate adaptation is more aggressive to ensure that a frame goes through soon, but there are fewer retries, because frames that are delivered late are useless.

The key to handling video over wireless is to understand that besides being sensitive to latency, video consumes a lot of bandwidth. Also note that it is better to use unicast as opposed to multicast.

The following are some of the best practices for running video over WiFi networks:

• With regards to bandwidth, it is preferable to use the 5 GHz band with channel bonding especially for handling High Definition (HD) video streams. Using 5 GHz is preferred even with SD video for supporting a high-density deployment, as well.

• It is always advisable to use a planning tool to determine the number and location of APs needed to handle the required bandwidth that the video applications demand.

• Use QoS mechanisms to prioritize voice and video traffic over other traffic in the network. The use of WMM Unscheduled APSD (Auto Power Save Delivery) is recommended to save battery life.

• Map wired side Layer 2 (802.1p) or Layer 3 (DSCP) traffic priorities to the video access category to enable an end-to-end prioritization.

• If the incoming video stream is bursty in nature and if the stream overshoots the reserved bandwidth, there would be a random packet drop. In the case of HD video streams with average bit rates of 20Mbps, bursts may be as high as 10Mbps. So it is essential that the bandwidth reserved using WMM TSPEC be sufficiently high to accommodate these bursts and avoid random packet drops that degrade video.

Useful tools for deploying video applications in enterprises include:

• A comprehensive planning tool that takes into account the floor plan layout, building material characteristics and the physics of 802.11n WLAN. Such tools provide valuable information on the number – and optimal locations – of Wi-Fi APs required to optimally support video applications.

• Centralized visibility into comprehensive, real-time RF network conditions

• Tools to remotely or automatically troubleshoot network connectivity issues

The knowledge of codecs and video formats is useful in wireless network planning. The encoding determines the required bandwidth; some video formats such as YouTube-style video require 1 to 2Mbps, for example, while HDTV with MPEG2 could require up to 20Mbps.

For example it is possible to use “selective packet forward” (SPF) Application Layer Gateway (ALG) on MPEG2Ts encoded streams having constant bit-rate in a densely populated WLAN environment. In this scheme (for which Motorola holds an IP), non-critical video frames such as B frames or P frames of MPEG2TS stream can be selectively dropped to reduce required bandwidth without affecting the output video quality.

In a dense WLAN environment such as classroom receiving a constant bit-rate multicast video stream (a lecture) as unicast streams to all the students, the SPF scheme can help increase the total number of unicast streams supported.

It should be noted that real-time video conferencing / video surveillance etc., are controlled essentially by another device, and the role of the WLAN AP is limited to delivering the video content over the WLAN. From the WLAN point of view, sufficient bandwidth must be available, and if the input video is multicast, it should be converted to unicast.

The same video stream could be delivered to various types of recipients such as desktops, HDTVs, smartphones, tablet PCs, etc., each having different capacity and capabilities. The HDTVs may be capable of receiving high-definition MPEG4 (H.264) encoded streams while the handheld may be capable of decoding MPEG2 streams. The network administrator should know the format of the video source (such as MPEG2, MPEG4 etc), the stream rate and expected bursts in the stream. The administrator should also know what types of clients would be receiving the stream and the codec supported by each of the clients so that source transcoding can be done if required.

At Motorola, we have a comprehensive test bed that includes the latest generation of smartphones (Android based phones, iPhone, etc.) and tablets (iPads, Xoom, etc.) test for video performance - for both real time and non-real time video applications. All these devices can take advantage of the Motorola specific optimizations mentioned.

Good question.

First of all it should be noted that if the laptops have 802.11n
capabilities, then they will automatically support WMM.

Secondly even if WMM is enabled, the packets may not get put in the
priority queue because they may not be marked with DSCP or 802.1p tags.
In that case we can do the following with Motorola's solution:

Option 1:

Use firewall rules to inspect the packets and assign the appropriate
packet marking rule if there is a match. The firewall rule can be used
to inspect traffic based on IP address, protocol or port number. If packets
are coming from YouTube we can either modify the 802.1p VLAN user
priority or the DSCP type of service (TOS) bits in the IP header. This way the YouTube traffic can be put in the right video priority queue.

Option 2:

We can force the entire WLAN to be video priority class. In this case
all packets whether it is YouTube or Gmail will go in the video queue
and be handled with the same priority.

Note that in both the cases this is only applicable for downstream
packets. For upstream it is up to the client to do the right thing
(assuming it is WMM capable).