Table Of Contents

Device Mobility

Need for Device Mobility

Device Mobility Feature

Dial Plan Design Considerations

Device Mobility Considerations for Building Classes of Service

Traditional Approach

Line/Device Approach

Choosing a Dial Plan Model

Uniform On-Net Dialing Using the Line/Device Approach

Variable Length On-Net Dialing with Partitioned Addressing Using the Line/Device Approach

Variable Length On-Net Dialing with Flat Addressing Using the Line/Device Approach

Design Guidelines for Using a VPN

Device Mobility

---

In Cisco Unified CallManager, 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. Cisco Unified CallManager 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. Cisco Unified CallManager 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 Call Manager Release 4.2 introduces a new feature called Device Mobility, which enables Cisco Unified CallManager to determine if the IP phone is at its home location or at a roaming location. Cisco Unified CallManager 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. Cisco Unified CallManager 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 Cisco Unified CallManager cluster.

Need for Device Mobility

This section explains the need for device mobility when there are many mobile users in a Cisco Unified CallManager cluster.

Figure 22-1 illustrates a hypothetical network with a Cisco Unified CallManager cluster using Release 4.1 or earlier, 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 22-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:

•Cisco Unified CallManager 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 Cisco Unified CallManager 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 Cisco Unified CallManager 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

Cisco Unified CallManager 4.2 introduces the Device Mobility feature, which 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 new device mobility terms introduced in Cisco Unified CallManager 4.2 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 22-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 22-2 are defined by physical location SJ_phyloc.)

Figure 22-2 illustrates the relationship between all these terms.

Figure 22-2 Relationship of Device Mobility Components

Cisco Unified CallManager 4.2 assigns a device pool to an IP phone based on the device's IP subnet. The following steps, illustrated in Figure 22-3, describe the behavior:

1. The IP phone tries to register to Cisco Unified CallManager by sending its IP address in the Skinny Client Control Protocol (SCCP) registration message.

2. Cisco Unified CallManager derives the device's IP subnet and matches it with the subnet configured in the Device Mobility Info.

3. If the subnet matches, Cisco Unified CallManager provides the device with a new configuration based on the device pool configuration.

Figure 22-3 Phone Registration Process

Cisco Unified CallManager 4.2 adds new parameters to 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:

–Date/time Group

–Region

–Media Resource Group List

–Location

–Network Locale

–SRST Reference

–Physical Location

–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, page 9-1.

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 Device Mobility, page 10-26.

•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

–AAR Group

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 22-4 represents the operation of the Device Mobility feature.

Figure 22-4 Operation of the Device Mobility Feature

The Cisco Unified CallManager publisher server must be available for Device Mobility feature operation. If the publisher is not available, mobile users will register with the call-processing server when they roam to other sites and will continue to use their home device pool configurations. When the publisher becomes available after the user has moved from its home location to a remote location, the phone will continue to use its home device pool configurations until the phone is reset. After the reset, the phone will update its configurations with roaming device pool settings.

The following guidelines apply to the Device Mobility feature:

•If the overlapping parameters listed in Figure 22-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 Cisco Unified CallManager. This section discusses several dial plan approaches for Device Mobility.

For detailed explanations of various dial plan approaches, see the chapter on Dial Plan, page 10-1.

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, page 10-1, discusses two approaches for building classes of service: Traditional Approach, and Line/Device Approach.

Traditional Approach

Figure 22-5 shows an example of building classes of service with the traditional approach when using Device Mobility in a cluster.

Figure 22-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, page 10-1. 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 22-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.

Line/Device Approach

Cisco Unified CallManager 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 22-6 shows an example of building classes of service with the line/device approach when using Device Mobility in a cluster.

Figure 22-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, page 10-1, 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 22-7 shows a uniform on-net dial plan for Device Mobility.

Figure 22-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 22-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 22-8 shows a variable-length on-net dial plan with partitioned addressing for Device Mobility.

Figure 22-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 22-8:

•Calls might be routed to the wrong destination when mobile users use abbreviated dialing from a roaming location. For the example in Figure 22-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 22-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 22-9 shows a variable-length on-net dial plan with flat addressing for Device Mobility.

Figure 22-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 22-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 Cisco Unified CallManager 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

http://www.cisco.com/go/srnd

Figure 22-10 shows an example of an IP software phone user connected over a VPN to the Cisco Unified CallManager cluster.

Figure 22-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.