Contents

1   Introduction

This section is an introduction to this document. It contains information about the prerequisites, purpose, scope, and target group for the document. This section also contains explanations of typographic conventions used in this document.

1.1   Purpose and Scope

This document gives, from an Ericsson™ Dynamic Activation (EDA) perspective, a brief introduction to the different changeover provisioning procedures supported in the Data Layered Architecture (DLA).

1.2   Target Group

The target groups for this document are as follows:

• Network Administrator
• System Administrator
• Application Administrator
• Network Supervision Administrator
• Application Designer
• Marketing
• Other

For information about the different target groups, see Library Overview, Reference [1]

1.3   Typographic Conventions

Typographic conventions are described in Library Overview, Reference [1].

2   Overview

The Identity changeover functionality includes:

• IMSI Changeover - It is in many cases related to the operators SIM Card management. This means that there is a relation between what happens if the SIM Card is replaced for a subscriber and the action that is performed in the Core Network. In this case, the Core network is the UDC solution where data is stored in the CUDB. IMSI changeover is a complex procedure. It could be performed in several different sequences as well as in different modes.

  When introducing EPS service in the IMSI changeover procedure, it is also authenticated on the subscribers USIM card. IMSI changeover for subscriber with IMS service is only supported for VoLTE IMS subscriber. While involving IMS service in IMSI changeover, both private user identity (IMPI) and public user identity (IMPU) derived from IMSI is required regardless of USIM or ISIM card being used. AUC and AVG are the Authentication service supported for IMSI changeover.

• MSISDN Changeover - It changes the MSISDN of a mobile user.

2.1   Data Model

The IMSI changeover feature span over several applications, AUC, AVG, HLR, EPS, IMS, and possibly more in the future. The IMSI changeover information data is now added to a common part (serv=Identities) of the UDC data model. HLR application still has a copy of the Identity changeover data stored under CSPS service.

The MSISDN changeover is supported for the AUC, HLR, and EPS applications. There is no specific data added to the data model in CUDB for the MSISDN changeover procedure.

2.2   Validation

For changeover procedures, the operations are validated against the HLR-FE and the HSS-FE validator, hosted in Dynamic Activation. This depends on which services are active for the subscriber. See the overview of an IMSI changeover procedure in Section 3 and an MSISDN changeover procedure in Section 4.

If the HLR service is active, validation is done towards HLR-FE for all changeover operations except for Get IMSI Changeover operation.

If the EPS service is active, validation is done towards the HSS-FE validator plug-in for create and set of a forced or delayed IMSI changeover.

If the IMS service is active, validation is done towards the HSS-FE validator plug-in for create of a forced IMSI changeover.

If the AVG service is active, validation is done towards the HSS-FE validator plug-in for creating a forced IMSI changeover.

For more information on EPS validation, see Function Specification Layered LTE EPC, Reference [6].

2.3   Notification

After a successful execution of a changeover, notifications are sent to HLR-FE and HSS-FE depending on the service involved. See the overview of an IMSI changeover procedure in Section 3 and an MSISDN changeover procedure in Section 4.

If the HLR service is active, notifications are sent to the HLR-FE when so indicated by HLR-FE validation response for all changeover operations.

If the EPS service is active, notifications are sent to the HSS-FE after a create/set operation of a forced IMSI changeover or an MSISDN changeover.

If the IMS service is active, notifications are sent to the HSS-FE after a create/set operation of a forced IMSI changeover.

For more information on HSS-FE notifications, see Function Specification Layered LTE EPC, Reference [6] and Layered IMS Provisioning over CAI3G, Reference [7].

3   IMSI Changeover

IMSI Changeover provides the Mobile operators and Mobile Subscribers (MS) means to replace SIM card in a flexible way. For instance when the card is lost, malfunctioning or periodically changed to prevent fraud or malfunctioning.

Dynamic Activation supports release of old IMSI, so that it becomes ready to be reused after IMSI changeover. A delayed IMSI changeover can be reversed in case the lost SIM-card has been found.

Because of the legacy of the HLR and its flexibility, there are many different scenarios deployed for IMSI changeover handling. Operators use it in different ways. There are two types of HLR subscriptions in CUDB, normal subscriptions and M2M subscriptions. The IMSI changeover functionality applies for both.

The available functions are:

• Immediate or delayed IMSI changeover execution. (IMS is only supported by immediate IMSI changeover procedure.)
• Secure that IMSI changeover is performed only on subscribers (Multi Service Consumers) that has AUC, EPS, IMS, or HLR services.
• Removal of MSISDN and old IMSI relation in CUDB.

IMSI changeover operations are supported through the provisioning interfaces, see Section 3.1.

Figure 1 and the following step list give a high-level description of the IMSI changeover procedure.

1. Dynamic Activation receives the IMSI changeover command.
2. The command is validated in HSS Validator.
3. Dynamic Activation sends an MML command to validate the IMSI changeover command in HLR FE.
4. Dynamic Activation updates all applicable entries in CUDB.
5. Dynamic Activation notifies HLR and HSS FE about the change, if necessary.

3.1   Interfaces

For IMSI Changeover Dynamic Activation supports operations over CAI3G, MML, CAI, and CLI.

The recommended interface is the CAI3G interface described in Layered Identity Changeover Provisioning over CAI3G, Reference [2]. This interface is recommended because the operations are developed to be future-proof when support for extra applications is added to this service. Support for IMSI changeover on an M2M subscription is supported on this interface.

The CAI3G interface supports the following operations:

• Create IMSI Changeover
• Set IMSI Changeover
• Get IMSI Changeover
• Delete IMSI Changeover
• Create IMSI Changeover Removal

The CLI interface supports an operation that prints all the ongoing IMSI changeover procedures. For more information, see Layered HLR AUC Massive Operations over CLI, Reference [8].

The following interfaces are also available in Dynamic Activation for IMSI changeover and are provided for backwards compatibility. They are phased out in a later release of the product:

• MML

  For more information, see Layered HLR AUC Provisioning over MML, Reference [3].

• CAI3G corresponding to the HLR components

  To allow EPS service to be supported, using this interface, the optional attribute of deleteOldRef in Create and Set operations must be omitted or set to false.

  For more information, see CAI3G Interface Specification for HLR Components, Reference [4].

• CAI corresponding to the HLR components

  When AUC, HLR and EPS services are active for the subscriber, this interface only supports delayed IMSI changeover. This is valid in both Create and Set operations. For a subscriber with AUC and HLR services both forced and delayed IMSI changeover is possible.

  For more information about available commands, see CAI Interface Specification for HLR Components, Reference [5].

3.2   Provisioning Handling

IMSI changeover provisioning orders are allowed in the following scenarios:

• HLR subscription (+AUC)
• IMS subscription (+AUC)
• IMS subscription (+AVG)
• EPS subscription (+AVG)
• HLR subscription + EPS subscription (+AUC)
• HLR subscription + IMS subscription (+AUC)
• EPS subscription + IMS subscription (+AUC)
• EPS subscription + IMS subscription (+AVG)
• HLR subscription + IMS subscription (+AUC+AVG)
• HLR subscription + EPS subscription (+AUC+AVG)
• HLR subscription + EPS subscription + IMS subscription (+AUC)
• HLR subscription + EPS subscription + IMS subscription (+AUC+AVG)

During an IMSI changeover procedure, there are several different states that can occur. The normal state is when there is no changeover ongoing. During the changeover, the state can be executed, pending, or forced.

The numbers in Figure 2 indicates the transitions that can occur when performing an IMSI changeover:

1. The Customer Administration System (CAS) initiates a Create IMSI Changeover request with an expiry date, see Section 3.3.1.
2. The CAS initiates Create IMSI Changeover request without an expiry date, see Section 3.3.1.
3. The CAS initiates a Delete IMSI Changeover request, see Section 3.3.3.
4. The subscriber uses the new SIM card before the expiry date has been reached.
5. This transition can happen in two situations:
   1. The subscriber uses either the old or new SIM card when the expiry date has been reached.
   2. The CAS initiates a Set IMSI Changeover request without an expiry date, see Section 3.3.2.
6. The CAS initiates a Create IMSI Changeover Removal request, see Section 3.3.5.

3.3   Functions

This section describes possible use cases for IMSI changeover.

Note:  

Simultaneously Create and Delete the same subscriber result in inconsistent data in the CUDB. Reserve sufficient time duration, with consideration to retry behavior, between the two operations.

3.3.1   Create IMSI Changeover

The goal with this operation is to allow the existing services (HLR, IMS, and EPS) for the subscriber to be switched over to the new IMSI in an immediate or delayed IMSI changeover procedure.

In delayed IMSI changeover procedure, the mobile subscriber has the possibility to use the old Subscriber Identity Module (SIM) or Universal Subscriber Identity Module (USIM) card until the predefined date is reached or until the new card is used for first time. If the mobile subscriber does not use the new card before the expiry date is reached, the procedure is forced to be executed.

After execution of the procedure, in both cases of immediate and delayed IMSI changeover procedure, all attempts to make calls with the old IMSI will be rejected.

Note:  

• If the subscriber has IMS, both IMPI and IMPU must be derived from IMSI.
• If the subscriber has service IMS or AVG , then only immediate IMSI changeover is allowed.
• It is not allowed to create services other than EPS service for a subscriber when the subscriber is involved in an ongoing IMSI changeover. This applies to both the old and new IMSI.
• If the old IMSI contains other services than AUC, AVG, HLR, IMS, or EPS, these services must be deleted manually before IMSI changeover can be executed. After IMSI changeover is executed, the deleted services can be re-created on the new IMSI.
• Between create IMSI changeover and create IMSI changeover removal, the IMS operations (Create, Set and Delete) with IMPI or IMPU which are derived from the old IMSI are not allowed.

3.3.2   Set IMSI Changeover

During a delayed IMSI changeover, it is possible to change the execution date for the changeover by this operation.

3.3.3   Delete IMSI Changeover

This operation can be used when a delayed IMSI changeover has been ordered but expiry date has not yet passed (IMSI changeover has not been executed). The result is that the old IMSI is kept for the subscriber. The new IMSI is released to be used again or deleted.

3.3.4   Get IMSI Changeover

With this operation, the IMSI changeover information is fetched and printed.

The different states that can be received are:

• PEND (Pending) - The changeover is still ongoing. At least one service has still not seen the new SIM card and the expiry date has not passed.
• EXEC (Executed) - The changeover has been executed because the subscriber has used the new SIM card before the expiry date has passed.
• FORC (Forced) - The changeover has been executed, either because the expiry date was reached or the operator has forced the changeover.

3.3.5   Create IMSI Changeover Removal

This operation is possible when all applications (HLR, IMS, and EPS) have done the changeover. If not all applications have executed the changeover, the operation is rejected.

Note:  

Even in case of immediate changeover, where the subscriber has IMS service with user password, the changeover procedure is not done until HSS-FE re-encrypt the password.

When this operation is performed, the old data (IMSI) is removed from the subscriber and released to be used again or deleted.

3.4   Exceptions

The new IMSI is allowed to have either or both of AUC service and AVG service when initiating an IMSI changeover procedure. This depends on which services are active for the subscriber.

In general, it is not allowed to add new services for a Subscriber (Multi Service Consumer) when the Subscriber (Multi Service Consumer) is involved in an ongoing IMSI changeover. This applies to both the old and new IMSI. If the old IMSI contains other services than HLR, AUC, AVG, IMS, and EPS, delete these services before creating an IMSI changeover. Recreate them on the new IMSI after IMSI changeover is completed.

There are some exceptions to this rule:

• EPS is allowed to be created with some restrictions
  • In case, the IMSI changeover is in state PEND (Pending)

    Creation of EPS service on the new IMSI is rejected. It is only allowed to create services on the old IMSI.

  • In case, the IMSI changeover is in state EXEC (Executed) or FORC (Forced)

    Creation of EPS service on the old IMSI is rejected. It is only allowed to create services on the new IMSI.

• AVG is allowed to be created with some restrictions:
  • In case, the IMSI changeover is in state PEND (Pending)

    Creation of AVG service on either old IMSI or new IMSI is rejected.

  • In case, the IMSI changeover is in state EXEC (Executed) or FORC (Forced)

    Creation of AVG service on the old IMSI is rejected. It is only allowed to create services on the new IMSI.

It is allowed to delete the services during an ongoing IMSI changeover. This allows the operator to remove the complete user with all the services instead of executing the IMSI changeover. When the service that has been deleted is the last service beside AUC and AVG, the old data (IMSI) is removed from the subscriber and released to be used again or to be deleted.

After IMSI changeover removal, parameter userPrimaryHA1Password and userSecondaryHA1Password need to be re-provisioning for IMS service.

3.5   Provisioning Sequences

A complete IMSI changeover procedure for AUC/AVG/HLR/EPS/IMS can be performed following a sequence below.

Basic behavior is that either or both of AUC and AVG subscription with the new IMSI is already created before the changeover procedure starts, (sequence 1).

It is possible, by changing configuration, to allow creation of the new IMSI in a later phase of the sequence (according to sequence 2, and 3).

Sequence 1

1. Create AUC and/or AVG Subscription with new IMSI
2. Create IMSI Changeover
3. Create IMSI Changeover Removal (Remove Old IMSI)

Sequence 2

1. Create IMSI Changeover
2. Create AUC and/or AVG Subscription with new IMSI
3. Create IMSI Changeover Removal (Remove Old IMSI)

Note:  

By changing a configuration parameter, this sequence can be allowed.

Sequence 3

1. Create IMSI Changeover
2. Create IMSI Changeover Removal (Remove Old IMSI)
3. Create AUC and/or AVG Subscription with new IMSI

Note:  

• By changing a configuration parameter, this sequence can be allowed.
• For sequence 2 and 3, to initiate IMSI Changeover procedure for the new IMSI without AUC service, the switch AUTCHOVERMAND must be enabled. Otherwise, the procedure is rejected with error The IMSI is unknown in Authentication Centre. For more information about AUTCHOVERMAND, refer to User Guide for Resource Activation, Reference [9].

3.6   Impact of Upgrade

Dynamic Activation supports the IMSI changeover procedure with the addition of covering the EPS service.

This has some impact on the former configurable functionality to allow EPS service to be created during an IMSI changeover. In previous releases, it was possible to create the EPS service on the new IMSI. After the creation, if a delete IMSI changeover was issued, the new EPS service had to be deleted before the IMSI changeover was possible to delete.

When EPS has become a part of the IMSI changeover feature, the behavior has been changed to make sure that the traffic can continue. If the EPS service is to be created during an ongoing IMSI changeover, the service must be created on the active IMSI, see Section 3.4.

All application services must be in release 13B or higher (HLR-FE 13B, HSS-FE 14A, CUDB 13B) for this IMSI changeover procedure to work.

HSS and AVG application services must be in release HSS 16A FD1 or higher for this IMSI changeover procedure to work.

Other assumptions during an upgrade are that CUDB, HLR-FE, and HSS-FE must be upgraded before upgrading Dynamic Activation. In addition to that, Dynamic Activation requires that old changeovers have been executed before it is upgraded.

4   MSISDN Changeover

MSISDN changeover provides the functionality to change the MSISDN of a mobile user. It supports the following use cases:

• A subscriber has 2G/3G services in HLR(+M2M).
• A subscriber has 4G services in HSS/EPS.
• A subscriber has 2G/3G and 4G services in HLR(+M2M)+HSS/EPS.

Figure 3 and the following step list give a high-level description of the MSISDN changeover procedure.

1. Dynamic Activation receives the MSISDN changeover command.
2. Dynamic Activation sends an MML command to validate the MSISDN changeover command in HLR FE.
3. Dynamic Activation updates all applicable entries in CUDB.
4. Dynamic Activation notifies HLR and HSS FE about the change, if necessary.

4.1   Interfaces

For MSISDN Changeover Dynamic Activation supports operations over CAI3G. For detailed information, refer to Layered Identity Changeover Provisioning over CAI3G, Reference [2].

The CAI3G interface supports the following operations:

• Create MSISDN Changeover

4.2   Provisioning Handling

MSISDN changeover provisioning orders are allowed in the following scenarios:

• HLR subscription (+AUC)
• HLR subscription + EPS subscription (+AUC)
• EPS subscription (+AUC)

If the old MSISDN contains services other than HLR, AUC and EPS, such as IMS, two solutions are adopted as follows to handle MSISDN changeover:

• Removing services other than HLR, AUC, and EPS to keep data consistency before the MSISDN changeover.

  To comply:

  1. Set ServiceCheckMsisdnCho to true on GUI to check the existing services before executing MSISDN changeover, refer to User Guide for Resource Activation, Reference [9]. If service other than HLR, AUC and EPS has been found, Dynamic Activation stops the provisioning of MSISDN changeover and report errors.
  2. Remove the services other than HLR/EPS/AUC.
  3. Execute MSISDN changeover on HLR/EPS/AUC.
  4. Re-create the services that have been removed with the new MSISDN.

  This solution aligns with the behaviors of IMSI changeover.

• Execute MSISDN changeover without removing any service to minimize the risk of deleting or needing to re-create other services. This solution can cause data inconsistency. Because HLR/AUC/EPS has been updated with a new MSISDN, but meanwhile other services still contains the old MSISDN data.

  To comply:

  1. Set ServiceCheckMsisdnCho to false on GUI, refer to User Guide for Resource Activation, Reference [9]. Dynamic Activation executes MSISDN changeover without checking existing services.
  2. Execute MSISDN changeover on HLR/EPS/AUC.
  3. Important that any additional services, existing while MSISDN changeover was executed, must be updated with the new MSISDN. This step requires customized operations or manual intervention.

4.3   Functions

This section describes possible use cases for MSISDN changeover.

4.3.1   Create MSISDN Changeover

The goal with this operation is to allow the existing services (HLR, EPS, and AUC) for the subscriber to update the MSISDN to a new MSISDN, in an immediate changeover procedure.

After execution of the procedure, all attempts to make calls with the old MSISDN will be rejected.

4.4   Exception

The new MSISDN is not allowed to be used by any subscriber when initiating a MSISDN changeover procedure.

MSISDN changeover is not allowed for a subscriber when the subscriber is involved in an ongoing IMSI changeover. An ongoing IMSI changeover means when the IMSI changeover is in state PEND, EXEC or FORC.

When ServiceCheckMsisdnCho is true, only HLR, AUC and EPS services are allowed in the old MSISDN subscriber. For detailed information, see Section 4.2.

Reference List

Ericsson Documents
[1] Library Overview, 18/1553-CSH 109 628 Uen
[2] Layered Identity Changeover Provisioning over CAI3G, 27/155 19-CSH 109 628 Uen
[3] Layered HLR AUC Provisioning over MML, 5/155 19-CSH 109 628 Uen
[4] CAI3G Interface Specification for HLR Components, 25/155 19-CSH 109 628 Uen
[5] CAI Interface Specification for HLR Components, 24/155 19-CSH 109 628 Uen
[6] Function Specification Layered LTE EPC, 5/15517-CSH 109 628 Uen
[7] Layered IMS Provisioning over CAI3G, 13/155 19-CSH 109 628 Uen
[8] Layered HLR AUC Massive Operations over CLI, 4/155 19-CSH 109 628 Uen
[9] User Guide for Resource Activation, 1/1553-CSH 109 628 Uen