This page contains a Flash digital edition of a book.
(e.g., G.711, G.728) to produce a low-bandwidth stream (e.g., 64Kbps, 16Kbps). Video sends longer packets, but frame size and compression still depends on encoding (e.g., MPEG-4, MPEG-2) which determines minimum acceptable throughput (e.g., 5Mbps, 20Mbps). However, because latency and jitter have such a significant impact, it is not enough to ensure that your network can transfer 64Kbps per call or 5Mbps per video. As a result, real-time video and voice goals are typically represented and measured using quality metrics. For voice, mean opinion score (MOS) and R-value are used to rate call quality (ranked from 1-5 and 1-100 respectively). For video, a common quality metric is media delivery index (MDI), which is composed of media loss rate (MLR) and delay factor (DF). Design targets for these metrics can vary, depending on the application, content encoding, device type, and what you are trying to achieve.

Where Should You Begin? Clearly, optimizing network performance for real-time

applications involves many components and parameters, integrated and tuned to meet or beat these design goals. Let’s consider a few critical pieces to this puzzle. Before even reaching the WLAN, mobile devices that run real-time applications require strong, reliable connectivity. This piece can be safely assumed for a desktop or notebook cabled to an Ethernet LAN, but varies over time for wireless devices—including notebooks in motion and handsets carried by users standing still but experiencing signal fluctuation due to RF interference. To deliver VoIP-grade wireless connectivity, most handset and AP vendors specify WLAN design goals, including maximum AP transmit power, minimum signal strength and signal to noise ratio (SNR), and delivery traffic indication message (DTIM) interval. Even though other real-time applications may have less stringent requirements, designing WLAN coverage to meet these goals gives you a fighting chance at achieving desired quality scores.

Prioritize and Optimize Inside the WLAN, traffic must be prioritized to ensure

that voice gets frequent predictable media access to keep jitter under about 10 ms. Because video requires more bandwidth, it should be prioritized under voice, but above best-effort data or background applications. This AP traffic queue and airtime prioritization can be accomplished by setting 802.11e (Wi-Fi Multimedia, WMM) defined access classes. When that traffic hits the wired network, WMM priorities should be mapped to 802.1p (Ethernet frame) or DiffServ Code Point (IP packet) header markings. Beware of “blind spots” in this mapping, such as when frames are tunneled from a WLAN controller to edge switch to core switch through a trunk port that does not provide 802.1p.

Avoiding Latency Even with prioritization, excessive competition for

scarce resources can still doom real-time applications. Here again, it’s important to evaluate this factor end- to-end, all the way from the channel to AP to controller, through Ethernet switches and WAN hops that must be traversed to reach the call manager, media server, or other real-time traffic destination. For example, channel competition can be managed by assigning voice handsets to their own SSID and frequency, using AP load balancing

and Call Admission Control to restrict the number of active calls per AP. When those packets hit Ethernet, they can stay segregated by mapping SSIDs to VLANs. However, those VLANs still compete for shared media

inside the wired network when relayed from APs to controllers and from controllers to switches. To address this, minimize the number of wired network hops a real- time packet must traverse and make sure that each hop provides sufficient capacity. You can achieve this by: • Employing distributed network architectures that permit direct client-to-client communication without tunneling real-time traffic back to a distant controller

• Estimating aggregate load on backhaul links and upgrade to Gigabit Ethernet where required to meet aggregate video throughput demands

• Eliminating low-speed or unreliable WAN link traversal by installing distributed real-time application servers in branch offices

In addition to packet flow optimization and capacity planning, look for other sources of latency and jitter that could be deal-breakers for real-time applications. For example, when mobile users roam from one AP to another (or enter/exit a dead zone) they may be required to re-authenticate. In a WLAN secured with 802.1X, this roam time can easily introduce unacceptable delay. Possible steps include virtual-cell solutions (which avoid channel changes), opportunistic key caching, 802.11r fast roaming, or using a faster method like WPA2-PSK to authenticate real-time clients. On the wired side, minimize dependency on a central

authentication server, take steps to reduce latency at intermediate choke points like firewalls, and consider whether and how to use IP multicast for streaming. The latter might surprise you – many WLANs do not handle IP multicast very well because data rates drop to satisfy the weakest (oldest or most distant) receiver. Even if you use IP multicast to reduce wired network load, consider WLAN products that convert wired-side multicast frames into wireless unicast frames that are uniquely-addressed to each client. This might be counterintuitive, but transmitting many frames at much faster data rates can actually consume less airtime, reducing latency for all clients using that WLAN.

Get the Most Out

of Real-Time Applications All of these pieces have a role to play in producing

voice MOS values, video MDI scores, and other real-time application performance metrics. Optimizing a network to support these demanding applications can be difficult, especially in a large enterprise network that includes a wide variety of client devices and applications. For best results, use real-time-aware performance test tools to measure MOS and MDI—both before and after network upgrades and expansions. If you cannot see what is going on, it is very hard to tune individual components and parameters to predictably and consistently achieve real-time application goals.




Page 1  |  Page 2  |  Page 3  |  Page 4  |  Page 5  |  Page 6  |  Page 7  |  Page 8  |  Page 9  |  Page 10  |  Page 11  |  Page 12  |  Page 13  |  Page 14  |  Page 15  |  Page 16  |  Page 17  |  Page 18  |  Page 19  |  Page 20  |  Page 21  |  Page 22  |  Page 23  |  Page 24  |  Page 25  |  Page 26  |  Page 27  |  Page 28  |  Page 29  |  Page 30  |  Page 31  |  Page 32  |  Page 33  |  Page 34  |  Page 35  |  Page 36