Voice over WLAN Unified Communications Test Architecture
Cisco Unified Communications Manager Introduction
Cisco Unified Communications Manager (Cisco UCM) is the call-processing component of the Cisco Unified Communications System (previously known as Cisco CallManager). The Cisco UCM extends enterprise telephony features and capabilities to IP phones, media processing devices, gateways, mobile devices and multimedia applications. Additional services such as unified messaging, multimedia conferencing, collaborative contact centers, and interactive multimedia response systems interact with the IP telephony solution through Cisco UCM APIs. The Cisco UCM is installed on Cisco Media Convergence Server (MCS) 7800 Series of server platforms and selected third-party servers. An example of Cisco UCM and several possible services and endpoints is shown in Figure 7-1.
Figure 7-1 Cisco Unified Communications Manager Example
This Cisco UCM design is based on the existing Cisco Unified Communications Solution Reference Network Design (based on Cisco UCM Release 6.x):
Cisco Unified Communications System Release Summary Matrix for IP Telephony:
Cisco Unified Communications Manager Design Overview
There are several deployment models for Cisco UCM based on the following factors:
•Number of call processing agent clusters
•Number of IP phones
•Locations of the call processing cluster(s) and IP phones
The single-site model for Cisco Unified Communications consists of a call processing agent cluster located at a single site, or campus, with no telephony services provided over an IP WAN.
Multisite WAN with Centralized Call Processing
The model for a multisite WAN deployment with centralized call processing consists of a single call processing cluster that provides services for many remote sites and uses the IP WAN to transport Cisco Unified Communications traffic between the sites.
Multisite WAN with Distributed Call Processing
The model for a multisite WAN deployment with distributed call processing consists of multiple independent sites, each with its own call processing cluster connected to an IP WAN that carries voice traffic between the distributed sites
Clustering Over the IP WAN
It is possible to deploy a single UCM cluster across multiple sites that are connected by a QoS-enabled IP WAN. For specific WAN requirements, refer to the Cisco Unified Communications Solution Reference Network Design:
Each deployment model has benefits and network requirements that should be considered. Further descriptions of the Cisco Unified Communications Manager Deployment models are available within the Cisco Unified Communications Solution Reference Network Design.
The design considerations presented in this chapter were based on the use of a Multisite WAN with Centralized Call Processing deployment. This model consists of a centralized call processing cluster and one or more remote sites using an IP WAN to transport voice and call control.
Figure 7-2 is an example of a Multisite WAN with Centralized Call Processing with one branch location.
Figure 7-2 Multisite with Centralized Call Processing
Cisco Unified Communications Manager Configuration
Wireless phones (and softphones) are inherently mobile so controlling the admission of their calls into a network is critical to maintaining the quality of calls by avoiding traffic collisions leading to loss, jitter and delay perceptible to the user. The next two sections will discuss CAC and Device Mobility and how Device Mobility configuration is important to maintaining accurate CAC decisions.
Call Admission Control
This chapter discusses Call Admission Control (CAC) by the Cisco UCM for those devices on the physical IP LAN/WAN, in the context of a single cluster design. This applies to wireless phones (Cisco 7920/7921) from the point of entry into the physical network. CAC must also be considered on the wireless network and is discussed in detail in the Chapter 2, "WLAN Quality of Service."
CAC in the context of this chapter is a concept that applies to real-time (voice) traffic only, not data traffic. If an influx of data traffic oversubscribes a particular link in the network, queuing, buffering, and packet drop decisions resolve the congestion. The extra traffic is simply delayed until the interface becomes available to send the traffic, or, if traffic is dropped, protocol timeouts or user-initiated actions will trigger the re-transmission of the information.
Network congestion cannot be resolved in this manner when real-time traffic, sensitive to both latency and packet loss, is present, without jeopardizing the quality of service (QoS) expected by the users of that traffic. For real-time delay-sensitive traffic such as voice, it is better to deny network access under congestion conditions than to allow traffic onto the network to be dropped and delayed, resulting in sporadic impairments perceived by the users.
QoS protects voice from being overrun by data. CAC on the other hand, protects voice from voice. If a link can support X calls, allowing X + 1 calls will have a negative impact on calls being carried by that link. CAC is therefore a deterministic and informed decision that is made before a voice call is established and is based on whether the required network resources are available to provide suitable QoS for the new call.
Considering Figure 7-3, because it is based on a packet-switched network (the IP network), no circuits are established to setup an IP telephony call. Instead, the IP packets containing the voice samples are simply routed across the IP network together with other types of data packets. QoS is used to differentiate the voice packets from the data packets, but bandwidth resources, especially on IP WAN links, are not infinite. Therefore, network administrators dedicate a certain amount of "priority" bandwidth to voice traffic on each IP WAN link. However, once the provisioned bandwidth has been fully used, the IP telephony system must reject subsequent calls to avoid oversubscription of the priority queue on the IP WAN link, which would cause quality degradation for all voice calls.
Figure 7-3 CAC Example
Most CAC control mechanisms fall into two categories:
•Topology-unaware call admission control—Based on a static configuration within the call processing agent
•Topology-aware call admission control—Based on communication between the call processing agent and the network about the available resources
Topology-unaware CAC is based on the UCM construct of CAC static locations, with each branch site belonging to a unique location. All devices in a site are assigned to the same location. Based on the amount of bandwidth available, each site would support a specific number of calls over the IP WAN.
Topology-aware CAC limits the number of calls across the IP WAN using real-time communications about the availability of network resources between the UCM and the network. This CAC mechanism works well in environments with constant topology changes as it can dynamically adjust to the changes, or with non hub-and-spoke WAN topologies. Resource Reservation Protocol (RSVP) is the primary industry-standard signaling protocol that enables an application to reserve bandwidth dynamically across an IP network. Using RSVP, applications can request a certain amount of bandwidth for a data flow across a network (for example, a voice call) and can receive an indication of the outcome of the reservation based on actual resource availability.
For this version of the design guide, static locations-based CAC (topology-unaware) was used. For an in-depth discussion of CAC, refer to Cisco Unified Communications Solution Reference Network Design at the following URL:
Mobility of wireless phones includes not just moving between access points within a building but also moving between buildings and locations. If a wireless phone user is defined with a UCM region and location specific to their home location (for example, San Jose) takes their phone to a branch office in somewhere else (for example, in RTP), it is important that device mobility is configured so the WAN links between these location are not oversubscribed. Without device mobility, when the users phone registers in the branch location (RTP), the UCM configuration for the phone assumes they have registered in San Jose. If the user dials a PSTN number in RTP, UCM may use a gateway in San Jose and also not deduct bandwidth that the phone is using over the WAN link between RTP and San Jose, possibly causing and over-subscription environment.
Device mobility allows UCM to make device configuration decisions based on the subnet of the device that is registering. Some of the device mobility elements include:
•Device Mobility Info—Configures IP subnets and associates device pools to the IP subnets.
•Device Mobility Group—Defines a logical group of sites with similar dialing patterns (for example, US_dmg and EUR_dmg).
•Physical Location—Defines the physical location of a device pool. In other words, this element defines the geographic location of IP phones and other devices associated with the device pool.
UCM uses a new set of parameters under the device pool configuration to accommodate device mobility. These parameters are of the following two main types:
•Roaming Sensitive Settings
•Device Mobility Related Settings
Roaming Sensitive Settings
The parameters under these settings override the device-level settings when the device is roaming within or outside a device mobility group. The parameters included in these settings are:
•Media Resource Group List
•Device Mobility Group
The roaming sensitive settings primarily help in achieving proper CAC and voice codec selection, because the location and region configurations are used based on the device's roaming device pool. The roaming sensitive settings also update the media resource group list (MRGL) so that appropriate remote media resources are used for music on hold, conferencing, transcoding, and so forth, thus utilizing the network efficiently. The roaming sensitive settings also update the Survivable Remote Site Telephony (SRST) gateway. Mobile users register to a different SRST gateway while roaming.
Device Mobility Related Settings
The parameters under these settings will override the device-level settings only when the device is roaming within a device mobility group. The parameters included in these settings are:
•Device Mobility Calling Search Space
•AAR Calling Search Space
The device mobility related settings affect the dial plan because the calling search space dictates the patterns that can be dialed or the devices that can be reached. Device mobility group, as explained earlier, defines a logical group of sites with similar dialing patterns (for example, sites having the same PSTN access codes and so forth). With this guideline, all sites have similar dialing patterns in the site-specific calling search spaces. Sites having different dialing behavior are in a different device mobility group. A user roaming within a device mobility group may preserve his dialing behavior at the remote location even after receiving a new calling search space. A user roaming outside the device mobility group may still preserve his dialing behavior at the remote location because he uses his home calling search space. However, if a device mobility group is defined with sites having different dialing patterns (for example, sites having different PSTN access codes), then a user roaming within that device mobility group might not preserve his same dialing behavior at all locations. A user might have to dial digits differently at different locations after receiving a new calling search space at each location.
For an in-depth discussion of device mobility, refer to Cisco Unified Communications Solution Reference Network Design:
Refer to the Cisco Unified Communications Solution Reference Network Design for additional network infrastructure recommendations.
UCM and Phone versions
This design guide use the following Cisco UCM and phone versions:
•Cisco UCM 6.0.1