Device Mobility

Table Of Contents

Device Mobility

What's New in This Chapter

Need for Device Mobility

Device Mobility Architecture

Roaming Sensitive Settings

Device Mobility Related Settings

Device Mobility Group

Device Mobility Operation

High Availability for Device Mobility

Capacity Planning for Device Mobility

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 Considerations for Using a VPN

Design Considerations for Device Mobility

Device Mobility

---

Revised: April 2, 2010; OL-21733-02

 

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.

The features and functionality discussed in this chapter apply to all Cisco Unified Communications call processing deployment models unless otherwise noted.

This chapter begins with a discussion surrounding the main purpose for the Device Mobility feature, followed by an in-depth discussion of the Device Mobility feature itself. This discussion covers the various components and configuration constructs of the Device Mobility feature. This is followed by discussions pertaining to concerns regarding high availability and scalability of the Device Mobility feature. Next the chapter presents an in-depth discussion of the impact of the Device Mobility feature on the enterprise dial plan, including the implication for various dial plan models. The chapter concludes with a summarized list of design considerations and guidelines for deploying Device Mobility.

This chapter contains the following sections:

•Need for Device Mobility

•Device Mobility Architecture

•High Availability for Device Mobility

•Capacity Planning for Device Mobility

•Dial Plan Design Considerations

•Design Considerations for Device Mobility

What's New in This Chapter

Table 20-1 lists the topics that are new in this chapter or that have changed significantly from previous releases of this document.

 

Table 20-1 New or Changed Information Since the Previous Release of This Document 

New or Revised Topic	Described in	Revision Date
Summarized list of design guidelines for Device Mobility.	Design Considerations for Device Mobility	April 2, 2010
Added information surrounding capacity planning for Device Mobility and the fact that there are no enforced limits in terms of configuration constructs (device pools, device mobility groups, and so forth).	Capacity Planning for Device Mobility	April 2, 2010
Added information surrounding high availability implications for the Device Mobility feature, which is fully redundant during a Unified CM cluster node failure (publisher or subscriber).	High Availability for Device Mobility	April 2, 2010

Need for Device Mobility

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

Figure 20-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 20-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 Architecture

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 20-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 20-2 are defined by physical location SJ_phyloc.)

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

Figure 20-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 20-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 20-3 Phone Registration Process

Unified CM uses a 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 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 11-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 example, if a user moves with their phone to a new location that loses connectivity to Unified CM, then based on the roaming sensitive Device Mobility settings, a new SRST reference is configured for the moved phone and the moved phone will now be under control of the local roaming location SRST router. When this occurs, not only would the user's phone be unreachable from the PSTN or other sites because the device's DID will not have changed and will still be anchored at their home location, but in addition reachabililty from devices within the local failed site might be difficult without the use of abbreviated dialing as implemented within SRST.

As an example, assume that a user moves a phone from their home location in San Jose, which has a directory number of 51234 and an associated DID of 408 555 1234 to a remote location in New York, and that the link between the New York site and San Jose fails shortly after the user roams to the New York location. In this scenario the phones in the New York site will all fail-over to the SRST router in that site. The roaming/moved phone will also register to the New York SRST router because its SRST reference was updated based on the device mobility roaming sensitive settings. In this scenario, the local New York devices will register to the SRST router with five-digit extensions just as they do to Unified CM, and as a result the roaming phone still has a directory number of 51234. To reach the roaming phone from all other sites and from the PSTN, the number 408 555 1234 will be routed to the San Jose PSTN gateway to which this particular DID is anchored. Because the New York site is disconnected from the San Jose site, any such calls will be routed to the users' voicemail boxes since they will be unreachable at their desk phones. Likewise, calls internally within the local failed site will have to be dialed using five-digit abbreviated dialing or based on the configured digit prefixing as defined by the dialplan-pattern and extension-length commands within the SRST router. In either case, local callers will have to be understand the required dialing behavior for reaching the local roaming device by abbreviated dialing. In some cases this may be simply five-digit dialing or it may be that users have to dial a special digit prefix to reach the local roaming phone. The same logic applies to outbound dialing from the moved or roaming phone in New York because its dialing behavior might have to be altered in order to reach local extensions using abbreviated dialing. Outbound dialing to the PSTN from the local roaming device should remain the same, however.

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

•Calling Party Transformation CSS

•Called Party Transformation CSS

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

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. As illustrated in Figure 20-2, the San Jose and RTP sites' Device Mobility Info, Device Pools, and Physical Locations are different; however, all of these have been assigned to the same Device Mobility Group US_dmg because the required dialing patterns and PSTN access codes are the same between the two locations. On the other hand, the London site is assigned to a separate Device Mobility Group EUR_dmg due to the fact that the required dialing patterns and PSTN access codes there are different than those of the US sites. 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, one site requires users to dial 9 to get an outside line while another site requires users to dial 8 to get an outside line), 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, therefore Cisco recommends against assigning sites with different dialing patterns to the same Device Mobility Group.

Device Mobility Operation

The flowchart in Figure 20-4 represents the operation of the Device Mobility feature.

Figure 20-4 Operation of the Device Mobility Feature

The following guidelines apply to the Device Mobility feature:

•If the overlapping parameters listed in Figure 20-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.

•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.

High Availability for Device Mobility

The Device Mobility feature is natively integrated with Unified CM, therefore the failure of a cluster node should have no impact on the functionality of Device Mobility. Device pool, Device Mobility Info, Device Mobility Group, and all other configurations surrounding Device Mobility are preserved if there is a failure of the publisher node or a call processing (subscriber) node. Additionally, if there is a call processing node failure, affected phones will fail-over to their secondary call processing node or SRST reference router as usual based on the Unified CM Group construct.

Capacity Planning for Device Mobility

There are no specific or enforced capacity limits surrounding the Device Mobility feature and the various configuration constructs (device pools, device mobility groups, and so forth) of the feature. However, as with many of the features and functions provided by Unified CM, configuration of these constructs does have sizing implications for the overall system. To ensure proper sizing of your system, use the Cisco Unified Communications Sizing Tool (Unified CST) to determine the system capacity based on everything from number of device pools and busy hour call attempt (BHCA) rates to number of phones and CTI applications deployed. While the sizing tool does not specifically address Device Mobility sizing, the overall sizing guidance provided by the tool will ensure that this feature as well as the overall system is deployed within supported capacity limits. Unified CST is available to Cisco employees and partners (with appropriate login account required) at http://tools.cisco.com/cucst.

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

Traditional Approach

With the traditional approach, both path selection and class of service are determined by the device-level calling search space. With the line/device approach, path selection is determined by the device-level calling search space and class of service is determined by the line-level calling search space. For all deployments, the line/device approach is recommended for building classes of service. In particular with deployments utilizing Device Mobility, it is important to use the line/device approach because this approach ensures that all calls made by a mobile device will use the roaming site or local gateway rather than the home site gateway. While the traditional approach can certainly be used, this chapter covers only the recommended line/device approach. For a general discussion of the traditional approach, see the chapter on Dial Plan, page 9-1.

Line/Device Approach

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

Figure 20-5 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 9-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 20-6 shows a uniform on-net dial plan for Device Mobility.

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

Figure 20-7 Variable-Length On-Net Dial Plan with Partitioned Addressing for Device Mobility

The following design considerations apply to the dial plan model in Figure 20-7:

•Calls might be routed to the wrong destination when mobile users use abbreviated dialing from a roaming location. For the example in Figure 20-7, 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. As shown in Figure 20-4, when devices roam, if the Device Mobility Group of the "home" device pool is different from the Device Mobility Group defined by the "roaming" device pool of the Device Mobility Info, then only the roaming sensitive settings from the "roaming" device pool are applied. This means that the Device Mobility calling search space that is not a roaming sensitive setting will not be used, and instead the "home" calling search space (as defined at the device level setting or the device pool setting of the phone) would be used when the roaming phone makes a call. This means that for the example shown in Figure 20-7, when user 1 dials extension 1001 while in Site 2, the call will be routed using the "home" site calling search space, resulting in the call being routed to extension 1001 in Site 1. However, in this call scenario WAN bandwidth would be consumed. Further, for any external PSTN calls dialed by user 1 in this example, the roaming phone would also use the home gateway and also consume WAN bandwidth because the "home" site calling search space is used.

•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 20-7, 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 20-8 shows a variable-length on-net dial plan with flat addressing for Device Mobility.

Figure 20-8 Variable-Length On-Net Dial Plan with Flat Addressing for Device Mobility

The following design considerations apply to the dial plan model in Figure 20-8:

•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 Considerations 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. Many users may have software-based phones or hardware phones running VPN client software 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 under the Security in WAN subsection of the Design Zone for WAN/MAN, available at:

http://www.cisco.com/en/US/solutions/ns340/ns414/ns742/ns817/landing_wan_security.html

Figure 20-9 shows an example of an IP software phone user connected over a VPN to the Unified CM cluster.

Figure 20-9 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.

Design Considerations for Device Mobility

Observe the following design recommendations when deploying Device Mobility:

•In situations in which sites with different dialing patterns (for example, sites having different PSTN access codes) are configured in the same Device Mobility Group, roaming users might have to dial numbers differently based on the location they are in, which can be confusing. For this reason, Cisco recommends assigning sites with similar dialing patterns (for example, sites having the same PSTN access codes) to the same Device Mobility Group. Doing so ensures that roaming users can dial numbers the same way at all sites within the Device Mobility Group.

•The Device Mobility settings from the "roaming" device pool are applied only when roaming within the same Device Mobility Group; therefore, avoid roaming between different Device Mobility Groups because the resulting call routing behavior will cause originated calls from the moved phone to be routed using the "home" or device-configured calling search space. This can lead to unnecessary consumption of WAN bandwidth because the call might be routed through a different site's gateway rather than the local "roaming" gateway.

•Define only one physical location per site. This ensures that device mobility is engaged only in scenarios in which a user is roaming between sites. For roaming within the same site, the concerns that mandate Device Mobility (for example, WAN bandwidth consumption, codec selection, and call admission control) are not present because low-speed links typically are not deployed within a single site.

•In failover scenarios, "roaming" phones will utilize the SRST reference/gateway as dictated by the "roaming" device pool's roaming sensitive settings. Therefore, in these situations the "roaming" phone is unreachable from the PSTN due to the fact that the DID for this phone is anchored in another location's PSTN gateway. Furthermore, for outbound calls from the "roaming" phone, dialing behavior might have to be altered for things such as PSTN access codes, and speed dials configured on the phone might not be usable.

•While the general recommendation is to always use the line/device approach to the dial plan, it is especially important when deploying Device Mobility because it allows different classes of service or calling privileges for each mobile user. With the line/device approach, the classes of service are defined using the line calling search space of the device, which stays the same when roaming and allows a mobile user to keep the same class of service while roaming.

•If your system requires the ability to use abbreviated dialing or to use speed dials that rely on abbreviated dialing, Cisco recommends using the Uniform On-net dial plan model because it will ensure that abbreviated dialing (direct or through speed dials) continues to work even when the mobile user's phone is in a roaming location. Abbreviated dialing is still possible with this dial plan model because all extensions or directory numbers are unique across all sites, and therefore abbreviated dialing can be used universally due to the fact that there are no overlapping extensions.

•If your system uses a Variable Length On-net dial plan model (with either partitioned addressing or flat addressing), Cisco recommends configuring speed dials in a universal way so that a single unique extension can be reached when invoke. By configuring speed dials using full E.164 numbers or using site or access codes, you can enable roaming users to use the same speed dials at any location.

•If Device Mobility is enabled for users who on occasion access the enterprise network through a VPN connection, Device Mobility Info (DMI) for VPN attached phones should contain IP subnets distributed or owned by the VPN concentrators to ensure that "roaming" to a VPN location results in appropriate dynamic Device Mobility configuration changes. Be sure to associate the DMI with the same device pool that is used for any devices co-located with the VPN concentrators.