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

The purpose of this document is to provide guidance for client integration towards Dynamic Activation in both standalone and redundant setups.

1.2   Target Groups

The target groups for this document are as follows:

• System Integrator

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

1.3   Typographic Conventions

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

For information about abbreviations used throughout this document, see Glossary of Terms and Acronyms, Reference [2].

1.4   Prerequisites

To use this document fully, users must meet the following prerequisites:

• Basic knowledge about the Ericsson Dynamic Activation (EDA) product.
• Knowledge about Generic CAI3G Interface 1.2, Reference [3].

2   Overview

When integrating towards Dynamic Activation, the following aspects need to be considered, which are covered throughout this document:

• Interfaces

  Integration towards Dynamic Activation is primarily with Web Service Interfaces, where corresponding Web Services Definition Language (WSDL) and XML Schema Definition Language (XSD) files are provided and are used as a baseline while implementing client code. For more information, see Section 3.1.

• Communication Protocols

  Different interfaces are accessed through different communication protocols (with or without encryption), each of which needs to be configured to some extent to integrate well with a particular client system.

  Primarily it is the security aspects that need to be configured explicitly (for example. SSL/TLS), whereas other properties should be left with default settings, if no particular needs are to be considered (for example high number of client sessions or connections). For more information, see Section 3.4.

• Security

  Hardening of a client integration is enabled through various configurations, where Dynamic Activation supports encrypted communication protocols, and individual access control per user. For more information, see Section 4.

• Redundant Setups

  Deploying Dynamic Activation in a redundant setup requires additional implementation on the client in terms of failover, fail-back, and heartbeat mechanism. For more information, see Section 5.

• Fault Management

  Dynamic Activation provides information about provisioning faults, either in the response to a request (both synchronous and asynchronous interface), and also through notifications (asynchronous interface), where the level of detail differs between the interface, and the application being provisioned.

  From a client integration point of view, it is important to differentiate between the different levels of error codes and only implement machine interpretation of well-defined error codes. That is, not rely on error messages, error details or subordinate error codes which are subject to change. For more information, see Section 7.

3   Interfaces

Dynamic Activation implements several provisioning interfaces, supporting both legacy applications and next generation applications.

The primary provisioning interface used in Dynamic Activation is the CAI3G 1.2 Interface, providing a single endpoint for provisioning for all applications.

For more information about the CAI3G implementation in Dynamic Activation, see CAI3G Implementation, Reference [14].

Example of format changes:

• Changes in indentation.
• Changes in number of newlines, whitespaces, and more.

Example of namespace definitions changes:

• Changes from a namespace prefix to a default namespace and the other way around.
• Changes in which element the namespace declaration occurs.

Additional provisioning interfaces may be added as Northbound Interface Adaptations, enabling northbound integration towards any IT or CAS system, and vendor.

3.1   Web Service Interface

The Web Services Description Language (WSDL) and XML Schema Definition Language (XSD) files that describe the provisioning interface can be found in /home/dveinstaller/ma/. It is also possible to download the files and view or store them in an appropriate area by following below instruction:

1. Save the zip file, Multi_Activation_WSDL_ and_ XSD_ files.zip, to a local folder.
2. Unpack the zip file.

Note:  

It is recommended to parse the XSD files as XML documents instead of plain text files. Because the Dynamic Activation-generated XSD can change XML format or namespace definitions in-between releases, even though the document content is the same.

Examples of format and namespace definition changes, see Section 3.

3.2   Northbound Interface Adaptation

For integration scenarios where CAI3G is not the preferred interface, Dynamic Activation provides a Northbound Interface Adaptation (NBIA) framework, enabling integration with arbitrary CAS/IT systems through customer adaptation (CA).

For more information about NBIA, refer to Northbound Interface Adapter Customization Development Guide for HTTP-Based Protocol, Reference [10].

3.3   Applications per Interface

Dynamic Activation provides multiple provisioning interfaces depending on application.

Common for all interfaces and applications is that concurrent provisioning is not allowed, that is sending multiple CSOs in parallel, affecting the same set of subscribers or services, which could result in race-conditions or inconsistencies.

• CAI3G - Synchronous and Asynchronous.

  Primary provisioning interface applicable for any application.

  Support for both synchronous (request and response) and asynchronous (request/response/notification) communication protocols.

  The following URL formats are used for synchronous and asynchronous interfaces respectively:

  • scheme://<IP address or host name>:<port number>/CAI3G1.2/services/CAI3G1.2
  • scheme://<IP address or host name>:<port number>/CAI3G1.2/services/CAI3G1.2/async

  scheme in the URL supports both http and https.

  For generic information about the CAI3G interface, refer to Generic CAI3G Interface 1.2, Reference [3].

  For detailed information about the synchronous CAI3G interface implementation, see CAI3G Implementation, Reference [14].

  For detailed information about the asynchronous CAI3G interface implementation, see Asynchronous CAI3G Interface Specification 1.2, Reference [15].

• CLI - Generic interface primarily used for massive- and profile- provisioning operations. Also applicable for specific OAM operations, such as subscriber repair and replay operations.

  For more information about the CLI interface, refer to Generic CLI Interface Specification, Reference [13].

• Legacy interfaces

  For backwards compatibility, Dynamic Activation provides support for legacy interfaces, typically used for monolithic and layered HLR/AUC provisioning:

  • CAI

    For more information about the CAI interface, see CAI Interface Specification for HLR Components, Reference [11].

  • MML

    For more information about the MML interface, see Layered HLR AUC Provisioning over MML, Reference [12].

3.4   Communication Protocols

Dynamic Activation supports multiple communication protocols depending on which provisioning interface that is used.

Parameters for each interface are configured independently, where the recommendation is to use default settings as much as possible.

Communication protocols supported per interface implementation are listed as follows:

• CAI - Direct Socket (Raw), TELNET, TLS/SSL
• CAI3G - HTTP/SOAP, TLS/SSL
• MML - Direct Socket (Raw), TELNET, SSH
• CLI - Direct Socket (Raw), TELNET, TLS/SSL

For more information about configuration of each independent interface, refer to System Administrators Guide for Native Deployment, Reference [8], or System Administrators Guide for Virtual and Cloud Deployment, Reference [9].

4   Security

Dynamic Activation supports encrypted communication protocols for both external northbound, and southbound interfaces, where choice of protocol varies depending on Northbound Interface implementation, and southbound connector implementation.

Authentication and authorization are supported for all external interfaces, enabling individual access control rules per user.

For more information about security policies, refer to Security and Privacy Management, Reference [7].

4.1   SSL/TLS

Secure Socket Layer (SSL) / Transport Layer Security (TLS) encryption protocol is supported for the following external interfaces:

• CAI3G (port 8181)
• CAI3G (test port 8989)
• CLI (port 8992)
• CAI (port 3301)

Dynamic Activation is pre-configured with a self-signed certificate, which is replaced with a signed certificate.

For more information about configuring SSL/TLS for external interfaces, refer to System Administrators Guide for Native Deployment, Reference [8], or System Administrators Guide for Virtual and Cloud Deployment, Reference [9].

4.2   SSH

Secure Socket Shell (SSH) encryption protocol is supported for the following external interfaces:

• MML (port 8111)

For more information about configuring SSH for external interfaces, refer to System Administrators Guide for Native Deployment, Reference [8], or System Administrators Guide for Virtual and Cloud Deployment, Reference [9].

4.3   Access Control

Access Control of users is administered through GUI, enabling individual authentication roles and authorization rules to be configured for each provisioning client.

For more information about Access Control, see User Guide for Resource Activation, Reference [4].

5   Redundant Setup

Redundant configurations in Dynamic Activation are managed as independent systems, meaning that they are unaware of each other except for synchronization of license counters and configuration data in-between the redundant systems, see User Guide for Resource Activation, Reference [4].

Any load-balancing or fail-over/fail-back mechanism must be implemented on client-side, where each independent Dynamic Activation system is addressed separately, with the corresponding VIP-TRAFFIC-IP address.

5.1   Active-Standby

(1)  Only ACTIVE-STANDBY redundant setup is supported for UDC Data Durability (automatic replay) operation, see Configuration Manual UDC Data Durability, Reference [5].

5.2   Active-Active

Dynamic Activation may be set up in an ACTIVE-ACTIVE configuration, where two (or multiple) Dynamic Activation systems are managing provisioning traffic at the same time, see Figure 2.

In this setup, it is recommended to let each Dynamic Activation system manage separate series/ranges of subscribers, rather than distributing provisioning traffic between the systems in a round-robin fashion. This is especially valid in troubleshooting scenarios, since processing logs are only stored or accessed locally.

In this setup, it is also crucial not to perform concurrent provisioning, that is sending multiple CSOs in parallel, affecting the same set of subscribers or services, which could result in race-conditions or inconsistencies.

If an ACTIVE Dynamic Activation system stops responding, the remaining ACTIVE Dynamic Activation system takes over operation as the serving system.

5.3   Heartbeat Mechanism

The recommended heartbeat mechanism to implement between CAS and Dynamic Activation, is to use a CAI3G LOGIN/LOGOUT request as heartbeat sequence, that is sent with a fixed time interval.

As long as a target node is successfully responding to a heartbeat sequence, it is considered as available.

Preferably the same CAI3G user, as defined for sending provisioning request to the CAI3G interface, is also used for sending heartbeat (LOGIN/LOGOUT) requests.

Example CAI3G LOGIN request and response:

<!-- Login Request -->

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org
/soap/envelope/" xmlns:cai3="http://schemas.ericsson.com/cai3g1.2/">
   <soapenv:Header/>
   <soapenv:Body>
      <cai3:Login>
         <cai3:userId>cai3guser</cai3:userId>
         <cai3:pwd>password</cai3:pwd>
      </cai3:Login>
   </soapenv:Body>
</soapenv:Envelope>

<!-- Login Response -->

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
   <S:Body>
      <LoginResponse xmlns="http://schemas.ericsson.com/cai3g1.2/">
         <sessionId>0b0291ff5b5b4e9786a3ea71ae4b9ef9</sessionId>
         <baseSequenceId>1665323492</baseSequenceId>
      </LoginResponse>
   </S:Body>
</S:Envelope>

Example CAI3G LOGOUT request and response:

<!-- Logout Request -->

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:cai3="http://schemas.ericsson.com/cai3g1.2/">
   <soapenv:Header>
      <cai3:SessionId>0b0291ff5b5b4e9786a3ea71ae4b9ef9</cai3:SessionId>
   </soapenv:Header>
   <soapenv:Body>
      <cai3:Logout>
         <cai3:sessionId>0b0291ff5b5b4e9786a3ea71ae4b9ef9</cai3:sessionId>
      </cai3:Logout>
   </soapenv:Body>
</soapenv:Envelope>

<!-- Logout Response -->

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
 xmlns:cai3g="http://schemas.ericsson.com/cai3g1.2/">
   <S:Header>
      <cai3g:SessionId>0b0291ff5b5b4e9786a3ea71ae4b9ef9</cai3g:SessionId>
   </S:Header>
   <S:Body>
      <LogoutResponse xmlns="http://schemas.ericsson.com/cai3g1.2/"/>
   </S:Body>
</S:Envelope>

5.3.1   Heartbeat Interval, Failure, and Response Time-out

The recommended heartbeat time interval is one minute, or same as the configured response time-out in CAS.

If a target node fails to respond to a heartbeat request within the configured response time-out in CAS, it is considered as unavailable.

To avoid premature failover, the heartbeat mechanism should strictly rely on the defined heartbeat signal. Response time-out derived from any other provisioning request should not initiate a failover, since the response time-out could also be because of pending southbound operations.

5.3.2   Failover and Preemptive Fail-Back

If a target node stops responding to heartbeat signals, a failover should be initiated from CAS, where subsequent CSOs are then sent to the redundant node.

Fail-back is pre-emptive, meaning that in-service operation is secured before initiating fail-back from CAS.

Example of pre-emptive fail-back sequence:

1. Five successful CAI3G LOGIN/LOGOUT heartbeat sequence
2. One successful CAI3G LOGIN/GET/LOGOUT heartbeat sequence

6   VoLTE Auto Provisioning Setup

For VoLTE auto provisioning, Dynamic Activation can receive the auto provisioning notification from CUDB, decide to do or not to do the VoLTE auto provisioning for the attached subscriber, and notify BSS of the result. For detailed information about the setup of Dynamic Activation integration with the CUDB and BSS, refer to VoLTE Provisioning Customer Adaptation Guide, Reference [16].

7   Fault Management

Dynamic Activation provides information about provisioning faults as a direct error response to CSOs (both synchronous and asynchronous requests), and also as alarms or events being sent as SNMP traps to a configured Network Monitoring System (NMS).

This section covers the contents of a direct error response to a CSO.

7.1   Error Codes, Messages, and Details

(1)  Structure corresponding to CAI3G interface. Structure and level of detail may vary, depending on interface.

7.1.1   CAI3G Generic Error Codes and Messages

Errors defined by generic interface implementations and protocols, such as generic CAI3G error codes.

For more information about generic CAI3G error codes, see Generic CAI3G Interface 1.2, Reference [3].

7.1.2   CAI3G Internal Errors and Messages

Errors defined by internal interface-, core- and processing- logic, or derived from external errors.

Example CAI3G Internal Error Message:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:cai3g="http://schemas.ericsson.com/cai3g1.2/">
 <S:Header>
    <cai3g:SessionId>37495e1842d945cfb997526c20a18650</cai3g:SessionId>
 </S:Header>
 <S:Body>
    <ns2:Fault xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:ns3="http://www.w3.org/2003/05/soap-envelope">
       <faultcode>ns2:Client</faultcode>
       <faultstring>This is a client fault</faultstring>
       <detail>
          <Cai3gFault:Cai3gFault xmlns="http://schemas.ericsson.com/cai3g1.2/" 
          xmlns:Cai3gFault="http://schemas.ericsson.com/cai3g1.2/">
             <faultcode>2003</faultcode>
             <faultreason>
                <reasonText>Unsupported data type.</reasonText>
             </faultreason>
             <faultrole>MF</faultrole>
             <details>
                <PGFault:PGFault xmlns="http://schemas.ericsson.com/pg/1.0" 
                xmlns:PGFault="http://schemas.ericsson.com/pg/1.0">
                   <errorcode>1003</errorcode>
                   <errormessage>Unrecognized namespace. No Target associated.
                   </errormessage>
                   <errordetails>There is no Target with the namespace 
                   [{http://schemas.ericsson.com/ma/HSS/}CreatemEPSMultiSC]. - 
                   [Processed by PG Node: CL23-PL-10]</errordetails>
                </PGFault:PGFault>
             </details>
          </Cai3gFault:Cai3gFault>
       </detail>
    </ns2:Fault>
 </S:Body>
</S:Envelope>

For more information about Dynamic Activation Internal Errors, refer to Generic Documents → Interface, Resource Activation → Interface or Resource Configuration → Interface documentation.

7.1.3   CAI3G External Errors and Messages

Errors defined by underlying processing logic or Network Elements, where additional error details may be provided (as-is) from the network element.

Example CAI3G External Error Message:

<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:cai3g="http://schemas.ericsson.com/cai3g1.2/">
 <S:Header>
    <cai3g:SessionId>37495e1842d945cfb997526c20a18650</cai3g:SessionId>
 </S:Header>
 <S:Body>
    <ns2:Fault xmlns:ns2="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:ns3="http://www.w3.org/2003/05/soap-envelope">
       <faultcode>ns2:Server</faultcode>
       <faultstring>This is a server fault</faultstring>
       <detail>
          <Cai3gFault:Cai3gFault xmlns="http://schemas.ericsson.com/cai3g1.2/" 
          xmlns:Cai3gFault="http://schemas.ericsson.com/cai3g1.2/">
             <faultcode>4006</faultcode>
             <faultreason>
                <reasonText>External error.</reasonText>
             </faultreason>
             <faultrole>MF</faultrole>
             <details>
                <EPSFault:EPSFault xmlns="http://schemas.ericsson.com/pg/1.0" 
                xmlns:EPSFault="http://schemas.ericsson.com/pg/1.0">
                   <errorcode>13002</errorcode>
                   <errormessage>SERVICE ALREADY DEFINED</errormessage>
                   <errordetails>IMSI defined and EPS service exists - 
                   [Processed by PG Node: CL23-PL-6]</errordetails>
                </EPSFault:EPSFault>
             </details>
          </Cai3gFault:Cai3gFault>
       </detail>
    </ns2:Fault>
 </S:Body>
</S:Envelope>

For more information about Dynamic Activation Internal Errors, refer to Generic Documents → Interface, Resource Activation → Interface or Resource Configuration → Interface documentation.

7.1.4   CAI3G Subordinate Error Details

Errors defined by external Network Elements are provided as-is and are subject to change without further notice. Specific information about error details originating from any external network element, is provided by the corresponding product documentation.

For more information about Dynamic Activation Internal Errors, refer to Generic Documents → Interface, Resource Activation → Interface or Resource Configuration → Interface documentation.

7.2   Automatic Retries

Dynamic Activation defines a set of error codes that are subject to automatic retries from CAS, meaning that the corresponding CSO may be resent without the need for any further actions.

Such error codes typically indicate interim communication problem, resource limitation, ongoing maintenance operation, or a successful rollback operation, and more, which may be retried after a slight delay.

The following error codes are subject to automatic retry operation from CAS:

(1)  The corresponding DELETE operation must be sent first to remove any inconsistencies because of unsuccessful rollback. For more information about Fault tolerant logic, see Function Specification Resource Activation, Reference [6]

Reference List