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 Service-Aware Policy Controller (SAPC) provisioning in the layered and monolithic deployment, 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].
2 Overview
2.1 Layered SAPC
Data Layered Architecture (DLA) is an Ericsson architecture that provides a layered structure for network elements which allows separation of traffic logic and data storage into different nodes.
An overview of the layered SAPC provisioning and including nodes is shown in Figure 1.
- BSS - Initiates the provisioning 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 [7].
- 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).
- SAPC FE - A central policy node that is responsible for network performance. It includes the functionality defined in the Policy and Charging Rules Function (PCRF), as described in the 3GPP standard, applies subscriber and service-centric policy control capabilities to mobile broadband, mobile IMS, SAE, and fixed deployments. The main policy types supported are related to Service Access Control, Quality of Service (QoS) control, and Charging Control.
2.2 Monolithic SAPC
An overview of the monolithic SAPC provisioning and including nodes is shown in Figure 2.
- BSS - Initiates the provisioning request towards Dynamic Activation.
- Dynamic Activation - A provisioning system that provides a single
provisioning interface towards the 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 [7].
- Monolithic SAPC - A central policy node that is responsible for network performance. It includes the functionality defined in the PCRF, as described in the 3GPP standard, applies subscriber and service-centric policy control capabilities to mobile broadband, mobile IMS, SAE, and fixed deployments. The main policy types supported are related to Service Access Control, QoS control, and Charging Control.
2.3 SAPC Configuration
For detailed information about SAPC NE configuration, refer to User Guide for Resource Activation, Reference [4] and Configuration Manual for Resource Activation, Reference [7].
3 Data Model
Dynamic Activation is responsible to:
- Map the CAI3G order to the SAPC data model for subscriber, family and dataplan data. There are attributes that have a different format in the CAI3G interface and in the SAPC schema.
- Check and add default values to attributes that are required (mandatory) but optional in CAI3G.
- Keep SAPC data consistency. For more information, see Section 4.
3.1 Layered SAPC
The corresponding layered SAPC data is stored in CUDB and SAPC-FE.
|
Database |
Supported MO |
|---|---|
|
SAPC subscription | |
|
SAPC-FE |
Dataplan |
(1) Provisioning SAPC family
data to CUDB or SAPC-FE can be determined by the property FamilyProvisionTowardsCUDB on Dynamic Activation GUI,
refer to Reference [4].
3.1.1 CUDB
The following figure shows the layered SAPC provisioning data model in Centralized User Database (CUDB).
When initiating a SAPC subscription, the subscriber data is created in PCRF entry and the attributes are contained in SAPC, SAPC1 and SAPC2 object classes accordingly. A traffic ID alias for subscriber identity is created. For every traffic identity also a traffic ID alias is created.
When initiating a SAPC family, the family data are created as an association entry. SAPC families are directly accessed in associations branch by using FamilyID key as an association id.
The SAPC family and the SAPC subscription can be linked according to the following:
- The SAPC subscription (in PCRF entry) can contain the attribute familyId to identify the SAPC family.
- The SAPC family (in assocId entry) can contain the multi-value attribute MemberList (in AdministrativeData entry), listing all SAPC subscriptions that belong to this SAPC family.
- A SAPC family can only be deleted if it does not contain any SAPC subscriptions.
3.1.2 SAPC-FE
The SAPC-FE handles the data model in the internal database.
From SAPC 1, the SAPC-FE is accessed over the REST interface. For details, refer to Provisioning REST API.
Provisioning data in the SAPC-FE includes families and dataplans. It also includes the SAPC policy related data, that is policy locators, policies and rules.
When initiating a SAPC data plan, the dataplan data is created in the entry /dataplans/{dataplanId} and the optional entry /dataplans/{dataplanId}/locators/resources/{resourceId}/contexts/{contextId}.
When initiating a SAPC family, the family data is created in the entry /shared-dataplans/{sharedDataplanId} and the optional entry /shared-dataplans/{sharedDataplanId}/usage-accumulators.
3.2 Monolithic SAPC
The monolithic SAPC handles the data model in the internal database.
SAPC 16B is accessed over the LDAP interface, see Section 3.2.1.
From SAPC 17A/SAPC 1, the monolithic SAPC is accessed over the REST interface. For details, refer to Provisioning REST API.
3.2.1 Monolithic SAPC with LDAP Protocol
The following figure shows the monolithic SAPC provisioning data model in LDAP.
When initiating a SAPC subscription, the subscriber data is created in the entry EPC-SubscribersName=EPC-Subscribers and the optional entry EPC-SubscribersAccumulatedName=EPC-SubscribersAccumulated.
When initiating a SAPC family, the family data is created in the entry EPC-FamiliesName=EPC-Families and the optional entry EPC-SubscribersAccumulatedName=EPC-SubscribersAccumulated.
3.2.2 Monolithic SAPC with REST Protocol
Provisioning data in the monolithic SAPC includes subscribers, families and dataplans. It also includes the SAPC policy related data, that is policy locators, policies and rules.
When initiating a SAPC subscription, the subscriber data is created in the entry /subscribers/{subscriberId} and the optional entry /subscribers/{subscriberId}/usage-accumulators.
When initiating a SAPC family, the family data is created in the entry /shared-dataplans/{sharedDataplanId} and the optional entry /shared-dataplans/{sharedDataplanId}/usage-accumulators.
When initiating a SAPC data plan, the dataplan data is created in the entry /dataplans/{dataplanId} and the optional entry /dataplans/{dataplanId}/locators/resources/{resourceId}/contexts/{contextId}.
4 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.
4.1 CUDB
One CAI3G CSO can imply several LDAP orders towards the CUDB. Dynamic Activation will provide atomicity in SAPC provisioning as below:
- Parses and validates the CSO order to minimize the received errors.
- Retry the LDAP order when some LDAP errors are returned from CUDB, for example Function Busy and CDC Collision. The number of retries is configurable. For more information about retry setting, see User Guide for Resource Activation, Reference [4].
- Support fault tolerance and rollback when LDAP errors are returned from CUDB and retry failed. For more information about fault tolerance and rollback on SAPC operations, see Function Specification Resource Activation, Reference [5].
If rollback is still failed, the atomicity is not achieved; the CUDB integrity is not assured. Dynamic Activation raised an alarm and sends back error information about inconsistent data in the CUDB.
For more information about SAPC alarm, see Event and Alarm Handling, Reference [6]
For more information about rollback failed error, see SAPC Provisioning over CAI3G, Reference [2].
In case of data inconsistency, manual action is needed. For more information about SAPC actions, see Function Specification Resource Activation, Reference [5].
- 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.
4.2 Monolithic SAPC and SAPC-FE
Dynamic Activation provides atomicity in SAPC provisioning as below:
- Parses and validates the CSO order to minimize the received errors.
- Support rollback when SAPC node errors are returned from SAPC during the Create operation.
- Support fault tolerance when SAPC node errors are returned from SAPC during the Delete operation.
If rollback is still failed, the atomicity is not achieved. Dynamic Activation sends an error message with inconsistent data in SAPC to the BSS.
For more information about rollback failed error, see SAPC Provisioning over CAI3G, Reference [2].
5 SAPC Provisioning
CAI3G is offered for provisioning of SAPC data. Through the CAI3G provisioning interface, it is possible to perform the following Customer Service Orders (CSOs):
- Create/Set/Get/Delete SAPCSubscription
- Create/Set/Get/Delete SAPCFamily
- Create/Set/Get/Delete Dataplan
For more information, refer to SAPC Provisioning over CAI3G, Reference [2].
CLI is offered for massive print of the layered SAPC subscriptions and the layered SAPC families.
5.1 SAPC Subscription
This MO is used to handle the provisioning of SAPC subscription.
5.2 SAPC Family
This MO is used to handle the provisioning of SAPC family.
5.3 SAPC Data Plan
This MO is used to handle the provisioning of SAPC data plan.
5.4 SAPC Massive Operation
- Note:
- This section applies for layered SAPC only.
PCMSFMP – command for printing the identifiers of the subscribers being members of a specified family. If the identifier of the family is not provided in the request, all families and their respective subscriptions are printed.
For more information, refer to SAPC Massive Operations over CLIReference [3].
Reference List
| Ericsson Documents |
|---|
| [1] Library Overview, 18/1553-CSH 109 628 Uen |
| [2] SAPC Provisioning over CAI3G, 20/155 19-CSH 109 628 Uen |
| [3] SAPC Massive Operations over CLI, 29/155 19-CSH 109 628 Uen |
| [4] User Guide for Resource Activation, 1/1553-CSH 109 628 Uen |
| [5] Function Specification Resource Activation, 3/155 17-CSH 109 628 Uen |
| [6] Event and Alarm Handling, 3/1553-CSH 109 628 Uen |
| [7] Configuration Manual for Resource Activation, 2/1543-CSH 109 628 Uen |
| [8] Provisioning REST API, 9/155 19-CSH 109 215/6 Uen |