Traditional priority and buffering techniques fail to provide the proper QoS mechanisms needed for the delivery of video streams over 802.11 links. Real-world 802.11 networks are subject to sudden and severe drops in available bandwidth that result is stuttering and frozen video. Other solutions have suggested using buffering, but buffering for a highly variable wireless link would require an enormous buffer to support QoS through worst-case scenarios. This enormous buffer is very costly and not consumer friendly; the consumer will not wait several minutes to "change a channel."

Fortunately, designers can solve QoS problems by combining rate adaptation with buffering. This article will examine an approach for an end-to-end solution providing guaranteed video QoS over standards based 802.11 networks. The solution for providing true wireless video QoS is to tightly couple the video server to the wireless hardware. In this way, real-time adjustments to the video can be made, maximizing the available bandwidth at all times. Guaranteeing 30 frames per second characterizes this management of the video over the 802.11 network, regardless of link conditions.

Several types of solutions have been brought forward to attempt to resolve these issues—mostly with very limited success. Dedicated bandwidth in combination with prioritization techniques such as in 802.11e are being pitched as a solution for supporting video distribution. However, the dedicated bandwidth/prioritization approach will not provide true QoS since it still does not resolve the true key issue: how to deliver and maintain broadcast quality or higher quality such as HDTV, QoS when the required bit rate exceeds the available bandwidth.

Buffering provides another QoS option for designers. But buffering for a highly variable wireless link would require an enormous buffer to support QoS through worst-case scenarios.

A final option, and one that will solve designers problems, is the implementation of a QoS technique that blends buffering with rate adaptation techniques. In this article, we'll look at the problems associated with existing WLAN QoS techniques. We'll then show how the combined buffer/rate adaptation scheme provides an effective QoS mechanism to support the streaming of video over 802.11a WLAN links.

Traditional Solutions
The mathematical study of video streaming can first be characterized by two main functions:

• = Bandwidth demand required for stream k at time T
• = Available bandwidth in the network

In the A/V headend retransmission and delivery business, all video channels exist as 6 MHz bands. Within this 6M Hz band, can exist a single analog TV channel. With the advent of digital A/V, each 6 MHz analog band can carry 27 Mbit/s with QPSK modulation or 36 Mbit/s with QAM-256 modulation. Many digital channels can be packed into this single analog band, the digital stream modulated into a single analog band is known as a transport. The problem of efficiently packing multiple A/V streams into each transport efficiently is known as the traditional statistical muxing problem.

In many traditional video networks, such as QAM or QPSK over coax, will be constant, which simplifies the statistical multiplexing problem highlighted in Here, the statistical muxing problem can be solved fairly easily in the digital broadcast world using simple solutions ranging from constant bit-rate (CBR) streams to elegant ones such as rate grooming with transrating capability.

The advantage of a constant =K is also that latency can be minimized to network limits in systems like this and that it ceases to be an issue.

Where this gets interesting in the WLAN world is that under 802.11a/b/g, where the environment can change, multiple clients can move around, is unlikely to be constant. In fact, it is so easy to get available bandwidth to not only dip by 90 percent or to 10% or less of the average, it can stay low for short or long periods of time.

Just so we understand what is happening, consider the comparison of the maximum observed total throughput of a completely clean environment for 802.11a compared to one that has a microwave working on a popcorn bag or other environmental changes and basic interference such as closing doors or movement (Figure 1).

Superimposing a single HDTV stream onto the clean environment yields clean video transmission; there is sufficient bandwidth to handle the video. However, over a real-world environment, there is a discontinuity in the video at the point of interference.

There are two commonly seen solutions to avoid this problem. The first is the least common denominator approach where the system measures and analyzes common installations and derives a minimal available network bandwidth figure. In this approach, designers must ensure that video bandwidth demand does not exceed the minimal figure.

The second approach is buffering. In this method, the system measures and analyzes common installations and derives a buffer size on the receiver. As the interference kicks in, the video bandwidth demand exceeds the available bandwidth.

The first solution is not very interesting because the failure rate is high or the video bit rate is always so low that the video quality itself ceases to be interesting to the end-user. The second solution works quite well up to a point, by a combination of (a) avoiding trying to maximally use all of as well as (b) sufficient buffer on the receiver, the streaming problem can be solved for many cases. However, the second solution does not work for the microwave popcorn or hands-free phone scenarios.

If we express this in mathematical terms, one notes that the study of the minimal latency required to solve the above problem can really be expressed as:

The buffer requirement for Δ_t worth of video is:

Assuming a latency of α, the consumption rate at any time period Δ_t is:
without loss of generality, we can take this to be:

meanwhile, the available bandwidth can support the following:

There is one caveat. As the input video feed is real time live video, F^*A cannot exceed F^D. This means then that we are really interested in the following:

Let α=demand latency. Then to avoid buffer underrun, we require that:

What we really need to known is that given any desired disruption or interference in the network, will enough bandwidth be available so that underflow does not occur. In the special case where underflow does occur, we can take F^*A=0. In this case, α=Δt.

From these equations, we can see that for a robust implementation of buffering, we really need to buffer enough video to handle the target disruption. But this latency can last for seconds or minutes, which makes buffering to handle all cases of disruption impossible.

Yet a useful question to understand is a simple one: Is buffering impractical for handling most disruption cases? The answer actually comes from the consumer electronics (CE) space. Consumer electronics manufacturers understand video requirements. Low latency is an important requirement. Channel change has to be immediate and in the sub-second range. Slow response time has plagued digital video for a while and is a frequent end-user gripe.

Buffering actually does work up till a point, but buffering introduces latency. Latency translates to delays in user activity such as channel changes, fast forward and rewind, making buffering a troublesome option for streaming video over WLAN link.

Finding a Good Solutions
As designers can tell, the approaches described above do not provide a good solution to solving the problem of delivering video over IP links. What separates a good solution from the rest is one that tries to utilize the available bandwidth efficiently and still minimize the buffering requirements. There is such a solution employing not only the network monitoring features, but rate control of the input video stream as well.

By being able to detect network congestion, and squeezing the video bit rate into available bandwidth, we can conveniently extend the functional environment of the video streams and at the same time use as much of the available bandwidth as possible. We call this technology adaptive bandwidth footprint management (ABFM).

ABFM is basically a means to adaptively modify the bandwidth footprint of all muxing all video streams in an environment where the total available bandwidth is subject to fluctuations. There are three parts to ABFM:

1. Detecting bandwidth fluctuations and predicting instantaneous available bandwidth
2. Selecting the victim(s) for adaptive bit-rate adjustment
3. Adaptively modifying the bitrate of the victims to ensure the resulting bandwidth footprint will not instantaneously flood the network

Latency Recovery Experiment
The tools to conduct an experiment can be done by building a HDTV decoder application that takes statistics of the health of the buffer and actual received video bit rate. The tools of the experiment is shown in Figure 2, and in more detail in Figure 3 which is a rather drastic extreme scenario of wireless dropout in an off-the-shelf 802.11a products.

Now, we study the results of an experiment using off-the-shelf 802.11a products. By a combination of methods (moving away quickly and closing doors), we were able to introduce a disruption to the link. The effect on the buffer level is seen in Figure 4.

In the system discussed here, the off-the-shelf 802.11a was capable of roughly 22 Mbit/s of bandwidth with a distance of 15-ft (no walls). It was not difficult to introduce disruption into this link to achieve a 50% drop in throughput. The video stream obtained was around 19.2 Mbit/s, which we forced to be a flat 19.2 Mbit with minimal padding to ensure the analysis was easier. Padding was less than 2% and no interval was padded by more than 5%.

In any buffering scheme, it is important to denote a watermark level. Under normal conditions, the buffer available is at the watermark level, and this watermark level should be time based and not size based as latency is still important even when using buffers. Whenever the buffer level is not at a normal, condition at the watermark level, then we have a potential problem as further disruption at any point when the buffer level is not full will have an easier task of underflowing. Hence we consider the buffer recovery time as a critical measure of how robust a system is to disruptions.

Next, we consider a rate-adaptive system that can reduce the video bit rate adaptively (RA) as the available network bandwidth drops. Comparing this to the non-RA scenario, we can see that the buffer recovery time for the client buffer is much shorter for the rate-adaptive case (left side of Figure 5) compared to the normal case (right side of Figure 5).

Lets analyze the experiment in terms of understanding the phenomenon of the observed data. In numerical terms, the observed result of the rate-adaptive experiment is summarized in Table 1.

The total data generated during the disruption is around 149.92 Mbits. Without an RA method, the actual data produced with the fixed 19.2-Mbit/s video stream, we would have got 11s*19.2 or 211 Mbits of video data.

To simplify our analysis, if we take the drop to be roughly 1/2 (11 Mbit/s) for 7 seconds, followed by complete recovery back to 20 Mbit/s, then for the above we see the difference in buffer recovery time illustrated in Table 2.

In practical terms, we see that the actual recovery time of the first RA method was significantly faster than the non-RA one. After the disruption was over, normal RA methods would have required 48 seconds to recover to full normal buffer, while the simple RA scheme would have recovered in 26 seconds.

It is also clear that a more drastic reduction of bitrate (eg : by 50% & 75% instead of 33% & 50%) can reduce the recovery time further, so determining the actual rate of the reduction seems to be the key here. Thus, more accurately predicting the available channel bandwidth quicker can help improve the basic rate adaptive scheme.

RA methods do not have to stop here. In a second version, a quick-response RA system that can be designed to more accurately predict available channel bandwidth and minimize RA. This scheme requires tighter coupling to wireless subsystem. It also requires a reduced bitrate to match .

If we study the graph in Figure 5 again for the behavior of during the disruption period, we come up with the results shown in Table 3.

During the disruption period of 1s, we notice that is roughly the same as . This means that in effect, if the streaming server has earlier feedback of the disruption, then performing significantly better than the simple RA method, we realize that recovery time can be as close to zero as implementation details can allow (there are other delays in the system such as digital tuners). This is easily achievable by making these statistics such as signal strength and packet error rate available at the MAC layer to the application layer that makes decisions on what the bit rate of each A/V steam has to be. .

About the Author
Indra Laksono is the vice president of R&D and co-founder of ViXS Systems. Indra holds a Bachelor of Science degree in Computer Science and Math, and a Master of Science degree in Computer Science from University of Toronto. He can be reached at indra@vixs.com.