Enterprise I Can See Clearly Now - arubanetworks.com · Aruba Networks I Can See Clearly Now:...

White Paper |

Peter Thornycroft

EnterpriseI Can See Clearly Now: Bringing Wireless Broadband Video

Into Focus

1 I Can See Clearly Now: Bringing Wireless Broadband Video Into Focus Aruba Networks

1 Introduction

Sending broadband video over wireless LANs (WLANs) used to be a trying experience, with jitter and dropouts marring picture quality, and bandwidth limits restricting the number of available channels. Three developments have transformed the video landscape by making it possible to transmit multiple channels of high-quality video over a multi-use WLAN that is also carrying data and voice.

To begin with, organizations that have already deployed pervasive multi-use WLANs are always on the lookout for ways to leverage this infrastructure in pursuit of cost savings. For example, Aruba’s university customers report that students already have an overwhelming preference for wireless over wired connections, and as a result up to 90% of the network-connected devices in student housing connect using the WLAN. This presents an opportunity to remove much of the wired infrastructure and reduce operating expenses, and to build new facilities with only minimal wired infrastructure and lower capital expenses.

The second development is the fast rise in the installed base of 802.11n-capable access points and clients. 802.11n provides reliable data throughput in the range of 70-170 Mbps, allowing plenty of headroom for bandwidth-hungry video applications: the performance improvement of 802.11n over 802.11a/g has proven to be around 5-7 times for real-world applications, an astonishing leap forward. The increased penetration of 802.11n, along with new video-optimizing features from enterprise WLAN vendors, allows video applications to be configured without the special network tuning that was often required in the past.

The final development is that the technology for video over IP has advanced significantly in recent years, affecting everything from desktop conferencing to TV over IP. The general availability of wideband video servers and H.264 codecs, combined with the improved video processing of end-point devices, means that it is now much easier to economically deploy video applications.

As a term, ‘video’ can refer to any service transporting a moving image, usually with accompanying sound, so it is important to categorize the different forms of video and the differing demands they place upon the network:

• High-bandwidth video vs. low-bandwidth. Small video windows such as YouTube are able to work with quite low bandwidth, a few hundred kbps. TV over IP can require from 1 to 8 Mbps for a high-quality, full-motion, standard-definition (SD) TV window, whereas a high-definition (HD) signal consumes up to 20 Mbps. In Wi-Fi networks, individual connections in the Mbps range represent a significant fraction of the available bandwidth of an 802.11a, b or g access point, and this type of video often required special network tuning in the past. With 802.11n technology raising access point capacity to the 70+ Mbps range, these connections are now much easier to accommodate.

• Low-latency bounded vs. delay-tolerant. Many video applications are one-way only: a signal is broadcast from a head-end server and received at the client. This form of video may be sensitive to variations in delay, depending on the jitter buffer implementation on the client. Relatively constant delays, even long ones are not usually a problem. For instance, a viewer can not normally tell if a TV signal was delayed, even by several seconds. In contrast to one-way video, interactive video conferencing is extremely sensitive to end-to-end delay as well as jitter. Natural conversation breaks down when one-way delay approaches the 250 millisecond level, as demonstrated by voice-over-satellite telephone calls.

• Quality of Service (QoS) and error-tolerance. As codec technology has become more sophisticated, an error in a critical packet can propagate, causing picture degradation over several seconds, so it is important to minimize network-induced errors. Some video applications are designed to work even over noisy connections, but most

Aruba Networks I Can See Clearly Now: Bringing Wireless Broadband Video Into Focus 2

are not, requiring a low error rate for good performance. The network must ensure that this QoS threshold is met.

2 Various video applications

The application diagrams below show state-of-the-art comprehensive campus video systems. These systems, offered by a number of vendors, are capable of serving all of the applications listed below, while interactive video conferencing and surveillance video are also served by their own specialist vendors.

The diagrams show video originating from a number of sources, including video cameras used either for live video feeds or to archive for later viewing, digital video libraries for video-on-demand services, and cable TV feeds. These sources can be streamed over IP networks using a variety of codecs, including the new H.264 codec, for viewing on any network-connected screen.

In addition to campus systems, vendors offer equipment for satellite campuses or branch offices, and distance learning options over the Internet, including PC soft clients (and client-less PC players) and video reflector appliances to compress/expand signals for WAN transmission. Software-as-a-Service (SaaS) offerings over the Internet may also be part of a comprehensive video solution.

Modern video services support much higher picture quality than did older generations, avoiding the visual fatigue that often plagued earlier systems. They can be provided with closed captioning, and come with electronic programming guides, tracking and reporting functions that can monitor and assure compliance with staff training and education mandates, and enforcement of need-to-know access policies for sensitive or valuable content.


We can categorize video applications into different classes, with differing demands on the network. While all video applications require attention to QoS and network bandwidth, some are especially demanding, requiring specific features and an application-aware WLAN.

2.1 Broadcast TV: Cable TV over Wi-Fi

Leading-edge universities are beginning to re-configure residence buildings during facility and network upgrades, forgoing wired Ethernet terminations in each room in favor of WLAN delivery of all telecom and datacom services. Downsizing the wired infrastructure in favor of 802.11n wireless – a process known as network ‘rightsizing’ – can save considerable expense provided that the WLAN carries all cable TV and other services formerly carried on the wired infrastructure. This transition places tremendous demands on the WLAN and only the latest architectures are up to the

task.

By way of example, the characteristics of cable TV are as follows:

• One-way delivery: latency is not critical; and for the WLAN, video traffic is on the downlink only; • Usually high bandwidth (~2 Mbps/channel), but in the downstream direction only; • Many channels: often 50 or 100 channels are available; and • Few simultaneous subscribers per-channel: there might be only a handful of subscribers tuned to any one channel.


A typical network design uses a satellite TV receiver at the head-end to acquire the TV signals. Channels are encoded, encrypted and encapsulated with UDP/IP headers to run over IP infrastructure. Students can install a set-top box that receives the UDP stream, and bandwidth is in the order of 2Mbps per channel for standard-definition TV.

Because of the number of available channels and the diversity of the student population, it is not usual for more than a handful of set top boxes to be tuned to the same channel simultaneously. This means that multicast distribution is not an automatic requirement for the network. Nevertheless these systems usually implement multicast distribution because it allows easy scalability to large numbers of subscribers while minimizing the load on the video server.

From the WLAN perspective, the most significant characteristic of this service is that it is unlikely that more than one or two users on a particular access point will be tuned to the same TV channel. This means that it is not necessary to use multicast over the WLAN segment of the connection, even though multicast may be used by the video server.

Cable TV providers and video specialists are beginning to offer standard equipment that runs over Wi-Fi rather than wired Ethernet. Set-top boxes can be modified to accept 802.11n USB NICs, or an external Wi-Fi interface unit can be added to convert to Ethernet. An alternative approach is to use an access point in ‘workgroup bridge’ mode, where the wired port is connected to the set-top box.

With the availability of 802.11n, and the increasing processing power of notebooks, many students are opting to watch TV on their PCs. Campus video vendors all provide PC clients for their services, allowing for much higher-quality pictures than Internet streaming services. From the WLAN perspective, a PC client is similar to a set top box in this scenario.

2.2 Live event video streaming: Corporate webcasts, university events on TV

Normally driven from a dedicated video server, live event video streaming is an increasingly common university or large enterprise application. It is used for live streaming of concerts, leadership presentations, sports and other events. This category of video also covers video lecture distribution, town hall meetings (if the flow is primarily one-way), and

live programming where many clients are tuned to the same signal simultaneously.

In ‘live’ mode, the video signal is encoded and distributed directly. All clients will see the same video signal simultaneously. This is the one application of all the ‘video’ variants discussed in this paper that requires multicast distribution, as hundreds of users may be tuned in simultaneously, and the server farm and network bandwidth requirements to support an equivalent number of individual unicast connections would be prohibitive.

• One-way delivery: latency is not critical; and for the WLAN, the video traffic is on the downlink only; • Usually high bandwidth (1-3 Mbps/channel); • Only one channel; and • Many simultaneous viewers.


Interestingly, ‘broadcast TV’ service can become ‘live event video streaming’ if an event is broadcast live, and many clients tune in to it. Recent examples include the U.S. presidential inauguration and important sporting events. The implication is that infrastructure supporting TV signals can be configured in the expectation of heterogeneous channel distribution, where unicast distribution is optimal. However, the infrastructure must be able to handle isolated peak events where a single signal dominates, requiring multicast transport over the network.

Live events often require cameras to be set up in areas where it is difficult to install Ethernet cabling. In this case, mobility can be enhanced by using Wi-Fi as the uplink between the camera and the video server. A mobile video broadcast kit typically includes a video camera, digital encoding unit, tripod and network switch in a durable travel case. Such a system, when supplemented with a Wi-Fi client, becomes a mobile wireless TV station. The requirements for the WLAN are similar to those for the distribution/display side of the system, and a WLAN that is set up for one will function well for the other.

Note that many of the specialized video servers offering ‘live event video’ service also support on-demand services, where video is archived and can be accessed on-demand. This service is similar to ‘cable TV’ in that it does not require multicast delivery over the WLAN.

2.3 Surveillance video

Many universities are now using WLANs to carry video from surveillance and security cameras around the campus. WLANs are particularly well suited for outdoor areas because mesh technology enables the Wi-Fi network to extend across sectors that could not otherwise be served by wired Ethernet. Until recently, most surveillance cameras were analog NTSC or PAL models, and were not easily integrated with IP networks. A new generation of digital surveillance cameras functions as networked hosts, reachable via an IP or Web interface, and incorporates the latest video codecs. Video cameras are now available with integrated Wi-Fi client radios, short-term rewind, pan and tilt remote controls,

and event triggers such as sound or motion detection.

• One-way, delay-tolerant; but video signal may be on the WLAN uplink or downlink; • Wide variation of bandwidth requirements, from slow-scan grayscale to full TV quality; • Many cameras offering signals; and • Usually few simultaneous viewers per camera.


Different architectures are available. Some cameras act as Web servers, streaming output in multicast or unicast to as many clients as wish to connect. Others communicate with a server, allowing users to access live or archived video by logging onto the server. In a surveillance network, some cameras may be set to record continuously to an archive, while others alert and record only when an event such as motion is detected. Selected video sources can remain confidential, with employees or security contractors given access to different cameras on a ‘need to know’ basis. Indeed, moving surveillance video onto the IP network and the WLAN allows a mobile public safety responder with a Wi-Fi enabled smartphone to view video of an area while in-transit, an important new application for this technology.

Older networked surveillance cameras using NTSC or PAL, or even motion JPEG encoding were bandwidth-inefficient, typically limited to grayscale, slow-frame rate pictures. With digital camera technology and modern codecs, surveillance video can now be as advanced as a full-motion SD TV signal.

Since surveillance cameras are often mounted outdoors, it can be challenging to connect them to a wired Ethernet port. Aruba’s customers have seen success pairing surveillance video with mesh-connected access points, allowing the video signal to be relayed wirelessly through intermediate access points before joining the wired network. When used for video, such a link must offer full multimedia QoS support.

2.4 Interactive video conferencing

Much anticipated for at least a decade, the age of large-scale business video conferencing has finally arrived. From room-scale video conferencing to IM applications such as Skype, or video as a feature of VoIP deskphones from Avaya, Cisco, Polycom and others, all major Unified Communications vendors now offer different levels of interactive video as

a supplement to the traditional voice interaction.

• Two-way interactive: very sensitive to round-trip delay and jitter; • Usually lower bandwidth (0.1-1.0Mbps) but high-end systems demand full TV quality; • Symmetrical bandwidth requirements, usually with equal uplink and downlink data rates; and • Peer-to-peer connections rather than one-to-many, although a central server may anchor a multi-site conference. Since the video window on the client is usually small, and the frame rate low, the bandwidth requirement is often an order of magnitude lower than for TV signals. But unlike broadband television, desktop conferencing carries video both ways across the connection.


The delay requirements of interactive video are quite different from the other forms of video discussed in this paper. Delay is an end-to-end consideration, and the WLAN does not contribute significantly, compared to delays in the codec and on any WAN connections. But planning should include a calculation of expected and worst-case delays, to ensure that they are within bounds for this type of service.

The two-way characteristic of interactive videos demands that both the Wi-Fi uplink and downlink should be considered. Additionally, the QoS capabilities of the client are very important: in one-way video, the access point is effectively responsible for managing contention over the air, but once the client must transmit with priority, its 802.11 contention implementation becomes a significant feature.

2.5 On-demand video

Many forms of video - ranging from TV programming to training videos, company videos to university lecture recordings - are recorded for access days or months later. Video-on-demand is in many ways a variation on the Cable TV model above, but from the video server’s perspective it differs in that the signal is served from disk, rather than a live stream. The network characteristics differ from previous examples in that it is highly unlikely that many users will start watching the same video at the same time. For this reason, campus video servers treat on-demand video as a unicast service instead of a multicast one. The requirement to manage perhaps hundreds of simultaneous streams places performance demands on the video server hardware and software.

• One-way delivery: latency is not critical, and for the WLAN, video traffic is on the downlink only; • Usually high bandwidth (~1 - 2 Mbps/channel for SDTV, or ~10 Mbps for HDTV); • Many channels: often 50 or 100 channels are available; and • Very few simultaneous subscribers per-channel (even same-channel access will be staggered in time).


On-demand video is as likely to be viewed on a PC as it is on a traditional television screen. Since most PCs on enterprise or university campuses are Wi-Fi equipped, this is one of the first applications to be tested for WLAN-friendliness.

A feature known as ‘digital signage’ can be thought of as video-on-demand with a ‘push’ stimulus. TV monitors mounted in public places can be used to display a message or a video session, under central control. From the WLAN viewpoint this is no different to implement than a user-initiated service, although because monitors are often outdoors, they may benefit from a mesh-extended WLAN, in which the signal traverses several access points between the last Ethernet segment and the display.

3 Video service connections over the WLAN

While enterprise-scale video systems have been evolving for many years, vendors have only recently given attention to

delivering video over WLAN networks. There are several ways to connect a video client over Wi-Fi.

Campus video systems are designed to work with two types of client. Dedicated set-top boxes, appliances that terminate a vendor’s video stream in hardware, can be placed next to a TV screen. Alternately, video can be streamed to software applications on PC clients. There are several variants, but in general all can be adapted for Wi-Fi access.

The simplest device is the PC, as all video vendors provide software clients, and most PCs are already Wi-Fi capable, usually with 802.11n. In this case, no special integration is necessary, although high-performance video may require planning and QoS policy configuration for the WLAN.


All set-top boxes and other client appliances already offer an Ethernet termination. Some also include a USB socket, and with a driver for a Wi-Fi USB NIC, a standard set-top box can be improved for use on the WLAN. However, as the vendor must integrate the Wi-Fi driver software, this option is not usually available to an integrator or IT department.

For Ethernet-connected devices, the quickest option may be to use a ‘work-group bridge’. In an Aruba network, this would comprise an access point in ‘mesh’ mode, with its Ethernet port connected back-to-back with the set-top box.

3.1 Video codec technology

One of the most rapidly-evolving technologies in video distribution is the codec used to encode the video stream. The codec determines the combination of picture definition, error tolerance and bandwidth consumed on disk and on the network. The most recent and most popular in campus video is the H.264 codec. H.264 was developed simultaneously in two standards bodies, so it is also known as MPEG4 part 10 or AVC. The specifications are identical. H.264 is generally reckoned to have twice the bandwidth efficiency (same picture quality at half the bandwidth, or double the quality for the same network bandwidth) as its predecessors, H.263 and MPEG4 level 2.

Another aspect of codec efficiency is the manner in which computations are undertaken. Due to improvements in PC processing power, it is now possible for a PC or Mac-based software client to process an H.264 high definition TV signal while still leaving CPU cycles for other tasks. For example, an Intel 3.0 GHz core-2 Duo PC can display a 1080i signal using H.264 ‘baseline’ level encoding with about 25% of its CPU capacity (H.264 defines several levels including ‘baseline’, ‘main’ and ‘high’ for increasing quality and complexity of encoding).

H.264 is used by Apple’s QuickTime 7 video player and Blu-ray DVDs. TV broadcasters use it for streaming over IP networks, and other vendors use it for campus video streaming and on-demand services, desktop and room-scale video

conferencing, and surveillance video systems.

H.264 has many options and features, several of which are of interest to WLAN engineers, as they affect bandwidth and sensitivity to errors (which are sadly unavoidable in a campus network).

H.264 can operate in constant bit-rate or variable bit-rate modes. The information content of a video signal varies with the scene, i.e., rapidly changing motion, textures, or other details carry more information. A constant bit-rate encoder must be set to an expected level of motion, so it may lose quality with increasing motion, or alternatively it can waste


bandwidth when a picture is relatively static. In contrast, constant bit-rates are much easier to manage and control in a network context. Variable bit-rate maintains constant picture quality by increasing its bit-rate when the image changes quickly from frame to frame. Campus video systems generally use constant bit-rate modes by default, although there may be opportunities for the network manager to experiment. For instance, two-pass encoding is often used for archived video, greatly improving quality for a given target bit-rate, although it is not always possible to employ this for a live streaming TV signal due to real-time encoding requirements.

Independent of the encoding and tuning options, the ladder of encoding rates allows an appropriate rate to be selected per-client, per-connection. Indeed, most systems can offer the same video feed with a menu of rates for different network and client situations. At present the rate is usually selected at the client, although some centrally-managed systems can pre-configure an appropriate bit-rate per-client. If a client is experiencing poor quality due to limited network bandwidth, selecting a lower bit-rate will usually restore picture quality. In the future, these systems may be able to change bit-rate on the fly, incorporating feedback from the client. In such an architecture, video will be much

more robust over changing network conditions.

Another feature of H.264, and some of its predecessors, is that it incorporates multiple frame types. Decoding can only start after reception of a ‘key’ frame which may only appear every few seconds, so it is most important that these are not lost in-transit. Following key frames, also known as I-frames, codecs can generate P-frames (predicted) and B-frames (bidirectional interpolated). P-frames incorporate a delta from the last I-frame, and B-frames reference the last and next I-frame or P-frame. If the advanced levels of encoding are used, I-frames become more critical to picture quality than P-frames, and P-frames are more significant than B-frames. (Also relevant to QoS, B-frames assist in compressing the signal, but at the expense of increased delay). This suggests a video frame-aware network would be able to improve video quality under specified conditions by giving unequal prioritization to I, P and B frames. This would ensure that the first frames to be dropped in the event of overload or interference were B-frames, followed by P-frames. While some progress has been made in demonstrating that a codec-aware network can improve video quality, there is as yet no standard way to identify packets containing different frames. As a result there is no universal solution in which key frames will be assured delivery even under adverse network conditions.

Errors and dropped frames are troublesome for video codecs. Especially where differential encoding is used to save bandwidth, even single errors can propagate across many frames. It is therefore important to test the error-sensitivity of the system to be used, and to take measures to reduce errors and dropped packets by using QoS, or limiting bandwidth, for example. Meanwhile, campus video vendors sometimes add forward error correction (FEC) to reduce the effect of network errors – one vendor claims that a 5% error rate is sustainable with no loss of picture quality.

As we note elsewhere, delays across the network do not typically cause significant problems. Most campus video vendors implement large jitter buffers or caches in the network or the client, turning variable delay into a fixed latency, and this is an effective, if inelegant, solution. Although delays in the order of seconds are acceptable for many


streaming video applications, and would not be noticed in a static viewing scenario, functions such as channel-switching (of the TV channel), and start/stop/pause will make the delays obvious to the user. Even though delays are not as critical in one-way video, they should be mitigated wherever possible.

While many factors, including picture characteristics and codec implementation, affect the viewer’s perception, H.264 can typically encode an SD video signal - with audio - in 1- 4 Mbps and a high definition signal in about 10 Mbps.

4 Technology used for video over the WLAN

Many technologies must come together to ensure good video performance, and several of them are also required for voice over IP and voice over Wi-Fi. The unique requirement for video, and for live-event streaming specifically, is a good multicast implementation. Video over multicast is a necessary function for a network designer to master, but it is difficult to control in terms of air-time (bandwidth) consumed and reliable delivery. In this section, we discuss several technologies that can be used for video over WLAN: 802.11n and the new era of plentiful bandwidth it introduces;

unicast and multicast transport, and their relative advantages; and Quality of Service (QoS).

The table above summarizes the requirements of the different video services examined earlier. Now that these video service requirements are known, they can be matched to WLAN capabilities.


4.1 802.11n and bandwidth requirements for video

The most significant recent development in video over Wi-Fi has been the new 802.11n standard. First introduced as a

draft IEEE standard in 2007, and finalized in September 2009 to include new options for better performance, 802.11n uses Multiple Input, Multiple Output (MIMO) and other techniques to significantly increase the achieved bit rate over distance (rate-range) performance of a Wi-Fi connection.

802.11n devices currently on the market routinely connect with modulation rates of 200+ Mbps, and TCP throughput in the 120 – 170 Mbps range. This contrasts with 802.11a and g which top out at 54 Mbps physical layer modulation rates, for a usable TCP throughput of around 22 Mbps. The most significant performance improvements are due to a doubling of the channel bandwidth, from 20 to 40 Mbps, and dividing the video stream into two or more spatial streams, capable of finding separate paths from transmitter to receiver. On a typical U.S. university campus, the penetration of 802.11n in the user-population’s PCs rose from 40% in 2008 to 60% by the fall entry of 2009, according to a survey of Aruba customers, allowing network managers to target these devices for broadband video services.

802.11n includes a number of other features to improve performance. For example, using a short guard interval and MAC aggregation may be useful. The actual performance improvement also depends on factors such as the RF environment and average packet size.

The final version of the IEEE 802.11n specification allows up to four spatial streams (600 Mbps under best-case conditions), while the Wi-Fi Alliance is testing up to three spatial streams (to 450 Mbps) in its new ‘n’ certification, versus two prior to ratification of the standard. The performance figures quoted in this note are for two spatial streams, the technology found in most Wi-Fi access points and 802.11n-equipped PCs shipped over the last two years.

In this note, we use two main measures of bandwidth. Building up the requirement from the application side, the starting point is the video codec with a given encoding rate. By way of example, assume a 2.5 Mbps codec rate plus data overhead for control purposes. When this raw rate has headers added for TCP/IP and 802.11, it may reach 3 Mbps (20% overhead). Since video uses long frames, the overhead is a smaller percentage than for voice traffic.

Meanwhile, the rates quoted for 802.11 are usually physical layer modulation rates. For 802.11a or g, these are 54, 48, 36, 24, 18, 12, 9 and 6 Mbps. It is well-known that the actual end-to-end application throughput of 802.11 is much lower than these figures. We would typically expect a 54 Mbps rate to support actual throughput of around 28 Mbps for


UDP (50%) or 22 Mbps for TCP (40%), and these percentages would be reduced as more clients associate to the access point.

In our example, the ‘raw’ 2.5 Mbps application layer codec rate becomes 3 Mbps after packet header overhead, and requires an 802.11 physical layer modulation rate of at least 6Mbps, for a single video connection. Multicast (UDP equivalent) needs slightly less air-time than unicast (TCP) because it does not need ACK packets. Since 802.11 uses a shared medium, we need to consider the bidirectional bandwidth requirement.

4.2 Multicast transport for video

Video applications often use a single multicast stream to which any interested client can subscribe, instead of using multiple unicast connections, one per client. The objective is to conserve bandwidth and to reduce the load on the video server. For example, if a multicast video stream requires 3 Mbps and ten clients subscribe to it, the bandwidth

requirement is 3 Mbps. But if unicast transport were to be used, a nominal 30 Mbps would be needed.

However, multicast suffers from one key disadvantage. Multicast traffic is not acknowledged. Clients cannot indicate to the transmitter that they missed a packet, and because there is no retransmission mechanism any errors due to lost packets are cannot be corrected.

Multicast over Wi-Fi compounds this difficulty. Wireless frames are subject to loss and corruption over the air, factors that are addressed using 802.11 protocol features such as acknowledgements, retransmission and rate adaptation. So under normal conditions, very few frames are irretrievably lost. But with 802.11 multicast (also called broadcast, since it’s the same protocol), there is no acknowledgement or adaptation, and therefore some level of frame loss is inevitable.

The error rate can be reduced by adjusting the modulation rate, given a constant over-the-air signal to noise ration (SNR). For instance, if the rate is reduced from 48 Mbps to 24 Mbps, the error rate will be improved provided that the noise level does not change. Because of the lack of acknowledgements, 802.11multicast traffic is usually transmitted at a much lower rate than would be used for unicast traffic. This takes more time on the air, consuming more of the network’s data capacity, but provides a margin of safety in case RF conditions deteriorate.

An additional challenge with multicast over Wi-Fi is that the modulation rate must be set for the worst-case among the client population, normally the client most distant from the access point. For example, if four clients on an access point subscribe to a multicast group, and they would connect with unicast traffic at 36, 36, 24, and 18 Mbps, then the multicast stream must be transmitted at a maximum of 18 Mbps. As noted above, a safer figure would be 12 or 9 Mbps, to allow for a short-term increase in error rates.


Power-save mechanisms also complicate the multicast picture. Without active power-save, downlink multicast traffic is transmitted immediately by the AP without first being buffered. However, if even one of the AP’s clients goes into power-save mode, all broadcast/multicast traffic must be buffered for delivery at the DTIM when the power-saving clients wake up. This situation occurs whether or not the client using power-save is subscribed to a multicast video stream. With the usual DTIM setting of four beacon intervals, power-save will delay multicast frames by up to 400 milliseconds, adding considerable delay and jitter. This effect can be mitigated by reducing the DTIM interval, at the expense of power consumption for clients using power-save. Finally, multicast frames transmitted by the access point are usually placed in the ‘background traffic’ wireless multimedia (WMM) queue, regardless of tagging, so unless the WLAN vendor has modified this function, they will not have over-the-air QoS.

These challenges make multicast over Wi-Fi difficult to control, and increase the amount of air-time bandwidth used by multicast when compared to the unicast equivalent. Therefore, while there are cases when multicast is a requirement for broadband video, it is usually better to use unicast, at least over the air, whenever feasible.

4.2.1 Multicast for video in LANs and WLANs When considering an end-to-end WLAN video network, multicast traffic is often seen in three segments of the network: between the server and WLAN controller; the controller and access points; and over the air between the access points and clients.

The first segment is typically not an issue. The video server connects to the WLAN controller over a high-capacity core network, and hence little bandwidth would be gained from using multicast in this segment of the network. However, some campus video servers can only work in one mode at a time, and must be configured for multicast in most cases. Many servers also support clients on the wired network, and the connection and bandwidth requirements from a large number of wired clients may force the use of multicast as a general rule. In this case, Aruba’s WLAN infrastructure will accommodate multicast traffic from the server to the controller, while implementing bandwidth optimization features such as multicast filtering, transparent to the video endpoints.

4.2.2 Multicast between the WLAN controller and access points The second video network segment spans across the wired network from the WLAN controller to its access points. Modern enterprise-class WLANs implement a variety of architectures for data traffic. Aruba supports centralized, distributed, split-tunnel, and resilient mesh forwarding models. Most campus networks employ a centralized traffic model, in which all data going to and originating from wireless clients pass through the controller. Other traffic models take traffic directly from the local LAN connection, although control and management data are sent to the controller. In either case, it is important to limit the LAN bandwidth consumed by video, particularly multicast video, because the video streams are high-bandwidth and persistent. Suppressing unnecessary multicast replication between the WLAN controller and access points can be accomplished using ‘IGMP snooping’. IGMP snooping uses the WLAN controller


to monitor which clients are subscribed to multicast video groups, and only sends multicast traffic to access points when

required and even then only on a per-group basis.

Aruba’s mobility controllers use IGMP snooping to identify which access points have clients that subscribe to multicast streams, and then block replication of the multicast stream to other access points. Since the tunnels between the controller and access points may traverse several wired LAN segments, this results in significant bandwidth savings over the distributed-traffic model.

4.2.3 Multicast over-the-air in the WLAN The third segment where multicast can be helpful is the over-the-air Wi-Fi link. Since over-the-air bandwidth is a precious commodity, even with 802.11n, the air-time savings from multicast (transmitted once, received by many) may be worthwhile in some cases. If multicast is to be used, Aruba offers a feature to select the optimum over-the-air data rate.

Some examples serve to illustrate the benefits of optimization in the 802.11 segment of the network. First, consider the modulation rate used by multicast traffic. Because multicast frames are un-acknowledged, the access point is transmitting ‘blind’ and cannot tell if frames are received, nor can it retransmit to recover lost frames. Thus, it is necessary to use a conservative approach when transmitting multicast frames, by selecting the lowest rate possible. Indeed, the usual configuration for 802.11 multicast is to use the lowest ‘basic rate’ configured for the SSID, which would be 1 Mbps for default 802.11b/g networks, or 6 Mbps for 802.11a and 802.11g networks. In a network with default settings, these rates would be used even though the clients receiving multicast might be capable of receiving at a higher rate, say 24 Mbps. As a result, a large amount of the access point’s usable air-time would be taken up with transmitting multicast video at these rates.

To avoid such outrageous bandwidth usage, techniques have been developed to optimize multicast rate selection. Aruba’s ‘accelerated wireless multicast’ feature references the rate used by the client to ACK the last unicast frame and then adjusts the maximum multicast rate accordingly. The net result is a rate cap that varies according to the capacity of the 802.11 technology in use.


In the example below, if three clients subscribe to the multicast stream and are connecting at 48, 36 and 24 Mbps, then 24 Mbps would be chosen. Taking real-world effects into account, this would support a video stream of 12 Mbps if all access point bandwidth were to be consumed.

Note that some enterprise video vendors already offer a multicast-or-unicast feature, directly from the video server. For instance, Microsoft’s Windows Media Services server monitors the number of clients, wired or wireless, subscribed to each multicast group, and automatically switches to unicast transmission as appropriate.

As discussed above, if multicast video is used over Wi-Fi then error rates will be greater than if unicast transmission was used. However, the effect of a given over-the-air error rate can be mitigated by adjusting the frame size used by the video server. Default settings on these servers often specify a relatively large frame size, where a single video frame


from the server is likely to be subsequently fragmented to meet network constraints. Now, if a single fragment is lost over the air, all other fragments of that frame will be discarded at the client, resulting in lower video quality than if a smaller frame size was configured at the video server.

4.3 Quality of Service for video services

The QoS requirement for video is similar to that of other delay- and loss-sensitive multimedia services, such as voice. A number of techniques are required to ensure that frames are delivered in a steady, uninterrupted stream.

First the video session must be identified, so that it can be prioritized. Most enterprise WLANs rely on the IP header’s original QoS tags to direct the traffic, packet by packet, into high-priority queues. However, Aruba has found that video streams do not always arrive at the WLAN with their tags intact, particularly if they are multicast. Therefore, Aruba introduced the ‘video detection and optimization’ feature to detect video stream protocols in the mobility controller, and re-apply or adjust priority tags as appropriate.

Prioritization over-the-air uses the well-understood WMM protocol, which has been tested and interoperability-certified by the Wi-Fi Alliance. All current Wi-Fi equipment, consumer and enterprise, supports WMM, and WMM compliance is mandated for 802.11n devices. Tags in the IP header (802.1p, with 8 priorities defined in 802.1D), are mapped to the four WMM access categories. Video has its own access category, below voice in priority but above best-effort and background data. In WMM, higher-priority traffic uses a shorter timer for access to the medium, and shorter random backoffs if a collision occurs, to ensure that when a mix of traffic is to be transmitted, those stations with voice or video

to send receive preferential access over others with lower-priority data.

WMM has proven to be an effective mechanism, although even with a heavily-loaded network, there is still dead time because of the imperfect contention algorithm. A network with a moderate level of voice or video traffic and an overload of data traffic will successfully deliver voice and video, while some of the lower-priority data will suffer long delays and eventually be dropped. This is the expected and the correct behavior.

Thus, with a mix of video and data approaching network capacity, video will be delivered successfully at the expense of data traffic. However, if the video traffic alone exceeds network capacity, some will inevitably be delayed or dropped, an unsatisfactory situation. One way to prevent this is to limit the number of connections allowed, a technique known as Call Admissions Control (CAC). CAC algorithms have been widely used for voice, and a number of approaches using different indicators have been developed. For example, the access point can advertise current load by access


category, allowing clients to estimate whether there is sufficient capacity for their new call. Alternatively, the access point can require explicit call admissions, where the traffic specification (TSpec) signaling protocol in 802.11 allows the client to request a specified connection rate. The access point can then grant or reject the request.

Earlier, we discussed the various I, P and B frames generated by video codecs. It is not yet feasible to segregate these frames in the WLAN for QoS purposes. However, another aspect of frame generation is important. The amount of data generated by the codec for each picture ‘frame’ is quite large. Therefore it is usually broken down into blocks for transport. However, these blocks are often larger than the maximum ‘frame’ size in the WLAN, so they are further segmented. At this point, the loss of even a single WLAN frame within the large video block making up an I-frame will cause an error. As a result, the entire I-frame will be lost, potentially causing the picture to freeze. The solution is to reduce the video server’s block size to match the largest frame to be sent over the WLAN.

Mobile video camera/encoder kits, discussed above in connection with broadcasting live events or streaming a training video to a central server, pose the same QoS challenges to the WLAN as a distribution signal to a TV screen. The difference is the high-bandwidth video signal is now directed from the client towards the access point. If WMM is correctly implemented, this should not pose a problem, but it is important that the Wi-Fi client sets the appropriate WMM priority. If it does not, it will be very difficult for the WLAN to prioritize the traffic against other data clients.

4.4 Latency and Jitter in WLANs

High quality video services require controlled, bounded delays, and we suggested some latency and jitter thresholds earlier in this paper. Since delay is an end-to-end phenomenon, the network designer should map out the video path from server to client to calculate the worst-case delay and ensure that it will be acceptable to the viewer. In the end-to-end calculation, the WLAN’s contribution is minor compared to the codec, and for on-campus video it should not be difficult to achieve the delay goals for streaming video, or even the more stringent requirements for interactive video.

The figures above show what can be expected when video and background data traffic are combined on a WMM-capable WLAN approaching air-time saturation. Latency and jitter are separated, and each has a maximum of around 6 milliseconds. With proper QoS, the WLAN’s over-the-air delays will contribute very little in an overall delay budget of 150 milliseconds.

4.5 Video performance enhancements

Since video demands more bandwidth than any other WLAN application, network data capacity has become a key performance parameter for the enterprise WLAN. Aruba addresses capacity optimization using Adaptive Radio


Management (ARM) technology to automatically control clients and network infrastructure. ARM optimizes the RF plan by automatically allocating RF channels and transmit power levels to access points, ensuring they make the best use of the available spectrum. ARM also load-balances clients across the network, so clients on congested access points are moved to less heavily-loaded access points. These field-proven bandwidth preservation techniques can significantly enhance video performance.

As noted above, 802.11n access points and clients have an enormous performance advantage over earlier 802.11 technologies. A network comprised of 802.11n-based access points and clients will have a capacity of 70 – 170 Mbps per access point, 5 – 7 times greater than for 802.11a or g.

Some network managers wish to confine video services to 802.11n clients only because older clients that operate at lower rates deliver poor picture quality, and reduce network capacity for all other users. Many networks offer 802.11b/g/n with 20 MHz channels at 2.4 GHz, and 802.11a/n in 20/40MHz channels at 5 GHz. Network managers often want to restrict high-bandwidth video services to 802.11n in 40 MHz channels at 5 GHz, even though clients should be allowed to connect for other services on any SSID they choose. While this type of segregated access policy can be realized using designated SSIDs and VLANs, it is much easier to implement in Aruba’s architecture because the integral stateful firewall can recognize video protocols and allow access to the service on a session by session basis. Other parameters, such as time-of-day access, can be added to the firewall rules if desired.

Traffic shaping is another technique used in enterprise WLANs to enforce air-time fairness, preventing any one connection from hogging too much network bandwidth. Traffic shaping may not be appropriate for use with video in all cases, but if the end-client video codecs are bandwidth-adaptive, a feature where infrastructure restricts a client’s bandwidth to a suitable rate, shaping may be very effective in managing bandwidth while delivering consistently good video. For instance, the manager of an Aruba network may wish to restrict video services to no more than 30% or 50% of available bandwidth (air-time), and can do so with a good degree of accuracy using bandwidth contracts.

Another important feature is automatic suppression of certain WLAN functions when a video stream is detected. Modern enterprise WLANs are multi-tasking: access points can serve clients, and scan other channels to calculate network coverage, identify interference sources and defeat intrusion attempts. Since high quality video requires consistent, uninterrupted packet delivery, scanning must be interrupted when an access point is carrying a video stream. In Aruba’s architecture, the stateful firewall integrated into the WLAN controller is responsible for monitoring the protocols passing through each access point, and suspending scanning for the duration of a video call.

The integral firewall is also used to re-classify QoS tags on video traffic were they not set, or lost in transit. Once a video or other high-priority session is recognized - by protocol, endpoint or other means - it can be tagged on the outside of the tunnel header and over-the-air.

As the number of clients on a network grows, it becomes necessary to limit broadcast traffic, and the usual way to accomplish this is by creating VLANs. In an Aruba network, the IP address of a client only has significance on the northbound interface of the mobility controller, so the controller can assign each client to a VLAN as it authenticates. To balance the number of clients across VLANs, Aruba developed a feature called ‘VLAN pooling’ to distribute clients evenly across a set of VLANs.

VLAN pooling is an established and effective feature, but when clients subscribe to multicast groups, it is insufficient by itself to prevent unnecessary multicast duplication in the LAN upstream of the controller. Consider two Wi-Fi clients that both subscribe to the same multicast video stream. If they are on different VLANs, the controller will make two IGMP ‘join’ requests on their behalf, one on each VLAN. In the absence of further processing, two multicast streams will be created between the upstream router and mobility controller. To avoid this extra traffic, the controller


will issue only one IGMP ‘join’ and internally duplicate the video packets on that stream for delivery to both clients. This can save significant LAN bandwidth in certain scenarios.

5 Progress in standards for video over Wi-Fi

Several features helpful to video over Wi-Fi are making their way through the standards process. The most immediate is the work in 802.11 Task Group v (Wireless Network Management), which should be ratified early in 2010. Some of the 11v features of interest to video network designers are discussed below. These features will not be widely implemented in enterprise equipment until the Wi-Fi Alliance ‘Wireless Network Management’ group develops a certification, probably in 2011.

• Flexible Multicast Service (FMS) allows a client to request individual service for multicast traffic. An FMS request identifies a set of multicast streams and allows tailoring of the delivery interval (as a number of DTIMs) and the data rate to be used. While this feature is primarily intended to allow battery-powered devices to save power by increasing their sleep interval between frames, and also the time during which they receive multicast frames (higher data rates mean faster transmissions), the rate option in particular allows optimization of data capacity of an access point. This has a similar effect to the Aruba video feature described above, but it is client-initiated and fully standardized.

• Directed Multicast Service (DMS) is a client-requested multicast-to-unicast conversion service. The feature provides a request frame from client to AP and delivers selected multicast streams as unicast traffic. The benefits are primarily increased reliability, as unicast is acknowledged and automatically retransmitted, but the savings in air-time due to higher data rate transmissions are also important.

The second important initiative in IEEE 802.11 is Task Group aa. TGaa (‘Video Transport Streams’) is in its early stages, and will not be finalized until 2011 at the earliest, but it represents a concerted effort, particularly by consumer electronics companies, to advance the capabilities for TV and video over Wi-Fi. The central feature in TGaa is ‘More Reliable Groupcast’, incorporating a number of measures to address the shortcomings of multicast explored above. While details of the proposed standard are not yet firm, it currently includes measures allowing selective acknowledgement and retransmission of multicast frames.


6 Conclusion

As video services grow in popularity, particularly in enterprises and universities, network managers have expressed a preference to run them over existing IP infrastructure, including wired campus LANs and WLANs. The introduction of high-speed 802.11n, and the proliferation of 802.11n-capable access points and clients with 5x the data capacity of older equipment, is driving the displacement of wired Ethernet connections and its replacement with 802.11n wireless solutions.

The main technology enablers for video over Wi-Fi are adequate bandwidth, QoS and multicast support. While 802.11n provides a significant bandwidth boost, RF planning is still important to ensure continuous, high-rate coverage. RF management algorithms that include access point and client control, such as Aruba’s ARM, automatically calculate the optimum channel and transmit power assignments, move clients to the most appropriate access point and optimize the network’s use of available spectrum. This function is especially important for mobile clients and in the presence of densely deployed clients, e.g., lecture halls and dormitories.

QoS for video uses the same mechanisms as for voice, so the technology is not completely new. However, since the bandwidth requirements of video applications vary widely, and session setup protocols are more complex, there is work to be done to standardize and implement call admissions control features. With the high bandwidth requirements of video, correct QoS tagging is crucial, and Aruba’s integrated stateful firewall ensures correct prioritization, recognizing video protocols and enforcing network policy for video independently of incoming QoS tags.

Since video can account for a large percentage of network bandwidth, multicast optimization across the LAN is an important function. Aruba incorporates IGMP snooping to monitor multicast group members, and only delivers the multicast stream across the LAN to access points whose clients require it.

Over the air, from access point to Wi-Fi client, multicast is optimized by choosing the highest ‘safe’ data rate for transmission, a dynamic calculation based on the unicast rate used by the client’s control traffic. This saves considerable bandwidth in most situations. However, it is nearly always more satisfactory to use unicast, as it incorporates ACKs and retransmissions for assured delivery.

Standards are crucial for making continued progress on enhancing the reliability of video over the WLAN, and the IEEE 802.11 committee has a number of initiatives in progress. Most notable is Task Group aa (802.11aa), ‘Video Transport Streams’, whose charter was approved in March 2008.

Advancements in available Wi-Fi bandwidth, video codec technology, and WLAN video features have combined to give video services a significant boost in enterprise and university networks. Combining a campus video system with an enterprise-class WLAN can deliver video quality of a level that equals wired standard-definition and even high-definition video transport. In so doing, video over WLAN provides roaming users with untethered access to video content. It also affords IT managers the opportunity to save considerable capital and operating expenses by rightsizing wired Ethernet and cable plants and replacing them with cost-effective 802.11n WLANs.


About Aruba Networks

People move. Networks must follow. Aruba securely delivers networks to users, wherever they work or roam, using a combination of award-winning solutions:

• Adaptive 802.11n Wi-Fi networks optimize themselves to ensure that users are always within reach of mission-critical information. Rightsizing expensive wired LANs by replacing them with high-speed 802.11n Wi-Fi reduces both capital and operating expenses;

• Identity-based security assigns access policies to users, enforcing those policies whenever and wherever a network is accessed;

• Remote networking solutions for branch offices, fixed telecommuters, and satellite facilities ensures uninterrupted remote access to applications;

• Multi-vendor network management provides a single point of control while managing both legacy and new wireless networks from Aruba and its competitors.

The cost, convenience, and security benefits of our secure mobility solutions are fundamentally changing how and where we work. Listed on the NASDAQ and Russell 2000® Index, Aruba is based in Sunnyvale, California, and has operations throughout the Americas, Europe, Middle East, and Asia Pacific regions. To learn more, visit Aruba at http://www.arubanetworks.com. For real-time news updates follow Aruba on Twitter at http://twitter.com/ArubaNetworks.

© 2009 Aruba Networks, Inc. AirWave®, Aruba Networks®, Aruba Mobility Management System®, Bluescanner, For Wireless That Works®, Mobile Edge Architecture, People Move. Networks Must Follow., RFProtect, The All Wireless Workplace Is Now Open For Business, Green Island, and The Mobile Edge Company® are trademarks of Aruba Networks, Inc. All rights reserved. All other trademarks are the property of their respective owners.

1344 Crossman Ave. Sunnyvale, CA 94089-1113Tel. 408.227.4500 | Fax. 408.227.4550 | [email protected]

http://www.arubanetworks.com

© 2009 Aruba Networks, Inc. AirWave®, Aruba Networks®, Aruba Mobility Management System®, Bluescanner, For Wireless That Works®, Mobile Edge Architecture, People Move. Networks Must Follow., RFProtect, The All Wireless Workplace Is Now Open For Business, and The Mobile Edge Company® are trademarks of Aruba Networks, Inc. All rights reserved. All other trademarks are the property of their respective owners. WP_VIDEO__WLAN_102809

Enterprise I Can See Clearly Now - arubanetworks.com · Aruba Networks I Can See Clearly Now:...

Documents

Transcript of Enterprise I Can See Clearly Now - arubanetworks.com · Aruba Networks I Can See Clearly Now:...