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 a brief introduction to the Layered Authentication, Authorization, and Accounting (AAA) NonSIM Device (NSD) Subscription Data in IPWorks provisioning solution, provided by Ericsson™ Dynamic Activation (EDA).

1.2   Target Group

The target group for this document is as follows:

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

For more information regarding 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   Layered AAA NSD Provisioning Solution

Data Layered Architecture (DLA) is an Ericsson architecture that provides a layered structure for network elements. This allows separation of traffic logic and data storage into different nodes.

2.1   Overview

An overview of the AAA NSD solution and including nodes is shown in Figure 1.

• BSS - Initiates the provisioning CAI3G request towards Dynamic Activation.
• Dynamic Activation - A provisioning system that provides a single provisioning interface towards the Business Support System (BSS), by hiding the complexities of provisioning multiple underlying network elements.

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

• CUDB - The Back-End database offered by the Ericsson realization of DLA, which decouples the user data storage from the application logic in the Front-Ends (FEs).
• AAA FE - Realizes Authentication, Authorization, and Accounting function to handle NSD user requests for non-3GPP Wi-Fi access to network resources.

2.2   Data Model AAA NSD

The following figure shows the AAA NSD provisioning data model in Centralized User Database (CUDB).

Dynamic Activation is responsible to:

• Map the CAI3G order to the LDAP objects in the data model for a subscriber. There are attributes that have a different format in the CAI3G interface and in the LDAP schema.
• Check and add default values to attributes that are required (mandatory) in CUDB but optional in CAI3G.
• Handle identities and alias under root identities entry, generate identity for MultiSC (IMSI and MultiSC ID) and validate their relations for a given subscriber.
• Create the service objects each time when a MultiSC is created in the CUDB. The service objects are removed each time when a MultiSC is deleted.
• Notify AAA-FE to detach the traffic session when AAA NSD data is deleted, AAA NSD user status is disabled, or AAA NSD user data is reset.

2.3   Atomicity and Integrity Handling

Atomicity means ensuring that any operations performed on the system are either all completed successfully or all reversed successfully to keep the data consistency.

One CAI3G CSO can imply several LDAP orders towards the CUDB. Dynamic Activation will provide atomicity in AAA NSD provisioning as below:

• Parses and validates the whole CSO before any LDAP order is sent towards the CUDB to minimize the LDAP errors received from the CUDB.
• Retry the LDAP order when some LDAP errors are returned from CUDB, for example Function Busy. The number of retries is configurable. For more information about retry setting, see User Guide for Resource Activation, Reference [2].
• Support fault tolerance and rollback when LDAP errors are returned from CUDB and retry failed. For more information about fault tolerance and rollback on AAA operations, see Function Specification Resource Activation, Reference [3].

If rollback still failed, the atomicity is not achieved; the CUDB integrity is not assured. Dynamic Activation raises an alarm and sends back error information about inconsistent data in the CUDB.

For more information about rollback failed error, see Wi-Fi Calling Provisioning over CAI3G, Reference [5].

In case of data inconsistency, manual action is needed. For more information about AAA repair actions, see CUDB Subscription Repair and Remove Procedures, Reference [6].

Note:  

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

2.4   Notification

The notification is used to inform AAA-FE to detach the traffic session after a successful CUDB provisioning is done via the CAI3G Set and Delete operations. The notification between Dynamic Activation and AAA-FE is performed in a synchronous procedure.

If the AAA-FE is down, Dynamic Activation stops sending notifications but it won’t affect provisioning result if CUDB subscription is done.

The following operations trigger AAA-FE notification:

• Delete AAA NSD user.
• Set AAA NSD user status as “disable”.
• Set AAA NSD user status as “reset” with parameters apn, certificateIssuerName, and certificateId.

Dynamic Activation can notify multiple AAA-FE with the configuration of NE Group “Active-Active”. All AAA-FE nodes in the NE group receive notification command in order.

2.5   AAA NSD Provisioning Flow

A simplified provisioning flow for AAA NSD over CAI3G interface is shown in Figure 3.

1. CAI3G Provisioning request is received from BSS.
2. Dynamic Activation checks CUDB if data exists and performs the LDAP operation regarding provisioning operations.
3. CUDB sends successful response to Dynamic Activation.
4. A notification is sent to AAA-FE if traffic session needs to be detached.
5. The notification procedure is done.
6. A CAI3G response is sent back to BSS.

3   AAA NSD Provisioning

CAI3G is offered for provisioning of Layered AAA NSD data. Through the CAI3G provisioning interface, it is possible to perform the following Customer Service Orders (CSOs):

• Create/Set/Get/Delete AAANSDUser

For more information, refer to Wi-Fi Calling Provisioning over CAI3G, Reference [5].

3.1   AAA NSD User

This MO is used to handle the provisioning of AAA NSD user.

When initiating AAA NSD user, perform the following operations towards CUDB:

• Check if IMSI identity exists
• Check if mscId and service NSD objects exist.
• If none of the above entries exists, create IMSI identity and the mscId object, and point IMSI to the mscId object.
• Create service NSD object under the mscid entry with required AAA NSD attributes.
• Create serv=Identities object under the mscid entry.

When modifying AAA NSD user, perform the following operations in CUDB:

• Check if service NSD object exists.
• Update required AAA NSD attributes under the serv=NSD object.
• If needed, send notification to inform AAA-FE to detach the traffic session.

When deleting AAA NSD user, perform the following operations in CUDB:

• Check if service NSD object exists.
• Remove service NSD and serv=identities objects under the mscId entry.
• Remove the mscId object.
• Remove the IMSI identity.

Reference List

Ericsson Documents
[1] Library Overview, 18/1553-CSH 109 628 Uen
[2] User Guide for Resource Activation, 1/1553-CSH 109 628 Uen
[3] Function Specification Resource Activation, 3/155 17-CSH 109 628 Uen
[4] Configuration Manual for Resource Activation, 2/1543-CSH 109 628 Uen
[5] Wi-Fi Calling Provisioning over CAI3G, 14/155 19-CSH 109 628 Uen
[6] CUDB Subscription Repair and Remove Procedures, 4/1553-CSH 109 628 Uen