We have a Vocera/Hill-Rom site survey going on right now. Our environment is around 200 AP with 5 4404 WLC. Some of the AP are 1242 and some are old 1200 that have been converted. I'll post any info that I find out, but I too would like to hear some implementation stories. Seems like the push to talk feature uses Multicast, which may be tricky with LWAPP.
Last I knew, Vocera was currently testing their badge with the LWAPP solution. This was mentioned at the user group I attended this spring. We also are deploying WCS w/7 4404. We already have experienced enough headaches with Vocera under IOS.....I'm testing Vocera this week and next. Stay tuned.
We have just implemented a Cisco LWAPP solution in a building at a Major Hospital in PHIL. they are already using a Vocera solution on their previously installed Symbol network. The Vocera SSID was configured the same for Cisco and Sybol and the badges didn't seem to know the difference. During testing we saw very good performance in badge to badge calls as well as badge to phone calls. It should be noted that traffic was fairly light on the WLAN at the time of testing. The APs in use were 1131s and 1242s all in LWAPP mode controlled by 4404s
We are also in the process of piloting some vocera badges in our facility, lwapp access points consisting of converted 1230's and many 1242 models. I am also curious about the fact that multicasting has to be used to support the broadcasted ssid. I will post any significant updates and would like to hear how everyone else is doing with this.
Vocera does work with LWAPP. We discovered a few new things to configure. IGMP Snooping has to be disabled on the VLAN interface. Multicast enabled on WLC4400, same mobility groups. Drop me a line if you want to discuss more in details. This also depends on which type of routing devices you are using. We are all Cisco here.
I've been using Vocera with v.22.214.171.124 for awhile now and it's working well. I have several hundred Access Points and several hundred Vocera badges.
If you have an existing deployment, you'll need to rebuild the location fields in Vocera as LWAPP appends to the real MAC address. This is only needed if you're using the location based service in Vocera where you can "call a nurse near building C."
From the Vocera KnowledgeBase:
There are really three main problems with LWAPP:
1) Loss of mobility anchor when roaming - a known bug that is fixed in the 4.x release (?)
2) Badges are unable to send a broadcast (multicast) - perhaps another known LWAPP bug that doesn't fully implement IGMP so that multicast does not traverse an L3 network.
3) Coverage holes.
This problem is reportedly fixed by the latest Cisco software release for the 4404 controllers (version 126.96.36.199) with LAG enabled, with Multicast enabled on all controllers, in UNICAST mode. To obtain the hot-fix one may need to open a TAC with Cisco to request it.
Setting the WLC multicast mode to unicast is the most important thing here if you intend to use the broadcast functionality.
Also, there is a new design guide out (attached).
The real challenges with the badges are the low power and the Vocera broadcast (multicast) but neither of these could be classified as a bug. 802.11 does not address roaming and multicast, the badges do not send out IGMP joins when they roam and the LWAPP infrastructure does not query the client.
Now if the badge is going to roam via Layer 3, it can no longer send packets to the network as they will be dropped by the upstream device do to it failing the uRPF checks required by multicast routing.
Good info here, but could you elaborate on #2 and 3 in a separate email to me if possible. We are running 188.8.131.52 and we have seen Vocera issues when we have APs across multiple WLC 4404. Coverage holes alarms always show up in WCS from Vocera badges. Seems that the badges have a tendency to hang on to an AP rather than roam.
No problem, not sure if I have your email or not, early, I promise to look back at the message but here is a document I wrote on how to deploy Vocera on top of our LWAPP infrstructure:
With regards to roaming, this came up when I had the opportunity to visit some hospitals on the east coast. There is the "CQ" value that the badge uses to decide when to start looking for another AP. What happens is that the badge will broadcast at 20mW and the AP at any value higher will allow the AP to be "Heard" clearer than the badge can be "heard" by the AP. The way to manipulate this is to make sure we turn our transmit power threshold down on the AP's or remove the lower data rates (remembering that the beacon is sent on the lowest permissable data rate.) I recomend that you manipulate RRM for your environment, as many applications prefer the lower data rates to function properly, including the badge. The command to manipulate this is only available from the CLI:
config advanced 802.11b tx-power-control-thresh -71
The -71 represents -71dBm that you will see under the AutoRF for 802.11b/g. Let this settle for about 30 minutes before retesting then with the badge issue the "begin tour" command and see how your roaming behavior is. If that changes to an acceptable level cancel the tour and issue the "play tutorial" command and begin a walk about again. If you are still too sticky (you should see some change) check the CQ values from the badge as you roam and adjust again, the largest value you can use is -80dBm.
Let me know how that works