Author: Neftaly Malatjie

As a basis for communications between the client devices and the application, most wireless systems implement either TCP or UDP. In either case, ensure that the client device successfully connects to the network and has a valid IP address. This can generally be done by observing the association table found in the access point. It is also a good idea to ensure that the client device is capable of responding to a ping generated from the same subnet where the application resides. The ping result should indicate that the client device responds to the ping with acceptable delays and not time out. If network connection tests indicate a problem, ensure that the client device has a valid IP address and you might want to upgrade the firmware on the client device, access points, or both.

After confirming that the client devices associate effectively with access points, the next step is to ensure that each of the client device types register successfully with the network and applicable applications. This involves protocols and processes that operate over the 802.11 protocols.

The WLAN must specific applications defined in the requirements, and to do so, it must be capable of passing a variety of tests. Association Tests Make sure that each of the client device types will associate with at least one or more access points that are part of the installed system. This is an initial test to see whether the client devices can establish a wireless connection, which primarily involves the 802.11 protocols and any vendor-specific enhancements. Confirm sufficient associations before moving on with other testing. This is important because sometimes client device radios are not fully compatible with the access points, even though they both comply with 802.11n. If you do not ensure that the client devices have stable associations, other performance tests may indicate erratic and inaccurate results.

For example, with a wireless IP phone implementation, the phone should have an indicator that confirms that association has been made. Power up the phone and check whether the phone indicates an association. If the phone will not associate with an access point, recheck the phone configuration, especially the service set identifier (SSID), authentication type, and security password. These parameters must match those configured on the access point for association to be successful. Also, ensure that you are operating the phone in an area where signal coverage exists. You can generally do this by observing the signal status on the phone. When performing an association test, connect the client device to an access point and monitor the connection for at least 10 minutes. In some cases, the client device may initially associate with an access point without any issues, but it might inadvertently disassociate after a few minutes. If problems occur, research similar problems regarding the types of client radios and access points that you are using, and upgrade the firmware if necessary to fix the problem. Sometimes you must upgrade the firmware in the client device radios, access points, or both, for the association process to work effectively.

When using survey tools to measure signal strength for generating signal coverage maps, be certain to take into account the 802.11 beacon intervals set in the access points or mesh nodes. The default beacon interval is generally 100 milliseconds, and the default setting for most survey tools is to measure signal strength on each radio frequency (RF) channel for 250 milliseconds (sometimes called the scan time). With these settings, you are assured of the access points or mesh nodes transmitting a beacon while the survey tool is measuring the signals on a particular channel. In fact, at least two beacons will occur during that time, so the survey tool will not miss any of the beacons. A possible problem may occur, however, if the beacon interval on the access points or mesh nodes is set to a longer value. For example, Tropos mesh nodes generally have default beacon intervals of 250 milliseconds. They do this to reduce overhead traffic (that is, beacons) on the network. In this case, if your survey tool is set to a scan time of 250 milliseconds or less, then there is a possibility that a beacon will not occur during the 250 milliseconds. In most cases, the scan time is adjustable. To ensure the survey tool you are using is measuring all possible signal data, it is a good idea to be certain that the scan time of the survey tool is greater than the beacon interval.

After installing a WLAN, it is important to perform as-installed signal coverage testing. This ensures that the WLAN is providing signal coverage in all required coverage areas based on the final positioning of access points. As with coverage testing done during a wireless site survey, as-installed coverage testing involves using a signal meter to measure signal values throughout the required coverage areas. As-installed coverage testing, however, does not use a test access point. The actual installed access points that comprise the WLAN generate the signals that the signal meter measures. In addition, instead of only testing specific locations, you walk through the entire facility and measure the signal values. The goal with as-installed coverage testing is to ensure that the signal coverage requirements are fully met by the installed access points. As with propagation testing done during a site survey, as-installed coverage testing requires you to determine minimum signals levels that constitute acceptable signal coverage. You can then utilize a signal meter to measure the signal values and generate coverage maps based on a minimum threshold. See Chapter 15 for more information about defining acceptable signal values for signal coverage. It is generally advisable to generate signal coverage maps for the facility where the WLAN is installed. Many of the signal meters specialized for performing site surveys include this feature. You load in floor plans of the facility, and the signal meter indicates where there is acceptable coverage based on the signal values that you have recorded during the testing.