Last revised on: August 5, 2008
In Cisco Unified Communications Manager (Unified CM), a site or a physical location is identified using various settings such as locations, regions, calling search spaces, and media resources. Cisco Unified IP Phones residing in a particular site are statically configured with these settings. Unified CM uses these settings for proper call establishment, call routing, media resource selection, and so forth. However, when mobile phones such as Cisco IP Communicator or Cisco Unified Wireless IP Phones are moved from their home site to a remote site, they retain the home settings that are statically configured on the phones. Unified CM then uses these home settings on the phones in the remote site. This situation is undesirable because it can cause problems with call routing, codec selection, media resource selection, and other call processing functions.
Cisco Unified CM uses a feature called Device Mobility, which enables Unified CM to determine if the IP phone is at its home location or at a roaming location. Unified CM uses the device's IP subnets to determine the exact location of the IP phone. By enabling device mobility within a cluster, mobile users can roam from one site to another, thus acquiring the site-specific settings. Unified CM then uses these dynamically allocated settings for call routing, codec section, media resource selection, and so forth.
This chapter explains the design consideration for implementing device mobility within a Unified CM cluster.
Need for Device Mobility
This section explains the need for device mobility when there are many mobile users in a Unified CM cluster.
Figure 21-1 illustrates a hypothetical network containing a Unified CM cluster without the Device Mobility feature, located at the headquarter site (HQ). The cluster has two remote sites, Branch1 and Branch2. All intra-site calls use G.711 voice codecs, while all inter-site calls (calls across the IP WAN) use G.729 voice codecs. Each site has a PSTN gateway for external calls.
Figure 21-1 Example Network with Two Remote Sites
When a user in Branch1 moves to Branch2 and calls a PSTN user in Denver, the following behavior occurs:
•Unified CM is not aware that the user has moved from Branch1 to Branch2. An external call to the PSTN is sent over the WAN to the Branch1 gateway and then out to the PSTN. Thus, the mobile user continues to use its home gateway for all PSTN calls.
•The mobile user and Branch1 gateway are in the same Unified CM region and location. Location-based call admission control is applicable only for devices in different locations, and an intra-region call uses the G.711 voice codec. Thus, the call over the IP WAN to the Branch1 gateway uses the G.711 codec and is not tracked by Unified CM for purposes of call admission control. This behavior can result in over-subscription of the IP WAN bandwidth if all the remote links are low-speed links.
•The mobile user creates a conference by adding multiple Branch2 users to the existing call with the PSTN user in Denver. The mobile user uses the conferencing resource that is on the Branch1 gateway, therefore all conference streams flow over the IP WAN.
Device Mobility Feature
The Unified CM Device Mobility feature helps solve the problems mentioned above. This section briefly explains how the feature works. However, for a detailed explanation of this feature, refer to the product documentation available on http://www.cisco.com.
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 in Figure 21-2).
•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. (For example, all San Jose IP phones in Figure 21-2 are defined by physical location SJ_phyloc.)
Figure 21-2 illustrates the relationship between all these terms.
Figure 21-2 Relationship of Device Mobility Components
Unified CM assigns a device pool to an IP phone based on the device's IP subnet. The following steps, illustrated in Figure 21-3, describe the behavior:
1. The IP phone tries to register to Unified CM by sending its IP address in the Skinny Client Control Protocol (SCCP) or Session Initiation Protocol (SIP) registration message.
2. Unified CM derives the device's IP subnet and matches it with the subnet configured in the Device Mobility Info.
3. If the subnet matches, Unified CM provides the device with a new configuration based on the device pool configuration.
Figure 21-3 Phone Registration Process
Unified CM 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
The parameters under these settings will 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 call admission control and voice codec selection because the location and region configurations are used based on the device's roaming device pool.
For more details on various call admission control techniques, see the chapter on Call Admission Control.
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. This registration can affect the dialing behavior when the roaming phones are in SRST mode. For more information on dial plan design considerations, see the chapter on Dial Plan.
•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. This behavior can be confusing for users.
The flowchart in Figure 21-4 represents the operation of the Device Mobility feature.
Figure 21-4 Operation of the Device Mobility Feature
With Cisco Unified CM 7.x, operation of the Device Mobility feature no longer depends on the publisher server. If the publisher is not available, mobile users will register with the call processing (subscriber) server and will use a roaming device pool configuration.
The following guidelines apply to the Device Mobility feature:
•If the overlapping parameters listed in Figure 21-4 have the same configurations on the device as well as the device pool, then these parameters may be set to NONE on the device. These parameters must then be configured on the device pool. This practice can greatly reduce the amount of configuration because the devices do not have to be configured individually with all the parameters.
•Define one physical location per site. A site may have more than one device pool.
•Define sites with similar dialing patterns for PSTN or external/off-net access with the same Device Mobility Group. Sites with different dialing patterns for PSTN or external/off-net access may be defined with the same Device Mobility Group. However, the users must be educated properly about the various dialing patterns or access codes that are used.
•A "catch-all" Device Mobility Info with IP subnet 0.0.0.0 may be defined for all non-defined subnets, depending on the company policy. This Device Mobility Info may be used to assign a device pool that can restrict access or usage of the network resources. (For example, the device pool may be configured with a calling search space NONE that will block any calls from the device associated with this device pool while roaming.) However, by doing so, administrators must be aware of the fact that this will block all calls, even 911 or other emergency calls. The calling search space may be configured with partitions that will give access only to 911 or other emergency calls.
Dial Plan Design Considerations
When using the Device Mobility feature, the dialing behavior of the phone depends on the roaming (or home) location of a phone. As discussed earlier, the device mobility related settings within the device pool affect the call flow behavior because the calling search space dictates the reachability of destination patterns within Unified CM. This section discusses several dial plan approaches for Device Mobility.
For detailed explanations of various dial plan approaches, see the chapter on Dial Plan.
Device Mobility Considerations for Building Classes of Service
Typically, a mobile user should have the same calling privileges while he is roaming as he would have at his home location. The chapter on Dial Plan, discusses two approaches for building classes of service: Traditional Approach, and Line/Device Approach.
Figure 21-5 shows an example of building classes of service with the traditional approach when using Device Mobility in a cluster.
Figure 21-5 Traditional Approach to Building Classes of Service
The following guidelines apply to this approach:
•Use the calling search space on the phone device for path selection to route calls to internal or external destinations. Do not set the calling search space to NONE.
•Use the calling search space on the phone device to assign calling privileges.
•Create a device pool per site and assign a calling search space to it based on required class of service. In the example above, the international calling search space (Site1_INTL_CSS) is assigned to the device pool. Because the configuration on the device takes precedence over the device pool configuration in the home location, the users continue to use the calling search space on the phone device.
•Device Mobility and Extension Mobility may be enabled for an IP phone; however, mobile users must be aware that the line calling search space of the IP phones may be used to define classes of service. Follow the extension mobility considerations with the traditional approach discussed in the chapter on Dial Plan. When you enable both Extension Mobility and Device Mobility for a mobile user, Cisco recommends using the line/device approach.
•Assign the same class of service or calling privileges to all mobile users in the cluster. For the example in Figure 21-5, a mobile user at Site 1 has Site1_National_CSS as the home device calling search space, and a mobile user at Site 2 has Site1_INTL_CSS as the home device calling search space. If both users roam to Site 2, then both users are assigned the Site2_INTL_CSS calling search space by the Site2_INTL_DP device pool, thus giving the mobile user from Site 1 a different class of service. Even if multiple device pools are created, each with different calling search spaces assigned, it is not possible to assign a correct roaming device pool with the same class of service as the home location because device pools assignments are based on IP subnet and not based on the user's capabilities.
•If not all mobile users have the same classes of service, then consider defining each site as a Device Mobility Group. This method ensures that mobile users preserve their calling privileges when they are roaming. However, this method will route all external PSTN calls using the home gateway.
•Consider using the line/device approach if customer policies require mobile users with different classes of service and the requirements cannot be satisfied by defining each site as a Device Mobility Group.
Unified CM concatenates the line and device calling search spaces for a given IP phone. The following key concepts apply to the line/device approach:
•The device calling search space provides call routing information.
•The line calling search space provides class-of-service information.
With the Device Mobility feature, the device calling search space is dynamically associated to the phone based on its location. The key concept of the line/device remains the same when using Device Mobility. The line calling search space provides the class-of-service information, while the roaming or home device calling search space that is selected provides the call routing information.
Figure 21-6 shows an example of building classes of service with the line/device approach when using Device Mobility in a cluster.
Figure 21-6 Line/Device Approach to Building Classes of Service
Cisco recommends using the line/device approach for building classes of service. This model has significant advantages when using Device Mobility because it greatly reduces the number of device pools needed, as indicated by the following formula:
Total device pools = (Number of sites)
The following design considerations apply to this approach:
•The calling search space on the phone device can be configured to NONE. The calling search space configuration on the device pool will be assigned to the phone device. This method can greatly reduce the amount of configuration because you do not have to configure the phones individually with a device calling search space.
•There is no restriction on having the same classes of service or calling privileges for all mobile users. Because the classes of service are defined using the line calling search space, a mobile user keeps the same class of service while roaming.
•A mobile user may have both Device Mobility and Extension Mobility enabled in his profile.
Choosing a Dial Plan Model
As discussed in the chapter on Dial Plan, there are three main approaches for the dial plan model:
•Uniform on-net dialing
•Variable length on-net dialing with partitioned addressing
•Variable length on-net dialing with flat addressing
The following sections present various dial plan models combined with an approach for building classes of service.
Uniform On-Net Dialing Using the Line/Device Approach
Figure 21-7 shows a uniform on-net dial plan for Device Mobility.
Figure 21-7 Uniform On-Net Dial Plan for Device Mobility
This is the most basic dial plan model, and it has the following characteristics:
•Mobile users can use abbreviated dialing (four digits for the example in Figure 21-7) from any location.
•Abbreviated speed dialing for internal extensions continues to work on the mobile user's phone in roaming locations.
•Mobile users use a "roaming" calling search space when they are at a remote location. Cisco recommends having the same access codes for PSTN calls at all sites. If the PSTN access codes are not the same, users must learn the different access codes.
Variable Length On-Net Dialing with Partitioned Addressing Using the Line/Device Approach
Figure 21-8 shows a variable-length on-net dial plan with partitioned addressing for Device Mobility.
Figure 21-8 Variable-Length On-Net Dial Plan with Partitioned Addressing for Device Mobility
The following design considerations apply to the dial plan model in Figure 21-8:
•Calls might be routed to the wrong destination when mobile users use abbreviated dialing from a roaming location. For the example in Figure 21-8, assume that mobile user 1 in Site 1 with extension 1000 moves to Site 2. If user 1 dials 1001 with the intention of calling a person in Site 1, the call will be routed to extension 1001 in Site 2 instead. If this behavior is not desired, consider defining each site as a Device Mobility Group. However, users must be aware that, for any external PSTN calls, the mobile phone continues to use the home gateway and therefore consumes WAN bandwidth.
•Additional device calling search spaces may be configured for roaming users with access only to the PSTN and translation partitions. This configuration will need at least one additional device pool and calling search space per site. Thus, N sites will need N device pools and N calling search spaces. However, this configuration will not require defining each site as a Device Mobility Group.
•Abbreviated speed dials should not be used. Cisco recommends configuring speed dials in a universal way that enables the users to use speed dials at any location. For example, users may configure speed dials using E.164 numbers or using site codes and access codes.
•Overlapping extensions at multiple sites might cause problems when a roaming user registers to a remote SRST gateway. For the example in Figure 21-8, assume that mobile user A in Site 1 with extension 1000 moves to Site 2. Also assume that the WAN link at Site 2 goes down, causing the phones to register to an SRST gateway at Site 2. An incoming call on the SRST gateway for extension 1000 will be routed to actual extension 1000 in Site 2 as well as to the mobile user with extension 1000. Thus, calls might not be routed properly. This issue can be avoided by using unique extensions throughout the network.
Variable Length On-Net Dialing with Flat Addressing Using the Line/Device Approach
Figure 21-9 shows a variable-length on-net dial plan with flat addressing for Device Mobility.
Figure 21-9 Variable-Length On-Net Dial Plan with Flat Addressing for Device Mobility
The following design considerations apply to the dial plan model in Figure 21-9:
•Mobile users cannot use abbreviated dialing after roaming to another site because calls might be routed to the wrong destination. If this behavior is not desired, consider defining each site as a Device Mobility Group. However, users must be aware that, for any external PSTN calls, the mobile phone continues to use the home gateway and therefore consumes WAN bandwidth.
•Additional device calling search spaces may be configured for roaming users with access only to the PSTN and internal phones partitions. This configuration will need at least one additional device pool and calling search space per site. Thus, N sites will need N device pools and N calling search spaces. However, this configuration will not require defining each site as a Device Mobility Group.
•Mobile users registered with a remote SRST gateway have unique extensions. However, mobile users must be aware that no PSTN user can call them when they are registered to a remote SRST gateway.
Design Guidelines for Using a VPN
This section briefly explains the design guidelines for enabling the Device Mobility feature for IP software phones or Cisco IP Communicator. Most users may have software phones that connect to the Unified CM cluster using a virtual private network (VPN) connection over the internet.
For information on deploying a VPN, refer to the various VPN design guides available at
Figure 21-10 shows an example of an IP software phone user connected over a VPN to the Unified CM cluster.
Figure 21-10 VPN Connection to Cisco IP Communicator
VPN users must adhere to the following guidelines:
•Configure Device Mobility Info (DMI) with the IP subnets distributed or owned by the VPN concentrators.
•Associate the DMI with the same device pool that is used for devices co-located with the VPN concentrators. However, parameters such as calling privileges, network locale, and so forth, must be taken into consideration.
•Educate the users to use the nearest VPN concentrator.
These guidelines ensure that call admission control is correctly applied on the enterprise WAN.