pointer

Keeping Wireless Streaming for the Olympics: Lessons Learned From Beijing

Last week, we covered how network administrators can prepare their system for the onslaught of Internet usage that is inevitable when a large sporting event like the Olympics happens, and employees decide to watch these events at work. For this week, we are focusing on how to troubleshoot and plan wireless and wired systems at an event like the Olympics.

Imagine that your company has been contracted to monitor and manage different networks at various locations at the Olympic games. This is exactly what happened with WildPackets during the 2008 Bejing Olympics . China Mobile was a major sponsor of the Olympic events and subsequently asked WildPackets to implement our OmniPeek network analyzer to proactively prevent wireless network outages at 14 Olympic venues, including the “Bird’s Nest” National Stadium where the opening and closing ceremonies were held. What an epic ceremony that was – check out the video here.

This year, we are not involved in the wireless at London. However from past experience, we wanted to give you a quick view into how to monitor and troubleshoot the various WLAN and Wi-Fi applications running throughout huge events like the Olympic games.

For this particular blog, instead of focusing on planning and designing a WLAN, which is essential for this event, let’s take a deeper look at how one manages users and ensures that they are able to stream those critical applications, like Instagram, via events’ wireless networks.

Managing Users on a WLAN
The precise topology of the WLAN changes as clients roam from one AP to the next. The topology can be expressed as a hierarchical tree, with the ESSs (all APs connected to the same Distribution System (DS)) at the top, then individual BSSs (individual APs and their clients), then the individual client nodes or stations (STAs).

It’s deceptively difficult to do large-scale wireless right. There is a limit to the number of STAs that can connect to each AP, so more APs are needed to provide service to large numbers. However, it requires careful planning to add more APs, because there are a limited number of non-overlapping channels.  If two APs on similar channels are too close to each other, their signals will cause interference with each other, and slow down the STA traffic on both APs.

When you are planning to manage the users at an event like the Olympics, it differs from managing a corporate WLAN system because the primary goal is different. In a corporate environment, the WLAN exists to allow users to access the network services in a secure fashion. Business users need email, internal servers, printers, and the Internet, usually in that order. Additionally, an enterprise network is usually encrypted with a login to let insiders have access and keep outsiders out. The lowest priority is guest network access.

At a large public event like the Olympics, the priority is often the reverse: guest access is most important. There is usually no password required to connect to the WLAN, but there is often a “captive portal” which requires users to agree to the terms of use, and potentially lets users pay for the access. That means that the captive portal needs to be scalable, just like the WLAN itself, or there will be a long and frustrating wait to get Internet access.

Rogue Access Points are a Pain in Public WLAN
The 2012 London Olympics has received some criticism for banning use of personal wireless hotspots. While some articles have speculated that the ban is to ensure that spectators pay to use the BT-provided Wi-Fi network, there are solid technical reasons that personal Wi-Fi shouldn’t be used in an environment with a high AP density. Personal Wi-Fi is essentially a small AP, whether it’s a dedicated device or a tethered smartphone. Adding too many APs causes interference, reduces the ability of people to connect to the WLAN, and slows down their connection once they’re online. One person could affect 100 nearby people, so even if only 1% of the total crowd has a personal hotspot, the impact could be substantial.

This problem isn’t just theoretical. At the Waldo Canyon fire in late June 2012, an engineer from the Cisco TACOPS Network Emergency Response Vehicle tweeted that there were WLAN network problems because there were so many different agencies – and individuals – with their own APs. Eventually they were able to get stable network access, as he tweeted,

“The WLAN is stable because we can crank the power like nobody else here can, but it shouldn’t be necessary.”

We at WildPackets have seen similar problems, albeit in far less dramatic environments. At a recent trade show, we detected over 200 different APs in the vendor expo room, most with different BSSIDs. We were also guilty of adding to the problem, as we had our own AP, but even so we had difficulty getting our equipment to connect reliably, even in our booth!

Ensuring Wi-Fi Applications are Running Smoothly
Application performance relates to the time it takes an application to respond to a specific user request, measured from the user’s perspective, through either the network and/or the web services infrastructure. When it comes to the Olympic games, you will have plenty of people trying to access different applications, and it is the network administrators job to determine if users are satisfied, and if not, what is causing the dissatisfaction.

Now it could be the application, for example, last Thursday it was stated that Twitter was down due to the Olympics, which cannot be fixed by the network engineer, but sometimes it is the network and that is a problem that you need to fix. In order to determine if it’s the application or the network, you need deep-packet inspection.

With packet-based analysis, you can inspect and even visualize the conversation between a client and a poorly performing application, packet by packet, to determine what’s causing the delay – network or application. A user request followed by a quick network acknowledgement (ACK) but a delayed data response is indicative of an application issue, while delayed or even missing ACKs indicate a network issue. Often times when the responsiveness of application data is poor, the application data payloads themselves contain detailed clues as to why – for example – database error codes embedded in the data packet payload.

Another quick tip on this is that network issues are shown through slow acknowledgements, TCP slow segment recovery, slow and frequent retransmissions, and low throughput. Application problems manifest themselves in slow HTTP response times (for web-based applications), slow database response times, and inefficient client errors. This can also provide you with a quick understanding that it is a network or application issue, however to unequivocally ensure that it is the network or the application, you must look at the packets.

As the Olympics are in full force, it is always interesting to learn about who and what are behind the power that it takes to make these events run. Although not a lot of people are thinking about the network when they are cheering for their country, the network is one of the most essential factors at these events—keeping people up-to-date on what is happening at each event and generally connected to the world at large.

Let us know if you have any other specific question about wireless at the Olympic games. We will try to cover and explain what we can!

One thought on “Keeping Wireless Streaming for the Olympics: Lessons Learned From Beijing

Leave a Reply