Implementing Device Mobility in Cisco Unified Communications Manager

This chapter is from the book

Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) (Authorized Self-Study Guide)

Learn More Buy

This chapter is from the book

This chapter is from the book 

Implementing Cisco Unified Communications Manager, Part 2 (CIPT2) (Authorized Self-Study Guide)

Learn More Buy

Device Mobility Operation

As discussed earlier, each phone is configured with a device pool, similar to previous versions of Cisco CallManager (CCM). This device pool is the phone's home device pool.

IP subnets are associated with device pools by configuring DMIs.

The following occurs when a Device Mobility-enabled phone registers with CUCM with an IP address that matches an IP subnet configured in a DMI:

• The current device pool is chosen as follows:
  • If the DMI is associated with the phone's home device pool, the phone is considered to be in its home location. Therefore, Device Mobility does not reconfigure the phone.
  • If the DMI is associated with one or more device pools other than the phone's home device pool, one of the associated device pools is chosen based on a round-robin load-sharing algorithm.
• If the current device pool is different from the home device pool, the following checks are performed:
  • If the physical locations are not different, the phone's configuration is not modified.
  • If the physical locations are different, the roaming-sensitive parameters of the current roaming device pool are applied.
  • If the Device Mobility Groups are the same, in addition to different physical locations, the Device Mobility-related settings are also applied, along with the roaming-sensitive parameters.

In summary, the roaming-sensitive parameters are applied when the physical location of the current device pool is different from the physical location of the home device pool. The Device Mobility-related settings are also applied when the physical locations are different and the Device Mobility Groups are the same. This occurs when roaming between physical locations within the same Device Mobility Group.

As a consequence, physical locations and Device Mobility Groups should be used as follows:

• Physical locations: Configure physical locations in such a way that codec choice and CAC truly reflect the device's current location. Also, local SRST references and local media resources at the roaming site should be used instead of those located at the currently remote home network. Depending on the network structure, subnetting, and allocation of services, you may define physical locations based on a city, enterprise campus, or building.
• Device Mobility Groups: A Device Mobility Group should define a group of sites with similar dialing patterns or dialing behavior. Device Mobility Groups represent the highest-level geographic entities in your network. Depending on the network size and scope, your Device Mobility Groups could represent countries, regions, states or provinces, cities, or other geographic entities. Device Mobility-related settings that are applied only when roaming within the same Device Mobility Group impact call routing. Therefore, different Device Mobility Groups should be set up whenever a roaming user should not be forced to adapt his dialing behavior. In this case, when roaming between different Device Mobility Groups, the phone Device Mobility-related settings that impact call routing are not modified.

Device Mobility Operation Flowchart

Figure 11-4 illustrates the flow of Device Mobility operation.

Figure 11-4 Device Mobility Operation Flowchart

The process of a phone registration with Device Mobility is as follows:

1. A phone device attempts to register with CUCM. Phones that do not register with CUCM cannot be part of the CUCM cluster and therefore do not have any Device Mobility configuration. If the phone successfully registers to a CUCM server, continue.
2. CUCM checks whether Device Mobility is enabled for the device. If it isn't, the default behavior applies; go to Step 10. Otherwise, continue.
3. CUCM checks whether the IP address of the IP Phone is found in one of the Device Mobility Groups (DMG). If it is not found, the default behavior applies; go to Step 10. Otherwise, continue.
4. If the home device pool (DP) is associated with the DMI in which the phone's IP address was found, the home device pool is chosen. If the home device pool is not associated with the DMI in which the phone's IP address was found, the device pool is chosen based on a load-sharing algorithm. The load-sharing algorithm applies if more than one device pool is associated with the DMI.
5. If the chosen device pool is the home device pool, the default behavior applies; go to Step 10. Otherwise, continue.
6. If the physical locations (PL) of the chosen device pool and the home device pool are the same, the default behavior applies; go to Step 10. Otherwise, continue.
7. The roaming-sensitive settings of the chosen device pool of the roaming device pool are used to update the phone's configuration.

   NOTE

   In this case, overlapping settings that exist at the phone as well as at the device pool (namely, Media Resource Group List, Location, and Network Locale of the roaming device pool) have priority over the corresponding settings at the phone. This behavior is different from the default behavior of Step 10.

8. If the Device Mobility Groups (DMG) of the chosen device pool and the home device pool are different, the device uses only the roaming-sensitive settings from the "roaming" DP. If they are not different, the device uses the roaming settings and the Device Mobility (DM) settings from the "roaming" DP.

   NOTE

   In this case, all settings are overlapping settings that are Device Mobility-related settings that exist at the phone as well as at the device pool. Therefore, the parameters of the roaming device pool have priority over the corresponding settings at the phone. This behavior is different from the default behavior in Step 10.

9. Next, where the phone configuration has been updated with either the roaming-sensitive settings only, or with the roaming-sensitive settings and the Device Mobility-related settings, the phone is reset for the updated configuration to be applied to the phone.

   CAUTION

   This is the end of the process. Step 10 applies only in the conditions outlined in the previous steps.

10. The default behavior is the settings of the home device pool (DP), which is the device pool configured on the phone. Some configuration parameters of the device pool can also be set individually at the phone. These overlapping phone configuration parameters are the Media Resource Group List, Location, Network Locale, Device Mobility Calling Search Space (which is just called Calling Search Space at the phone), AAR Calling Search Space, and AAR Group. If these are configured at the phone, implying they are not set to [None], the phone configuration settings have priority over the corresponding setting at the device pool.

Device Mobility Considerations

Roaming-sensitive settings ensure that the roaming device uses local media resources and SRST references. In addition, they ensure the correct use of codecs and CAC between sites. Typically, this is always desired when a device roams between different sites. It is not required when the device moves only between IP subnets within the same site. Therefore, the recommendation is to assign all device pools that are associated with IP subnets (DMI) that are used at the same site to the same physical location. This results in phone configuration changes only when the phone roams between sites (physical locations) and not in a situation where a phone is only moved between different networks of the same site.

Device Mobility-related settings impact call routing. By applying the device CSS, AAR group, and AAR, CSS calls are routed differently. The settings at the roaming device pool determine which gateway will be used for PSTN access and AAR PSTN calls based on the device CSS and AAR CSS. They also determine how the number to be used for AAR calls is composed based on the AAR group.

Such changes can result in different dialing behavior. For instance, when you roam between different countries, the PSTN access code and PSTN numbering plans might be different. For example, to dial the Austrian destination +43 699 18900009, users in Germany dial 0.0043 699 18900009, whereas users in the U.S. have to dial 9.01143 699 18900009.

German users who roam with their softphones to the U.S. might be confused when they have to use U.S. dialing rules access code 9 instead of 0 and 011 instead of 00 for international numbers. To prevent this confusion, suppress the application of Device Mobility-related settings. You do this by assigning device pools that are to be used at sites with different dialing rules to different Device Mobility Groups and different physical locations. Now, when a user roams with a device from Germany to the U.S., all the roaming-sensitive settings are applied, but the Device Mobility-related settings are not applied. The phone now uses the PSTN gateway and dial rules of its home location even though the user moved to another site. The user does not have to adapt to the dial rules of the local site to which the phone was moved.

Review of Line and Device CSSs

An IP Phone can be configured with a line CSS and a device CSS. If both exist, the partitions configured to the line CSS are considered before the partitions of the device CSS when routing a call. (This is another example of "more specific overrides more general.")

These two CSSs allow the use of the line/device approach for implementing calling privileges and the choice of a local gateway for PSTN calls. With the line/device approach, all possible PSTN route patterns exist once per location, which is configured with a site-specific partition. This partition is included in the device CSS of the phones and therefore enables the use of a local gateway for PSTN calls. To implement class of service (CoS), PSTN route patterns that should not be available to all users (for example, international calls, long-distance calls, or all toll calls) are configured as blocked route patterns and are assigned to separate partitions. The line CSS of a phone now includes the partitions of the route patterns that should be blocked for this phone. Because the line CSS has priority over the device CSS, the blocked pattern takes precedence over the routed pattern that is found in a partition listed at the device CSS.

Device Mobility and CSSs

Device Mobility never modifies the line CSS of a phone. It does, however, change the device CSS and AAR CSS of a phone when the phone is roaming between different physical locations within the same Device Mobility Group.

The line CSS implements CoS configuration by permitting internal destinations such as phone directory numbers, Call Park, and Meet-Me conferences but blocking PSTN destinations. Because the line CSS is not changed by Device Mobility, CoS settings of the device are kept when the device is roaming.

The device CSS is modified when roaming within the same Device Mobility Group. In this case, the device CSS that is used at the home location is replaced by a device CSS that is applicable to the roaming location. This device CSS refers to the local gateway of the roaming site instead of the gateway that is used at the home location.

If the traditional approach of using only one CSS combining class of service and gateway choice is used, the device CSS must be used, because Device Mobility cannot modify the line CSS, and the line CSS has priority over the device CSS. These settings can be modified by Device Mobility.

The AAR CSS can be configured only at the device level. Therefore, it is always correctly replaced when roaming between physical locations within the same Device Mobility Group.

Examples of Different Call-Routing Paths Based on Device Mobility Groups and TEHO

Table 11-3 shows how calls are routed in different Device Mobility scenarios.

Table 11-3. Examples of Different Call-Routing Paths Based on Device Mobility Groups and TEHO

Calls are routed differently depending on the configuration of Device Mobility Groups. Call-routing factors depend on whether Device Mobility-related settings are applied, the dialed destination, and the use of tail-end hop-off (TEHO). In some scenarios, calls might take suboptimal paths.

For example, assume that a user from London roams to the U.S. office with Cisco IP Communicator. For simplicity, assume that there is only one U.S. office.

For the following three scenarios, the home device pool and the roaming device pool are assigned to the same Device Mobility Group, which means that Device Mobility applies Device Mobility-related settings. As a result, PSTN calls placed from the roaming device are treated like PSTN calls of standard U.S. phones.

• If a call to a PSTN destination close to the home location such as a U.K. PSTN number is placed and TEHO is not configured, the call uses the local U.S. PSTN gateway to place an international PSTN call. From a toll perspective, this is a suboptimal solution, because the IP WAN is not used as much as it could be when implementing TEHO. This factor applies not only to the roaming user, but also to U.S. users who place calls to PSTN destinations in Great Britain.
• If the same call to a U.K. PSTN number is placed and TEHO is configured, the call uses the IP WAN to the London site and breaks out to the PSTN at the London gateway with a local call. This solution is the optimal one from a toll perspective.
• If a call to a U.S. destination number is placed, the U.S. gateway is used for a local or national call. This event is optimal from a toll perspective.

For the next three scenarios, the home device pool and the roaming device pool are assigned to different Device Mobility Groups. This means that the Device Mobility-related settings are not applied. Therefore, calls placed from the roaming device are routed the same way as they are when the device is in its home location:

• If a call from the U.S. to a U.K. PSTN destination is placed, the call uses the IP WAN to the London site and breaks out to the PSTN at the London gateway with a local or national call. This solution is the optimal one from a toll perspective.
• If a call from the U.S. to a PSTN destination close to the roaming location such as a U.S. PSTN number is placed and TEHO is not configured, the call uses the IP WAN from the U.S. office to the London site and breaks out to the PSTN at the London gateway to place an international call back to the U.S. From a toll perspective, this is the worst possible solution, because the call first goes from the U.S. to London over the IP WAN, wasting bandwidth, and then goes back from London to the U.S. via a costly international call.
• If a call from the U.S. to a PSTN destination close to the roaming location such as a U.S. PSTN number is placed and TEHO is configured, the U.S. gateway is used for a local or national call. This event is optimal from a toll perspective.

In summary, when allowing the Device Mobility-related settings to be applied by using the same Device Mobility Group, calls to the home location use a local PSTN gateway to place a long-distance or international call when not implementing TEHO. All other calls are optimal.

When the Device Mobility-related settings are not applied by using different Device Mobility Groups and by not using TEHO, calls to the roaming location first use the IP WAN to go from the roaming location to the home location and then use the home gateway to place a long-distance or international call back to the roaming location. All other calls are optimal.