Forum

I have a dilemma that I ask for the recommendation of those that have been there and done that.

There are situation's when LWAPP is used or any other CAPWAP (protocol) of current specifications which makes performing manual and virtual site surveys a bit impractical, if not impossible.

How does one survey using a LWAPP type environment ,without putting up more than enough WAPs to mitigate the under or over subcription that can occur, especially in the enterprise?

Let me throw out where I am going....I stated this to my former employers, they brsuhed it off and ended up going back in deploying more WAPs at their cost.

The access points in certain environments are able to adjust the power and load balance themselves with the controller based on the changes in the environment and client population.

Moreover, this deployment method and design of networks that is dynamically changing can become a nightmare. Especially when there are surveys being done using the manual or virtual methods and not taking into account the LWAPP features like TPC indoors.

This inevitably create blindspots, should say the AP adjust its power to overcome or support some of the usage patterns.

Also, if using RFID tags in these environments, the ability to triangulate and provide location based awareness is suspect to more inaccurate locations.

Throwing out more WAPs is often times troublesome (location and costs) The surveyor/designer is limited in understanding the dynamics with more and more devices in the unlicensed spectrum coming on board.

Is there a way to mitigate this : will 802.11n be the Silver Bullet?

What has worked for you?

When I do site surveys for LWAPP environments, I just use the APs we'll be deploying (typically AP1240s and 1130s) and put a standalone version of IOS on them. Do your site survey with the same antennas you'll be using for the deployment and your RF characteristics will be the same when the APs are LWAPPed and joined to the controllers.

Joel

Thanks joelb

What about situations when LWAPP is already engaged on the network . You go in to optimize the RF environment and the RF keeps changing around you giving you the up and down RSSI /SNR readings. The WAPs signal fluctuates with your current walk through survey tool and voids the process?

Say the customer doesn't have a graphical management platform to understand where to place the APs in the WLAN environment on a heat map?

Lastly,

What if you have an organization that is presently using set powered APs, using for example, IOS, and then they convert to using LWAPP.

Will that change the dynamics of the RF ? Or will the controllers simply learn the old environment and make changes, only if you specify a change is needed?

I'm not sure exactly what you mean by this question:

What about situations when LWAPP is already engaged on the network . You go in to optimize the RF environment and the RF keeps changing around you giving you the up and down RSSI /SNR readings. The WAPs signal fluctuates with your current walk through survey tool and voids the process?

but I'll try to answer you anyway.

The feature Cisco uses in LWAPP environments to automatically adjust the APs is called Auto RF and uses Radio Resource Management (RRM) to perform the adjustments. The controller makes adjustments based on how the APs and their clients are performing so if you've already got controller-based APs deployed, there's not a huge need for additional site surveys. You use the capabilities of the system to self-monitor and self-adjust as needed.

If you feel you need to perform a re-site survey, for example, say you want to add advanced capabilities like location tracking or VoWLAN to an existing data-only WLAN, you could either use tools in the controller or Wireless Control System or perform a manual site survey.

I'm not sure I understand what you mean by, "The WAPs signal fluctuates with your current walk through survey tool and voids the process?" Just because you've got Auto RF enabled, doesn't mean the APs are constantly changing their settings. For Cisco, some threshold exception must occur to cause the controller to adjust the AP settings, for example, a lot of people enter a conference room and all of them want WLAN access -- this might cause neighboring APs to increase their power so the clients are better distributed (i.e. load balanced) rather than swamping the one AP in the conference room. Or, if a wall is erected to separate one area from another, clients experiencing a "coverage hole" could lead to a warning that would prompt an administrator to consider adding an AP to that area. Until the coverage hole was alleviated, neighboring APs could increase their power to take care of clients in that area.

With any system that does auto AP reconfiguration, it will make static site surveys less reliable but it does not invalidate them, especially if part of the site survey is to get an overall picture of the RF environment. This information is as important to understand as where to place APs. For Cisco, Auto RF allows customers to always keep an up-to-date picture on the health and status of the WLAN -- it's like having a permanent site survey running.

Say the customer doesn't have a graphical management platform to understand where to place the APs in the WLAN environment on a heat map?

If this is the site survey before APs are deployed, then a site survey is always recommended. The customer has two methods of accomplishing this. They can either have a site survey done before the WLAN is deployed or the deployment team can use tools that will let them perform site survey functions while the APs are being deployed. Either way, the same information is required for the end result. The customer either incurs the cost up front or in the extra amount of time it takes to do it while the WLAN is being deployed. Many customers are moving toward the "deploy and go" process because it's faster overall, i.e. they start getting wireless access the day the APs get deployed rather than having to wait until after the site survey is done.

If at the end of the deployment the customer doesn't have some management tool for their WLAN, then it's most likely a small environment, probably less than 20 APs. The deployment team will have to choose how to manage that environment. With Cisco they have three basic choices, 1) use Auto RF and let the system self-adjust, 2) run Auto RF until the WLAN is stablized then use "On Demand" which will only recalculate the environment when an administrator deems it necessary, or 3) disable Auto RF and use the values determined through the site survey process. Disabling Auto RF will make the WLAN vulnerable to RF interference such as when neighboring offices install their own WLAN systems. Enabling Auto RF allows the environment to dynamically adjust when issues arise.

You also asked:

What if you have an organization that is presently using set powered APs, using for example, IOS, and then they convert to using LWAPP. Will that change the dynamics of the RF ? Or will the controllers simply learn the old environment and make changes, only if you specify a change is needed?

In this scenario, unless you've upgraded the radios and/or APs, the RF environment will be the same. Moving from autonomous APs to controller-based APs doesn't change the characteristics of the radio or antenna in that AP. Note, there are some older Cisco APs that will need upgraded radios in order to work with the controllers. There are also some really old Cisco APs, such as AP340s and AP350s, that aren't supported with the contollers. If you have supported APs and migrate them to controllers, the controller will "see" the RF environment and adjust accordingly.

Hope that helps,
Joel

joelb, thank you much. My eyes are opening. This HELPS much.

The situation is the RF surveyor is trying to validate his network design/installation after networks are installed with the AutoRF features by conducting a survey. The APs power levels dynamic adjustments causes misleading readings on his survey device.

This (manual survey) may not be possible from what I have read with the Auto RF enabled. The dynamics of the clients roaming and the challenging environment doesn't support validating the design with a manual survey.

Most likely disabling the AutoRF feature, may cause more problems too...as it (the survey) is in a healthcare/hospital environment. They have a mix of 802.11b voice devices not from your organization but those kind that sounds like mascera.

Perhaps this should be in the Vendor specific forum? If so, please forgive me for posting it here.

Best Regards

You're talking about Vocera Communications. Vocera sells VoIP devices that are wireless. They call them "badges". The badges aren't traditional phones but they do offer voice communications across the WLAN. Here's a link to their website:

http://www.vocera.com

Joel

Yes, Vocera are the devices in use.

They (Vocera) are looking at adding some cell phone features to the badges and the CCX stamp of approval to work with your Call Managers amongst other enhancements.

Vocera isn't just for Wi-Fi badges anymore. At the medical-themed HIMSS show in New Orleans this week, it announced partnerships to extend its reach. One deal is with Sprint, who will help Vocera's customers stay in touch on the Sprint cell network even when not in range of their local WLAN used by the VoIP badges. Motorola's ruggedized MC70 digital assistant hardware will get full Vocera abilities, so it can be used as a speakerphone like the badge (or like a regular phone if held to the ear). Vocera will support Cisco Compatible Extentions (CCX) to work better under Cisco infrastructure, even talking with Cisco IP phones connected to the Cisco Call Manager. A deal with Dictaphone will let doctors use their Vocera badge to dictate and edit notes, even while they're with a patient. And Vocera will have a new SIP interface later in 2007.

I will investigate that" On Demand" feature you mentioned more in detail. Sounds as though that is a good feature to have, when conducting a manual survey. If it propagates the RF only when you select it, that may help during the validation period.

I wonder if throughput measurements might serve as a really good validation for WLAN performance in a data network, and helpful for wVoIP?

This will give you a quality score, which accounts for co-channel interference, adjacent-channel interference, excessive multipath, load balancing, and AP or client rf output power adjustment. It might give you an indication of roaming efficiency with a planned path through the facility.

Would this provide useful information to confirm or add to whatever management information you are getting from a controller? If you use the same radio/tablet/laptop that is a standard in that facility, it might be a better guide to client experience than using predicted client experience based on RSSI and SNR or SINR.

If you made one pass at a light WLAN load time, and one at a heavy load time it might show whether the controller was working effectively.

Of course, the next question is throughput of what, which would depend on the type of traffic on the WLAN. I've found a big difference in mainly long packets to the client, vs more balanced flows or short packets.

In my last post, about using throughput for validation, I wasn't suggesting not capturing RSSI at all measurement points, as well. The software I use does this, since I'm very interested in predicted vs actual RSSI at all locations. That leads to the problem of knowing the AP power output at measurement time for existing installations.

I've tried different ways to measure this, with client cards and spectrum analyzers at short known distances from visible omnidirectional antennas, but it's hard to get a good measurement at a high level of certainty, especially with people moving around in the vicinity.

Charles Preston

joelb Escribi?3:

I'm not sure exactly what you mean by this question:

What about situations when LWAPP is already engaged on the network . You go in to optimize the RF environment and the RF keeps changing around you giving you the up and down RSSI /SNR readings. The WAPs signal fluctuates with your current walk through survey tool and voids the process?

but I'll try to answer you anyway.

The feature Cisco uses in LWAPP environments to automatically adjust the APs is called Auto RF and uses Radio Resource Management (RRM) to perform the adjustments. The controller makes adjustments based on how the APs and their clients are performing so if you've already got controller-based APs deployed, there's not a huge need for additional site surveys. You use the capabilities of the system to self-monitor and self-adjust as needed.

If you feel you need to perform a re-site survey, for example, say you want to add advanced capabilities like location tracking or VoWLAN to an existing data-only WLAN, you could either use tools in the controller or Wireless Control System or perform a manual site survey.

I'm not sure I understand what you mean by, "The WAPs signal fluctuates with your current walk through survey tool and voids the process?" Just because you've got Auto RF enabled, doesn't mean the APs are constantly changing their settings. For Cisco, some threshold exception must occur to cause the controller to adjust the AP settings, for example, a lot of people enter a conference room and all of them want WLAN access -- this might cause neighboring APs to increase their power so the clients are better distributed (i.e. load balanced) rather than swamping the one AP in the conference room. Or, if a wall is erected to separate one area from another, clients experiencing a "coverage hole" could lead to a warning that would prompt an administrator to consider adding an AP to that area. Until the coverage hole was alleviated, neighboring APs could increase their power to take care of clients in that area.

With any system that does auto AP reconfiguration, it will make static site surveys less reliable but it does not invalidate them, especially if part of the site survey is to get an overall picture of the RF environment. This information is as important to understand as where to place APs. For Cisco, Auto RF allows customers to always keep an up-to-date picture on the health and status of the WLAN -- it's like having a permanent site survey running.

Say the customer doesn't have a graphical management platform to understand where to place the APs in the WLAN environment on a heat map?

If this is the site survey before APs are deployed, then a site survey is always recommended. The customer has two methods of accomplishing this. They can either have a site survey done before the WLAN is deployed or the deployment team can use tools that will let them perform site survey functions while the APs are being deployed. Either way, the same information is required for the end result. The customer either incurs the cost up front or in the extra amount of time it takes to do it while the WLAN is being deployed. Many customers are moving toward the "deploy and go" process because it's faster overall, i.e. they start getting wireless access the day the APs get deployed rather than having to wait until after the site survey is done.

If at the end of the deployment the customer doesn't have some management tool for their WLAN, then it's most likely a small environment, probably less than 20 APs. The deployment team will have to choose how to manage that environment. With Cisco they have three basic choices, 1) use Auto RF and let the system self-adjust, 2) run Auto RF until the WLAN is stablized then use "On Demand" which will only recalculate the environment when an administrator deems it necessary, or 3) disable Auto RF and use the values determined through the site survey process. Disabling Auto RF will make the WLAN vulnerable to RF interference such as when neighboring offices install their own WLAN systems. Enabling Auto RF allows the environment to dynamically adjust when issues arise.

You also asked:

What if you have an organization that is presently using set powered APs, using for example, IOS, and then they convert to using LWAPP. Will that change the dynamics of the RF ? Or will the controllers simply learn the old environment and make changes, only if you specify a change is needed?

In this scenario, unless you've upgraded the radios and/or APs, the RF environment will be the same. Moving from autonomous APs to controller-based APs doesn't change the characteristics of the radio or antenna in that AP. Note, there are some older Cisco APs that will need upgraded radios in order to work with the controllers. There are also some really old Cisco APs, such as AP340s and AP350s, that aren't supported with the contollers. If you have supported APs and migrate them to controllers, the controller will "see" the RF environment and adjust accordingly.

Hope that helps,
Joel