Cisco 71642 User Manual

Vocera IP Phone Deployment in Cisco Unified
Wireless Network Infrastructure

Document ID: 71642

Introduction
Prerequisites

Requirements
Components Used
Conventions

Executive Summary
Vocera Badge Overview
Vocera Call Capacity Considerations
Vocera Communications Server Capacity
The Vocera Solution
Vocera's Infrastructure Planning
Architecture Overview
Multicast in an LWAPP Deployment

Unicast−Multicast Delivery Method
Multicast−Multicast Delivery Method
Router and Switch Multicast Configuration
Enable IP Multicast Routing
Enable PIM on an Interface
Disable Switch VLAN IGMP Snooping
Multicast Enhancements in Version 4.0.206.0 and Later

Deployment Scenarios

Single Controller Deployment
Multiple Controller Layer 2 Deployment
Multiple Controller Layer 3 Deployment

VoWLAN Deployments: Ciscos Reccommendations

Recommendations for Multi−Floor Buildings, Hospitals, and Warehouses

Security Mechanisms Supported

LEAP Considerations

Wireless Network Infrastructure

Voice, Data and Vocera VLANs
Network Sizing

Switch Recommendations
Deployments and Configuration

Badge Configuration

Tune AutoRF for Your Environment
Wireless Network Infrastructure Configuration

Create Interfaces
Create the Vocera Voice Interface
Wireless−Specific Configuration
WLAN Configuration
Configure Access Point Detail
Configure the 802.11b/g Radio

Wireless IP Telephony Verification
Association, Authentication, and Registration
Common Roaming Issues

The Badge Loses Connection to the Network or Voice Service is Lost when Roaming
Badge Loses Voice Quality while Roaming

Audio Problems

One−sided Audio
Choppy or Robotic Audio
Registration and Authentication Problems

Appendix A

AP and Antenna Placement
Interference and Multipath Distortion
Signal Attenuation

NetPro Discussion Forums − Featured Conversations
Related Information

Introduction

This document provides design considerations and deployment guidelines for the implementation of the
Vocera® Badge Voice over WLAN (VoWLAN) technology on the Cisco Unified Wireless Network
infrastructure.

Note: Support for Vocera products should be obtained directly from Vocera support channels. Cisco
Technical Support is not trained to support Vocera−related issues.

This guide is a supplement to the Cisco Wireless LAN Controller Deployment Guide and only addresses the
configuration parameters that are particular to Vocera VoWLAN devices in a lightweight architecture. Refer
to Deploying Cisco 440X Series Wireless LAN Controllers for more information.

This document builds upon ideas and concepts presented in the Cisco IP Telephony Solution Reference
Network Design (SRND) and the Cisco Wireless LAN SRND. Both of these SRNDs are available online at
http://www.cisco.com/en/US/netsol/ns656/networking_solutions_program_home.html.

Prerequisites

Requirements

It is assumed that readers are familiar with the terms and concepts presented in the Cisco IP Telephony SRND
and the Cisco Wireless LAN SRND. Both of these SRNDs are available online at
http://www.cisco.com/en/US/netsol/ns656/networking_solutions_program_home.html.

Components Used

This document is not restricted to specific software and hardware versions.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Executive Summary

This table summarizes the four key functions and how they behave within a Cisco Unified Wireless network.

Single

Controller

Controller−to−Controller

Layer 2 Roaming

Controller−to−Controller

Layer 3 Roaming

Badge−to−Badge No special

configuration

No special configuration No special configuration

Badge−to−Phone No special

configuration

Badge−to−Broadcast

Badge Location No special

Enable
Controller
Multicast

configuration

No special configuration No special configuration

Enable Controller
Multicast

Disable Vocera VLAN
IGMP−Snooping or run

4.0.206.0 or later

No special configuration No special configuration

4.0.206.0 or later

Vocera Badge Overview

The communication badges allow a wearer instant communication with any other badge wearer as well a
Private Branch Exchange (PBX) integration and badge location tracking. The utilization of an 802.11b/g
wireless network requires the use of multicast and UDP unicast packet delivery with limited requirements for
Quality of Service (QoS) as of Vocera Server Software release 3.1 (Build 1081). The encryption capabilities
are 64/128 bit Wired Equivalent Privacy (WEP), Temporal Key Integrity Protocol (TKIP), Message Integrity
Check (MIC), and Cisco Temporal Key Integrity Protocol (CKIP) combined with the authentication
capabilities of Open, Wi−Fi Protected Access−Pre−shared Key (WPA−PSK), WPA−Protected Extensible
Authentication Protocol (PEAP) and Lightweight Extensible Authentication Protocol (LEAP).

With the push of a button, the Vocera server responds with Vocera, which is a prompt to issue commands
such as record, where (am I) /is..., call, play, broadcast, messages, and so forth. The Vocera server provides
the necessary services and/or call setup to complete the request.

Vocera's 802.11b capable Communication System makes use of proprietary voice compression and the use of
a UDP port range. The Vocera System software runs on a Windows server that manages call set up, call
connection and user profiles. They have partnered with Nuance 8.5 Speech Recognition and Voiceprint
software in order to enable badge voice communications. Vocera recommends a separate Windows server to
run the Vocera Telephony Solutions Software to enable Plain Old Telephone Service (POTS) connectivity
with the badges.

Vocera Call Capacity Considerations

See the Network Sizing section of this document for further details.

Vocera Communications Server Capacity

Refer to the Vocera Communications System Specifications for more information on Vocera Server sizing
matrix.

The Vocera Solution

The Vocera Badge utilizes both unicast and multicast packet delivery to provide several key features that
make up this complete solution. Here are four of the essential features that rely on proper packet delivery.
Also provided is a basic understanding of how each feature uses the underlying network for delivery and
functionality.

Badge to Badge CommunicationsWhen one Vocera user calls another user, the badge first contacts

•

the Vocera server, which looks up the IP address of the badge of the callee and contacts the badge
user to ask the user if they can take a call. If the callee accepts the call, the Vocera server notifies the
calling badge of the IP address of the callee badge to setup direct communication between the badges
with no further server intervention. All communication with the Vocera server uses the G.711 codec
and all badge−to−badge communication uses a Vocera proprietary codec.
Badge Telephony CommunicationWhen a Vocera Telephony server is installed and setup with a

•

connection to a PBX, a user is able to call internal extensions off of the PBX or outside telephone
lines. Vocera allows users to make calls by either saying the numbers (five, six, three, two) or by
creating an address book entry in the Vocera database for the person or function at that number (for
example, pharmacy, home, pizza) the Vocera server determines the number that is being called, either
by intercepting the numbers in the extension or by looking the name up in the database and selecting
the number. The Vocera server then passes that information to the Vocera Telephony server which
connects to the PBX and generates the appropriate telephony signaling (for example, DTMF). All
communication between the badge and Vocera server and Vocera server and Vocera Telephony
server use the G.711 codec over unicast UDP.
Vocera BroadcastA Vocera Badge user can call and communicate to a group of Vocera badge

•

wearers at the same time by using the Broadcast command. When a user broadcasts to a group, the
user's badge sends the command to the Vocera server who then looks up the members of a group,
determines which members of the group are active, assigns a multicast address to use for this
broadcast session, and sends a message to each active users badge instructing it to join the multicast
group with the assigned multicast address.
Badge Location FunctionThe Vocera server keeps track of the access point to which each active

•

badge is associated as each badge sends a 30 second keep alive to the server with the associated
BSSID. This allows the Vocera system to roughly estimate the location of a badge user. This function
has a relatively low degree of accuracy because a Badge might not be associated to the access point to
which it is closest.

Vocera's Infrastructure Planning

The Vocera whitepaper Vocera Infrastructure Planning Guide , describes the site survey minimum
requirements that show that the badge should have a receive signal strength minimum of −65 dBm, a
signal−to−noise ratio greater than 25 db and proper access point overlap and channel separation. Although the
badges use a similar omni directional antenna as a notebook that is used for a site survey, it does not mimic
the behavior of the badge very well, given the wearers' affects on signal strength. Given this unique
requirement and this behavior of the transmitting device, the use of the Cisco Architecture and Radio
Resource Management is ideal in order to make sure there is a lack of unusual radio frequency (RF) site
characteristics.

The Vocera badge is a low powered device, worn next to the body with limited signal error correction
capabilities. The Vocera requirements in this document can be easily achieved. However, it can become
overwhelmed if there are too many SSIDs for it to process and allow the badge to work effectively.

Architecture Overview

Figure 1General Multicast Forward and Prune with Lightweight Access Point Protocol (LWAPP)
Wireless

Multicast in an LWAPP Deployment

Understanding multicast within an LWAPP deployment is necessary to deploy the Vocera broadcast function.
This document later covers the essential steps to enable multicast within the controller−based solution. There
are currently two delivery methods that the LWAPP controller uses to deliver multicast to the clients:

Unicast−Multicast•
Multicast−Multicast•

Unicast−Multicast Delivery Method

The unicast−multicast delivery method creates a copy of every multicast packet and forwards it to every
access−point. When a client sends a multicast join to the wireless LAN, the access point forwards this join
through the LWAPP tunnel to the controller. The controller bridges this multicast join onto it's directly
connected local area network connection that is the default VLAN for the associated WLAN of the client.
When an IP multicast packet arrives from the network to the controller, the controller replicates this packet
with an LWAPP header for each access point that has a client within the wireless domain who has joined this
specific group. When the source of the multicast is also a receiver within the wireless domain, this packet is
also duplicated and forwarded back to the same client who sent this packet. For Vocera badges, this is not the
preferred method of multicast delivery within the LWAPP controller solution. The unicast delivery method
works with small deployments. However, due to the considerable overhead on the Wireless LAN Controller
(WLC), this is never the recommended multicast delivery method.

Figure 2LWAPP Multicast−Unicast

Note: If AP Group VLANs are configured, and an IGMP join is sent from a client through the controller, it is

placed on the default VLAN of the WLAN that the client is on. Therefore, the client might not receive this
multicast traffic unless the client is a member of this default broadcast domain.

Multicast−Multicast Delivery Method

The multicast−multicast delivery method does not require the controller to replicate each multicast packet
received. The controller is configured for an un−used multicast group address that each access point becomes
a member of. With Figure 3, the multicast group defined from the WLC to the access point is 239.0.0.65.
When a client sends a multicast join to the WLAN, the access point forwards this join through the LWAPP
tunnel to the controller. The controller forwards this link−layer protocol onto it's directly connected local area
network connection that is the default VLAN for the associated WLAN of the client. The router that is local to
the controller then adds this multicast group address to that interface for forwarding ((*,G)) entry. With Figure
3, the example multicast join was sent to the multicast group 239.0.0.30. When the network now forwards
multicast traffic, the multicast address of 239.0.0.30 is forwarded to the controller. The controller then
encapsulates the multicast packet into an LWAPP multicast packet addressed to the multicast group address
(example here is 239.0.0.65) that is configured on the controller and forwarded to the network. Each access
point on the controller receives this packet as a member of the controllers multicast group. The access point
then forwards the clients/servers multicast packet (example here is 239.0.0.30) as a broadcast to the
WLAN/SSID identified within the LWAPP multicast packet.

Note: If you improperly configure your multicast network, you could end up receiving another controller's
access point multicast packets. If the first controller has to fragment this multicast packet, the fragment is
forwarded to the network and each access point must spend time to drop this fragment. If you allow all traffic
such as anything from the 224.0.0.x multicast range, this is also encapsulated and subsequently forwarded by
each access point.

Figure 3LWAPP Multicast−Multicast

Router and Switch Multicast Configuration

This document is not a network multicast configuration guide. Refer to Configuring IP Multicast Routing for
a complete implementation story. This document covers the basics to enable multicast within your network
environment.

Enable IP Multicast Routing

IP multicast routing allows the Cisco IOS® software to forward multicast packets. The ip multicast−routing
global configuration command is required to allow multicast to function in any multicast enabled network.
The ip multicast−routing command should be enabled on all routers within your network between the
WLC(s) and their respective access points.

Router(config)#ip multicast−routing

Enable PIM on an Interface

This enables the routing interface for Internet Group Management Protocol (IGMP) operation. The Protocol
Independent Multicast (PIM) mode determines how the router populates its multicast routing table. The
example provided here does not require the rendezvous point (RP) to be known for the multicast group and
therefore sparse−dense−mode is the most desirable given the unknown nature of your multicast environment.
This is not a multicast recommendation to be configured to work although the Layer 3 interface directly
connected to your controller should be PIM enabled for multicast to function. All interfaces between your
WLC(s) and their respective access points should be enabled.

Router(config−if)#ip pim sparse−dense−mode

Disable Switch VLAN IGMP Snooping

IGMP snooping allows a switched network with multicast enabled to limit traffic to those switchports that
have users who want multicast to be seen while pruning the multicast packets from switchports that do not
wish to see the multicast stream. In a Vocera deployment, it can be undesirable to enable CGMP or IGMP
snooping on the upstream switchport to the controller with software releases earlier than 4.0.206.0.

Roaming and multicast are not defined with a set of requirements to verify that multicast traffic can follow a
subscribed user. Although the client badge is aware that it has roamed, it does not forward another IGMP join
to make sure that the network infrastructure continues to deliver the multicast (Vocera broadcast) traffic to the
badge. At the same time, the LWAPP access point does not send a general multicast query to the roamed
client to prompt for this IGMP join. With a Layer 2 Vocera network design, disabling IGMP snooping allows
traffic to be forwarded to all members of the Vocera network no matter where they roam. This ensures that the
Vocera broadcast feature works irrespective of where the client roams. Disabling IGMP snooping globally is a
very undesirable task. It is recommended that IGMP snooping only be disabled on the Vocera VLAN that is
directly connected to each WLC.

Refer to Configuring IGMP Snooping for more information.

Router(config)#interface vlan 150
Router(config−if)#no ip igmp snooping

Multicast Enhancements in Version 4.0.206.0 and Later

With the release of 4.0.206.0, Cisco introduces an IGMP query to allow users to roam at Layer 2 by sending a
general IGMP query when this occurs. The client then responds with the IGMP group that they are a member
of and this is bridged to the wired network as described earlier in this document. When a client roams to a
controller that does not have Layer 2 connectivity, or a Layer 3 roam, synchronous routing is added for
multicast source packets. When a client, who has completed a Layer 3 roam sources a multicast packet from
the wireless network, the foreign controller encapsulates this packet in the Ethernet over IP (EoIP) in IP tunnel
to the anchor controller. The anchor controller then forwards that to the wireless clients locally associated as
well as bridge this back to the wired network where it is routed using normal multicast routing methods.

Deployment Scenarios

These three deployment scenarios cover best practices and design parameters to help with a successful Vocera
Badge deployment:

Single Controller Deployment•
Multiple Controller Layer 2 Deployment•
Multiple Controller Layer 3 Deployment•

Understanding how the Vocera Badge features interact within an LWAPP split MAC environment is essential.
With all deployment scenarios, multicast should be enabled and aggressive load balancing should be disabled.
All badge WLANs should be contained within the same broadcast domain across your entire network.

Figure 4

Single Controller Deployment

This is the most straight forward deployment scenario. It allows you to deploy the Vocera Badge solution with
little deployment concerns. Your network must be enabled for IP multicast routing only to allow the access
points to receive the LWAPP multicast packets. If required, you can limit network multicast complexity by
configuring all routers and switches with the controllers multicast group.

With multicast configured globally on the controller, the proper SSID, security settings, and all the access
points registered the Vocera Badge solution and all its functions operates as expected. With the Vocera
Broadcast function, a user roams and the multicast traffic follows as expected. There are no extra settings
required to be configured to allow this solution to function properly.

When a Vocera Badge sends a multicast message, as it does with the Vocera Broadcast, it is forwarded to the
controller. The controller then encapsulates this multicast packet within an LWAPP multicast packet. The
network infrastructure forwards this packet to every access point that is connected to this controller. When the
access point receives this packet, it then looks at the LWAPP multicast header to determine which
WLAN/SSID it then broadcasts this packet to.

Figure 5Single Controller in Multicast−Multicast Mode

Multiple Controller Layer 2 Deployment

Multiple controllers must all have connectivity to each other via the same Layer 2 broadcast domain. Both
controllers are configured for multicast as shown, using the identical access point multicast groups on each
controller to limit fragmentation. With the assumption that this Layer 2 broadcast domain is connected via a
common switch or a common set of switches, CGMP/IGMP snooping on these switches must be disabled for
this single VLAN or run 4.0.206.0 or later WLC software. With the Vocera Broadcast function and a user
roam from an access point on one controller to an access point on a different controller, there is no mechanism
for IGMP joins to be forwarded to the new Layer 2 port for IGMP snooping to work. Without an IGMP
packet reaching the upstream CGMP or IGMP capable switch, the specified multicast group is not forwarded
to the controller and therefore is not received by the client. In some cases this might work, if a client that is
part of the same Vocera Broadcast group has already sent this IGMP packet before the roaming client roams
onto the new controller With the advantages of version 4.0.206.0, a client who roams to another controller as a
Layer 2 roam receives a general IGMP query immediately after authentication. The client should then respond
with the interested groups and the new controller is then bridged this to the locally connected switch. This
allows the advantages of IGMP and CGMP on your upstream switches.

You can create additional badge SSIDs and Layer 2 domains for separate badge networks as long as your
network is configured to pass multicast traffic appropriately. Also, each Vocera Layer 2 broadcast domain
created must exist everywhere a controller is connected to the network so as not to break multicast.

Figure 6Multiple Controller Layer 2 Deployment

Multiple Controller Layer 3 Deployment

The Layer 3 roaming deployment strategy should only be used with controller−to−controller roaming with
WLC software release 4.0.206.0 or later. If a client that has been connected to the Vocera broadcast group and
receives the appropriate multicast stream and roams to another controller as a Layer 3 roam with the LWAPP
Layer 3 roaming configured, it is queried for interested multicast groups. The client, when sourcing to the
same Vocera broadcast group, has these packets delivered to the anchor controller through the EoIP tunnel