Contents

1   Introduction

This section contains information about the purpose, scope, and target group for the document.

1.1   Purpose and Scope

This document gives an introduction to the Machine to Machine (M2M) provisioning solution provided the Ericsson™ Dynamic Activation (EDA) product.

For general functionality of Dynamic Activation, see Function Specification Resource Activation, Reference [1].

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 [2].

1.3   Typographic Conventions

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

2   Overview

M2M communication is a rapid growing area for innovative services aiming for increasing efficiency and improving life quality by minimizing human interventions. The Ericsson User Data Consolidation (UDC) solution provides user management support for M2M communication. The solution includes three key components, the Centralized User Database (CUDB), the Front End (FE), and Dynamic Activation.

Dynamic Activation provides provisioning interface for managing M2M subscription-related data and secure data consistency in the CUDB.

2.1   Deployment Scenarios

The UDC solution supports multiple deployment scenario which facilitates different business models, as shown in Figure 1. For telecom operators that offer M2M services or infrastructure for M2M services, it is possible to combine M2M traffic with the HLR FE or introduce new dedicated FE instances to handle M2M traffic. For M2M service providers, it is possible to deploy a UDC solution to manage only M2M communication.

From provisioning point of view, different deployment scenarios affect network element configuration.

For more information about configuration of Dynamic Activation in these deployment scenarios, see Configuration Manual for Resource Activation, Reference [3].

2.2   Data Model

From provisioning point of view, there are two types of data for M2M communication: subscription-related data and service associated data. Figure 2 illustrates the data categories

The following sections describe the data model in detail.

2.2.1   Multiple M2M Subscription

A Multiple M2M Subscription links several previously defined M2M subscriptions to an association. For details regarding Multiple M2M subscription provisioning function, see chapter Section 3.4.

2.2.2   M2M Subscription and M2M Service Profile

M2M Subscription, about normal HLR subscription, is a subscription type of its own. All services available for normal subscription are applicable for M2M subscription but are modulated and managed in a different way.

Subscriber data applicable for M2M subscription is divided into the following categories:

• M2M Service Profile data

  Data is assigned to a subscription via an M2M Service Profile. The M2M Service Profile provisioning function manages M2M Service Profile data. For more details, see Section 3.2.

• Individual data

  Data is assigned to a subscription directly and is stored on per subscription basis. The M2M Subscription provisioning function manages provisioning of individual data. For more details, see Section 3.3.

Each specific parameter can be assigned to only one of the previous mentioned categories. An M2M subscription hosts individual data. An alias pointing to a M2M Service Profile is mandatory for a M2M subscription. In this way, an M2M subscription has access to all service while data storage and data management effort are kept to minimum. An M2M Service Profile can be assigned to one or more subscriptions.

2.2.3   Other Profiles

M2M Profile		Consists of M2M specific data, for example Device Mobility Information as well as information of the Network Application Server. This profile type is only applicable for M2M Subscriptions. For details, see chapter Section 3.1.
GPRS Profile		Consists of a set of predefined PDP-context data, for example extended quality of service, charging characteristics, or PDP context type. This profile type is applicable for both M2M Subscription and HLR subscription.
CAMEL Profile		Consists of a set of CAMEL data, for example CAMEL trigger detection points, CAMEL subscription options, extended CAMEL data, and CAMEL triggering criteria data. This profile type is applicable both for M2M Subscription and HLR subscription.
GSMSCF Profile		Consists of a list of gsmSCF addresses where a notification message is sent when particular data is modified. This profile type is applicable for both M2M Subscription and HLR subscription.

These profile types are optional for a M2M Subscription. The profiles are assigned to a M2M Subscription via a M2M Service Profile. One M2M Service Profile can have an alias of one profile of each type. One profile can be assigned to one or more M2M Service Profiles.

For details of the provisioning interface of these profiles, see Layered HLR Common Profile Data over CAI3G, Reference [6], and Layered HLR Common Profile Data over CLI, Reference [4].

2.2.4   Service Associated Data

Service Associated Data is data indirectly associated to subscriptions. This data category is applicable for both M2M Subscription and HLR subscription. This data is configured in the FEs.

For information of how to configure Dynamic Activation for provisioning of this data, see Configuration Manual for Resource Activation, Reference [3]. For information about the provisioning interface, see Layered HLR Common Profile Data over CLI, Reference [4].

3   Provisioning Functions

This section describes the M2M specific provisioning functionality in detail.

3.1   M2M Profile Management

M2M Profile is an optional entry in the M2M data model. It is necessary when automatic device configuration is desired. M2M Profile contains the following data used to configure the M2M device:

• Network application server name
• Network application server type
• Network application server IP type
• Network application server IP address
• Network application server IP port
• Network application server URL address
• Network application server MSISDN
• Mobility information

Provisioning of M2M profile is available via the Command-Line Interface (CLI). For more information about the CLI interface, see Layered HLR Common Profile Data over CLI, Reference [4].

3.1.1   Initiate an M2M Profile

The function Initiate an M2M Profile verifies that data in the profile is compatible via FE validation and updates CUDB with the desired data.

3.1.2   Print M2M Profiles

It is possible to print one or all profiles.

3.1.3   Change an M2M Profile

The function Change an M2M Profile ensures that data to be changed is allowed via FE validation and updates CUDB with the desired data.

3.1.4   End an M2M Profile

The function End an M2M Profile verifies that no M2M Service Profile is using the M2M Profile and then removes the profile in CUDB. If the M2M Profile is in use, the operation is ended with error message.

3.2   M2M Service Profile Management

M2M Service Profile contains a setup of subscriber data that is common for a segment of devices. The following data is to be managed in an M2M Service Profile, and must not be assigned to a subscription individually:

• GPRS Data defined in a GPRS Profile
• CAMEL Data defined in a CAMEL Profile
• GSMSCF Data defined in a GSMSCF Profile
• Device Configuration Data defined in an M2M Profile
• Network Access Mode
• Availability indication of Basic Services and Supplementary Services
• Location Services and Location Service Address Options
• Spam SMS Data

3.2.1   Create an M2M Service Profile

An M2M Service Profile is created based on the content of a normal HLR subscription, the creation process is illustrated in Figure 3.

A normal HLR subscription must be created before creation of an M2M Service Profile. The normal HLR subscription is called dummy subscription. The dummy subscription must be provisioned with all the services that the M2M Service Profile host. The general workflow for creating dummy subscription is the following:

1. User initiates the Create HLR subscription operation with normal HLR subscription operations. For information of normal HLR subscription provisioning function, see Function Specification Layered HLR, Reference [5].
2. The built-in validation process makes sure that the data is correct and consistent.
3. A dummy subscription is created in CUDB as a normal HLR subscription.

When the dummy subscription is in place, an M2M Service Profile can be created. The general workflow for creating an M2M Service Profile is the following:

1. User initiates the Create M2M Service Profile operation. M2M Service Profile identity and the identity for the dummy subscription are mandatory information while M2M Profile identity is optional. For more information about the provisioning interface, see Layered HLR Common Profile Data over CAI3G, Reference [6].
2. The provisioning logic fetches data from the dummy subscription.
3. The provisioning logic creates an M2M Service Profile with the fetch information.

When the M2M Service Profile is created successfully, the dummy subscription can be deleted.

The service profile creation process does not transfer all data provisioned to a dummy subscription into the M2M Service Profile. For example, Subscription Option Control of Barring Services (SOCB) and Subscriber Password (PWD) are not transferred to an M2M Service Profile. For supplementary services, only the service availability, for example BOAC=1, is transferred into the Service Profile. The BOAC activation state for a basic service group is not transferred. Data not transferred into a Service Profile must be provisioned as individual data via the M2M Subscription provisioning function, see section Section 3.3.

For a list of data that is transferred into a M2M Service Profile, sees response data for Get M2M Service Profile operation in Layered HLR Common Profile Data over CAI3G, Reference [6].

For a list of data that is not transferred into a M2M Service Profile, sees request data for Create M2M Subscription operation in Layered HLR Common Profile Data over CAI3G, Reference [6].

Note:  

If a create M2M Service Profile operation fails, the partially created M2M Service Profile must be deleted via the Delete operation before resending the Create command. This is because of that change of M2M Service Profile is not supported.

3.2.2   Get an M2M Service Profile

The response of a Get an M2M Service Profile operation contains data defined in the M2M Service Profile and also details of all the common profiles associated to it.

Both the CUDB and FE are inquired during the data gathering process. Sometimes not all data can be retrieved because of communication error or incompleteness of data in the databases. Therefore, the response can contain error message or incomplete data. Read the response carefully and troubleshoot the error accordingly.

This function is available via CAI3G interface. For more information about the CAI3G interface, see Layered HLR Common Profile Data over CAI3G, Reference [6].

3.2.3   Print All M2M Service Profiles

Up to 65535 M2M Service Profiles can be created in a UDC system. The print all operation searches for all defined M2M Service Profiles in CUDB and retrieves data for each found profile accordingly. The result is written to an xml file which can be retrieved via ftp.

This function is available via Command-Line Interface (CLI). For more information about the CLI interface, see Layered HLR Common Profile Data over CLI, Reference [4].

3.2.4   Delete an M2M Service Profile

Before deleting an M2M Service Profile, the deletion function controls that no subscription is associated with the M2M Service Profile. In case, a subscription is using the M2M Service Profile, the operation is ended with error message.

This function is available via Command-Line Interface (CLI). For more information about the CLI interface, see Layered HLR Common Profile Data over CLI, Reference [4].

3.2.5   Modification of an M2M Service Profile

This function is not available in this release. The walk around solution is to first delete the M2M Service Profile, then create a profile with the desired services.

3.3   M2M Subscription Management

The M2M Subscription provisioning function provides a high abstraction level provisioning interface that orchestrates the following individual data:

• Extra MSISDN
• Closed User Group
• Close User Group Basic Service Group Options
• M2MSP alias (Mandatory)
• Mobility Management IN Triggering Subscription Data
• Mobility Management IN Triggering Subscription Data Activation
• PrimaryHLRId: this is an CAI3G extension used only in the N+1 redundancy scenario. It indicates the HLR-FE node working as backup of the N number of classic HLRs. For detail information of N+1 redundancy, see Function Specification Layered HLR, Reference [5].
• Region ID
• Subscriber data (SOCB and PWD)
• Subscriber Spatial Triggers
• Supplementary service settings for basic service group
• Zone ID

The general provisioning flow is illustrated in Figure 4. The Provisioning Client initiates one command that contains all data needed for the provisioning task. Dynamic Activation breaks down the incoming command into one or more suboperations. Data validation, update of CUDB as well as network notification are managed transparently by Dynamic Activation on suboperation basis. When all suboperations are concluded, one response is sent back to the user.

Provisioning of M2M subscriptions is available via CAI3G interface. For more information about the CAI3G interface, see Layered M2M Subscription Provisioning over CAI3G, Reference [7].

3.3.1   Create an M2M Subscription

An M2M Service Profile Identity must be provided at subscription creation. Individual subscriber data can be managed at subscription creation.

MSISDN-less M2M subscription is supported. The incoming subscription creation command can contain only IMSI. An MSISDN is automatically generated by replacing the first digit of the IMSI to 0, for example IMSI=12345678, MSISDN=02345678. This MSISDN is used for internal provisioning purpose, and not used in traffic.

The creation process contains many suboperations. To secure data completeness in CUDB, the creation function comes with built-in rollback function. If an error occurs during the creation process, the already created data is removed. Error message is sent back to the user indicating whether rollback is successful or not. If rollback is successful, the creation operation can be resent. If rollback fails, a delete operation must be initiated to remove the incomplete subscription. Such garbage cleaning delete operation must use MSISDN only as identity.

3.3.2   Get an M2M Subscription

The function retrieves subscription data from CUDB. When necessary, it also retrieves data from the FE.

3.3.3   Set an M2M Subscription

This function allows modification of individual data for an existing subscription. One or more attributes can be managed in one operation. Via this operation, the following actions can be performed:

• Add new services to an existing subscription. For example, add Subscriber Spatial Triggers to the subscription.
• Modify existing service for an existing subscription. For example, change activation state for a barring service.
• Remove services for an existing subscription. Remove a Mobility Management IN Triggering Detection Point from the subscription.
• A combination of the previous actions.

3.3.4   Delete an M2M Subscription

This function removes the M2M Subscription from CUDB. If the operation fail because of communication error, the same command can be resent to conclude the task.

3.4   Multiple M2M Subscription Management

Multiple M2M Subscription links several previously defined M2M subscriptions to an association. One of the linked subscriptions is identified as “active subscription”. All terminating calls and SMSs directed to any of the linked subscriptions are automatically directed towards this active subscription. The only exceptions are the configuration messages that the HLR FE identifies which must be delivered to the requested subscription. One of the linked subscriptions is identified as “master subscription”. The operator decides, via network configuration, whether the master MSISDN identifies the whole multiple subscription, or if every subscription included in the multiple subscription is identified by its own MSISDN.

The common data, from provisioning point of view, for a multiple subscription association is the following:

• Current Active subscription
• Activation mechanism
• Master subscription

Via the provisioning interface, it is possible to administer these common data as well as add subscriptions to the association or remove subscription from the association. The provisioning function ensures that all linked subscriptions are M2M subscriptions, that is, linking a normal HLR to M2M multiple subscription is not allowed.

Provisioning of Multiple M2M Subscriptions is available via CAI3G interface. For more information about the CAI3G interface, see Layered M2M Subscription Provisioning over CAI3G, Reference [7]].

3.4.1   Create a Multiple M2M Subscription

At least two M2M subscriptions must be defined before the creation of the Multiple M2M Subscription. When creating a new Multiple M2M Subscription, the master subscription is identified by its MSISDN while the linked subscriptions are identified by their IMSI. Up to ten subscriptions can be linked to an association. Activation mechanism is mandatory in creation.

Optionally, zone ID can be assigned to a Multiple M2M Subscription. However, the provisioning function does not verify whether all subscriptions in the association as well as the association itself belong to the same zone.

3.4.2   Get a Multiple M2M Subscription

This function retrieves a Multiple M2M Subscription from CUDB. It shows the activation mechanism and optionally also the zone ID defined for the Multiple M2M subscription. For each subscription linked to the association, MSISDN and IMSI are listed. It is also listed whether it is an active subscription, master subscription, or both.

Multiple M2M Subscription data can also be retrieved via Get Subscription function described in section Section 3.3.2.

3.4.3   Set a Multiple M2M Subscription

This function modifies an existing Multiple M2M Subscription. The following actions can be performed:

• Change of activation mechanism
• Change of active subscription
• Change of master subscription
• Add new subscriptions to the association
• Remove subscriptions from the association

3.4.4   Delete a Multiple M2M Subscription

This function deletes a Multiple M2M Subscription association from CUDB. A Multiple M2M Subscription can only be deleted when there is only two subscriptions linked to it. If there are more than two subscriptions linked to the association, the subscriptions must be removed from the association via the Set Multiple M2M Subscription function, see Section 3.4.3.

3.5   IMSI Changeover

IMSI Changeover is a generic function that allows changing IMSI for an existing multi-service consumer defined in the CUDB. This function covers M2M subscriptions. For more detailed information regarding the provisioning function for IMSI Changeover, see Function Specification Identity Changeover for Layered Applications, Reference [8].

The applicable IMSI Changeover specification for M2M subscription is Layered Identity Changeover Provisioning over CAI3G, Reference [9].

3.6   MSISDN Changeover

MSISDN Changeover is a generic function that allows changing MSISDN for an existing multi-service consumer defined in the CUDB. This function covers M2M subscriptions. For more detailed information regarding the provisioning function for MSISDN Changeover, see Function Specification Identity Changeover for Layered Applications, Reference [8].

The applicable MSISDN Changeover specification for M2M subscription is Layered Identity Changeover Provisioning over CAI3G, Reference [9].

4   Customization

Customization can be carried out as an extension of the standard product implementation. Some typical examples are extension of existing attribute value, introduction of new subscriber data, or other functionality that is not available in the standard product. Such customization is often a cross node activity, that is, they require not only modification in Dynamic Activation but also customization in CUDB or FE, or both. For more information, contact Ericsson local representative.

Reference List

Ericsson Documents
[1] Function Specification Resource Activation, 3/155 17-CSH 109 628 Uen
[2] Library Overview, 18/1553-CSH 109 628 Uen
[3] Configuration Manual for Resource Activation, 2/1543-CSH 109 628 Uen
[4] Layered HLR Common Profile Data over CLI, 23/155 19-CSH 109 628 Uen
[5] Function Specification Layered HLR, 2/155 17-CSH 109 628 Uen
[6] Layered HLR Common Profile Data over CAI3G, 8/155 19-CSH 109 628 Uen
[7] Layered M2M Subscription Provisioning over CAI3G, 28/155 19-CSH 109 628 Uen
[8] Function Specification Identity Changeover for Layered Applications, 14/155 17-CSH 109 628 Uen
[9] Layered Identity Changeover Provisioning over CAI3G, 27/155 19-CSH 109 628 Uen