Wi-Fi works well for pre-recorded video files, but can create significant performance bottlenecks for live streaming video.
Wi-Fi data links, also known as wireless Ethernet or 802.11, can be found in coffee shops, airports, train stations and many other places where people use laptops to access the Internet. In homes, Wi-Fi links are frequently used to provide access to printers and for sharing resources such as Internet connections. The great benefit of this technology is, of course, high-bandwidth IP connections without the use of Ethernet cables.
Much video content has no problem with Wi-Fi—in fact, any prerecorded video program that can be downloaded and placed into a (large) buffer before play-out begins will rarely have a problem.
For example, a Roku player connected to a family-room television can progressively download short segments of a movie via the Internet through a Wi-Fi connection to flawlessly play a three-hour movie.
Other devices can use this same progressive download technique over a wireless link, such as a laptop browser that is playing content from YouTube.
No, the problems with Wi-Fi for video happen when real-time transport is needed—for live content, videoconferencing or other applications when the video signal is delivered as it is being created. Live streaming is often used in a variety of applications such as video surveillance and real-time broadcasting.
HOW WI-FI WORKS
Most Wi-Fi systems are configured with Access Points (AP) and clients. Each AP broadcasts a beacon on a selected radio channel, and clients must find this broadcast signal and tune to the AP’s frequency before communicating. All communication that takes place is “half-duplex,” meaning that when a device on one end of the link is broadcasting, any other device has to be listening, rather like walkie-talkies or CB radios. Of course, in a Wi-Fi system this process is handled automatically.
The basic protocol for Wi-Fi is similar to the original Ethernet standard, where multiple devices share a single LAN network cable. Each device on the cable first listens to determine if the LAN is in use, and then transmits data as soon as the other senders are idle.
Occasionally, two devices can decide to transmit at the same time, and a data collision occurs where neither signal gets through. Each device recognizes when a collision occurs, and each one waits a random amount of time before trying to transmit again. For wired networks, this technology has become mostly obsolete due to the common practice of wiring each device individually to a port on a switch or a router.
Fig. 1: The Wi-Fi handshaking process This simple system for access control doesn’t quite work for Wi-Fi applications because of the complexities of working on a single radio frequency and because there is no way to guarantee that a station at one end of a coverage area will be able to sense the carrier of a radio at the other end of a coverage area.
Instead, a handshake has been developed between the APs and the clients to provide functions that are designed to eliminate collisions. This handshake process is illustrated in Fig. 1:
- • The sequence begins with a Distributed IFS gap time, which occurs whenever the radio channel is available for use by a new sending device.
- • A device that has data to send issues an RTS (Request To Send) packet, with information about itself, the intended destination, and the length of the packet that it wishes to send. Other devices that receive the RTS set a timer known as the Network Allocation Vector (NAV) based on the packet length and refrain from trying to use the channel until their timers expire.
- • The destination device that is addressed by the RTS packet waits a Short IFS gap time, and then sends a CTS (Clear To Send) message back to the originating device. Any device that receives the CTS and is not the original requesting device sets its NAV timer to wait before broadcasting. (The two NAV timers are somewhat redundant to cover the case when a device receives just one half of the RTS/CTS message pair.)
- • After another short IFS gap, the originating device sends the actual data to be transmitted, along with a header that contains the routing information for the packet (labeled H in the diagram). Each packet also includes a CRC (Cyclic Redundancy Check) value (not shown) that can be used to determine if any bit errors have occurred in the transmitted packet.
- • After another short IFS gap, the destination device responds with an Acknowledgment (Ack) message, indicating that the data has been received correctly. This is sent only if the CRC has been checked and no bit errors have occurred. If the sending device does not receive an Ack, it must assume that the message it sent was not received properly, and it must repeat this entire process to attempt to send the data again.
- • Once the Ack is transmitted, all devices can start timing the Distributed IFS gap, which must elapse before the next device can begin the process of sending a message.
From this simplified description of the Wi-Fi handshaking process, it is easy to see how message overhead impacts the overall system bandwidth, with gap times, acknowledgments for every packet, and the back-and-forth transmission setup process.
Furthermore, priority schemes such as WMM (Wireless Multi-Media, related to 802.11e) can’t resolve bandwidth resource conflicts when there are multiple, high-bit-rate cameras all set to the same “video” priority.
A WI-FI ALTERNATIVE
The 2.4 GHz and 5.8 GHz bands used by Wi-Fi networks are unlicensed within the United States and many other countries. These bands do not carry restrictions on data encoding or radio modulation, as long as RF power limits are obeyed. So, a new protocol can be used to make high-performance video work smoothly.
A TDMA (Time Division, Multiple Access) style protocol allocates bandwidth to applications that have predictable, near-constant bitrates. This technology converts the central AP into a control node for all of the remote clients, allocating transmission windows to each client on a round-robin basis. By doing this, overhead associated with the RTS/CTS/Ack handshaking can be avoided to improve channel utilization.
Fig. 2: The protocol for reducing bandwidth used for AP-to-client communication Also, the amount of bandwidth used for AP-to-client communication is reduced, freeing up more bandwidth for the clients to use. This protocol is illustrated in Fig. 2:
- • The AP issues an Authorization To Send (ATS) to client 1.
- • After a Short IFS gap, client 1 can transmit a data packet.
- • After another Short IFS gap, the AP issues an ATS to client 2.
- • Client 2 can then transmit data after a Short IFS gap.
This process can be scaled to more clients, and each client can send multiple packets of data during each window. The AP can choose to give larger or more frequent authorizations to clients with larger bandwidth needs.
For AP-to-client communication, an ATS can be delayed slightly while the AP sends data packets to one or more of the remote clients. With multiple clients each generating a high-speed, delay-sensitive video signal, this TDMA-like protocol can give each unit a repeatable, high-bandwidth link to a central display station or recording server.
CONCLUSION
For Web access, it is hard to beat the convenience of standard Wi-Fi networks. However, the overhead is not ideal for high-performance video. By replacing the Wi-Fi protocol in both AP and client devices with a protocol that is designed for high-bandwidth streaming, it is possible to greatly increase network throughput and collect video from a number of remote cameras simultaneously.
Thanks to Bob Ehlers of HauteSpot.net for help with the technical details of Wi-Fi and the TDMA-like protocol.
Wes Simpson is an industry consultant and author of “Video Over IP, Second Edition,” from Focal Press. Your comments are welcome tomailto:wes.simpson@gmail.com.
