Think of it this way: Imagine you are in a hospital, and the hospital uses a WLAN for guest Internet access, employee email, and not-so-trivial things such as patient monitoring and lifeline/lifecare applications. The last thing you want as an administrator is for a guest or employee network request to consume all available bandwidth, making it impossible to transmit the lifeline application. Until
This brings WLAN usage reporting into play as an overall aspect of WLAN capacity planning. It really helps to understand which users and groups are consuming what bandwidth. WLAN usage reporting is generally a tool-based approach that allows network administrators to gain insight and visibility into the traffic and usage on the WLAN network. As with any tool-based approach, there are multiple directions that can be taken in order to ascertain the usage on the network.
There are several tools that can be used to gather information from the airwaves (sniffer-type captures) using a sensor-based approach (BlueSocket, AirDefense, AirMagnet), as well as network-management platforms that gather usage information from the APs (Cisco WLSE for SWAN, WCS for LWAP, AirWave, Aruba -- Mobility Management System, etc.). More or less every vendor provides a centralized tool that can be used to gather performance information, and they are all working toward capturing usage statistics that can be leveraged in capacity planning and charge-back models.
Most of the vendors that sell WLAN networks today tout the ability to provide performance and capacity planning, but the information provided by the majority of these vendors is information from the APs, not information regarding the applications traversing the APs. This is good information, but it is very critical to understand the actual traffic patterns and applications that are utilizing the bandwidth. For example, the vendor reports may show that AP number 1 is 80% utilized by users A, B, C and D; 80% capacity is generally a high threshold for upgrading capacity -- but what if 60% of that bandwidth represents non-mission-critical applications? You would be purchasing more bandwidth for applications that do not enhance your ability to deliver services over the installed infrastructure.
These tools are still evolving. AirMagnet, AirDefense and others like them have the ability to capture packets and provide information on the traffic, but these tools are positioned more as 24/7 security platforms. Sniffer and Ethereal provide WLAN sniffing capabilities, but these tools are more focused on expert analysis for troubleshooting.
You can use the following guidelines to evaluate and deploy usage-based tools within your environment.
- Statistics have to be gathered regarding the applications and their users on the WLAN. This means collecting not only bandwidth data but also source and destination IP addresses and port pairs. The tool should be able to distinguish among applications at the port level (FTP, TCP, UDP, HTTP, etc.).
- Unless you want to distribute collection agents throughout your environment (distributed model), you will need to set up collection of your data at the area of the network that provides the most WLAN traffic streams (the most centralized location of users/APs). This is using a probe/sniffer-based tool approach.
- Ensure that the tool you evaluate has the ability to store historical data and to provide trending over time.
Your best bet in the short term is to query the vendors whose tools you own today, find out what they have to offer for granular application-layer WLAN capture, and develop a roadmap to tools that can provide the granularity required for your environment.
Robbie Harrell (CCIE#3873) is the National Practice Lead for Advanced Infrastructure Solutions for SBC Communications. He has more than 10 years of experience providing strategic, business and technical consulting services. Robbie lives in Atlanta and is a graduate of Clemson University. His background includes positions as a principal architect at International Network Services, Lucent, Frontway and Callisma.
This was first published in June 2006