Contents

1   Introduction

This document describes the processes of developing VoLTE Provisioning Customizations, by use of the VoLTE service model templates.

1.1   Purpose and Scope

This document is intended for the Customer Adaptation (CA) developers who develop service model Business Logic (BL) with Designer Studio, targeting VoLTE provisioning solution in Data Layered Architecture (DLA).

For information about the VoLTE provisioning solution in DLA, see Solution Description VoLTE, Reference [2].

1.2   Target Groups

The target groups for this document are as follows:

• CA developers
• Solution architects

1.3   Typographic Conventions

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

1.4   Prerequisites

The readers of this document must meet the following prerequisites:

• Knowledge of Dynamic Activation
• Knowledge of Linux
• Knowledge of Java, Eclipse, and Maven.

2   VoLTE Service Model Overview

2.1   VoLTE Decision Service Model

The VoLTE decision service model is a notification layer referring to the capabilities of notification handling, targeting VoLTE auto provisioning in DLA. It provides a single asynchronous CAI3G interface towards Core Network (CN) or any entities. The procedure of VoLTE auto provisioning subscriptions is as follows:

1. Make decisions.
2. Handle concurrent requests for the same subscriber.
3. Map the default service profiles to the execution service model.
4. Notify the results.

The VoLTE decision service model initiates each subscription with the default service profiles as template. For information about the default service profiles, see Section 2.5.

2.2   VoLTE Decision Service Model Design Base Projects

The CA design base project, VOLTEAutoProvisioning_DP-<version>.tar.gz, supports the following features as a template for the VoLTE decision service model. Customers can follow this guide to extend the service model, for full support of the VoLTE auto provisioning criteria.

• Schema validation of the service model request.
• VoLTE auto provisioning criteria validation
• Concurrent request handling
• The default service profiles mapping to the execution service model
• Error code mapping
• Notification result
• Decision service model test code

2.3   VoLTE Execution Service Model

The VoLTE execution service model is an abstract layer referring to the capabilities of the underlying resource features of the product, targeting VoLTE fundamental provisioning in DLA. It provides a single synchronous CAI3G interface towards Business Support System (BSS) or any entities. The VoLTE provisioning subscriptions are as follows:

• IP Multimedia Core Network Subsystem (IMS) subscription in Home Subscriber Server (HSS)
• IMS-based Multimedia Telephony (MMTel) subscription in Multimedia Telephony Application Server (MTAS)
• ENUM subscription in IPWorks
• Evolved Packet System/Long Term Evolution (EPS/LTE) subscription in HSS
• Optional, EPC subscription in Service Aware Policy Controller (SAPC)
• Optional, 2G/3G subscription in the Home Location Register (HLR)
• Optional, VoLTE service data synchronization from HLR to MTAS

The VoLTE execution service model initiates each subscription with basic VoLTE features as template. For information about the basic VoLTE features, see Section 2.5.

The VoLTE execution service model also supports rollback to maintain data consistency in the network.

Figure 1 shows a typical DLA application deployment with VoLTE execution service model on top.

2.4   VoLTE Execution Service Model Design Base Project

The CA design base project, VOLTEAutoProvisioning_EP-<version>.tar.gz, supports the following features as a template for the VoLTE execution service model. Customers can follow this guide to extend the service model, for full support of the VoLTE subscription features.

• Schema validation of the service model request
• Service mapping from service model request to the sub applications request
• Service mapping from HLR to MTAS
• Error handling, including rollback
• Execution service model test code

2.5   VoLTE Basic Services Data Model

The VoLTE execution service model CA design base projects support a composed data model for: IMS, HLR, EPS, SAPC, DNS, and MTAS.

The data model is implemented in CUDB, and the communication with CUDB is handled by:

• JDV IMS
• JDV HLR
• JDV EPS
• JDV SAPC
• JDV DNS
• JDV MTAS

  Note:  

  JDV MTAS is responsible to send MMTel request to MTAS, which stores the service data in CUDB, through HSS-FE, as Sh transparent Data.

  
  

The VoLTE execution service model consolidates the data model for exposure towards BSS and the VoLTE decision service model, for the VoLTE fundamental provisioning.

The following subsections show the basic VoLTE provisioning services data model in each function. For more information on the data model, refer to Solution Description VoLTE, Reference [2].

2.5.1   IMS

2.5.2   MMTel

2.5.3   ENUM

(1)  Provides E164 number translation to SIP URI

2.5.4   EPS

2.5.5   SAPC

2.5.6   HLR

3   Preparing for VoLTE Service Model Development

3.1   Preparing for CA Development Environment

CA service models are developed in Designer Studio. For more information about the configuration of Designer Studio environment, refer to User Guide for Designer Studio, Reference [5].

3.2   VoLTE Decision Service Model Development Workflow

The VoLTE decision service model design base project contains the auto provisioning criteria, and the project is located in the CXP9029435-<version>.tar.gz > ca-deployables-<version>.tar.gz file, in the Dynamic Activation distribution.

To develop the CA for VoLTE decision service model, use the VOLTEAutoProvisioning_DP-<version>.tar.gz project as a design base, and follow these steps:

1. Analyze the service model application. See Section 4.1 for details.
2. Define the service model data model. See Section 4.2 for details.
3. Define the service model access control model. See Section 4.3.
4. Initialize the service model projects. See Section 4.4 for details.
5. Validate the request schema. See Section 4.5.1 for details.
6. Validate the VoLTE auto provisioning criteria. See Section 4.5.2 for details.
7. Handle the concurrent requests. See Section 4.5.3 for details.
8. Map the default service profiles to the execution service model. See Section 4.5.4 for details.
9. Map error codes. See Section 4.5.5 for details.
10. (Optional) Integrate with UPG. See Section 4.5.6.
11. Notify the results. See Section 4.5.7 for details.
12. Build and deploy the projects. See Section 5 for details.
13. Test and verify the projects. See Section 7 for details.

3.3   VoLTE Execution Service Model Development Workflow

The VoLTE execution service model design base project contains the provisioning workflow, and the project is located in the CXP9029435-<version>.tar.gz > ca-deployables-<version>.tar.gz file, in the Dynamic Activation distribution.

To develop the CA for VoLTE execution service model, use the VOLTEAutoProvisioning_EP-<version>.tar.gz project as a design base, and follow these steps:

1. Analyze the service model application. See Section 4.1 for details.
2. Define the service model data model. See Section 4.2 for details.
3. Define the service model access control model. See Section 4.3.
4. Initialize the service model projects. See Section 4.4 for details.
5. Validate the request schema. See Section 4.6.1 for details.
6. Map the service model request to the southbound application requests. See Section 4.6.2 for details.
7. Handle exceptions and ignored errors. See Section 4.6.3 for details.
8. Handle data inconsistency. See Section 4.6.4 for details.
9. Build and deploy the projects. See Section 5 for details.
10. Test and verify the projects. See Section 7 for details.

4   VoLTE Service Model Development

This section holds information about the VoLTE service model development.

4.1   Analyzing the VoLTE Service Model Application

The first step for VoLTE developers is to confirm that the VoLTE requirements are supported, decide what customer-specific VoLTE features that are to be provisioned, and the corresponding data model details.

4.2   Defining the VoLTE Service Model

The procedure of defining a VoLTE service model data model is as follows:

• Customize the northbound interface data model:

  Note:  

  The northbound interface namespace must contain http://schemas.ericsson.com/ma/CA/ as prefix for license control, otherwise the CA application is not deployed. For example, the namespace for VoLTE decision service model is http://schemas.ericsson.com/ma/CA/Service/, and the namespace for VoLTE execution service model is http://schemas.ericsson.com/ma/CA/VoLTESubscriber/.

  VoLTE decision service model interface includes the notification identities IMSI, MSISDN, and so on. Customers can use it directly. Update is required when the sub MO interface needs to be upgraded by new services, demanded by VoLTE requirements.

  VoLTE execution service model interface integrates the complete sub MOs interface, which provides full application services. Customers can use it directly. Update is required when the sub MO interface needs to be upgraded by new services, demanded by VoLTE requirements.

  
  
  1. Find the northbound interface in the CXP9029435-<version>.tar.gz > ca-sourcecode-<version>.tar.gz > JDV-VOLTE-AUTO-P file.
  2. Define the namespace, operations, and other related parameters of the requests in the schema and WSDL files according to Generic CAI3G Interface 1.2, Reference [4].
• Customize the southbound interface data model:
  1. Find VoLTE decision service model southbound interface, which is the northbound interface of the VoLTE execution service model.

     Find DPHelp interface, which is located in the CXP9029435-<version>.tar.gz > ca-sourcecode-<version>.tar.gz > JDV-DPHELP-P file.

  2. Define the namespace, operations, and other related parameters of the requests in the schema and WSDL files according to Generic CAI3G Interface 1.2, Reference [4].

4.3   Defining the VoLTE Service Model Access Control Model

For information on how to define the VoLTE Service Model Access Control Model, refer to User Guide for Resource Activation, Reference [6].

4.4   Initializing the VoLTE Service Model Project

4.4.1   Importing the VoLTE Service Model Design Base Project

CA developers can initialize their own VoLTE project by importing the existing VoLTE service model design base project.

Follow the steps:

1. Start Designer Studio to import the CA southbound interface for decision service model or standard southbound applications interface for execution service model, according to the section Updating Southbound Interface in User Guide for Designer Studio, Reference [5].
2. Click Service Models > Import Service Models.
3. In the Import Service Models dialog, click Choose File and select VOLTEAutoProvisioning_DP-<version>.tar.gz or VOLTEAutoProvisioning_EP-<version>.tar.gz.
4. Click Next and Finish.
5. If customers define the northbound interface for the decision service model or execution service model, import the customized northbound interface by clicking Actions > Update northbound schema.

4.4.2   Renaming the VoLTE Service Model Design Base Project (Optional)

Follow these steps to rename the VoLTE service model design base project:

1. In the Import Service Models dialog, select VoLTE Service Model.
2. Click Actions and select Rename.
3. In the Rename Service Model dialog, fill in name and version, and click Confirm.

4.5   Handling the VoLTE Decision Service Model Business Operations

After VoLTE decision service model receives an XML request, the model executes the inner defined tasks.

The handling steps of an incoming request are as follows:

1. Validate the inbound request. See Section 4.5.1.
2. Handle VoLTE Auto Provisioning criteria. See Section 4.5.2.
3. Handle concurrent requests. See Section 4.5.3.
4. Map default service profiles. See Section 4.5.4.
5. Map error codes. See Section 4.5.5.
6. (Optional) Integrate with UPG. See Section 4.5.6.
7. Notify results. See Section 4.5.7.

4.5.1   Handling CAI3G Data Validation

Designer Studio already supports the CAI3G interface schema validation for the service model.

4.5.2   Handling VoLTE Auto Provisioning Criteria

The current VoLTE auto provisioning criteria is based on the following cases:

• The end user is an EPS user.
• The end user is not doing IMSI changeover.
• The end user is not a VoLTE user.

When VoLTE auto provisioning criteria is changed, the tasks must be redefined in decision service model.

4.5.3   Handling Concurrent Requests

Handling concurrent requests for the decision service model includes: CreateLockService and DeleteLockService:

• The CreateLockService task is created at the beginning of executing the VoLTE decision service model, and the task must be enabled for rollback.
• The DeleteLockService task is created at the end of executing the VoLTE decision service model.

The concurrent request MoType is LockService@http://schemas.ericsson.com/ma/CA/DPHelper.

For details about how to assign parameters and set condition for the CreateLockService task and DeleteLockService tasks, refer to the VoLTE decision service model template in Designer Studio as well as User Guide for Designer Studio, Reference [5].

For details on how to handle concurrent requests during the Create and Delete operations, see the following files in CXP9029435-<version>.tar.gz > ca-sourcecode-<version>.tar.gz > JDV-DPHELP-P:

• com.ericsson.jdv.dphelper.handler.CreateLockServiceLogic
• com.ericsson.jdv.dphelper.handler.DeleteLockSeriveLogic

4.5.4   Mapping Default Service Profiles

In the VoLTE decision service model, define the default VoLTE service profiles before executing the CreateVolteSubscription task to create the VoLTE user.

The IMS service data of the CreateVolteSubscription task is mapped by the GetDefaultVolteProfile task. Other services data is mapped by setting data parameters directly.

GetDefaultVolteProfile request MoType: DefaultVolteProfile@http://schemas.ericsson.com/ma/CA/DPHelper/

CreateVolteSubscription request MoType: VoLTESubscription@http://schemas.ericsson.com/ma/CA/VoLTESubscriber/

For details about how to assign parameters and set conditions for the GetDefaultVolteProfile task and CreateVolteSubscription tasks, see the VoLTE decision service model template in Designer Studio as well as User Guide for Designer Studio, Reference [5].

For details on how to generate the default service profiles during the Get operation, see the following file in CXP9029435-<version>.tar.gz > ca-sourcecode-<version>.tar.gz > JDV-DPHELP-P:

com.ericsson.jdv.dphelper.handler.GetDefaultVolteProfileLogic

The default IMS service profiles named GetResponseDefaultVolteProfile.xml is provided as the template, which is located in CXP9029435-<version>.tar.gz > ca-sourcecode-<version>.tar.gz > JDV-DPHELP-P/JDV-DPHelper-Provisioning/src/main/resources/META-INF/template/.

4.5.5   Mapping Error Codes

User self-defined error function is provided by VoLTE auto provisioning. When the current scenarios do not meet VOLTE auto provisioning criteria, a new CA validation error code is returned.

In VoLTE decision service model template, create an error code task to map the original error code to a new CA validation error code.

The new error code request MoType is ErrorCode@http://schemas.ericsson.com/ma/CA/DPHelper/

For details about how to assign parameters and set conditions for the new error code task, see the VoLTE decision service model template in Designer Studio and User Guide for Designer Studio, Reference [5].

For details on how to create error code requests, see the following file in CXP9029435-<version>.tar.gz > ca-sourcecode-<version>.tar.gz > JDV-DPHELP-P:

• com.ericsson.jdv.dphelper.handler.CreateErrorCodeLogic

4.5.6   Integrating with UPG (Optional)

Customer can first develop MV-NE of UPG to support synchronizing user’s supplementary service. And define a task in the VoLTE decision service model to send the synchronization subscription request to UPG through the MV-NE after the VoLTE execution service model is successfully completed.

For more information on MV-NE development, refer to Customer Adaptation Development Guide for Resource Activation, Reference [3] .

4.5.7   Notifying Results

Customers need to configure the target BSS endpoint in WSDL file to send asynchronous CAI3G notification results to BSS:

• Username: Set the username value in <wsse:UsernameToken>, and the default value is admin.
• Password: Set the password value in <wsse:UsernameToken>, and the default value is admin.
• ReplyTo: Set the ReplyTo value in <wsa:Address>, and the default value is http://business456.example/client1.
• FaultTo: Set the FaultTo value in <wsa:Address>, and the default value is http://business456.example/client1.

<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?>
<Envelope xmlns="http://schemas.xmlsoap.org/soap/envelope"
  xmlns:wsa="http://www.w3.org/2005/08/addressing"
  xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
  xmlns:cai3="http://schemas.ericsson.com/cai3g1.2/"
  xmlns:async="http://schemas.ericsson.com/async/">
    <Header>
        <wsse:Security>
            <wsse:UsernameToken>
                <wsse:Username>sogadm</wsse:Username>
                <wsse:Password>sogadm</wsse:Password>
            </wsse:UsernameToken>
        </wsse:Security>
        <wsa:MessageID>6B29FC40-CA47-1067-B31D-00DD010662DA
        </wsa:MessageID>
        <wsa:ReplyTo>
            <wsa:Address>http://business456.example/client1</wsa:Address>
        </wsa:ReplyTo>
        <wsa:FaultTo>
            <wsa:Address>http://business456.example/client1</wsa:Address>
        </wsa:FaultTo>
        <async:FireTime>2012-05-30T09:00:00</async:FireTime>
        <async:GroupId>IMSI=123456789000</async:GroupId>
    </Header>
    <Body>
        <cai3:Create xmlns:cai3="http://schemas.ericsson.com/cai3g1.2/"
         xmlns:ns="http://schemas.ericsson.com/ma/Service/">
            <cai3:MOType>DefaultProfile@http://schemas.ericsson.com/ma/Service/
            </cai3:MOType>
            <cai3:MOId>
                <ns:serviceType>VOLTE</ns:serviceType>
                <ns:imsi>123456789000</ns:imsi>
            </cai3:MOId>
            <cai3:MOAttributes>
                <ns:CreateDefaultServiceProfile serviceType="VOLTE">
                    <ns:serviceType>VOLTE</ns:serviceType>
                    <ns:imsi>123456789000</ns:imsi>
                </ns:CreateDefaultServiceProfile>
            </cai3:MOAttributes>
        </cai3:Create> 
    </Body>
</Envelope>

If customers need to change the configurations in future, follow these steps to configure the preceding values for the notification NBIA submodule:

1. Set the configuration values for auto-provisioning as the root user:

   $ bootloader.py config set --parameter @AUTO_PROVISIONING_USER@ --value <Username value>

   $ bootloader.py config set --parameter @AUTO_PROVISIONING_PWD@ --value <Password value>

   $ bootloader.py config set --parameter @AUTO_PROVISIONING_REPLY_TO@ --value <ReplyTo value>

   $ bootloader.py config set --parameter @AUTO_PROVISIONING_FAULT_TO@ --value <FaultTo value>

2. Activate the configuration for auto provisioning as the root user:

   $ bootloader.py node activate --host all

A successful response contains the IMSI, while a failed response contains the IMSI and the error information.

4.6   Handling the VoLTE Execution Service Model Business Operations

The VoLTE execution service model defines the fundamental service execution tasks for IMS, MTAS, DNS, EPS, SAPC, and HLR. When the VoLTE execution service model receives an XML request, the service model executes the inner defined tasks.

The handling steps of an incoming request are as follows:

1. Validate the inbound request. See Section 4.6.1.
2. Map the request data. See Section 4.6.2.
3. Handle exceptions. See Section 4.6.3.
4. Handle data inconsistency. See Section 4.6.4.

4.6.1   Handling CAI3G Data Validation

Designer Studio already supports the CAI3G interface schema validation for the service model.

4.6.2   Mapping Request Data

The VoLTE execution service model defines the fundamental service execution tasks for IMS, MTAS, DNS, EPS, SAPC, and HLR.

• In the Create tab, map northbound request data to all tasks.

  The getHLR task is to do the migration of data from HLR to MMTeL (MTAS).

• In the Get tab, map northbound request data to the GetIMSService and GetSAPCService tasks. Other tasks mapping request data such as application identities are from the GetIMSService task response data.

  The getHLR task is to judge whether the user has Volte flag(ics=1). If not, do not return HLR data.

• In the Delete tab, map northbound request data to the GetIMSService and DeleteSAPCService tasks. Other tasks mapping data such as application identities are from the GetIMSService task response data.

  The getHLRService task is to judge whether the user has Volte flag(ics=1). If not, loose it.

• In the Set tab, map request data to all tasks.

For details, see the service model template in VOLTEAutoProvisioning_EP-<version>.tar.gz.

For more information about how to map the VoLTE northbound request to the southbound applications, refer to the section Assign Parameters for a Task in User Guide for Designer Studio, Reference [5].

Note:  

Designer Studio executes tasks in parallel, while VoLTE execution service model solution executes tasks in sequential order and in parallel. For the tasks that are executed in sequential order, configure them first according to the section Define Condition for a Task in User Guide for Designer Studio, Reference [5].

4.6.3   Handling Exceptions

The execution service mode handles the following specific errors:

For the Create operation:

• Configure the error handling for the GetEPSService task. If EPS subscription does not exist, Create an EPS service. If EPS subscription exists, Set the EPS service.
• Configure the error handling for the GetHLRService task. If HLR subscription does not exist, Create an HLR service, if HLR subscription is exists, Set the HLR service.

For the Delete operation, if any service does not exist, configure loose error handling.

4.6.4   Handling Data Inconsistency

During the Create and Set operations on the service model, the requests towards tasks can fail. If one or more task requests for this service model operation fail, previously successful requests are rolled back.

The rollback is done by creating a task. To create a task, select Enable rollback in the Error Handling tab. If rollback is successful, the service model Create and Set operations return the information that the operations failed, but rollback was successful.

During the Delete operations towards the service model, configure loose error handling if data does not exist.

For details on how to handle data inconsistency during the Create/ Set/ Delete operations, see the Create/ Set/ Delete container of the service model template in VOLTEAutoProvisioning_EP-<version>.tar.gz.

5   Building and Deployment

5.1   Deploying DPHelper JDV

Before deploying CA service model, deploy DPHelper JDV first to support CA service model.

5.1.1   Preparing for CA Package

The CA development package is part of the Dynamic Activation software deliverable. Regardless of native deployment or visualized deployment, download the CA Package SW Container CXP9029435.zip from SW Gateway, and extract the 19089-CXP9029435_<version>.tar.gz file to the /var/log/installfiles/ directory.

This package contains the following packages:

• ca-deployables-<version>.tar.gz - Deployable CA Design Based projects
• ca-plugins-<version>.tar.gz - Development tools
• ca-repository-<version>.tar.gz - Maven repository and settings.xml file
• ca-sourcecode-<version>.tar.gz - CA Design Based Projects source code
• ca-dup-convert-tool-<version>.tar.gz - DUP migration tools

5.1.2   Installing DPHelper JDV

To install DPHelper JDV:

1. Extract the ca-deployables-<version>.tar.gz file to a local directory.
2. Upload JDV-DPHELPER-Provisioning-<version>.tar.gz file to the /var/log/installfiles/ directory.
3. Change the owner and the group of the JDV-DPHELPER-Provisioning-<version>.tar.gz file.

   # chown actadm:activation /home/bootloader/repository/JDV-DPHELPER-Provisioning-<version>.tar.gz

4. Copy JDV-DPHELPER-Provisioning-<version>.tar.gz file to the /home/bootloader/repository/ directory.
5. Install the DPHelper JDV as the root user to the dve-application module.

   $ bootloader.py submodule add -n JDV-DPHELPER-Provisioning-<version>.tar.gz -t jdv -p dve-application --host <hostname>

6. Activate the installed JDV as the root user.

   $ bootloader.py node activate --host all

5.1.3   Uninstalling DPHelper JDV

To uninstall DPHelper JDV:

1. Uninstall the DPHelper JDV as the root user to the dve-application module.

   $ bootloader.py submodule delete -n JDV-DPHELPER-Provisioning-<version>.tar.gz -p dve-application --host <hostname>

2. Activate the installed JDV as the root user.

   $ bootloader.py node activate --host all

5.2   Deploying and Undeploying a CA Service Model

For information on how to deploy and undeploy a CA service model, follow the instructions in User Guide for Designer Studio, Reference [5].

For information on how to find VoLTE decision service model, see Section 3.2.

For information on how to find VoLTE execution service model, See Section 3.3.

6   Configuring Dynamic Activation for VoLTE Provisioning

6.1   Configuring NE in Dynamic Activation

Customers need to configure the VoLTE relevant NEs, IMS-HSS, MMTel-MTAS, ENUM-IPWorks, EPS-HSS, SAPC and HLR, in Dynamic Activation. For general information about how to configure NE in Dynamic Activation, refer to User Guide for Resource Activation, Reference [6].

6.2   Configuring Notification Endpoint in CUDB

CUDB sends the VoLTE auto provisioning notification to Dynamic Activation, and CUDB needs to configure the notification endpoint towards Dynamic Activation in the following formats:

• http://<VIP-TRAFFIC-IP>:8080/soap/services/notification
• https://<VIP-TRAFFIC-IP>:8181/soap/services/notification

7   Testing and Provisioning over CAI3G

This section provides some common tools that can be used for testing a customer adaptation.

7.1   Testing Tools for Sending Requests – SoapUI

SoapUI is a cross-platform functional testing solution. With an easy-to-use graphical interface and enterprise-class features, SoapUI allows to easily and rapidly create and execute automated functional, regression, compliance, and load tests. CA developers can use this tool to send CAI3G requests to Dynamic Activation and check the response from Dynamic Activation.

Download and install SoapUI from http://www.soapui.org.

Reference List