Function Specification Layered HLR
Ericsson Dynamic Activation 1

Contents

1Introduction
1.1Purpose and Scope
1.2Target Group
1.3Typographic Conventions

2
Overview
2.1Layered Provisioning Functions
2.2Interfaces
2.2.1MML
2.2.2CAI3G
2.2.3CAI

3
Provisioning Scenarios
3.1Individual Subscriber Provisioning
3.2HLR Subscriber with MNP Provisioning
3.3IMSI Changeover
3.4Massive Operation
3.4.1Conditional Search
3.4.2Massive Update
3.5Administration of Profiles
3.6Administration of Service Associated Data
3.7Location Procedure
3.8Data Model Extensibility
3.9Multiple Administration Area Support for HLR
3.10N+1 Redundancy Support
3.11Data Consistency Assurance in Core Network and CUDB
3.11.1Feature Operation
3.11.2Parameters

4
End to End Provisioning Solution
4.1Migration Support
4.2Other Advanced Provisioning Features

5
Enforcement of Subscriber Licensing

Reference List

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 a brief introduction to the HLR/AUC/MNP-FE provisioning solutions based on Ericsson™ Dynamic Activation (EDA).

1.2   Target Group

The target groups for this document are as follows:

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

In addition to the writing conventions mentioned above, the following applies:

2   Overview

User Data Consolidation (UDC) is an Ericsson solution that provides the Data Layered Architecture (DLA) for subscriber data repositories. It allows separation of traffic logic and data storage into different nodes.

An overview of the UDC solution and surrounding nodes is shown in Figure 1.

Figure 1   UDC Overview

All the data associated with the subscriber is stored in the Centralized User Database (CUDB). The traffic logic is executed on the application servers, such as the HLR-Front End (HLR-FE) and the AUC-Front End (AUC-FE). The provisioning aspects are handled by Dynamic Activation.

Dynamic Activation is an Ericsson solution for the common provisioning regardless of the vendor and network technology. Dedicated features in Dynamic Activation provide the provisioning interface for UDC. They are one of three mandatory building blocks in the UDC solution. On top of the UDC provisioning interface, Dynamic Activation offers a number of complementary features. The feature is covering different provisioning aspects that are crucial for the Business Support System (BSS), forming a sophisticated UDC provisioning solution.

2.1   Layered Provisioning Functions

Provisioning of Home Location Register (HLR) covers provisioning functionality for the HLR, Authentication Center (AUC), and Mobile Number Portability (MNP) components within the HLR product.

For information about the related platform functions, refer to Function Specification Resource Activation, Reference [3].

The main functions are:

2.2   Interfaces

Command-Line Interface (CLI) is used for massive operations, scheduled procedures as well as service associated data administration.

CAI, CAI3G, and classic MML can be used for individual subscriber provisioning of layered HLR/AUC/MNP.

The same business logic is executed regardless of whether the order is initiated from classic MML, CAI, or CAI3G.

For individual subscriber provisioning, operator can choose one of the following alternatives:

All these CAI/CAI3G interfaces are optional features for HLR.

2.2.1   MML

MML is an interface that has been originally designed to be used between human and machine. The MML interface is accessed through telnet clients, SSH clients, or direct socket connections.

The maximum number of concurrent MML sessions is 160 per payload node. Session time-out is 300 seconds. For security purposes, the MML can be protected by SSH.

The supported character set in an MML interface is ASCII.

This interface is used for synchronous communication, as an alternative to CAI3G.

2.2.2   CAI3G

CAI3G provides the operators a uniform interface to contain the subscription data towards to all NEs, and hides physical implementation of the networks, protocols, and interactions among those NEs.

For more information, refer to Function Specification Resource Activation, Reference [3].

2.2.3   CAI

CAI is a fast and simple Common Management Information Service Element (CMISE), and American Standard Code for Information Interchange (ASCII) based protocol, transmitted over TCP/IP by using Telnet or port communications. (When using the port communication, there is no UNIX™ logon procedure. This enables sending of commands directly to Dynamic Activation without having to perform an initial system logon.)

CAI Setup and Configuration

The setup and configuration of the CAI connections are handled by the Dynamic Activation maintenance or support personnel.

CAI Connections and Sessions

It is always BSS to initiate a CAI connection. Once the CAI connection is established, BSS starts a CAI session with a logon procedure, which requires the user identity and password to grant authorized access.

BSS can use the CAI session to send unlimited number of continuous CSOs over a period, until on of the following occurs:

In either case, the CAI connection is terminated when the session is closed.

Dynamic Activation supports multiple connections from one or more BSS, and up to 160 parallel CAI sessions per Playload (PL) node. Each session is independent of the others, and has a unique CAI connection.

The communication over a CAI session is synchronous – one message is always followed by its response. If there is a connection failure between BSS and Dynamic Activation, the response for any ongoing message is not stored, and therefore not sent back to BSS.

3   Provisioning Scenarios

This section contains information about the different provisioning scenarios.

3.1   Individual Subscriber Provisioning

CAI3G, CAI and MML are offered for provisioning of an individual subscriber. Through these interfaces, it is possible to perform the Create, Set, Delete, and Get operations.

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

The following types of subscribers are managed:

A simplified flow for an individual subscriber provisioning request is shown in Figure 2.

Figure 2   Individual Subscriber Provisioning

  1. The provisioning command is received.
  2. The data is validated by invoking the validation function in HLR/AUC-FE.

    2'

    HLR/AUC-FE fetches the subscriber data from CUDB.

  3. The data is sent to CUDB.
  4. The notification of the successful execution is sent to HLR/AUC-FE.
  5. The response message is sent back.

Validation function is provided by a validation Network Element (NE) Group. There can be more than one front end included in the group, all are used for validation following round-robin algorithm or Weighted Round Robin algorithm. Communication with CUDB is through a CUDB group, where two or three CUDB nodes are included. The CUDB nodes are configured in failover mode where only one node at a time is in use. For more information regarding configuration of NE Group, see Configuration Manual for Resource Activation, Reference [9].

For interface information of the individual subscriber provisioning, refer to CAI3G Interface Specification for HLR Components, Reference [7], and Layered HLR AUC Provisioning over MML, Reference [4].

Communication failures during the provisioning process are in most cases resolved by resending the same command. When a Create command has failed and the rollback also fails, it is not possible to resend the Create command directly without sending a corresponding Delete command first.

3.2   HLR Subscriber with MNP Provisioning

HLR subscription can be configured for provisioning of MNP subscription via a new JDV configuration in addition to HLR provisioning. CAI3G and CAI are offered for provisioning of HLR with MNP.

With HLR and MNP subscription cases, HLR subscription invokes both HLR and MNP subscription respectively. MNP subscription only deals with imported subscriber record. If the HLR subscriber’s MSISDN belongs to the operator's own network, the MNP subscription is skipped. Otherwise the MNP subscription is provisioned in CUDB as the imported subscriber. Meanwhile, if HLR subscription is NOT configured, the original HLR provisioning is not affected. For details about MNP configuration on HLR JDV, refer to User Guide for Resource Activation, Reference [17].

The MSISDN and additional MSISDN data is provisioned through MNP logics in the following HLR subscription operations:

Note:  
  • For the MNP Create operation, if MNP subscription already exists, the MNP subscription execution is skipped.
  • For the MNP Delete operation, if MNP subscription doesn’t exist, the MNP subscription execution returns a successful response.

HLR subscription with MNP provisioning flow is shown in the following figure.

Figure 3   HLR Subscription with MNP Provisioning Workflow

Step 1 – The HLR provisioning command is received.

Step 2 or 5 – The data is validated by invoking the validation function in HLR-FE or MNP-FE.

Step 3 or 6 – The HLR or MNP data is sent to CUDB.

Step 4 – The notification of the successful execution is sent to HLR-FE.

Step 7 – The HLR provisioning response message is sent back.

3.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. An IMSI Changeover can be reversed in case the lost SIM-card has been found.

The available functions are:

IMSI changeover is supported through the provisioning interfaces.

For more information, see Function Specification Identity Changeover for Layered Applications, Reference [10].

3.4   Massive Operation

The massive operation refers to the conditional search and massive update. Such operations are supported through the provisioning CLI.

For information about available operations in CLI, refer to the following documents:

3.4.1   Conditional Search

Conditional search is the name of the operations used to read subscriber data (including multiple subscription data) for all or a subset of subscribers fulfilling a certain criteria.

A simplified flow for a search request sent on the CLI is shown in Figure 4

Figure 4   CLI Use Case for Conditional Search

The flow for a search request sent on the CLI is as follows:

  1. A CLI client, such as the Operations Support System (OSS), sends a request for conditional search to Dynamic Activation. The search results in subscribers in the CUDB that match a certain condition. Dynamic Activation informs the client that the request has been ordered.
  2. If the FE involved is the HLR-FE, Dynamic Activation fetches more information from the HLR-FE before the search is initiated for all use cases. The configuration data is given as a condition in the CLI command or the result can be exported to the XML files. Dynamic Activation fetches information from the HLR-FE for the following use cases:
    • Request access point name

      The CLI command HEMSAPP with either the Access Point Name (APN) or the APN identifier (APNID) is entered as condition.

    • Request extended quality of service

      The CLI command HEMSEQP as the Extended Quality of Service identifier (EQOSID) is always entered as condition.

    • Request GSM service control function address

      The CLI command HEMSGSP with all the Global System for Mobile Communication (GSM) service control function address (GSA=ALL) is entered as condition.

    • Request location services address

      The CLI command HEMSGLP with one of the following is entered as condition:

      • Gateway Mobile Location Center (GMLC) address
      • GMLC Address Identifier (GMLCID)
      • Home GMLC Address (HGMLCA)
      • HGMLCA Identifier (GMLCID)
      • Privacy Profile Register Address (PPRA)
      • PPR Address Identifier (PPRID)
    • Request subscriber location services address

      The CLI command HEMSSGP with either GLMC or HGMLC or PPR, or any combination of them, is entered as condition.

  3. Profile data is needed to filter the subscribers, fulfilling a certain condition, in the following cases:
    • Request access point name

      The CLI command HEMSAPP is entered at requesting either of the following:

      • Subscribers using either an APN or an APNID in any of the Packet Data Protocol (PDP) contexts directly assigned to the subscriber or through a PDP context profile (parameter MSISDNALL or MSISDNS are given).
      • Subscribers using a non-subscribed APN in any of the PDP contexts directly assigned to the subscriber or through a PDP context profile (parameter MSISDNALL or MSISDNS are given).
    • Request GSM service control function address

      The CLI command HEMSGSP is entered at requesting the following:

      • All or a series of subscribers using a specified GSM service control function address associated to the user function CAMEL.
  4. Dynamic Activation sends an LDAP search request operation according to client order to the CUDB to fetch the subscriber fulfilling the condition or conditions.
  5. The CUDB sends a response to Dynamic Activation for each subscriber that matches the search condition. One or more LDAP search result operations can be returned.
  6. Dynamic Activation stores the result in a local file in XML format. This result file is continuously updated with the LDAP search responses and is stored in a predefined path.
  7. The CUDB notifies Dynamic Activation that the last entry has been found. Dynamic Activation notifies the client that the search is completed and returns the filename where the result is stored.
  8. The client fetches the file result using SFTP. Dynamic Activation returns the file result in XML format.

Conditional searches consist of the CLI operations described in Layered HLR AUC Massive Operations over CLI, Reference [12].

3.4.2   Massive Update

A massive update example is shown in Figure 5.

Figure 5   Massive Update

  1. The massive update request is received.
  2. The Lightweight Direct Access Protocol (LDAP) search command is sent to CUDB with search criteria.
  3. Subscribers that match the search criteria are sent back from CUDB and stored in a file.
  4. Each subscriber is updated with new data following the normal provisioning flow, that is, data validated by the FE and CUDB is updated. Several subscribers can be updated in parallel. This is regulated by the configurable parameter MaxParallelRequests.
  5. Execution results for all subscribers are stored in a file.
  6. The client fetches the file through the SFTP protocol.

3.5   Administration of Profiles

The following types of profiles are used for the HLR subscription:

CAI3G and MML are used to administer these profiles, regardless where the profiles are stored. CLI is used to manage M2M profiles and gsmSCF profiles.

For information about available operations for the profile administration, refer to:

3.6   Administration of Service Associated Data

The service associated data is administered through CLI. The data are provisioned to all HLR-FEs in the network, except the data of gsmSCF profiles which are provisioned to CUDB. Error is returned if not all FEs are updated.

The following are available functions:

For information about available operations for the service associated data administration, refer to Layered HLR AUC Service Associated Data over CLI, Reference [13].

3.7   Location Procedure

The location procedure gathers the subscriber statistics from CUDB on per Visitor Location Register (VLR) and Serving GPRS Support Node (SGSN) bases. The procedure can also be used to obtain the roaming area characteristics. It is possible to schedule single or recurrent location procedure. The result statistics are stored, and can be retrieved via CLI.

3.8   Data Model Extensibility

The CUDB data model can be extended based on customer needs. An operator can add a new application in CUDB or extend the existing application data model with new information.

When extending HLR/AUC in existing CUDB data model, in most of the cases, customer adaptation can be performed to modify configuration data in the existing provisioning logic. Complex modification, such as introducing new managed object can be performed as product customization. For details, contact your local Ericsson representative.

3.9   Multiple Administration Area Support for HLR

The HLR Multi Region and Virtual HLR feature virtualized the physical HLR resources for the operator. Thus, it eliminates the impact on organization when HLR evolves from monolithic architecture to UDC.

When a subscriber is created, an administration area identifier must be provisioned for the subscriber. This administration area identifier is one of the attributes in the CAI3G operation for subscriber creation. The identifier is stored together with the rest of the subscriber data in the CUDB. To change the administration area identifier for a subscriber, the subscriber must be deleted and then recreated with a new administration area identifier.

The list of administration area identifier per SGSN/VLR address can be retrieved through the location procedure. See Section 3.7.

HLR-FE uses the administration area identifier to support different traffic cases and to provide statistics counters for them as well.

In addition, each administration area can be restricted to administer its own subscriber with limited capacity of the provisioning resource. For details, see Function Specification Administration of Multi Domains and BSS Capacity, Reference [14].

3.10   N+1 Redundancy Support

The UDC solution can be used as the redundant system in the HLR N+1 configuration. One HLR-FE is backing up one or more monolithic HLRs in the network. UDC can also be used as primary HLR for some subscriber and redundant HLR for the others.

To enable this flexible redundancy configuration, each subscriber is given an extra attribute as indicator for traffic routing. For subscribers stored in CUDB, the attribute MultipleRedundancyPrimaryHLRIdentity (MRPPID) indicate whether the subscriber is a redundant subscriber in CUDB. If so, the primary HLR identity and redundancy group is given.

When provisioning a redundant subscriber in CUDB, the subscriber data must be validated by the corresponding HLR-FE that backs up the primary monolithic HLR. The CAI3G interface is extended for the provisioning client to provide this routing information. By using the parameter PrimaryHLRIdentity, Dynamic Activation is able to route validation requests towards the backup HLR-FE based on configured routing rules. For details, see Configuration Manual for Resource Activation, Reference [9].

HLR N+1 redundancy using classic Multi Activation:

As shown in Figure 6, the primary HLRs are divided in multiple redundancy groups. Classic Multi Activation can be used to handle double provisioning function. In this setup, the PrimaryHLRId is used to provide extra routing information only in the CAI3G request towards Dynamic Activation.

Figure 6   HLR N+1 Redundancy Using Classic Multi Activation

HLR N+1 redundancy not using classic Multi Activation:

As shown in Figure 7, Dynamic Activation can also support HLR N+1 redundancy without using classic Multi Activation where provisioning of monolithic HLRs and UDC are managed separately. The primary HLRs are divided in multiple redundancy groups. CAS can be used to handle double provisioning function. In this setup, the PrimaryHLRId is used to provide extra routing information only in the CAI3G request towards Dynamic Activation.

Note:  
In a setup where there is only one HLR redundancy group, the use of PrimaryHLRId is optional. Number Series Routing or Number Range Routing can be used for routing towards the corresponding backup HLR-FE for both CAI3G and MML requests.

Figure 7   HLR N+1 Redundancy Not Using Classic Multi Activation

3.11   Data Consistency Assurance in Core Network and CUDB

This feature enables Dynamic Activation to block an HLR provisioning command if there is already a pending notification, therefore data corruption can be avoided. Dynamic Activation will retry the blocked provisioning command a number of times, until the previous command’s timestamp becomes old or has been removed.

3.11.1   Feature Operation

When the Data Consistency Assurance in Core Network and CUDB feature is enabled, the operation workflow is described as follows:

  1. When the HLR-FE downloads the subscriber from the CUDB, it checks if there is a notification timestamp existing for this subscriber. If there is, the HLR-FE includes the timestamp in the printout to Dynamic Activation.
  2. Dynamic Activation retrieves the timestamp from the printout, and performs one of the followings:
    • If the timestamp is older than the specified time out or no timestamp at all, which means that there is no pending provisioning notification for the subscriber, Dynamic Activation calculates the current time as a timestamp, and adds the timestamp to the LDAP modification towards the CUDB.
    • If the timestamp is newer than the specified timeout, which means that an old provisioning command is still in progress, Dynamic Activation blocks the HLR notification provisioning in pending, and retries to send the newer provisioning command a configurable number of times.

      If all the retries fail, Dynamic Activation returns an error to the client.

  3. When the provisioning command is finished, the HLR-FE removes the timestamp from the CUDB for the subscriber.

3.11.2   Parameters

The following parameters can be configured per JDV in the GUI:

The retry configuration should be configured to enable fast retry in cases network update is fast (0.3-2 s), and to persistent enough to handle long network updates of outbound roamers.

Example

Table 1    Default Retry Configuration

Parameters

Description

Default value

HLRNotificationNumberOfRetries

Maximum number of retries

5

HLRNotificationWaitTime

Wait time

2000 ms, (2 s)

HLRNotificationRetryFactor

Retry factor

2

When the feature is enabled, Dynamic Activation retries five times for a blocked provisioning command as follows:

1st retry waits 2 seconds

(2 seconds after the first request)

2nd retry waits 4 seconds

(6 seconds after the first request)

3rd retry waits 8 seconds

(14 seconds after the first request)

4th retry waits 16 seconds

(30 seconds after the first request)

5th retry waits 32 seconds

(62 seconds after the first request)

4   End to End Provisioning Solution

When introducing UDC, Dynamic Activation provides extra functions to reduce provisioning impact on BSS.

4.1   Migration Support

When evolving from the monolithic HLR to UDC, two architectures coexist in the network for a relatively long period, depending on the network size and complexity. The migration of the subscriber is a highly sensitive activity. Dynamic Activation with its long history working with the HLR provisioning and large customer base, provides a proven solution that reduces the risks and complexity within the provisioning aspect.

Figure 8   Provisioning Solution for Migration

The provisioning solution for migration from monolithic to data layered architecture is shown in Figure 8. The key functions in the migration support are:

After migration of all subscribers to layered architecture, BSS can switch over from classic Multi Activation to Dynamic Activation. This interface in layered is backwards compatible with monolithic HLR and allows continue provisioning of subscribers with minimal impact on BSS.

4.2   Other Advanced Provisioning Features

5   Enforcement of Subscriber Licensing

Several features are sold under capacity-based licenses. If the use of these features exceeds the defined capacity levels, the system reacts. If the subscriber capacity level is exceeded for a specified time, creation of new subscribers is disabled.

For more information regarding this feature on each platform, see Function Specification Resource Activation, Reference [3].


Reference List

Ericsson Documents
[1] Library Overview, 18/1553-CSH 109 628 Uen
[2] Provisioning Overview, User Data Consolidation, 1/1550-1/HSD 101 012/1 Uen
[3] Function Specification Resource Activation, 3/155 17-CSH 109 628 Uen
[4] Layered HLR AUC Provisioning over MML, 5/155 19-CSH 109 628 Uen
[5] Layered HLR Common Profile Data over CAI3G, 8/155 19-CSH 109 628 Uen
[6] Layered HLR Common Profile Data over CLI, 23/155 19-CSH 109 628 Uen
[7] CAI3G Interface Specification for HLR Components, 25/155 19-CSH 109 628 Uen
[8] CAI Interface Specification for HLR Components, 24/155 19-CSH 109 628 Uen
[9] Configuration Manual for Resource Activation, 2/1543-CSH 109 628 Uen
[10] Function Specification Identity Changeover for Layered Applications, 14/155 17-CSH 109 628 Uen
[11] Generic CLI Interface Specification, 15/155 19-CSH 109 628 Uen
[12] Layered HLR AUC Massive Operations over CLI, 4/155 19-CSH 109 628 Uen
[13] Layered HLR AUC Service Associated Data over CLI, 6/155 19-CSH 109 628 Uen
[14] Function Specification Administration of Multi Regions and BSS Capacity, 10/155 17-CSH 109 628 Uen
[15] Function Specification Dynamic Activation Execution Environment, 6/155 17-CSH 109 628 Uen
[16] Function Specification Layered Machine to Machine, 15/155 17-CSH 109 628 Uen
[17] User Guide for Resource Activation, 1/1553-CSH 109 628 Uen


Copyright

© Ericsson AB 2017. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    Function Specification Layered HLR         Ericsson Dynamic Activation 1