Wi-Fi Location-Based Services 4.1 Design Guide
Best Practices—Location-Aware WLAN Design Considerations
Downloads: This chapterpdf (PDF - 5.64 MB) The complete bookPDF (PDF - 9.66 MB) | Feedback

Best Practices—Location-Aware WLAN Design Considerations

Table Of Contents

Best Practices—Location-Aware WLAN Design Considerations

Minimum Signal Level Thresholds

Access Point Placement

Access Point Separation

Determining Location Readiness

Location, Voice and Data Coexistence

Avoiding Location Display Jitter

Multiple Location Appliance Designs

Single Management Domain with Multiple Location Domains

Multiple Management Domains with Multiple Location Domains

Antenna Considerations

Third-Party Antennas

Antenna Orientation and Access Point Placement


Calibration Validity

Tips for Successful Calibrations

Data Collection

Calibrating Under Representative Conditions

Recommended Calibration Clients and Techniques

Calibration of Non-Uniform Environments

Inspecting Location Quality

Using Test Points to Verify Accuracy

Best Practices—Location-Aware WLAN Design Considerations

In the past decade, the design of enterprise-ready wireless LANs has evolved from being centered around the model of maximum coverage with minimum AP count to a model where coverage uniformity and proper cell-to-cell overlap are the predominant concerns. This has been driven by increasing interest in deploying new wireless applications such as wireless voice with its intolerance jitter and high roaming delays. In a similar fashion, deploying location-based applications using a Wi-Fi wireless LAN requires augmenting our traditional approaches, both in the design of "greenfield" location-aware installations as well as the augmentation or retrofit of existing designs.

This chapter describes best practices that should be followed in designing and deploying location-aware wireless LANs and includes the following main sections:

Minimum Signal Level Thresholds

Access Point Placement

Access Point Separation

Determining Location Readiness

Location, Voice and Data Coexistence

Avoiding Location Display Jitter

Multiple Location Appliance Designs

Antenna Considerations


Inspecting Location Quality

Using Test Points to Verify Accuracy

Minimum Signal Level Thresholds

For mobile devices to be tracked properly, a minimum of three access points (with four or more preferred for better accuracy and precision) should be detecting and reporting the received signal strength (RSSI) of any client station, asset tag, or rogue device being tracked. It is preferred that this detected signal strength level be -75dBm or better.

Note As of WLAN controller software Release, each tracked entity (WLAN client, RFID tag, rogue access point, or rogue client) is detected by up to sixteen registered access points at any time on each WLAN controller. This helps to improve the tracking of devices in motion across many access point coverage cells by assuring that the latest device RSSI is properly reflected.

When performing a site survey of an area where clients or tags are tracked, the RSSI of representative devices should be verified to ensure compliance with the minimum number of recommended access points and the recommended detected signal strength. This should be performed via one of two techniques:

Viewing detected RSSI for the client or asset tag using the show client detail <mac address> or show rfid detail <mac address> controller CLI command, as shown in Figure 5-1.

Viewing detected RSSI for the client or asset tag using the location floor map GUI, as described in Figure 5-2 and Figure 5-3.

Figure 5-1 Checking Client RSSI at the WLAN Controller

In either case, these techniques should be used with representative test clients or asset tags in the area where localization is desired. When performing this check, it is important to ensure that all access points and antennas are installed and representative of the final configuration. The maximum transmit power level supported as well as the probing behavior of the test client should be as close as possible to that of the production clients you wish to track. Figure 5-1 indicates that the output of the CLI command displaying the signal strength of the client as detected by all of the access points detecting the client, registered to the same controller. In situations where the detecting access point registrations are distributed among two or more controllers, more than one CLI session is required. From the information provided within the red rectangular area in Figure 5-1, it can clearly be seen whether or not the client in question is being detected by three or more access points at the recommended signal strength level or better. In a similar fashion to that shown for WLAN clients in Figure 5-1, the CLI command show rfid detail <mac address> can be used to display detected RSSI information for an asset tag.

This same information can be obtained graphically via the location map GUI by clicking on either a WLAN client icon (blue rectangle) or asset tag icon (yellow tag), enabling the location debug checkbox and then enlarging the miniature location map as shown in Figure 5-2 and Figure 5-3.

Figure 5-2 Enabling Location Debug

Figure 5-3 Displaying Detected RSSI via the GUI

Access Point Placement

Proper placement of access points is one of several best practices that should be adhered to in order to unleash the full performance potential of the location-aware Cisco Unified Wireless Network. In many existing office wireless LANs, access points are distributed mainly throughout interior spaces, providing service to the surrounding work areas. These access point locations have been selected traditionally on the basis of coverage, WLAN bandwidth, channel reuse, cell-to-cell overlap, security, aesthetics, and deployment feasibility. In a location-aware WLAN design, the requirements of underlying data and voice applications should be combined with the requirements for good location fidelity. Depending on the particular site, the requirements of the location-aware Cisco UWN are flexible enough such that the addition of location tracking to voice installations already designed in accordance with Cisco best practices, for example, may not require extensive reworking. Rather, infrastructure already deployed in accordance with accepted voice best practices can often be augmented such that location tracking best practice requirements are met as well, (such as perimeter and corner access point placement, for example) depending on the characteristics of the areas involved.

In a location-ready design, it is important to ensure that access points are not solely clustered in the interior and toward the center of floors. Rather, perimeter access points should complement access points located within floor interior areas. In addition, access points should be placed in each of the four corners of the floor, and at any other corners that are encountered along the floor perimeter. These perimeter access points play a vital role in ensuring good location fidelity within the areas they encircle, and in some cases may participate in the provisioning of general voice or data coverage as well.

If using chokepoint location, verify that all areas planned for chokepoint trigger installation are clearly within the range of your access points. In addition to ensuring that messages transmitted by asset tags located within chokepoint areas are properly received by the system, proper planning can help assure that asset tags can be tracked using RF Fingerprinting as they approach and exit chokepoints. The ability to track asset tags using RF Fingerprinting complements the system's ability to locate tagged assets within chokepoint areas using highly granular chokepoint location techniques.

The access points that form the perimeter and corners of the floor can be thought of as outlining the convex hull or set of possible device locations where the best potential for high accuracy and precision exists. By definition, the convex hull of a set S of points, denoted hull(S), can be regarded as the smallest polygon P for which each point of S is located either on the boundary or within the interior of P.

Figure 5-4 illustrates the concept of a convex hull. In Figure 5-4, assume the set of access point locations is denoted by the black dots, which we refer to as set S. The convex hull of set S, or Hull(S), is figuratively represented as an elastic band (shown by the blue line) that is stretched and allowed to snap over the outermost members of the set (which in this case represents perimeter and corner access points).

The interior area encompassed by this band (depicted in green) can be considered as possessing high potential for good location accuracy. As tracked devices stray into the area outside the convex hull (outside the green area in Figure 5-4), accuracy can begin to deteriorate. Although it may vary given the number of access points deployed and their inter-access point spacing, generally speaking, the rate of this accuracy degradation has been seen to be almost linear as the tracked device moves further and further outside the convex hull. For example, a device that experiences less than or equal to 10m/90% accuracy within the convex hull may deteriorate to 18m/90% by the time the device moves to a point 20 feet outside it.

Figure 5-4 The Convex Hull of a Set of Points

In order to assure proper convex hull establishment around the set of location data points possessing high potential for good accuracy, access points should be placed in each corner of the floor, as well as along the floor perimeter between corners. Inter-access point separation along the perimeter should be in accordance with the general access point separation guidelines (described in a subsequent section). The designer may reduce this spacing if necessary, in order for these access points to participate in the provisioning of voice or data service to the floor.

Figure 5-5 provides an illustration where these concepts are applied to a floor with a type of floor plan found in many enterprises (that of rooms or offices contained by and surrounding an interior corridor). In this case, the area in which we desire to locate tracked assets is the entire floor. In Figure 5-5, note that the access points located towards the center of the floor are complemented by those that have been placed along the perimeter. As is the case in most proper location-aware designs, the set of location data points possessing the highest potential for good location accuracy is contained within the convex hull, which in Figure 5-5 is represented by the blue rectangle and encompasses the entire floor.

Figure 5-5 Proper Access Point Perimeter Placement

In some cases, customer preferences or deployment restrictions may factor into the access point placement decision, and the placement of access points at the floor perimeter may be restricted in one way or another. While this still may result in acceptable placement from the perspective of providing basic RF coverage, because there may be significant areas where asset tracking is required outside the access point perimeter (and thus outside the convex hull), such placement may lead to reduced location fidelity in those areas.

Figure 5-6 illustrates an example of a less-than-desirable situation where the placement of access points has been restricted to hallway corridors and administrative/storage facilities located within the areas encircled by the corridors. For aesthetic reasons, facilities management has decided that access points will not be placed within any of the executive offices or conference rooms located between the hallway corridors and the physical perimeter. Because of these restrictions, our convex hull now lies at the outside edge of the corridor (indicated by the blue rectangle) and not at the true physical perimeter of the floor.

Figure 5-6 Artificially Constrained Access Point Perimeter

Given what we know about the distribution of location errors when operating outside the convex hull, it is logical to expect that location accuracy will not be as good in the offices and rooms located there. These areas of potentially lower accuracy are highlighted in red in Figure 5-6.

With our recommendation of establishing the convex hull at the true floor physical perimeter notwithstanding, in practice the difference in location error rate between points located within the convex hull and outside it may be tolerable in some situations. These might include situations where such areas extend beyond the office perimeter for only a short distance (for example, small 10x10 foot rooms lining the walls of a corridor). For example, looking at the areas highlighted in red in Figure 5-6, the potential increase in location error would be less in the smaller offices located at the right side of the floor plan than in any other affected area. Depending on magnitude, the effect of operation outside the convex hull will likely be the least. In contrast, the areas at the bottom of the floor plan, with larger offices and multiple wall partitions, would be potentially effected to a significantly higher degree.

In cases where access point placement in perimeter offices and conference rooms is restricted due to aesthetic concerns, a potential compromise may be possible using a very low profile antenna (such as the Cisco AIR-ANT5959 or Cisco AIR-5145V-R) along with access point mounting in a plenum-rated enclosure (where permitted by local codes). This would offer the ability to mount access points at the proper perimeter and corner locations (thereby avoiding the quandary described in Figure 5-6), but with minimal visible footprint to the casual observer.

As mentioned earlier, the floor plans shown in Figure 5-5 and Figure 5-6 are commonplace, but by no means exclusive. For example, some modern building designs may possess hallway corridors that are located directly alongside the actual floor and building perimeter, typically allowing a panoramic view of campus environs as visitors move about between offices and conference rooms. In this case, all offices and conference facilities are located within the area between the corridors and the center of the floor. Figure 5-7 provides an illustration of such a floor plan. Note that with this floor layout, placement along the outer edge of the hallway corridor places the access points along the actual physical perimeter, by default.

Figure 5-7 Perimeter Corridor Floor Plan

Figure 5-8 provides simple illustrations summarizing the access point placement concepts discussed in this section so far. Note that designs that make use of only clustered or straight-line access point placement should be augmented or redesigned in favor of those that combine center access-point placement with perimeter and corner placement.

Figure 5-8 Basic Example of Location-Aware Access Point Deployment

If possible, mount antennas such that they have an unencumbered 360º view of all areas around them, without being blocked at close range by large objects. For example, if possible, avoid placing access point antennas directly against large objects such as steel columns, as illustrated in Figure 5-9. One option is to mount the access point along with its antennas to a ceiling location (provided that this allows an acceptable mounting height). Another option is to use short, low loss cable extension to allow separation between antennas and such obstructions.

Figure 5-9 Access Point Mounted Directly to Steel Column

Additional discussion of proper access point placement can be found in Cisco Wireless Location Appliance: Deployment Guide at the following URL: http://www.cisco.com/en/US/products/ps6386/prod_technical_reference09186a008059ce31.html.

Access Point Separation

The distance between deployed access points can impact location performance, as well as the performance of co-resident voice and data applications. From a location perspective, while location tracking inter-access point spacing requirements tend to be relatively flexible and supportive of the coverage needs of underlying applications, very small or very large inter-access point separation distances are usually best avoided.

An excessive inter-access point distance1 can detract from good location accuracy by not providing sufficient signal strength differentiation at extended distance. Insufficient inter-access point distance can expose the system to short range antenna pattern anomalies, which may also be non-conducive to good location accuracy. From the perspective of co-resident voice and data applications, the inter-access point distance is one of the key factors determining whether required minimum signal level thresholds, data rate thresholds, signal to noise ratios (SNR), and required coverage overlap will be met. From a location accuracy perspective, the range of acceptable inter-access point distance tends to be rather broad, and can provide excellent location accuracy while accommodating the needs of most co-resident voice and data applications.

The techniques incorporated in the location-aware Cisco UWN to localize tracked devices operate most effectively when RSSI and distance are seen to possess a clearly monotonic relationship. To better understand what is meant by this, we examine a simulated plot of a tracked device's detected RSSI as the distance between it and a detecting access point is increased (see Figure 5-10). While the relationship between RSSI and distance varies depending on different combinations of antenna, antenna height and environmental characteristics, the graph shown in Figure 5-10 for an access point mounted at approximately twelve feet elevation can be used to better understand the concepts discussed here.

Figure 5-10 An Example of the Relationship Between RSSI and Distance

In Figure 5-10, we see that beginning at some point a fairly near the access point, and ranging to another point c further in distance, the two variables exhibit a strict monotonically decreasing relationship (as distance between the tracked device and the access point increases, the RSSI at which the access point detects the device is shown to decrease). Between point a and another point b, the amount of change in RSSI (dBm) that occurs per-unit change in distance (feet) is highly consistent, approximately -5 dBm per 20-foot change in distance. This results in the slope of the graph between points a and b being fairly steep. As the distance continues to increase beyond point b, the slope of our graph begins to diminish and the level of RSSI differentiation decreases, providing increasingly less differentiation in received signal strength per-unit change in distance. Note that the slope of the graph between points b and c is not nearly as steep as it is between points a and b. As distance begins to significantly exceed point b in this example, the slope of the graph will diminish even further. This greatly reduced slope and steepness results in a decreased level of differentiation in signal level with increasing distance. When this occurs at extended distances, it becomes more difficult to accurately predict changes in distance based on detected changes in RSSI (lateration).

The risk of this lack of RSSI differentiation having a significant impact on location accuracy can be reduced if steps are taken to avoid areas of the RSSI versus distance curve where this phenomena is known to exist most prominently. In general, for access points deployed indoors at antenna heights of 20 feet or less, this can be achieved if the range of any point on the floor to at least three detecting access points on that floor (one in each of at least three of the four quadrants surrounding it) is maintained within approximately 70 feet in an indoor environment. This is a general recommendation that is intended to assist designers in avoiding situations where excessive inter-access point distance may be a contributing factor to location inaccuracy. As shown in Figure 5-10, diminished RSSI differentiation with increasing distance is a gradually increasing phenomenon, therefore, a degree of flexibility is implied in this recommendation.

In practice, in addition to being conducive to good location accuracy, this recommendation applies well to deployments where location tracking is deployed in conjunction with other WLAN applications (such as voice and high speed data) in accordance with current recommended best practices. This is especially true for environments where the expected path loss exponent is 3.5 (walled office environment) or higher, as the required inter-access point spacing tends to generally fall within this range. In addition to the potential effects of a lack of RSSI differentiation at distance extremes, inter-access point distances significantly greater than 70 to 80 feet can make it more challenging to satisfy the best practice signal strength and overlap requirements of VoWLAN devices such as the Cisco 7921G and the Vocera Communication Badge in environments with high path loss.

At ranges closer than point a in our example, propagation anomalies that are due to the elevation pattern of the chosen antenna, the antenna's installation height, and the current physical location of the tracked device can potentially combine to degrade monotonicity. As a result, RSSI cannot be depended on as a reliable predictor of distance in this part of the curve, since it may be possible that more than one equally likely value for distance exists at a particular detected RSSI level. Figure 5-11 illustrates this case, depicting how a tracked device's RSSI reading of -40dBm can be associated with three different distances (5, 7, and 12 feet) from the access point antenna when operating in this close-range non-monotonic region of the RSSI versus distance graph. This behavior is typically the result of a variation in an overhead antenna's propagation pattern as a device approaches it begins to venture into the area almost directly beneath it. Obviously, these effects vary depending on the propagation pattern of the specific antennas used and their installation height above the area where tracked devices is located. However, the lesson to be learned from this is that although increased access point density can often be conducive to better location accuracy, the effect is not without its limits.

Figure 5-11 Example of Close-Range Non-Monotonicity

Clearly, such RSSI ambiguity can be confusing, especially when attempting to use RSSI to accurately laterate distance. Such ambiguous behavior is generally not conducive to good location fidelity. In tests conducted with access points at an installed height of 10 feet in with 2.2dBi omni-directional antennas in an environment with a path loss exponent of 3.4, this behavior could sporadically be observed out to a distance of almost 14 feet. In the specific case of this example, it would be best to maintain the inter-access point spacing above 28 feet (in other words, twice the distance at which such behavior would be expected) in order to reduce the potential of this phenomena occurring.

In some application designs, it may be desirable to deploy multiple access points on non-overlapping channels in order to potentially increase the amount of RF bandwidth available to users2 ("collocated non-overlapping access points"). This approach is often seen in classrooms and conference halls where there may be a large number of mobile users. If location tracking of WLAN clients and other devices is desirable in situations where some rooms may possess several collocated access points, it is suggested that the co-located access points not be deployed within very close proximity (i.e. a few feet) of each other. Rather, every attempt should be made to obtain as much separation as possible between these co-located access points, so as to avoid any of the close-range effects that can be detrimental to good location fidelity. One way to accomplish this for co-located access points in a lecture hall, for example, would be to place the access points on different walls and perhaps the ceiling as well, with appropriate inter-access point spacing.

In general then, most indoor location tracking deployments with access point antennas installed at heights of between ten and twenty feet can be well served with an inter-access point spacing of between 40 and 70 feet, especially when combined with the signal threshold and access point placement recommendations suggested in the preceding sections of this document. In some cases however, inter-access point spacing below 40 feet may be necessary to satisfy the requirements of some applications for high signal strength thresholds, especially in environments where high path loss is present. An example of this might be a voice application deployed in such an environment (for example, a path loss exponent of 4.0 where a high degree of environmental clutter is present). Best practices for Cisco 7921G VoWLAN deployments would suggest a minimum signal level of -67dBm, 20% inter-cell overlap and signal to noise ratio of 25 dB for 802.11g in this type of situation. Applying these requirements mathematically, we calculate an estimated cell size of 24 feet and an inter-access point spacing of 33 feet. In this case, in order to deploy our voice application in accordance with recommended best practices, the inter-access point spacing should be reduced below the general guideline of 40 feet. Note that good location accuracy is achievable at inter-access point ranges below 40 feet, provided that the access point spacing is not decreased so much that the negative effects of close range non-monotonicity come into play. Generally, this should not be an issue if the inter-access point distances are above 25 to 28 feet when using low gain, omni-directional antennas mounted at an installation height of approximately 10 feet in an indoor environment.

Figure 5-12 illustrates an example of access point placement and inter-access point spacing, offering a foundation for a location-aware design. The environment in Figure 5-12 consists of drywall offices and cubicle office spaces with a total space of approximately 275 feet by 159 feet. Taking into consideration the location tracking requirement for illustrative purposes only, our inter-access point linear-spacing recommendations of 40 to 70 feet suggests approximately 22 location-aware access points as an initial estimate. Incorporating the placement strategies made in preceding sections, interior, perimeter, and corner access points are placed to facilitate multi-lateration and establish a clearly delineated convex hull around the floor.

Note In an actual installation involving WLAN applications deployed in conjunction with location tracking, interior access point design should be conducted prior to instituting design modifications in support of location tracking modifications to ensure that best practice recommendations for signal strength, overlap and signal to noise ratio requirements of data and voice applications are met.

Figure 5-12 An Example of Location Aware Access Point Placement

WCS includes a planning tool that allows designers to model "what-if" design scenarios. The WCS Planning Tool is accessible via the Monitor > Maps > floormapname > Planning Mode dropdown menu selection. This is a predictive modeling tool that is used on a per-floor basis to provide initial guidance on access point placement, as well as an interactive representation of predicted access point signal strength and data rate information. It can be safely used without impacting any actual deployment of access points that may already be in service. The WCS Map Editor is accessible from the top line hyperlink bar of the planning tool, and can be used to add wall attenuation information to floor maps. Wall information added via the Map Editor does not affect access point placement or location designs, however, it will be used by the planning tool when displaying predicted RF coverage maps for planned access points.

The planning tool operates purely on a hypothetical basis without the need to connect or deploy any access points or controllers. Since it is WCS feature, a WCS server must be installed somewhere in network before the planning tool can be used. If there are any existing access points that have been deployed and defined to WCS already, the planning tool allows for the configuration of those access points to be copied into the planning virtual environment, allowing you to safely model with a virtual copy of your production environment.

Before using the planning tool for RF coverage planning, ensure that an appropriate path loss model has been assigned to the floor upon which you wish to conduct your planning. WCS will use the coverage reference path losses and path loss exponents when it plots the predicted coverage heatmaps from each access point in the planning tool. Seasoned WLAN veteran designers have the option of using the planning tool in a manual mode to place access points on floor maps as they see fit and adjust several criteria in order to see their effect (such as transmit power, antenna type, and so on). Alternatively, the WCS planning tool also allows automated access point placement based on the type of deployment model desired. Those users and designers desiring that the system make an initial design suggestion can use the planning tool in an automated mode, thereby specifying the type of design they wish and allowing the planning tool to examine their requirements and make qualified suggestions. For designers wishing to combine voice and data designs meeting Cisco VoWLAN best practices with location tracking, it is recommended that the planning tool be first used to model voice and data designs separately from location tracking requirements. Once a satisfactory voice and data design has been created, any modifications necessary to provide for good location fidelity can then be manually incorporated.

The planning tool assumes a transmit power of +18dBm for 802.11bg and +15dBm for 802.11a, along with an antenna azimuth position of 180º, elevation height of ten feet and elevation angle of 0º. Transmit power, access point type, antenna type, and azimuth position can be changed individually for each access point. In addition, planning tool users can specify a several additional criteria to further fine tune data and voice designs.

Note For complete information about planning tool options (such as data/coverage, voice, location, demand and override) consult the chapter Using Planning Mode to Calculate Access Point Requirements found in the document entitled Cisco Wireless Control System Configuration Guide, Release 4.1 at the following URL: http://www.cisco.com/en/US/docs/wireless/wcs/4.1/configuration/guide/wcsmaps.html#wp1104248.

Selecting the location planning option results in the planning mode access points being placed along the perimeter and in the corners of a floor, in addition to the interior of the floor as necessary. At least four access points are assumed to be present in every location design, and access points are placed using a spacing of up to 70 feet. Note that when using the location planning option, the resulting design may meet best practice recommendations for voice and data, although the signal strength and overlap requirements of co-resident applications are not explicitly taken into account. Therefore, in designs where location tracking is intended to co-reside with voice and high speed data, it is recommended that these application designs be addressed first, according to Cisco-recommended best practices. Once a design satisfying application needs has been completed, the design can then be modified or augmented as necessary to meet location tracking requirements.

Prior to software Release 4.1, the automated placement capabilities of the planning tool were limited to floors and buildings whose shapes were simple polygons, such as squares and rectangles. A new capability added in this release allows the planning tool to accommodate irregularly shaped floor areas. To accomplish this, an irregular coverage perimeter is drawn using the WCS Map Editor and when saved, becomes available for use in the planning tool. When designing new floor layouts using the planning tool, the user is allowed to choose between using the traditional closed polygon or the newly created irregular shape. Further information on this newly introduced capability can be found in the chapter Using the Map Editor to Draw Polygon Areas in the document entitled Cisco Wireless Control System Configuration Guide, Release 4.1 at the following URL: http://www.cisco.com/en/US/docs/wireless/wcs/4.1/configuration/guide/wcsmaps.html#wp1104253.

With this enhancement, the planning tool becomes more useful to designers when working with common buildings having irregular shapes, such as a building with an open courtyard as shown in Figure 5-13. In Figure 5-13, we see a location design performed using the automatic planning tool mode. Note the red outlined perimeter of the building, which was added to the floor image using the Map Editor and is now eligible for use within the planning tool.

Figure 5-13 Using WCS Planning Tool with an Irregularly Shaped Floor Plan

More complex designs containing totally enclosed interior voids (for example, a building with a fully enclosed interior atrium as shown in Figure 5-14, with the perimeter of the building shown by a red outline) may not lend themselves well to automatic access point placement. The planning tool does not currently allow the exclusion of zones into which access point placement should not occur. Note in Figure 5-14 the placement of access points 2, 4, 9 and 24 in the atrium area (indicated by the blue outline). The placement of these access points in this area is incorrect, since the floor map is for the building's third floor. This should be corrected by manual intervention and moving the access points into correct locations or eliminating them entirely if not necessary.

Figure 5-14 Example of Floor Plan with Fully Enclosed Interior Atrium

Determining Location Readiness

The Inspect Location Readiness feature (Monitor > Maps > floormapname > Inspect Location Readiness) allows the network designer to perform a quick predictive check of the location performance for a floor before time is invested in pulling cable, deploying equipment, and performing calibrations. Inspect Location Readiness takes into consideration the placement of each access point along with the inter-access point spacing indicated on floor maps to predict whether estimated location tracking accuracy will be within 10 meters in 90 percent of all cases. The output of the location readiness inspection is a "go / no-go" graphical representation of the areas that are predicted to be likely candidates for producing this level of accuracy, as well as those that are not.

Note that unlike the planning tool described earlier, the location readiness tool assumes that access points and controllers are known to WCS and have been defined on the WCS floor maps using Monitor > Maps > Position APs. While it is not necessary to actually install access points and antennas on walls and ceilings in order to conduct a location readiness assessment, you must add any applicable controllers to WCS along with their registered access points, and place the icons representing the access points on the appropriate floor maps. In order to do this initially, all such controllers and access points must be physically present, powered on and online to the network. These access points and controllers need not be deployed and installed, they can be on a floor, tabletop or other temporary location, as long as the access points and controllers are capable of communicating with WCS. The Cisco Wireless Location Appliance need not be present in order to conduct a location readiness assessment.

Once the access points that you wish to place on floor maps have been added to the WCS database, subsequent location readiness assessments can be conducted using these same access points, even if they are not reachable from WCS at that time. Because the location readiness inspection is based on access point placement and the inter-access point distances shown on the floor maps, accurate map placement of access points is very highly recommended. The location readiness tool is used to only assess the preparedness of the design to perform RF Fingerprinting-based location tracking. It does not validate any aspect of the design to perform chokepoint location, especially with regard to the definition or positioning of chokepoint triggers. After access point placement has been performed, select the floor map that you wish to verify the location readiness of and then choose Inspect Location Readiness from the upper right-hand dropdown command menu.

A point is defined as being "location-ready" if the following are all determined to be true:

At least four access points are deployed on the floor

At least one access point is found to be resident in each quadrant surrounding the point-in-question

At least one access point residing in each of at least three of the surrounding quadrants is located within 70 feet of the point-in-question.

Figure 5-15 illustrates our three location readiness rules, where the green and yellow circles represent access point locations and the point-in-question is represented by a red dot.

Figure 5-15 Definition of a "Location-Ready" Point

Figure 5-16 shows an example of a floor deployment where not all areas have passed three-point location readiness assessment described earlier for 10m/90% accuracy. Although there are green areas toward the center of the figure, notice that red areas abound as you get beyond the perimeter access points representing the convex hull.By establishing a solid understanding of the requirements that define location readiness, the information contained in Figure 5-15 can be used to help determine how access points may be required to be relocated (or additional access points introduced) to improve performance. For example, if 10m/90% or better location accuracy is required within the red areas, additional access points could be introduced to establish a more clearly delineated floor perimeter, including the placement of access points in the corners of the floor and re-checking inter-access point distances. By implementing these types of modifications, the ability of the Cisco UWN to resolve the location of tracked devices in these highlighted areas is likely to be significantly enhanced.

Figure 5-16 Example of Location Readiness Tool Usage

Once again, keep in mind that location readiness inspection is a distance-based predictive tool. As is the case with most predictive tools, it can be expected that some degree of variance will occur between predicted and actual results. Cisco recommends that the location readiness tool be used in conjunction with other best-practice techniques outlined in this document, including the location quality inspection.

Location, Voice and Data Coexistence

The location-aware Cisco Unified Wireless Network is a multi-purpose wireless platform that allows enterprises to bring consistency and efficiency to their business processes, providing increased overall effectiveness. A key advantage of the location-aware Cisco UWN is the integration and the cost advantage that stems from its ability to perform high quality location tracking of clients, asset tags and rogue devices with only reasonable additional investment required beyond that necessary to support other enterprise wireless applications, such as VoWLAN and high speed data.

Note This section describes the pertinent characteristics of voice and data designs only as they relate to co-existence with the location tracking capabilities of the Cisco UWN. For a more comprehensive examination of Cisco Unified Wireless Network VoWLAN solution design and Cisco recommended best practices, refer to the Voice Over Wireless LAN 4.1 Design Guide which can be found at the following URL:

Note For a more comprehensive examination of the Cisco Unified Wireless Network data solution design and best practices, refer to Enterprise Mobility 4.1 Design Guide at the following URL: http://www.cisco.com/go/srnd.

When architecting VoWLAN and high speed data designs and determining subsequent access point placement, the primary concerns of the designer should include:

Minimum desired cell signal level threshold—For example, when designing VoWLAN solutions that involve the Cisco 7921G VoWLAN handset, current VoWLAN best practices suggest a minimum planned signal level threshold of -67dBm. Other voice devices may have differing requirements (such as the Vocera Communications badge, which requires a signal level threshold of -65dBm). Requirements for data devices will depend on the transmission rate that they are required to operate at. Lower speed devices (such as handheld bar code or RFID computers that operate at data rates up to 11 Mbps) typically do not have very demanding minimum signal requirements, often times in the range of -73 to -76 dBm. Data devices used to pass streaming multimedia and other bandwidth-intensive applications will typically require higher data transmission rates and consequently, higher minimum signal levels.

Signal to Noise Ratio (SNR) —This is the ratio of the signal strength at the receiver to the noise floor, and is measured in dB. Since both components of the ratio are specified in dBm, the SNR can be calculated by simply subtracting the noise value from the signal strength value. The minimum required SNR for a receiver to operate properly varies depending on construction of the receiver, as well as the bit rate or modulation it is expected to operate at. A typical example is shown below:

Transmission Rate (Mbps)













Signal to Noise Ratio (dB)













Ensuring the existence of sufficient SNR is very important when designing for robust and reliable wireless application support. This is especially so in wireless voice applications, where it is necessary to ensure that a high percentage of packets are successfully decoded in each cell and jitter is kept to a minimum. For example, with a Cisco 7921G VoWLAN handset the recommended SNR to ensure a good user VoWLAN experience is 25 dB. Keep in mind that if the signal to noise ratio is insufficient due to a high noise floor, proper operation of the wireless device may be difficult to achieve in spite of high overall received signal levels. SNR and minimum received signal levels should be considered together in order to assure that a new deployment has met design standards and is ready for production pilot testing.

Data rate—Data bit rates are enabled or disabled via the wireless infrastructure, with minimum signal level thresholds and the signal to noise ratio determining which of the enabled bit rates will actually be usable. For example, with the Cisco 7921G, the combination of a -67dBm minimum signal level and a 25dB signal to noise ratio generally makes the use of 24 Mbps or greater data rates possible.

Cell-to-cell overlap—In a very simple sense, we can think of each of our access points as residing at the center of an RF "cell" with a spherical boundary of RF coverage around them. Our primary interest is in the coverage boundary associated with our desired minimal signal threshold. In order to provide consistent coverage and availability across our floor, each of our cells should join with each adjacent cell at a coverage boundary that is greater than our desired minimal signal threshold. How much greater? That is determined by the amount of cell-to-cell overlap we wish to implement in our design, which in conjunction with the other parameters we have described, will dictate the potential packet loss experienced by VoWLAN devices before a roam event occurs.

The application of cell-to-cell overlap is intended to increase the probability that VoWLAN clients will quickly detect and roam to an adjacent cell without enduring an excessive degree of rate shifting and re-transmission as the device approaches the cell boundary. Excessive rate shifting and packet re-transmission is especially counter-productive for VoWLAN devices, as such behavior typically results in packet loss which usually translates into jitter. Since jitter is well established to be detrimental to a high quality VoWLAN user experience, we strive to minimize jitter in our VoWLAN designs by ensuring that devices have the opportunity to roam well before the quality of the user's voice call is in jeopardy. We accomplish this by assuring that the recommended degree of cell-to-cell overlap exists in our designs.

Figure 5-17 illustrates the concept of cell overlap for a Cisco 7921G VoWLAN handset using 802.11bg. For the Cisco 7921G, the recommended best practices found in the Voice Over Wireless LAN 4.1 Design Guide suggest that the cell-to-cell overlap should be approximately 20 percent when using 802.11bg and approximately 15 percent when using 802.11a.

Figure 5-17 20% Inter-Cell overlap

Data applications, on the other hand, typically do not display the same level of sensitivity to packet loss as do voice applications, hence they seldom require the same degree of cell-to-cell overlap. In most cases, a minimum 10% cell-to-cell overlap is sufficient for reliable roaming with data applications, as illustrated in Figure 5-18. High speed data applications and applications combining voice and data capabilities in a single device (smartphones, for example) may require cell-to-cell overlap that resembles a VoWLAN design much more than a data design.

Figure 5-18 10% Inter-Cell Overlap

Although they are possible and do exist, network designs for the location-aware Cisco UWN performed with only location tracking as a use case represent a minority of all Cisco mobility customer installations. Therefore, the designer striving towards completing an optimized location design is likely to be attempting to satisfy the four primary concerns of VoWLAN and data WLAN designers concurrently.

The chief location-tracking concerns of most designers wishing to track asset tags, clients or rogues will center around:

Perimeter and corner access point placement—Perimeter and corner access point placement is very important to good location accuracy. Refer to Figure 5-4 and the previous discussion surrounding the concept of a "convex hull". As described earlier, location accuracy tends to fall off the further one strays outside the convex hull encompassing the set of potential device locations on the floor.

Staggered pattern—Access points should be located on the floor in a staggered fashion to both facilitate an acceptable inter-access point spacing as well bolster the system's ability to perform RSSI multi-lateration for tracked devices.

Antenna mounting height—In most indoor location applications, antenna mounting height above the area where devices are to be tracked should be ideally between 10 and 15 feet, with 20 feet being a recommended maximum.

Inter-access point spacing—Access points should be situated so as to minimize any potential risk of degraded location accuracy rises due to:

Non-monotonic RSSI versus distance behavior at close range

Degradation in the ability of the system to resolve distance based on changes in RSSI.

Generally, this results in access points being deployed with an inter-access point distance of between 40 and 70 feet. However, the coverage requirements of demanding applications (such as voice and high speed data) may require more dense deployments under certain circumstances.

The question that comes to mind then is, can the requirements described earlier for voice and data applications be met in combination with the requirements of location tracking? The answer is yes, with the precise mechanics of how it is done dependent upon the specific requirements of the voice and data applications themselves, the access point and antenna configuration being considered, and the physical characteristics of the environment into which the infrastructure will be deployed. In order to explore this further, we examine the details behind how an access point layout, primarily intended for high speed data and 7921G voice applications, can be further optimized to include location tracking.

As an example, let us examine a voice access point layout for the 275 x 159 foot facility first presented in Figure 5-11. This represents a drywall office and indoor commercial office environment with a path loss exponent of 3.5 (see Figure 5-19). These access point locations were selected based on desired signal strength and overlap calculations that were performed by the original designer. In architecting this design, the designer's intention was to provide a solution that closely followed Cisco VoWLAN design best practices described in Voice Over Wireless LAN 4.1 Design Guide, which is available at the following URL:


We opted for a dual band infrastructure, with an 802.11a 5 GHz WLAN that is used by 7921G VoWLAN handsets and high-speed WLAN client devices. 802.11bg 2.4 GHz operation is also supported, but due to the substantially reduced overall capacity on 802.11bg brought about by the existence of only three non-interfering channels, its use is restricted to legacy data and voice devices, as well as active RFID asset tags that are in compliance with the Cisco Compatible Extensions for Wi-Fi Tags specification. Legacy data devices would include devices that are unable to migrate to 802.11a for reasons such as the client hardware device being no longer offered for sale, battery life concerns, and so on. Candidate legacy devices might include PDAs, bar code scanners, and other devices with embedded wireless onboard that is not easily upgradeable. In the case of our example, we assume that there are still some users of 802.11b voice devices present in the environment (for example, legacy Cisco 7920 VoWLAN IP phones, or similar legacy 802.11b-only devices from third parties) that have not yet been addressed with 802.11a replacements.

Figure 5-19 Layout for 5GHz Voice and High Speed Data, 2.4GHz Legacy

In Figure 5-19, we assume the use of 35 ceiling mounted AP1240AG access points, each of which is equipped with a pair of 2.2dBi AIR-ANT4941 antennas for 802.11bg and a pair of 3.5 dBi AIR-ANT5951 antennas for 802.11a. The access points and the antennas are mounted at a height of 10 feet. The design is intended to provide a minimum of -67 dBm signal level and a data rate of at least 24 Mbps on 802.11a for VoWLAN and high speed data clients, and a minimum of -67 dBm signal level and data rate of at least 11 Mbps on 802.11bg for legacy data and voice clients. 802.11a VoWLAN devices are assumed to be Cisco 7921G VoWLAN IP phones with integrated antenna. Legacy voice and data client devices are assumed to possess nominal antenna gain of 0 dBi. Inter-access point spacing is approximately 42.7 feet and was selected to allow for a uniform distribution of access points within the floor interior, and also ensure that the access point power levels required to produce our desired cell-to-cell overlap would fall within the capabilities of our client devices.

Note the following:

With the exception of access points 1, 5, 32 and 34, access points are not located directly at the floor perimeter. This is not optimal for the support of good location accuracy in all areas of the floor.

The lack of perimeter access points in the right hand corners of Figure 5-19. Because of this, there are areas in the vicinity of access points 31, 32, 34 and 35 where the location requirement for each point to lie within 70 feet of three different access points in at least three different quadrants (with an access point present in the fourth quadrant at any range) will not be satisfied.

Transmit power for each access point has been configured to +5dBm for 802.11bg and +11 dBm for 802.11a. This results in a -67 dBm cell radius of approximately 28.72 feet with a cell-to-cell overlap of 15% for 802.11a VoWLAN and high speed data clients. For 802.11bg legacy clients, it results in a -67 dBm cell radius of approximately 31 feet with a 20% cell-to-cell overlap.

Note The transmit power configured for access points should be within the range of the transmit power levels supported by clients to help avoid potential "one-way audio" telephony calls. When using Cisco's Radio Resource Manager to manage access point power levels, it is further recommended that designers target achieving the required coverage radii and overlap at transmit-power levels that are less than the maximum supported transmit power level of the client device. This is recommended in order to allow the Radio Resource Manager some degree of power allocation "headroom" that can be used to address potential coverage hole situations while still using transmit power levels that are achievable by the client devices.

In order to facilitate optimal location tracking with this design, a few changes, additions and adjustments will be necessary. Examining the current voice and data design and its associated parameters, the current access point spacing, antenna installation height, and placement pattern appear to be acceptable for location usage. However, the lack of access points located at the actual floor perimeters and in the corners of the floor are a concern that should be addressed. This can be seen from the dashed line in Figure 5-19 which illustrates the convex hull established by the current perimeter of access points. Note that areas at each corner and along each upper and lower perimeter lie outside of this boundary. Although these areas may not prove to be a hindrance to some users, for the purposes of this example, our goal is to assure optimal location accuracy in all areas of the floor. This includes the conference rooms in the corners of the floor and in all perimeter areas. Therefore, establishing a proper floor perimeter will be our first order of business.

The first step is to implement top and bottom access point perimeters as close to the building perimeter as feasible, while attempting to maintain the uniform density of access points shown in Figure 5-19 to the highest degree possible. Maintaining a high degree of access point uniformity is especially beneficial to those users that depend on the Cisco Radio Resource Management (RRM) to maintain transmit power control and perform coverage hole remediation. RRM functions most effectively when the distribution of access points on a floor is as uniform as possible.

At this point, we must decide on one of the following options:

1. Expand the equilateral formations comprising our existing access point constellation to accommodate rearranging the top and bottom rows of access points to form the upper and lower portions of the floor perimeter. With this option and our example environment, a minimal number of additional access points would be required, as their primary use is to fill-in any missing areas on the left and right side perimeters. Since it requires expanding the separation between access points, this option is considered more aggressive when compared to option 2 below. Caution must be exercised to avoid modifying the design beyond the limits imposed on access point transmit power (see below).

2. Contract the equilateral formations comprising our existing access point constellation to accommodate shifting upward the current top row of access points and subsequently introducing a sixth row of access points at the bottom to form a new lower perimeter. This option requires a greater number of additional access points when compared to option 1 above. However, since we are reducing the inter-access point distances, this option typically does not possess the risk of increasing access point transmit power levels beyond that of the original design, and is considered the more conservative option of the two.

When considering the first option, it is necessary to examine the current inter-access point spacing and transmit power levels, and estimate the increase that will be required to the inter-access point separation in order to place the existing outer rows of access points at the actual floor perimeters. If current access point transmit power levels are already at high levels relative to the power capabilities of our client devices, and the estimated increase to inter-access point separation appears to be large, then expanding the constellation of existing access points to accommodate perimeter placement may not be the best option. This is mainly because it may require the use of higher than desirable access point transmit power levels. In such cases, it is recommended to pursue the second option, which contracts the equilateral formations and results in shorter inter-access point separation, typically with the same or reduced access point transmit power levels.

Recall from our discussion that our transmit power levels are configured at +5dBm for 802.11bg and +11 dBm for 802.11a. In order to determine the new inter-access point separation that would be in effect if we were to uniformly expand the current formations (seen as equilateral triangles in Figure 5-19), we need to perform some basic geometrical calculations. We determine the new inter-access point separation required by assuming that the current top and bottom rows of access points are relocated such that they are positioned at the actual top and bottom floor perimeter. For the 275 x 159 floor in Figure 5-19, this is performed by dividing the top-to-bottom width of the floor (159 feet) by the number of desired rows of equilateral triangular formations (4), thereby yielding a projected formation height of 39.75 feet.

From the premise that in an equilateral triangle each angle is equal to 60× (shown in Figure 5-20), we calculate the length of any side s from the height h of our equilateral triangle formations as follows:

Figure 5-20 Equilateral Access Point Formation

Solving for s, we calculate or = 45.9 feet. Thus, we would need to expand our current inter-access point spacing from 42.7 feet to 45.9 feet in order to move both the top and bottom rows of outermost access points to the actual building perimeter. As this represents a relatively minor increase in inter-access point spacing, it should be easily accommodated by a correspondingly minor increase in transmit power, if any at all. In our next step, we determine the new cell size that would be required to support the recommended levels of overlap, given our newly calculated inter-access point spacing.

Using this new value for inter-access point spacing, we first calculate the -67dBm cell signal boundary with a 15% cell-to-cell overlap for 802.11a. We then calculate the -67dBm cell signal boundary with a 20% cell-to-cell overlap for our legacy data and voice devices that will be using 802.11bg. With the assumption that the radii of any two adjacent access point cells are equal (that is R1=R2=R), we can use the equation for the area of a circle-circle intersection as the basis for this calculation. To determine the cell radius given that the inter-access point separation and the percentage of overlap are known, we proceed as follows:


O = the desired overlap percentage divided by 100

is expressed in radians

d = the inter-access point distance in feet

R = the cell radius in feet

We substitute either 15 (for 802.11a) or 10 (for 802.11bg) as the percentage of overlap O, and 45.9 feet for the inter-access point distance d. Solving for R as an approximate root of the function shown above, we determine that the cell radii should be equal to 30.88 feet for a 15% cell-to-cell overlap using 802.11a and 33.4 feet for a 20% cell-to-cell overlap using 802.11bg3 .

At this point, we have the information necessary to calculate the access point transmission power settings that will be necessary to achieve our desired cell signal boundaries. This can be performed using a form of the equation presented earlier to calculate receive signal strength (TXPOWER) from knowledge of our reference path loss, path loss exponent, transmit power and various miscellaneous receive and transmit gains and losses. This was discussed in Received Signal Strength (RSS), page 2-7. As it is the transmit power (TXPOWER) of our access points that we wish to calculate and not the receive signal strength, we shall use a modified form of the equation as follows:

For the purposes of this example, we have assumed:

That transmission losses due to cables, connectors, etc (LossTX and LossRX) are equal to 0 dB.

0 dB shadow fading standard deviation.

Receive antenna gain for our legacy 2.4 GHz data client devices of 0 dBi.

Substituting the appropriate values along with our expectation of a -67 dBm minimum receive signal strength (RXPOWER) for both 802.11a 802.11bg, as well as the appropriate antenna gains, our cell radius in meters (30.88 feet = 9.41 meters, 33.4 feet = 10.18 meters), an estimated path loss exponent n of 3.5 and our reference path losses, we obtain the following results:


TXPOWER = -67 dBm + 0 - 2.2 dBi + 40 dB + 10log(10.183.5) - 0 + 0

= -29.2 + (10 * 3.527)

TXPOWER = +6.07 dBm, or approximately +8 dBm


TXPOWER = -67 dBm + 0 - 3.5 dBi + 46 dB + 10log(9.413.5) - (-3.0) + 0

= -24.5 + (10 * 3.408) + 3

TXPOWER = +12.58 dBm, or approximately +14 dBm

Note that these power levels have been rounded upward to the next available transmit power increment available on the AP1240AG access point. Since this is +1.93 dBm higher than the required transmit power to achieve our recommended 20% overlap goal at a cell signal boundary of -67 dBm, we can expect that the overlap will exceed the 20% target. This is acceptable, as the 20% overlap is a minimum target. Similarly, for 802.11a the access point transmit power level of +14 dBm is +1.42 dBm higher than what is required to achieve the recommended 15% overlap, once again resulting in more overlap between cells than expected.

In this particular case, the option to expand our inter-access point separation is an acceptable alternative. Due to the increase in the inter-access point separation (from 42.7 feet to 45.9 feet), a +3 dBm increase is required to both our 802.11a and 802.11bg access point transmit power settings in order to remain in strict compliance with our calculated requirements. Despite the increase in access point transmit power level, additional transmit power is left in reserve on both bands to address potential coverage holes or other anomalies that could occur due to changes in the environment. If this had not been the case, we would have proceeded with our second option which entails contracting our inter-access point spacing and introducing a sixth row of access points. The main differences in our calculations would be to divide the size of floor by five (instead of four) rows of equilateral triangular formations. This would have resulted in a smaller formation height, a smaller inter-access point separation, and therefore, smaller cell-to-cell radii and lower transmit powers.

Note The signal level measurements and the calculations described in this section, while based on generally accepted RF theory, are intended for planning purposes only. It is reasonable to expect some level of signal level variation from these theoretical calculations in different environments.

Rather than statically administering access point transmission power levels, the Cisco Radio Resource Manager (RRM) can be used instead. RRM can be used to dynamically control access point transmit power based on real-time WLAN conditions. Under normal circumstances, transmit power is maintained across all access points to maintain capacity and reduce interference. If a failed access point is detected, transmit power can be automatically increased on surrounding access points to fill the gap created by the loss in coverage. Should a coverage hole occur, RRM can use any remaining transmit power reserve on surrounding access points to raise the adjacent coverage levels and address the coverage hole until it can be investigated and resolved.

In either case, it is recommended that a verification of access point transmit power settings be performed periodically. If you opt to manually administer access point transmit power settings, you should examine the overall performance of your system to ensure that your original design assumptions are still valid and that there have not been significant changes in your environment that might warrant reconsideration of those assumptions. When using RRM, it will monitor your system for changes that might warrant an increase or decrease in access point transmit power settings for you. After your system has been installed, various adjustments can be made to RRM to bring its selection of access point transmit power levels and other parameters within your expectations for the environment at hand.

Keep in mind that immediately after installation and for a period of time after, it is reasonable to see a fair degree of RRM activity, as the system settles in and final parameter selections are made. At the conclusion of this "settling in" period, the system designer should ensure that the choices made by RRM are inline with the overall expectations of the design. Once the system has settled there should be little to no change in RRM managed parameters over time, as barring any significant environmental or equipment changes, the selections made for access point transmit power levels should remain fairly static. Any indication of constant fluctuation in assigned access point transmit power levels or channels should be regarded by the system administrator as potential indication of other anomalies that may be developing within the environment. The root causes behind such frequent fluctuations should be investigated and addressed promptly.

Note A comprehensive discussion of the mechanics of RRM is beyond the scope of this document. For information of this nature, it is highly recommended that readers refer to Radio Resource Management under Unified Wireless Networks document, which can be found at the following URL: http://www.cisco.com/en/US/tech/tk722/tk809/technologies_tech_note09186a008072c759.shtml. In addition, it is recommended that all users considering using RRM in VoWLAN designs refer to the Voice Over Wireless LAN 4.1 Design Guide, which can be found at the following URL:

Figure 5-21 illustrates the updated access point layout, using the information from the calculations above along with perimeter access point placement which is discussed next.

Figure 5-21 Layout for 5GHz Voice and High Speed Data, 2.4GHz Legacy, with Location

In Figure 5-21 we can see the effects of the increase in inter-access point distance:

The top row (access points 1, 6, 11, 16, 21, 26 and 31) and bottom row (access points 5, 10, 15, 20, 25, 30, and 35) of access points are now located at the actual top and bottom floor perimeter.

On the right side of the floor perimeter, access points 31 and 35 have been moved into the right hand corners of the floor. Access point 33 has been moved to the right side of the floor perimeter. As a group, access points 31 through 35 now comprise the right side of the floor perimeter.

On the left side of the floor perimeter, access points 1 and 5 have been moved into the left hand corners of the floor. In addition, two new access points (36 and 37, indicated by adjacent yellow stars) have been added to the design to complete the formation of the left side of the floor perimeter.

The two new access points added in Figure 5-21 bring the total access point count for the integrated voice, data and location design to 37 access points. The primary source of voice and data coverage in this design still emanates from the access points participating in the equilateral formations seen across the floor (i.e. this can be seen in Figure 5-21 as the set of access points depicted in red). Access points 32, 34, 36 and 37 are necessary to establish a location perimeter, but based on the assumptions and calculations presented here, may not be required to participate in providing voice or data coverage in either band. That being the case, these access points can be statically configured to operate at significantly reduced transmit power (such as -1 dBm, for example), which also minimizes the co-channel interference contribution of these access points as well.

Note For information regarding co-channel interference concerns in VoWLAN designs, it is recommended that readers refer to the Voice Over Wireless LAN 4.1 Design Guide, which can be found at the following URL:

When using Cisco RRM to manage power levels, access points that are placed into the design solely for location purposes should not be included in either the Radio Resource Management transmit power control or coverage hole remediation processes. Configuring a custom access point transmit power level (using the "custom" TX power option on WCS or the controller GUI) will automatically exclude these access points from transmit power and coverage hole remediation algorithms.

Based on our planning output and our calculations, our original voice and data design shown in Figure 5-19 can be migrated to a location-ready design that is in compliance with the best practices described in the Voice Over Wireless LAN 4.1 Design Guide with only minor changes in both layout and configuration. The result is a combined design that is well suited to support VoWLAN, high speed data and location tracking on 5 GHz, as well as legacy data and voice support with location tracking on 2.4 GHz.

Additional activities that can be performed to improve designs and design implementation include:

Performing a walk-around of the site and verifying that areas on the floor plan where access point mounting is desired can actually accommodate it. This is always a good idea, since floor plans and blueprints do not always indicate the precise conditions present at each location where an access point may be mounted. For example, you may find that certain locations that appear to be viable candidates "on paper" actually are inaccessible (such as an electrical closet), inappropriate (such as an outdoor balcony) or are otherwise not acceptable. In such cases, access points should be relocated close to the original location such that the impact on the overall design is minimal. In Figure 5-21, some common-sense obstacles have been avoided, and the affected access points have been moved slightly.

Verifying RF propagation and coverage assumptions by temporarily installing a few access points in various test areas of the floor, and measuring actual RF signal strength and cell-to-cell overlap using a portable client device with appropriate "site survey" software tools. This is an excellent time to measure the ambient noise levels of the potential access point cells as well, and determine whether the projected signal to noise ratio will be sufficient. Note that Cisco's RRM feature also monitors client SNR and increases access point power if a number of clients are noticed to fall below a prescribed SNR threshold. For more information about RRM, refer to the Radio Resource Management under Unified Wireless Networks at the following URL:


Validating whether there are any radar users present in your locale that may interfere with the use of the additional 802.11a that are subject to DFS. If there are not, these channels can be made available for use by enabling DFS on your WLAN controllers.

Note In software Release 4.1 of the Cisco Unified Wireless Network, Cisco Compatible Extensions Location Measurements are not enabled for any 802.11a channels on which DFS operation has been mandated. For DFS channels, RSSI from probe requests transmitted by WLAN clients as a part of their normal operation will be used for location tracking purposes.

The techniques and principles described in this section illustrate how a design performed in accordance with VoWLAN and data best practices can be upgraded to being "location-ready". The key concepts behind how inter-access point separation, cell radius and transmit power are inter-related, and how these factors can be used to determine coverage overlap, can be applied to designs of various different sizes and shapes, as well as environments with varying path loss characteristics and shadowing.

Avoiding Location Display Jitter

Location smoothing was introduced to enable the network administrator to compensate for cases of location instability sometimes seen with clients that are not actually experiencing any change in movement. This can be due to a variety of factors, including the following:

Variations in client transmit power resulting in changes in detected RSSI

Environmental changes, including semi-permanent obstructions that may have shifted position, result in variations in attenuation and multi-path

Changes in client orientation

Shadow fading

Location smoothing allows for varying degrees of averaging to be applied to device location. Smoothing factors are set in Location > Location Server > Administration > Location Parameters through the Smooth Location Positions parameter, as shown in Figure 5-22.

Figure 5-22 Configuring Location Smoothing

The various smoothing factor options impact the displayed location position by assigning different weights to the latest calculated position of the device versus its last known position. These weights are assigned as shown in Table 5-1.

Table 5-1 Smoothing Factor Weight Assignments 

Smooth Location Positions Value
Weight Assigned to Previous Position
Weight Assigned to New Position

Off (no smoothing)



Less smoothing



Average smoothing



More smoothing (default)



Maximum smoothing



As the weight assigned to the previous position is increased in relation to the weight assigned to the new position, the amount of displayed device movement is decreased. Note that the use of location smoothing will not eliminate all observed movement in the location display for that device. Rather, the use of location smoothing simply limits the rate at which such changes are communicated to the end user.

The use of location smoothing involves a small tradeoff between location viewing stability and the reaction time of the location display to changes in position. For most environments, the use of the default smoothing factor should provide an improved viewing experience. Higher smoothing factors are best reserved for environments where there is very infrequent movement of WLAN clients and tagged assets. Low smoothing factors (or no smoothing) may provide better results in situations where tagged assets and clients are frequently moving, and in some cases experiencing constant or near-constant motion. Users that are primarily concerned with minimizing displayed location latency (albeit at the risk of some location jitter) should choose low values for location smoothing, or disable location smoothing altogether.

Multiple Location Appliance Designs

As stated earlier, a single Cisco Wireless Location Appliance can track up to 2500 devices, which includes WLAN clients, asset tags, rogue access points, and rogue clients. The location appliance allows for specific tracked device categories to be enabled via Location > Location Server > Administration > Polling Parameters. To make best use of the capacity of each location appliance, Cisco recommends enabling only those polling categories (client stations, rogues, asset tags, or statistics) in which there is genuine interest and that require simultaneous tracking/historical location. For example, if the primary interest is in tracking asset tags only, do not enable the client and rogue polling categories because this only adds to overall network traffic between the location appliance and WLAN controllers as well as unnecessarily consuming a portion of the 2500 device tracking capacity. By disabling polling for device categories for which there is little interest, the full capacity of the location appliance can be better used.

Note Although not the focus of this document, Release 4.2 of the location-aware Cisco UWN introduces a enhancement that allows for individual limits to be placed on what portion of the location appliance's entire tracked device capacity is allocated to each tracked device category (i.e., WLAN clients, asset tags, and rogue devices).

Cisco WCS Release 4.1 can support between 500 and 3000 access points and between 125 and 750 WLAN controllers, depending on hardware configuration, as follows:

WCS high-end server—Supports up to 3000 access points and 750 WLAN controllers

WCS standard server—Supports up to 2000 access points and 500 WLAN controllers

WCS on Cisco Wireless LAN Solutions Engine (WLSE) hardware—Supports up to 1500 access points and 100 WLAN controllers

WCS low-end server—Supports up to 500 access points and 125 WLAN controllers

Note For complete details, see the Cisco Wireless Control System Configuration Guide, System Requirements at the following URL: http://www.cisco.com/en/US/products/ps6305/products_configuration_guide_chapter09186a00808317da.html#wp1061082

The maximum size of the WCS management domain (that is, the total number of devices managed by a single WCS) is related to the choice of server platform. In very large networks, it may be necessary to partition the network into multiple management domains, each with a separate WCS managing it. Beginning with software Release 4.1, Cisco introduces the WCS Navigator, which is a management aggregation platform for the enhanced scalability, manageability, and visibility of large-scale implementations of the Cisco Unified Wireless Network. WCS Navigator is a software-based solution that enables overall management of multiple Cisco WCS management platforms, regardless of their physical location. Cisco WCS Navigator runs on a separate server platform with an embedded database, and supports up to 20 Cisco WCS management platforms and up to 20,000 access points. Additional information regarding Cisco WCS Navigator can be found at the following URL: http://www.cisco.com/en/US/products/ps7305/index.html.

Although the maximum size of the each management domain is related to the capacity of the WCS platform managing it, the maximum size of the location domain (that is, the number of devices tracked by a single location appliance) is limited by the tracked device capacity of the location appliance. In a large percentage of mid to large size deployments, the standard deployment model of a single WCS management domain combined with a single location domain (Figure 5-23) can meet the device tracking and management needs.

Figure 5-23 Single Management and Location Domains

However, in the case of larger campuses, the total number of tracked devices may exceed the capacity of a single location appliance, making it necessary to use multiple location appliances (and multiple location domains) in the design. Some organizations may in fact choose to purposely divide the tracked device load among two or more location appliances for internal reasons, such as to better accommodate internal cost accounting within the organization, or to better accommodate growth. A good example of this might be a campus medical center WLAN that is tracking a large amount of patient-related medical assets in addition to the internal IT assets of the organization. It may wish to use separate location appliances to partition the tracking of assets as well as to provide clear delineation of equipment and cost separation between departments.

Note Keep in mind that if there are more than 250 tracked devices detected in a particular device category, WCS displays only the first 250 tracked devices. After displaying the initial 250 tracked devices, WCS will prompt the user to initiate the use of device filtering in order to display the remainder.

In software Release 4.1, WLAN controllers offer the device capacities shown in Table 5-2.

Table 5-2 WLAN Controller Device Capacities 

Controller Model
WLAN Clients Supported
Asset Tags Supported
Rogue APs Supported
Rogue Clients









































The subsections that follow examine how WCS, the location appliance and WCS Navigator can be combined to satisfy the needs of more demanding designs that are typically beyond the capabilities of single management/location domain combinations.

Single Management Domain with Multiple Location Domains

In this design approach, the network management needs of the enterprise WLAN are expected to be well within the capacity of a single WCS management domain. However, there is a need to track a combination of more than 2500 clients, rogues, and asset tags. This can be accomplished using multiple location domains that are managed via a single management domain, as shown in Figure 5-24.

Figure 5-24 Single Management Domain with Multiple Location Domains

Figure 5-24 illustrates a single campus WCS server providing WLAN management services for a large regional headquarters campus location as well as three extended regional metropolitan campus locations. In this case, all are located within a major metropolitan city.

Note Although the locations in this example are geographically dispersed, the concepts discussed regarding multiple location domains and controller assignments also applies to the case of a single contiguous campus where the total number of tracked devices exceeds 2500.

In the example depicted in Figure 5-24, the regional headquarters location contains 140 access points and each metro location contains 50 access points along with an unspecified number of chokepoint triggers. The design calls for the use of a centralized Cisco Catalyst 6500 with Wireless Service Module (WiSM). The WiSM contains two embedded controllers per service module, which are referred to as WiSM-1 and WiSM-2. WiSM-1 is used to service access points at the regional headquarters location while WiSM-2 services access points located at the metropolitan locations. Two Cisco 2710 Wireless Location Appliances provide the capacity to track up to a maximum of 5000 device MAC addresses. Location appliance 2710-1 is assigned to track assets within the regional headquarters complex only, and location appliance 2710-2 tracks assets across all three of the metropolitan locations. Note that location appliance 2710-2 does not track devices in the regional headquarters complex.

We can use WCS to create a single network design (a set of outdoor, campus, building and floor maps along with access point and chokepoint placements) that encompassing the entire extended campus shown in Figure 5-24. We first add in buildings 1 and 2 and the floors that are included in each building for the regional headquarters location. The 140 access points that are registered to controller WiSM-1, along with any chokepoints that are in use at the regional headquarters, are assigned to this network design. In addition, an event notification group is created for the regional headquarters location. WCS is then used to add metro remote buildings 3, 4, and 5 and their respective floors. The 150 access points that are registered to controller WiSM-2, along with any chokepoint triggers in the metro remote locations, are assigned to this network design. A separate event notification group is created for the metro remote locations.

The critical step in this process is not only to share the network design between both location appliances, but to ensure that the WLAN controllers we wish included within the location domain of each location appliance are correctly synchronized to (and only to) that location appliance. Thus, while our campus network design is synchronized to both location appliance 2710-1 and 2710-2, only controller WiSM-1 is synchronized to location appliance 2710-1 and only controller WiSM-2 is synchronized to location appliance 2710-2.

After these actions are performed, we will be able to manage the entire campus from the single WCS management domain, while dividing the aggregate number of tracked devices between two separate location domains. Once implemented, the entire enterprise is managed as a single management domain, with all management polling and reporting emanating from a centralized WCS. Location appliance 2710-1 handles polling controller WiSM-1 for all information pertaining to tracked devices found within its location domain, which is the regional headquarters. Location appliance 2710-2 handles the polling of controller WiSM-2 with regard to all tracked devices found in its location domain, which are the regional metro locations. Except for the fact that the two location domains operate across a common network, are managed from a common management domain, and possesses a controller that co-resides on the same physical WiSM module at the regional headquarters, the two location domains essentially exist independent of one another.

An alternate approach would entail creating two separate location appliance network designs containing only the portion of the campus network encompassed within each respective location domain. Each of these individual network designs would then be synchronized to the appropriate location appliance, along with the controller(s) that the location appliance will service. While this approach is indeed functional, in general, the single network design approach is preferred from a convenience and ease of maintenance perspective. On the other hand, when working with very large network designs, the dual network design approach may be preferable. By splitting the environment into two distinct network designs, it avoids loading the details about unnecessary access points, buildings, floors and the graphical images representing them into location appliances that have no need for this information.

In any design containing two or more independent location domains, it is important to be aware of the degree and frequency of inter-domain tracked device migration, if any. Some designs involving two or more location domains are meant to operate as pure "closed loop" systems. This implies that tracked devices are added and removed under very controlled circumstances, with the exception of any newly discovered rogues. In a closed loop system, the number of non-rogue tracked devices in each location domain can be expected to remain fairly constant. However, many actual deployments may employ "open-loop" business processes, where some degree of uncontrolled device addition, removal or migration can, and often will occur.

This can be significant since tracked devices that migrate from one location domain to another may appear in the active location database of each location appliance until such time that they are pruned. A tracked device will be pruned from the active location database of a location appliance when all of the following conditions are true4 :

1. The device is no longer being detected by any of the access points registered to any controller being serviced by that location appliance (i.e., any controller that has been synchronized to that location appliance).

2. All controllers whose access points have detected the tracked device have ceased reporting RSSI for the device to the location appliance (typically after the controller's RFID timeout or client user timeout has expired).

3. the location appliance Absent Data Cleanup Interval (ADCI) has expired (default is 1440 minutes).

During the time that a tracked device is present in more than one location appliance, multiple entries for the same device may appear in WCS client, tag or rogue display menus. An example of this is depicted in Figure 5-25, which illustrates the results of an asset tag search across all location appliances in lab testing. In this test, an asset tag with MAC address 00:0C:CC:5E:82:90 has migrated from the domain of location appliance "Loc1" to the domain of location appliance "Loc2". The access points of the two buildings are registered to different controllers, and these controllers are individually contained within two different location domains. For example, the controller servicing the hypothetical Havermeyer Building is being polled by the "Loc1" location appliance while the controller servicing the hypothetical Pupin Hall Building is being polled by the "Loc2" location appliance.

Figure 5-25 Duplicate Device Appearances Due to Device Migration

Note that in Figure 5-25, the asset tag MAC address 00:0C:CC:5E:82:90 appears twice, found in two different location appliances and with locations listed for two different buildings. If we were to display the map locations listed at the extreme right of Figure 5-25, we would see a tag icon displayed on both the main floor of the Havermeyer Building as well as floor number one of Pupin Hall. In order to differentiate between which of these two entries represents the latest and true location of asset tag 00:0C:CC:5E:82:90, we can use the information provided by the "Last Located At" time stamp and the age of the RSSI readings used to locate the device. To obtain the RSSI age information, we click on each appearance of device MAC address 00:0C:CC:5E:82:90, enable the location debug option on the tag detail screen that appears, and view the age of the RSSI readings used to establish the device location (shown in Figure 5-26).

Figure 5-26 RSSI Age Comparison for Duplicate Tag Entries

After the location appliance's absent data cleanup interval has expired, our lab test tag report appears as shown in Figure 5-27. Note that our migrated asset tag with MAC address 00:0C:CC:5E:82:90 has been pruned from the active location database of location appliance "Loc1".

Figure 5-27 Tag Report After Device Pruning

Relating this to the example shown in Figure 5-24, devices moving between metro remote buildings 3, 4, and 5 would not be affected by this anomaly, since these buildings are all contained within the location domain of appliance 2710-2. However, it would be of concern with devices migrating between any of the metro remote buildings and regional headquarters buildings 1 and 2, since the regional headquarters buildings are contained within a different location domain.

In cases where tracked devices may migrate between location domains at a more or less equal rate (that is, the rate of devices leaving a location domain is approximately the same as that of those entering) and the absent data cleanup interval is left at the system default, the situation illustrated above may persist for approximately 1440 minutes (24 hours). If a significant degree of device migration is expected, it is a good idea to tune the absent data cleanup interval to the anticipated level of migration expected at your site. This will help make more efficient use of location appliance resources and help avoid the possibility of exhausting tracked device capacity.

For example, assume a situation where a particular site begins its workday with:

Its location appliance's tracked device capacity at 60% (1500 devices).

A bi-directional two device per-minute migration rate (clients and tags).

No other tracked device additions or removals (rogue tracking is disabled).

In this case, the remaining capacity on the location appliance (1000 tracked devices, also referred to as "headroom") would allow for 500 minutes of operation at this rate of device migration before the potential for tracked device capacity exhaustion becomes a concern. To help avoid this situation, the Absent Data Cleanup Interval should be set below 500 minutes (for example, 440 or 470 minutes) in order to reclaim tracked device capacity prior to headroom depletion.

A common question that often arises is "why not just set the Absent Data Cleanup Interval to a very short interval initially?" The answer revolves has to do with decreases in the Absent Data Cleanup Interval not being entirely without tradeoffs:

While reducing the location appliance's Absent Data Cleanup Interval to an arbitrarily short value may have the effect of freeing up device capacity quickly, it can also effect the ability to view prior location and statistics for all categories of tracked devices (asset tags, clients and rogues) for which updated RSSI information has not been received within the ADCI time period. If the ADCI has been reduced and a device has been removed from the active location database, the ability to view past location information via the "Load Location Data as Old As" dropdown menu in the left hand margin of WCS floor maps display screens will now be limited to the reduced length of the Absent Data Cleanup Interval. Normally, this function allows information to be extracted from the active location database for up to a full 24 hour period, matching the default time period of the Absent Data Cleanup Interval. If the Absent Data Cleanup Interval is reduced, the maximum scope of the "Load Location Data As Old As" dropdown is reduced to the new value for the Absent Data Cleanup Interval, despite values higher than this being displayed in the dropdown selector.

When devices are pruned from the active location databases, historical location information on that location appliance will not be accessible for those device MAC addresses until such time that these devices re-enter the location domain and are re-added to the active location database. This assumes that the historical location information has not been pruned via an the independent location history pruning process that occurs periodically.

Multiple Management Domains with Multiple Location Domains

In this section, we examine the case where both of the following are true:

The combined number of access points and controllers managed within the enterprise cannot be contained within a single management domain

The number of tracked devices in the enterprise exceeds the capacity of a single location domain.

We revisit the enterprise depicted in Figure 5-24, except we now examine the organization's structure from a perspective higher up in the organization's hierarchy. We see that the headquarters location and the metropolitan remote office extended campus locations that we discussed in Figure 5-24 actually comprise a regional entity, with the headquarters location in Figure 5-24 now representing a "regional" headquarters location. Each regional headquarters reports to a national headquarters location, and there are three other regional headquarters locations that are very similar to what we described in Figure 5-28. In other words, we see that the "enterprise" we discussed in Figure 5-24 is really part of a much larger entity In this section, this larger entity is discussed in detail using Figure 5-28, with much of our discussion building on the information we covered in the previous section and Figure 5-24.

Figure 5-28 Multiple Management Domains with Multiple Location Domains

Each of the four regions depicted inFigure 5-28 contains a total of 290 access points, with a WCS server resident at each regional headquarters. As we discussed in the previous section, two location appliances are deployed per region and physically reside within each regional headquarters location, managing the two location domains present within each region. A national headquarters campus provides overall management for the entire enterprise, and contains 200 access points and a total of 2,100 tracked devices of its own, with WLAN controller services provided by a resident WiSM-equipped Catalyst 6500. The national headquarters location contains a single management and a single location domain, primarily dedicated to the WLAN and location tracking needs of the national headquarters staff itself.

This design contains a total of nine location domains and five management domains. To provide top-down management of the entire Unified Wireless Network, WCS Navigator is deployed at the national headquarters location, providing both management and location visibility internally as well as to all four regional campuses. Each WCS server communicates with WCS Navigator via its northbound API, allowing for the events, activities and resources of each regional management domain to be monitored and managed via a centralized portal. Figure 5-28 contains a single management and a single location domain, primarily dedicated to the WLAN and location tracking needs of the national headquarters staff itself.

This design contains a total of nine location domains and five management domains. To provide top-down management of the entire Unified Wireless Network, WCS Navigator is also deployed in the national headquarters location, providing both management and location visibility to all four regional campuses in addition to the national headquarters. WCS Navigator communicates with each of the five WCS servers via the WCS server's northbound API, allowing for the events, activities and resources of each regional management domain to be monitored and managed via a centralized portal. Figure 5-29 illustrates the network summary screen of WCS Navigator, where we can see its ability to monitor the status of multiple WCS servers as well as their location appliances. The alarm counts shown here represent aggregate quantities across all the monitored management domains. Clicking on any link takes the user to the appropriate detail screen using information retrieved from the WCS server that is responsible for the particular domain being queried.

Figure 5-29 WCS Navigator Summary Screen

WCS Navigator allows for the location of individual clients, asset tags and rogues to be determined by searching across the entire set of WCS servers. Tracked device searches can be conducted based on IP address, user name, MAC address, or asset name, category or group. WCS displays the output of such searches in a list format (shown in the top half of Figure 5-30). Clicking on any of the tag MAC addresses, controller or map links transports the user to the appropriate detail screen using information from the responsible WCS server (as shown in the lower half of Figure 5-30). Note that when this occurs, additional fields (highlighted in blue ovals) are inserted into the WCS menus to indicate that the user has arrived at these WCS menus via the WCS Navigator and provide for an easy return path back to the main menu.

Figure 5-30 Result of Tag Search Across Multiple WCS Servers

The cautions stated earlier with regard to the degree and frequency of device migration between location domains also apply here. That is, attention should be paid to the level of tracked device migration that may occur intra-regionally, inter-regionally or between any of the regions and the national headquarters. In this case, when tracked devices migrate between location domains and are included in the active location database of two or more location appliances, duplicate entries may not only be seen in local WCS servers (as described earlier) but also in WCS Navigator. Figure 5-31 provides an illustrative example of this, for two tracked asset tags 00:0C:CC:73:14:D9 and 00:0C:CC:73:2A:4D. As described in the preceding section, judicious adjustment of the Absent Data Cleanup Interval can be used to reduce the lifetime of duplicate entries and help mitigate this condition.

Figure 5-31 Duplicate Devices in WCS Navigator Due to Device Migration

Antenna Considerations

Third-Party Antennas

When engineering in-building WLAN solutions, varying facility sizes, construction materials, and interior divisions can all pose concerns that need to be considered during design and deployment. Cisco Systems is committed to providing not only the best WLAN infrastructure and client components in the industry, but also providing complete WLAN solutions. To this end, Cisco Systems provides the widest range of antennas, cabling and accessories available from any wireless LAN manufacturer. With a full suite of directional and omni-directional antennas, low-loss cable, mounting hardware, and other accessories, installers and designers of Cisco-supplied wireless solutions that meets the requirements of some of the most challenging wireless LAN applications.

In the Cisco Unified Wireless Network, antennas available from Cisco Systems are pre-configured in WCS and available for assignment to access points via the drop-down menus found at Monitor > Maps > Position APs. Selecting a Cisco antenna from this list automatically defines the antenna's gain and propagation patterns to WCS and the location appliance, which helps facilitate optimal localization of tracked devices.

In some specialized cases however, there may be reasons to consider the use of third-party antennas that are not found on the WCS antenna list. These reasons may include:

Retrofit of a pre-existing installation—If a pre-existing autonomous network is being upgraded to the LWAPP-based UWN solution, or if a pre-existing UWN installation is being upgraded, there already a large install base of third party antennas already deployed. Depending on their physical condition and their regulatory approval status for use with the latest 802.11 technologies, designers may wish to consider re-deployment.

Specific Product Requirements—In some cases a specific physical or electrical requirement of the design might dictate the use of a niche third party antenna not contained on the WCS-supported list. For example, a fashion retailer may require the use of a "zero-footprint" antenna or an antenna available in a specific shape or color to augment the decor of a "Fifth Avenue" flagship retail location. Or an electronics manufacturing facility requires a directional antenna with a unique (and very specific) coverage pattern or polarization to better cover a specific area of the plant floor, while minimizing interference with sensitive equipment in a particular location.

WCS allows for antenna gain to be specified for antennas that are not on the dropdown list of standard antennas. This can be performed using the "Other" antenna option (shown in Figure 5-32). Custom azimuth and elevation propagation patterns for "Other" third-party antennas cannot be defined to either WCS or the location appliance, (note the loss of the antenna orientation compass in Figure 5-32 when using the "Other" antenna option). Because of this, access points that are defined as being equipped with third party antennas will not be included in coverage heat maps and will not participate in client, tag, or rogue on-demand location tracking.

Figure 5-32 Specifying "Other" Antennas on WCS Floor Maps

Since the exact propagation pattern of third-party antennas cannot be specified, a question often asked is whether the propagation patterns for a pre-defined Cisco Systems supplied antenna can be substituted when the antenna from Cisco Systems is regarded as being a "close match" for the third-party antenna. The answer to this popular question depends on several factors. For optimal location fidelity, it is recommended that one of the antennas listed within WCS be used whenever possible. However, if this is impossible, the following suggestions should be considered before performing such substitutions:

For third-party antennas providing a gain of +6dBi gain or less, the difference in gain between the third-party antenna and the Cisco equivalent should not exceed 3 dBi.

For third-party antennas providing greater than +6dBi gain, the difference in gain between the third-party antenna and the Cisco equivalent should not exceed 3 dBi. In addition, the gain of the third-party antenna must not exceed the gain of the Cisco equivalent. The latter condition must be enforced to avoid circumstances where excessive antenna gain may lead to regulatory compliance issues (FCC regulatory domain, other regulatory domains may differ).

The third-party antenna should be of the same type as the Cisco equivalent. In other words, omni-directionals should only be substituted for omni-directionals, yagis for yagis, etc.

Note Keep in mind that substitution of third-party antennas while configuring WCS for the nearest Cisco equivalent may not be supported by the Cisco Technical Assistance Center (TAC).

Antenna Orientation and Access Point Placement

When installing access points using either internal or external antennas, it is highly recommended that both the placement of the access point as well as the orientation selected for the access point antennas in WCS match the actual physical access point placement and antenna orientation. This helps to ensure accuracy and precision in both location tracking as well as the display of predictive heat maps.

The typical Cisco Aironet access point is installed using antenna diversity. Antenna diversity helps ensure optimal range and throughput in high multipath environments. With few exceptions, it is recommended that antenna diversity always be enabled. The location-aware Cisco UWN is designed to take RSSI information from both access point antennas into account when localizing tracked devices. For good accuracy, ensure that antennas are physically present on all enabled access point antenna ports. Failure to do so may cause inordinately low RSSI readings to be reported on enabled antenna ports that do not have an attached antenna. The use of abnormally low RSSI from antenna ports without antennas is not conducive to good location accuracy and should be avoided.

Figure 5-33 illustrates how the configuration of the antenna's azimuth orientation within WCS is mapped to the actual physical orientation of the antenna. The blue triangle in the azimuth compass rose shown at the right of the figure indicates how the actual antenna should be physically positioned during deployment (notice that each of the antenna graphics contains a blue arrow as well). For omni-directional antennas, use unique identifying factors that are associated with the antenna (such as the right angled flexible antenna connector shown at the bottom of the 2.2dBi black whip antenna in Figure 5-33) to assist in proper positioning. For directional antennas, use unique physical characteristics of the antenna such as the exit location of the cable (for example, cable exiting up or cable exiting down) or other unique marks and construction characteristics.

Figure 5-33 Antenna Orientation

In software Release 4.1 of the location aware Cisco UWN, the ability to specify installed access point and antenna characteristics has been enhanced. Whereas prior releases assumed all access point antennas were uniformly installed at the same height on a floor, software Release 4.1 now provides the ability to account for antenna installations at varying heights. In this software release, the ceiling height that was configured when the floor was defined is used as the initial default for each access point. However, this can now be easily overridden on a per-access point basis (as shown in Figure 5-34). This capability allows the location appliance to incorporate varied access point antenna heights in its lateration calculations, an approach that more realistically approximates installations, especially in non-carpeted office type environments. Note that the individual height specified for an access point antennas cannot exceed the height of the floor.

Figure 5-34 Defining Individual Access Point Heights

Note The antenna propagation characteristics of the AP1131 access point are optimal along its azimuth plane when ceiling mounted. For optimal location performance when using the AP1131, it is preferred that the access point be ceiling mounted rather than wall mounted.

In some cases, it is desirable to separate access points from antennas using a short length (less than 10 feet) of low-loss antenna cable. Reasons for this might include avoidance of obstacles or simply the desire to position access points and other active electronic infrastructure components within easy reach of local employees using commonly available ladders and stepladders. This facilitates easy removal and installation of these components should they require replacement. An example of this is shown in Figure 5-35. In this case, a nationwide retailer has mandated that all electronic infrastructure components be accessible to store employees using the ten foot step-ladders commonly available at each store location. Here we see that the access point is mounted at 10 feet (for easy access) while the antennas are mounted at 15 feet. In cases such as this, the value specified for "AP Height" in Figure 5-34 should reflect the height of the antennas and not the height of the access point.

Figure 5-35 Example of Differing Antenna and Access Point Heights


The Cisco WCS and the location appliance are shipped with default RF models that facilitate setup under two of the most common indoor office environments. One of these models represents a typical corporate office environment with both cubicles and drywall offices, and the other represents a similar environment with drywall offices only5 . These RF models provide an estimate of the path losses found in these typical indoor commercial office environments, and can be very useful when the primary requirement at hand is to provide a working location tracking system in the shortest amount of time possible.

Some indoor environments may possess more attenuation than is found in a typical office environment. In properly designed indoor installations where increased attenuation may be a factor contributing to less than optimal location accuracy, a site calibration may help restore lost performance. When an on-site calibration is performed, the system is allowed to sample path losses from known points throughout the environment, allowing it to formulate a custom RF model that provides a better understanding of the propagation characteristics specific to that environment.

In many cases, using the information collected during calibration instead of a default model can markedly reduce the degree of error between reported and observed client location. In environments where many floors share almost identical attenuation characteristics (such as the floors of a library containing similar arrangements of book shelves, for example), these strong similarities may allow for the RF model created by a calibration performed on any one of the floors to be applied to all floors with good results.

Calibration is actually a multi-step process that begins with the definition of a new calibration model via Monitor > Maps > RF Calibration Models > Create New Model. A step-by-step description of the calibration process can be found in the following two documents:

"Creating and Applying Calibration Models" in the Cisco Wireless Control System Configuration Guide, http://www.cisco.com/en/US/products/ps6305/products_configuration_guide_chapter09186a008083196d.html#wp1089489

Cisco Wireless Location Appliance: Deployment Guide at the following URL: http://www.cisco.com/en/US/products/ps6386/prod_technical_reference09186a008059ce31.html.

During the data point collection process, the calibration client repeatedly transmits probe requests on all channels. Depending on the particular calibration client being used, the client may be triggered to transmit probe requests on-demand via a network request. Clients that are incapable of recognizing these requests may be de-authenticated and disassociated in order to cause them to issue probe requests to the wireless medium and subsequently re-associate / re-authenticate. Access points in the vicinity of the client detect the RSSI of these probe requests and pass this information to their registered controllers. Controllers furnish the RSSI information detected during the calibration process to the location appliance and WCS for use in computing the path losses that will ultimately be associated with the new calibration model.

The data point collection phase of the calibration process in WCS can be performed using one of two methods. It can be performed from a single web-enabled mobile device associated to the WLAN, which controls both the probing of the network as well as the actual data collection. Alternatively, the data collection phase can be performed from two separate devices that are associated to the WLAN infrastructure. In this case, interaction with the WCS GUI is controlled from a primary device that is equipped with keyboard and mouse capabilities, while the actual generation of probe requests occurs on a second device.

Due to an open caveat6 concerning the use of dual-band calibration clients and performing a location calibration data collection on both bands simultaneously, it is recommended that calibration data collection be performed for each band individually at this time. When using a dual-band client, use either of the following alternatives:

1. Perform the calibration data collection using a single laptop equipped with a Cisco Aironet 802.11a/b/g Wireless CardBus Adapter (AIR-CB21AG) on each band individually. For example, proceed to disable the 5 GHz band and complete the data collection using the 2.4 GHz band only. Then, disable the 2.4 GHz band and enable the 5 GHz band, and proceed to repeat the data collection using the 5 GHz band only.

2. Perform the calibration using two people and two laptops. Each laptop should have a Cisco AIR-CB21AG and be associated to the infrastructure using a different band. The two calibration operators may operate independently; there is no need for them to visit each data point together. In this way, a complete calibration data collection can be performed across both bands in half the amount of time as option #1 above.

When a client compatible with the Cisco Compatible Extensions specification version 2 or greater is associated to the WLAN infrastructure and is specified as the calibration client in WCS, the client's MAC address will be inserted into the location calibration table of all controllers servicing the access points contained on the floor being calibrated. This insertion initially occurs immediately after the MAC address of the calibrating client and calibration campus, building and floor are specified via WCS Maps> RF Calibration Models > Add Data Points. After each save of a collected data point, the client MAC address will be removed from the controller's location calibration table. The client MAC address will then be briefly reinserted into controller location calibration tables upon each subsequent data point save and immediately removed thereafter. This process repeats for each data point collected.

When the MAC addresses of clients that are compatible with the Cisco Compatible Extensions specification version 2 or greater appear in the location calibration table of controllers, unicast Radio Measurement Requests will be sent to these clients (see Figure 5-36). Similar to how broadcast Radio Measurement Requests help improve the location accuracy of compatible clients during normal operation, unicast Radio Measurement Requests sent at short regular intervals (4 seconds) should cause compatible calibration clients to transmit probe requests very frequently. The use of Cisco Compatible Extensions Radio Measurement Requests and Cisco Compatible Extensions version 2 or greater clients allows this to occur without the need to force the client to continually disassociate and re-associate. This allows more consistent and reliable probing of the network, and allows smoother operation of the calibration client especially if it is being used as a workstation that is interacting with WCS via the calibration data collection GUI.

Note Unicast Radio Measurement Requests will not be sent to clients that are associated to WLANs where the Aironet Information Element ("Aironet IE") has not been enabled on the supporting controller. For best calibration results with calibration clients supporting the Cisco Compatible Extensions specification version 2 or greater, ensure that Aironet IE support is enabled.

Figure 5-36 Unicast Radio Measurement Request

The fields in the unicast Radio Measurement Request shown in Figure 5-36 (highlighted with colored rectangles) are very similar to that of the broadcast Radio Measurement Request discussed previously in this document. However, Cisco Compatible Extensions Location Measurement broadcasts Radio Measurement Requests to all associated clients whereas during calibration data collection, Radio Measurement Requests are unicast only to calibration client MAC addresses that are contained in WLAN controller location calibration tables. For example, in Figure 5-36, we see that the MAC address we are unicasting the Radio Measurement Requests to is 00:40:96:A1:9D:47.

Calibration clients that are compliant with the Cisco Compatible Extensions specification version 1 (or not compliant with the Cisco Compatible Extensions specification at all) will not respond to unicast radio measurement requests. Instead, these clients will be forced to re-associate and re-authenticate in order to generate probe requests. If the Cisco Compatible Extensions Location Measurement parameter (discussed in the section entitled "Tracking Assets and Devices in the Cisco UWN") is enabled on a controller for which a Cisco Compatible Extensions specification version 2 or greater client is being used for calibration, the calibration client should respond to both the broadcast request used for Cisco Compatible Extensions Location Measurement as well as the unicast Radio Measurement Requests used for calibration.

Note The Cisco Aironet 802.11a/b/g Wireless CardBus Adapter (AIR-CB21AG) is recommended by Cisco Systems for location calibration data collection.

In most cases, WCS will handle the maintenance of the controller location calibration tables, inserting client MAC addresses as needed for calibration data collection and removing them when they are no longer necessary. Proper maintenance of this table is important, since every client compliant with the Cisco Compatible Extensions specification version 2 that is present in the table (up to a maximum of five) will receive unicast radio measurement requests whenever they are associated to any access point registered to that controller. This occurs regardless of whether the client is actively collecting calibration data points or being used simply as an associated mobile workstation during non-calibration periods.

Because of this, residual client MAC addresses in controller location calibration tables can result in unnecessary load and traffic:

Each WLAN controller containing these entries should perform the following every four seconds:

Issue radio measurement requests to each client in the table.

Process incoming probe requests from each client in the table.

Process incoming radio measurement responses from each client in the table.

Each WLAN client present in the location calibration tables must perform the following every four seconds:

Issue one or more probe requests per channel in the regulatory channel set.

Process one or more incoming probe responses.

Generate a radio measurement response report containing the results of all probe responses received.

During normal calibration procedures, WCS will manage the addition and deletion of entries from the location calibration tables. However, there are some situations where residual stray entries may be observed. A common cause is improper termination of calibration data collection by the user, two examples of which might include:

WCS normally adds the client MAC address to the location calibration table immediately after the parameters on the Maps > RF Calibration Models > Add Data Points GUI menu panel are completed. If data point collection is aborted at this point by simply selecting a different WCS function from the main WCS menu, entries in controller location calibration tables will remain. To avoid this situation, it is recommended that users wishing to abort data collection use the "Cancel" option instead (shown in Figure 5-37) before returning to a previous menu.

Figure 5-37 Using the Cancel Option to Help Trigger Location Calibration Cleanup

WCS adds the client address to the location calibration table immediately after clicking on the "Save" button shown in Figure 5-37 and initiating the data collection process for a particular data point. While data is being collected for the calibration client, the screen shown in Figure 5-38 will be displayed.

Figure 5-38 Data Point Collection in Progress

Once the data collection has completed, the data collection screen will be re-displayed with the new data points illustrated on the map. In extraordinary situations, the data collection process may take a few minutes to complete (or timeout in about 90 to 120 seconds) due to an unexpected interruption in calibration client connectivity, such as moving into a coverage hole for example. If the user becomes impatient and decides to abruptly terminate the calibration by selecting a different menu option from the WCS main menu, residual controller location calibration table entries may occur. To avoid this, it is recommended that all calibration users refrain from this behavior and instead exercise patience in waiting for the data collection to complete or timeout (shown in Figure 5-39).

Figure 5-39 Data Collection Timeout Message

In cases where the contents of the controller's location calibration table is in question, it can be queried directly using the CLI command.

(Cisco Controller)>show client location-calibration summary
   MAC Address        interval
 -----------------  -------------
 00:40:96:a1:9d:47       4

In situations where there are unnecessary residual entries present in a controller's location calibration table from prior calibration data collections, they can be removed manually using the following controller CLI command:

 (Cisco Controller)>config client location-calibration disable 

Note Before removing any entries in controller location calibration tables, it is good practice to be sure that these entries are not in use by other users performing a calibration data collection.

Calibration data collection should be performed after the system has been fully installed, basic coverage checks are completed, and the recommended RSSI cutoff (typically -75 dB or better) to a minimum of three access points has been verified. All access points should be in place, properly oriented and registered to their respective controllers with WCS and the location appliance fully operational. For optimum ease of use and visibility during the data collection procedure, a portable laptop or tablet computer (or "computer on wheels" cart setup) with a large, clear and bright screen is recommended, especially in areas of bright ambient light.

During the calibration data collection process, WCS suggests locations on the floor map where samples should be taken (shown in Figure 5-40) along with graphical indication of the degree of progress achieved. At any point during the calibration data collection process, a graphical representation of the calibration points captured thus far can be generated by clicking on the dropdown menu in the upper right hand corner of the calibration data collection screen. The calibration data collection process can be completed in one session, or the session can be stopped and returned to at a later time. This process can be repeated as often as necessary to complete calibration data collection for a floor.

Figure 5-40 Calibration Data Collection Screen

Calibration Validity

Strictly speaking, a properly performed site calibration is considered valid as long as the fundamental environmental factors affecting RF propagation between clients and access points have not deviated significantly from the state under which the original calibration was performed. For example, significant changes in the material contents of the target environment may have an impact on the path losses experienced within that environment. Performing a re-calibration allows the system to better understand the current level of attenuation and fading present in the environment and allow it to re-calculate the path loss model. In many cases, this can help to restore lost accuracy and performance to the system.

From a practical standpoint, the location-aware Cisco UWN is seen to be more tolerant of environmental path loss changes when those changes move from higher path losses to lower path losses, relative to the path loss model currently in use. Therefore, if faced with designing a location tracking for an environment where seasonal content variations are the norm, it is recommended that the calibration of the site be performed at peak content levels, when path losses would be expected to be at their highest. The use of a high path loss model when actual path loss is lower than expected has been shown to produce better location performance than the use of a path loss model with low path loss when the actual path loss of the environment is higher than expected.

Examples of the types of changes where a re-calibration may be recommended if a significant drop in performance is noticed include, but are not limited, to the following cases:

Changes in stocked material—A floor of an supply warehouse that was last calibrated when it contained paper products has now been converted to stocking bulk metal containers of dense liquids, such as motor oil, transmission fluid, gear oil, etc).

Changes in interior walls—A newly remodeled office facility was last calibrated prior to the installation of several new walls with improved fire protection and interior sound deadening insulation.

Changes in stocking density—A large library was originally calibrated when it was still using older bookshelves that contained six to eight shelves per stack. However, it has since been upgraded and now sports new bookshelves that contain between ten to twelve shelves per stack.

Changes in access point density—A manufacturing site was originally calibrated for location tracking with 50 access points and an inter-access point spacing of 40 feet. However, due to a business slowdown, a large portion of the plant has been mothballed with 50% of the access points powered down. The effective inter-access point spacing at this point is 65 feet.

Tips for Successful Calibrations

Data Collection

As stated earlier, the WCS calibration process helps ensure that a sufficient number of calibration data point measurements are collected before allowing the calibration user to move forward with calibrating the model and applying it to floors. During the calibration process, use the blue crosshairs on the calibration grid (shown in Figure 5-41) as suggestions with regard to where the calibration client should be positioned when collecting data points. Always make sure you accurately position the red cross hairs prior to clicking on Save and initiating data collection.

Although they are only suggested locations, the blue crosshairs are an excellent way to stay on track and uniformly cover ground, especially within large environments. The calibration grid will be updated to indicate the locations actually visited, with the surrounding area of localization that is now "covered" being indicated by a blue color for 802.11b/g, yellow for 802.11a, and green for both bands, as illustrated in Figure 5-41.

Note In order to promote better location fidelity, every attempt should be made to be as accurate as possible when indicating the calibration client's actual physical position using the red crosshairs in Figure 5-40 and Figure 5-41.

Figure 5-41 Example of a Completed Calibration Data Collection for Both Bands

Keep in mind that the calibration utility is not able to recognize floor plan obstructions or hazards, such as interior walls, pipes, racks, or other structures. Therefore, it is not unusual to have a suggested data point crosshair appear in an area that is physically inaccessible to the operator. In that case, simply visit a location as close as possible to the inaccessible location and perform the calibration data collection there. Make sure, however, that the red cross hair is positioned to correctly indicate the physical location where the data collection actually took place.

Calibrating Under Representative Conditions

As mentioned previously, the location appliance and the Cisco WCS use the information gathered during a calibration data collection to better understand the propagation characteristics present within the environment. This information is culled from the aggregate of all the data points accumulated during calibration data collection. To facilitate an accurate calibration, it is recommended that the environment in which the calibration data collection is performed be representative of the daily production environment. For environments that experience variations in the level of material and personnel present, it is recommended that calibration be performed at a time when such levels are at or near their peak.

For example, the calibration should be performed during business hours when the facility contains a representative population of people (human attenuation) as well as material on shelves (material attenuation). If carts, racks, beds, or other large metallic objects are normally used in this environment, these should also be present during calibration. If large doors are present in the environment, they should be positioned as they would normally be during business hours. In most cases, calibrations performed during normal business hours are more likely to be representative of the levels of attenuation found in the production daily environment than off-hours calibration.

Often, the most convenient time to perform a calibration may be after construction is completed but before people and contents are moved into a site. Cisco Systems highly recommends against performing calibrations of such "empty rooms". Once these areas are stocked and occupied, attempting to localize tracked devices using a RF model based on data collected in an empty and barren environment is not likely to provide optimal results. When presented with a choice between calibrating when stockroom shelves are only at half capacity or at full capacity, the calibration that is done at full capacity will typically yield better accuracy, even when used at times when the stockroom is only half full.

If it is necessary to deliver an operational location tracking system on "day one" for a newly constructed area, you may wish to use one of the RF models that are supplied with WCS and the location appliance, as a temporary measure. Once the area has been fully stocked and staffed, perform calibration data collection under conditions that would be considered representative of its peak or normal capacity. After the calibration has been completed, use the newly created RF model instead of the supplied model chosen originally. In this way, the supplied model initially chosen allows for users and administrators to quickly familiarize themselves with the system, and the subsequent switch to a properly calibrated RF model should provide for better overall performance.

In order to plan for the most optimal time to perform a calibration of the area, the designer should work closely with those personnel possessing an intimate knowledge of the business patterns and processes occurring there. This is especially true if seasonal variation in stocking levels may occur, as would be the case in a retail or logistics site. If it cannot be determined from prior conversations with site personnel, one way to determine a good time to perform a calibration is to visit the site beforehand and observe the activity pattern of both the facility and the personnel present. Prior observation of activity in this manner allows the designer to plan for the optimum time to perform the calibration, so as to yield the most representative results and also to not excessively inconvenience the personnel employed at the facility.

Recommended Calibration Clients and Techniques

The Cisco Aironet 802.11a/b/g Wireless CardBus Adapter (AIR-CB21AG) is highly recommended for use as a calibration client by Cisco. This client is compatible with the Cisco Compatible Extensions specification for WLAN devices at version 5, and fully supports the use of both broadcast and unicast radio measurement requests as described earlier in this section.

If a Cisco Aironet 802.11a/b/g Wireless CardBus Adapter (AIR-CB21AG) cannot be used as a calibration client, a third party client device that is compatible with the Cisco Compatible Extensions specification for WLAN devices at version 2 or higher may be used. In order to assure a reliable calibration data collection, any third party WLAN client used for location data collection should be capable of recognizing and responding to S36 unicast radio measurement requests sent during calibration. Also, the transmit power level used by third party clients when transmitting probe requests should be known.

WLAN client devices that are not compatible with the Cisco Compatible Extensions for WLAN devices specification, or compatible only with version 1 of the specification, are not considered optimal for use in location calibration data collection.

Note that when using a laptop computer containing the Intel® PRO/Wireless 3945ABG Network Connection or the Intel® PRO/Wireless 2915ABG Network Connection adapter, the default configuration is for a Personal level of security settings (intended for non-enterprise use) that does not include compatibility with the Cisco Compatible Extensions specification. When using this default Personal level of wireless security, clients equipped with the Intel 3945ABG or 2915ABG client adapters will not support S36 unicast or broadcast radio measurement requests and are not compliant with the Cisco Compatible Extensions specification for WLAN devices.

In order to enable compatibility with the Cisco Compatible Extensions specification, the Intel ProSet client supplicant must be used to reconfigure the client for Enterprise Security and enable Cisco Compatible Extensions. Figure 5-42 and Figure 5-43 illustrate how this is performed.

Figure 5-42 Intel ProSet Security Settings Panel

In Figure 5-42, under the Security Settings panel of the Intel ProSet configuration, select the Enterprise Security option (highlighted by the red circle) instead of the default Personal Security option. Configure the appropriate authentication and authentication types, and select Cisco Options (highlighted by the blue circle). This will present the panel shown in Figure 5-43.

Figure 5-43 Intel ProSet Cisco Compatible Extensions

In Figure 5-43, Cisco Compatible Extensions should be enabled (as indicated by the red circle). Note that Cisco Compatible Extensions is automatically enabled when configuring profiles for CKIP, LEAP, or EAP-FAST.

Note For additional information regarding the configuration of the Intel® PRO/Wireless 3945ABG Network Connection or Intel® PRO/Wireless 2915ABG Network Connection adapters, refer to the following documents from Intel Corporation: ftp://download.intel.com/support/wireless/wlan/sb/3945abgug.pdf ftp://download.intel.com/support/wireless/wlan/pro2915abg/sb/2915ABG_UG.pdf

Calibration should be performed using a calibration client and a suitable laptop computer with a fully charged battery. The following recommendations should be considered when performing calibration data collection:

1. Ensure that your calibration client is being detected by the access points on the floor where you wish to perform the calibration.

2. Temporarily disable Dynamic Transmit Power Control (DTPC) prior to conducting calibration data collection. DTPC must be disabled separately for each band using either the controller GUI, the controller CLI or WCS for each controller whose registered access points are expected to participate in calibration data collection. After calibration data collection has been performed, DTPC should be re-enabled for normal production operation.

3. Ensure that the WLAN to which your calibration client will associate is configured to support Aironet Information Elements (Aironet IE). Doing so will enable the use of unicast radio resource measurement requests during calibration data collection for more efficient operation.

To obtain best performance when displaying access point coverage heat maps and tracking devices in most cases, calibration clients should be pre-configured as closely as possible to transmit power levels of 63mW (+18dBm) for 2.4GHz and 32mW (+15dBm) for 5 GHz. Note that it is imperative that DTPC be disabled (item number two above) such that these transmit power levels do not vary during calibration data collection.

Due to an open caveat7 concerning dual-band calibration clients when attempting to perform a simultaneous data collection on both bands, it is recommended that calibration data collection be performed for each band individually at this time. In order to do this using a dual-band client, use either of the following alternatives:

1. Perform the calibration data collection on each band individually using a single laptop equipped with a dual-band client adapter compatible with the Cisco Compatible Extensions specification for WLAN devices specification at version 2 or higher, and capable of recognizing and responding to S36 unicast radio measurement requests. An example of such a client is the Cisco AIR-CB21AG. For example, proceed to disable the 5 GHz band and complete the data collection using the 2.4 GHz band only. Then, disable the 2.4 GHz band and enable the 5 GHz band, and proceed to repeat the data collection using the 5 GHz band only.

2. Perform the calibration data collection using two operators and two independent laptops. Each laptop should be equipped with a dual-band client adapter compatible with the Cisco Compatible Extensions specification for WLAN devices specification at version 2 or higher, and capable of recognizing and responding to S36 unicast radio measurement requests. An example of such a client is the Cisco AIR-CB21AG. Each laptop should be associated to the infrastructure using a different band. The two calibration data collection operators may function independently, there is no need for them to visit each data point at the same time, or to even visit the same data points. In this way, a complete calibration data collection can be performed across both bands in half the amount of time compared to option #1 above.

Some embedded laptop client adapters may not transmit probe requests at these power levels, but instead are restricted to lower transmit power levels (for example, +15dBm for 2.4 GHz). Generally, these clients can still be localized with acceptable accuracy when calibration data collection is performed according to the guidelines outlined above. However, a slight increase in location accuracy may be possible if the calibration data collection is performed at power levels with which we expect the embedded laptop client to transmit its probe requests. A tradeoff that must be considered when opting for this approach, is the possibility of reduced access point heat map accuracy (heat maps are most accurate when calibration is performed at 63mW (+18dBm) for 2.4GHz and 32mW (+15dBm) for 5 GHz).

After calibration data collection has been completed, all temporarily configured parameter changes should be returned to their normal settings. In some cases, the device that is used to control the calibration data collection process may not be the same device that is used to transmit probe requests. For example, a laptop with an embedded wireless adapter compatible with the Cisco Compatible Extensions specification version 1 might be a user's preferred device based on a ergonomic or special accommodation feature that he or she requires. Since this device is not compatible with the Cisco Compatible Extensions specification at version 2 or greater, its use is not recommended for optimal results when performing calibration data collection. However, we can use this device to log into the UWN and control the data collection process remotely, assigning the role of transmitting probe requests to another device that is, for example, equipped with a Cisco AIR-CB21AG. As shown in Figure 5-44, this arrangement allows the location of the probing client (otherwise referred to as a "remote calibration client") as well as the timing of each data collection to be fully controlled from the laptop. The probing client (with MAC address 00:1a:a1:92:a1:20 in Figure 5-44) is remotely instructed to issue probe requests to the network infrastructure appropriately.

Figure 5-44 Controlling Calibration Data Collection Remotely

Calibration of Non-Uniform Environments

In some cases the network designer is faced with challenges because of an environment that is of non-uniform construction. An example is a single floor consisting of a large call center cubicle area (path loss exponent of 3.3), dense metal racking and electronic equipment in a second area (path loss exponent of 4.3) and a large group of individual offices with drywall walls in a third area (path loss exponent of 3.5).

Cases such as this can be addressed via one of two options:

1. Calibrate in the area with highest expected attenuation (path loss)—The most straightforward method in which to handle this situation is to perform the calibration in the areas possessing the highest overall attenuation (i.e. the highest path loss exponent), and apply the resulting RF model to all areas of the floor. In mathematical simulations as well as lab research, the application of an RF model that is based upon a higher level of path loss to areas where the actual path loss is lower has shown to provide better location accuracy than the converse approach. Thus in our example, it would be recommended that the calibration be performed in the area with the dense metal racking and electronic equipment (path loss exponent of 4.3) and the RF model that results from this calibration used for the entire floor.

2. Calibrate across all areas of the floor—This approach takes into account all areas of the floor and attempts to produce a "balanced" RF calibration model. While performance may be acceptable using this approach depending on the accuracy needs of the location application, laboratory testing indicates that in general, improved results are obtained when using option one above. Note that if there are large differences in size between the different floor areas that result in significant differences in the number of calibration data points collected within each area, the final path loss model using this approach may be biased in the direction of the path loss associated with the larger areas.

3. Address the different areas of the floor as if they were individual floors—In some cases, improved accuracy can be obtained within each individual area with a tradeoff of increased management overhead and some potential edge accuracy degradation. Since WCS and the location appliance do not allow for the provisioning of different RF models to sub-floor areas in software Release 4.1, each of these sub-floor areas would need to be defined as a separate floor in WCS. Individual calibrations are then performed in each of the sub-floor areas, applied to their pseudo-floor definition within WCS and then synchronized with the location appliance. Because this approach allows for the provisioning of separate path loss models that are attuned to the characteristics of each sub-floor area, improved accuracy and precision is possible. However, potential tradeoffs may include additional management overhead on the part of the WCS administrator. An organized naming convention is typically required for floors and sub-floors such that they are easily recognizable by WCS users and able to be logically considered as a group. Each sub-floor area should be considered as an independent location area subject to the location-aware design recommendations made in this document. Also, it should be noted that accuracy may degrade as devices approach the edges and borders of sub-floors, since the location appliance positioning engine does not consider signal strength readings from access points that are resident on a different floor in software Release 4.1.

In addition to these two mainline options, it is possible to treat each of the three areas as separate "floors" in WCS, and thereby allow the development of RF models attuned to each area's characteristics. However, this approach possesses a serious limitation that must be understood. In addition to the management overhead of developing floor and sub-floor naming conventions that bring a modicum of sensibility to such an approach, a technical limitation exists whereupon the location appliance currently does not take into account tracked device RSSI coming from access points that are deemed to be located on a different floor than the tracked device itself. Thus, when physical floors are divided into areas that are then defined to WCS as individual floors themselves, tracked devices that venture into the edge boundary areas of these newly defined "floors" may experience degraded accuracy. Unless the designer as well as the system user is comfortable with this limitation and its potential impact on boundary area accuracy, this approach is best avoided.

While there is no ideal solution to situations where the degree of uniformity is vastly different across a floor, in general option #1 is observed to offer the best compromise between ease of implementation and performance.

Inspecting Location Quality

Location inspection allows path loss model accuracy to be validated by comparing the actual versus the predicted location of calibration data points. Unlike the location planner or location readiness tools, which are purely predictive in nature, when you perform location inspection, you are directly comparing the predicted locations of calibration data points to the actual physical locations originally specified by the calibration operator. In order for location inspection to deliver on its true value, however, accurate placement of the red crosshairs during calibration data collection is very important.

The results of each data point comparison are used to graphically express the overall accuracy of the path loss model at various points on the floor. This provides the system designer or installer with "real-world" feedback with regard to how the expected performance of the system compares to its actual performance, given the calibration client used and the condition of the environment at the time of calibration.

Location inspection is accessible from the Monitor > Maps > RF Calibration Model > model name WCS menu via the "Inspect Location Quality" hyperlink located next to the name of the floor where data collection for the calibration model was performed, as shown in Figure 5-45.

Figure 5-45 Accessing Location Inspection

Figure 5-46 illustrates an usage example for the Location Inspection tool. Here we have performed a location inspection after a calibration has been completed for a test lab facility. The results indicate the level of accuracy and precision the location appliance delivered during the calibration. In this example, using an 802.11bg-only calibration client, the location appliance is seen as capable of delivering a level of accuracy and precision (based on conditions in place at the time of calibration) of 7 meters or 23 feet with 90% precision over the majority of the test lab area. Looking at a single calibration data point in specific (artificially indicated in the figure by a yellow arrow to represent the point at which a mouse-over was performed), we see the estimated location indicated by , as well as the details behind the degree of location error for this particular case (16.8 feet).

Figure 5-46 802.11bg Location Inspection

When a mouse-over is performed of any calibration data point (whose location is indicated using small crosshair and is based on the actual coordinates reported by the calibration operator), the following information is displayed:

The predicted location of the calibration client, depicted on the location inspection display by

The RSSI detected by each contributing access point and the band the contribution was made on, as shown in Figure 5-46 by symbols such as BG=-74 or A=-59.

The true and estimated location of the calibration data point listed numerically, in terms of x and y coordinates.

The estimated location error.

A time stamp indicating when the calibration information was collected and the MAC address of the calibration client used to perform the collection.

Note that the band can be specified (2.4 GHz, 5GHz, or both) as well as the performance criteria. The flexibility imparted by this level of control allows the system designer to perform "what if" planning based on the results of location inspection, and examine the limits of higher (or lower) levels of accuracy and precision. This can be useful, for example, when planning for future location applications or in analyzing what areas of the current environment might require additional attention. For example, it is quite easy for us to use both of these controls to visualize the limits of location precision at the 5 meter accuracy level using 802.11a instead of 802.11bg, as shown in Figure 5-47.

Figure 5-47 802.11a Location Inspection Example at 5 m Accuracy

In the case of our test lab example in Figure 5-47, we see that the infrastructure appears to be capable of delivering 5 meter accuracy using 802.11a, with a precision of 85% percent or better in the top two thirds of the test lab floor. However, the bottom area of the figure reveals that challenges exist in meeting this level of accuracy in the lower third of the floor, thereby meriting further investigation. The value of location inspection here is that the modeling of future scenarios where increased accuracy may be required can be performed using the information collected during a current calibration, without involving actual users and without requiring them to participate in trial and error testing.

In both Figure 5-46 and Figure 5-47,note the appearance of calibration data points all along the perimeter of the test lab, between the perimeter access points. These data points were purposely placed there in order to eliminate (or at least reduce) the appearance of "white space" along the perimeter during location inspection. When pure white spaces occur in location inspection output, often times it is due to a lack of data in those areas, which prevents location inspection tool from calculating a valid representation of accuracy and precision at those points. Rather than attempt to provide an estimation based on little or no information, the location inspection tool leaves these areas blank.

To help avoid such behavior, it is suggested that calibration data points be taken along the perimeter, as well as in areas contained within the perimeter. Perimeter data points can be added after the initial calibration if desired. To do this, simply rerun the "Add Data Points" data collection phase for the calibration model, and be sure to take a sufficient number of new data points directly in these white areas. After completion, rerun the "Calibration" phase and re-inspect location quality. These white areas should now be totally eliminated or at least significantly reduced. The process can be repeated if necessary to further address any remaining white areas if still present.

Note Signal strength information for each selected band as well as the test client's actual location coordinates must be available for each floor targeted by the location inspection tool. Even if multiple floors share the same RF model, only the floor upon which the model was actually calibrated is eligible for location inspection.

Using Test Points to Verify Accuracy

Complementing the capabilities found in Location Inspection, beginning with software Release 4.1 the location aware Cisco UWN allows for impromptu "go/no-go" verification of whether the location appliance's baseline accuracy and precision specification has been met on a particular floor. This can be done using the test point facility, which is accessible from the WCS main menu via Monitor > Maps > floor map name > Position Test Point. For a specified device MAC address, the test point facility keeps track of the total number of location test point samples taken, and can calculate the percentage of the total number of test point samples taken whose location accuracy are within the location appliance's baseline specification.

The test point facility is useful when there are tagged assets, wireless client devices or even rogues on a floor whose actual physical location is known and which move very infrequently or not at all. An example of this might be asset tags that are deployed attached to shipping containers that will not be used during this shift, or a wireless-equipped desktop computer that does not move from its deployed location at a supervisor's workstation. If the MAC address of these devices are known, and their actual location will be fixed for an extended period of time, the test point facility can be used to perform a running comparison of their estimated versus actual location, and the results reported back to the user.

When the actual location of a device is specified by the user of the test point facility, and the device's MAC address is added as an active test point, WCS works in concert with the location appliance's debugging facility to compare the device's actual location to its estimated location after each SNMP poll period for that device category. WCS performs these comparisons and calculates the percentage of occurrences where the estimated location of each tracked device is within the baseline performance specification of the location appliance. This information is reported to the WCS user whenever the user highlights the device MAC address in the test point's MAC address drop-down menu and clicks on the "Analyze" option. When the user has completed tracking a specific MAC address, usage of that device as a test point can be terminated by highlighting the device MAC address in the test point MAC address drop-down menu and clicking on the "Stop" option. When all tracking has been completed and the accumulated tracked data is no longer needed, all test points and their test point tracking data can be removed by using the "Clear Logs" option.

Additional information regarding the configuration of the test point facility for use can be found at the following URL: http://www.cisco.com/en/US/docs/wireless/location/2700/3.0/configuration/guide/lacg_ch7.html#wp1066057

Note that before the "Analyze" feature can provide any useful feedback, at least one device category poll period must occur. This is so as to allow the location appliance sufficient time to obtain location information regarding the test points (note that historical location data is not used by the test point facility). It is recommended to allow at least several poll periods to transpire in order to provide the best possible indication of long term location accuracy. Figure 5-48 illustrates an example of the output provided by the "Analyze" feature of the test point facility.

Figure 5-48 Test Point Facility

When using the test point facility, keep in mind the following:

Advanced Debug must be enabled on WCS prior to attempting to use the test point facility. If Advanced Debug is not enabled on WCS, the "Position Test Point" option will not appear in the dropdown menu located at Monitor > Maps > floor map name.

Although it is a recommended best practice to enable the Advanced Debug on the location appliance prior to using the test point facility, it will be enabled automatically whenever a test point is added using the "Save" option.

The "Preview" option is used to position the red cross hair on the Position Test Point floor map only when the user is directly specifying horizontal and vertical (x,y) coordinates. This is done instead of manually positioning the red crosshair to the test point's actual location. The preview capability is provided so that graphical indication of the location corresponding to the (x,y) coordinates just entered can be presented as visual confirmation to the user. If the user manually positions the crosshairs to the test point's location and then clicks on preview, they will not receive any feedback. The preview feature is not intended to display the estimated location of the test point device.

In Figure 5-48, note that the "Total Test Points" quantity reflected in the output of the analyze command does not indicate the total number of test point devices currently in use. Rather, it indicates the total number of test point location samples taken for the highlighted device MAC address.

Although multiple devices can be selected on the Position Test Point WCS screen, test points can only be added (using "Save") one device at a time. The MAC address of the last device used for a save or stop operation is retained and shown under the "Last Used" heading.

Any test points that have been added using "Save" will no longer be accessible to the user if they log out of WCS and then log back in at a later time. In order to ensure that all such residual test points are cleared prior to beginning a new test session, it is a good idea to issue "Clear Logs" before beginning the definition of a new set of test points.

Test points that have been added will not survive a reboot or restart of the appliance. Collected test data will still be resident on the location appliance, however, it will not be possible to add further test point data to that already collected. In order to proceed with further test point data collection and analysis, it is recommended that the device MAC address be stopped or the "Clear Logs" option be used.

The "Clear Logs" option clears all test point data logs and resets any assigned test point devices. Keep in mind that clearing the logs will delete not only the test points created by the current user, but those test points created by any other users that are logged in and authorized to make use of the test point facility as well.

In software Release 4.1, the "Analyze" option performs its calculations in regard to a single device MAC address at a time. If multiple device MAC addresses are added as test points, examine the test point data for each device MAC address individually by highlighting the MAC address of the device in the drop-down selector and then clicking on "Analyze".

1 As discussed in a later section of this design guide, excessive antenna heights can also contribute to diminished accuracy.
2 Note that any realized increase in bandwidth from co-located access points is subject to limitations due to co-channel interference from other access points on those same channels.
3 A computer algebra system (CAS) capable of both symbolic and numeric calculations, such as Maple, Mathematica or Maxima was found to be helpful in solving such calculations. See Appendix B of this document for information regarding how to use Maxima to calculate R as an approximate root of the aforementioned equation over the closed interval (d/2, d).
4 The length of the location appliance's polling cycle for the particular category of device may also play a role. The precise degree of impact will be dependent on the point within the polling cycle the tracked device was prior to migrating out of the location domain.
5 A third RF-calibration model is provided for designers wishing to attempt outdoor deployments using the Cisco Wireless Location Appliance. This white paper does not address outdoor location design guidelines at this time.