Contents

1   Introduction

The information in this document is targeted to System and Network administrators. Use this document after installing the Ericsson Dynamic Activation (EDA) system.

1.1   Purpose and Scope

The purpose of this document is to describe how to configure application services for provisioning features in Dynamic Activation.

1.2   Target Group

The target group for this document is as follows:

• Network Administrator
• System Administrator

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

1.3   Typographic Conventions

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

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

1.4   Prerequisites

To make full use of this document, the following prerequisites must be met:

• Knowledge about the Dynamic Activation product.
• Knowledge regarding the applications that need to be provisioned.

2   General Configuration

Throughout this document, there are instructions on configuration procedures for each application service in Dynamic Activation.

For more generic configuration details, see User Guide for Resource Activation, Reference [3].

It is possible to load predefined default configurations. The predefined default Network Elements (NE) Groups are loaded according to Table 5, Table 6, Table 7 and, Table 8, and routing according to Table 9.

For more information on how to load the predefined configurations, see section Load Default NE Groups and Routing Methods in the System Administrators Guide for Native Deployment, Reference [4].

3   Configuration for HLR/AUC/MNP/M2M Provisioning

To provision HLR/AUC/MNP/M2M, the Centralized User Database (CUDB) and HLR/AUC/MNP/M2M-FEs need to be configured as described in the following subchapters.

3.1   CUDB Configuration

The CUDB is configured by configuring the NE, Network Element Group (NE Group), and Routing. Figure 1 illustrates the CUDB configuration.

Network Element

An NE must be defined and configured for each CUDB node that Dynamic Activation is connected to. For further instructions, see Section 18.

Primary, secondary, and tertiary CUDB NE must be configured as separate NE.

How an NE needs to be configured depends on the purpose of using the NE. For each CUDB, several NEs can be configured with different configuration settings. For example, the time to wait for a response after sending a request differs depending on if Individual Provisioning and Massive Updates are used, or if Massive Search is used. For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Supported protocols are: LDAP

Network Element Group

The configured primary, secondary, and tertiary NEs are grouped in an NE Group configured in Failover mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 18.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE Group from the business logic.

For CUDB UnconditionalRouting method is used.

Configure the routing according to Section 22.

3.2   HLR/AUC/MNP/M2M-FE Configuration

The HLR/AUC/MNP/M2M-FEs are configured by configuring an NE, NE Group, and Routing. Figure 2 illustrates the HLR/AUC/MNP/M2M-FEs configuration.

The following FE deployment scenarios are supported:

• Same FEs provide HLR/AUC/MNP/M2M functionality

  All FEs must be configured using respective NE types and NE groups.

• Dedicated FEs provide HLR/AUC/MNP/M2M functionality respectively

  All FEs must be configured using respective NE types and NE groups.

For more information about the deployment scenario, see Function Specification Layered Machine to Machine, Reference [5].

Network Element

An NE must be defined and configured for each HLR/AUC/MNP/M2M-FE that Dynamic Activation is connected to. For further instructions, see Section 19.

Supported protocols are: TELNET and SSH

Network Element Group

The configured NEs are grouped in an NE Group configured in Round-Robin mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 19.

The same NE can be assigned to several NE Groups. For example, an AUC server that is colocated with HLR can share connections.

Routing

Routing is needed to find an NE Group from the business logic.

When HLR N+1 Redundancy is used, it is configured with the RegularExpressionRouting method.

The RegularExpressionRouting decision for N+1 is based on the parameter PrimaryHLRId. N+1 Redundancy and PrimaryHLRId is not supported when using the MML interface.

The parameter has the following format, <1-15>-<1-32>. The first part identifies the HLR Redundancy Group and the last part identifies a specific HLR Identity in a Redundancy Group.

Each HLR Redundancy Group has a standby HLR-FE node. This means that the NE Type (HLR_RED, and M2M_HLR_RED) must be able to route to every HLR-FE node depending on the parameter PrimaryHLRId.

For more detailed information regarding N+1 redundancy, see Function Specification Layered HLR, Reference [6].

Configure the Routing according to Section 22.

3.3   Create User

Create a client application user according to instructions in Section 24.

3.4   Administration Domain

An Administration Domain must have restrictions for the key parameter Region ID (RID), IMSI, and MSISDN. Restriction rules for other attributes can also be applied.

For more information regarding Administration Domains and restriction rules, see Function Specification Administration of Multi Regions and BSS Capacity, Reference [7].

Note:  

If Mobile Number Portability (MNP) is used, then MSISDN cannot be specified in the Administration Domain.

3.4.1   Enabling of Administration Domain

To enable the Administration Domains function, two actions are required:

• Configure the parameters NEType and RootDN shown in Table 1.
• Enable CUDB Lookup in the Dynamic Activation GUI.

  This is performed in the System > Options tab. Beneath the Administrations of Multi-region property, enable the CUDB Lookup check box. For more information, see User Guide for Resource Activation, Reference [3].

(1)  This parameter is not necessary to change if the Change All RootDN's To: parameter has been set. For more information, see User Guide for Resource Activation, Reference [3]

(2)  The Dynamic Activation configuration must match the CUDB configuration. The RootDn parameter is case-sensitive.

To set and get the NEType and RootDn parameters, use the template files located in /opt/dve/tools/jmxbatchclient/templates/

The jmxbatchclient tool makes it possible to access JMX through the Command-Line Interface. Use this tool to set the RootDn and NEType attribute. It is located in the /opt/dve/tools/jmxbatchclient/ directory.

To execute jmxbatchclient tool issue the following command:

$ sudo -u actadm /opt/dve/tools/jmxbatchclient/jbc-rmi.sh -Aadmin:admin service:jmx:rmi://<PG_JMX_Server_IP>:8995/jndi/rmi://<PG_JMX_Server_IP>:8100/connector /opt/dve/tools/jmxbatchclient/templates/<XML-file with JMX data>

To get RootDn and NEType, use CUDB-lookup-get.xml.

To set the RootDn and NEType, run the jmxbatchclient tool with the modified CUDB-lookup-set.xml.

3.4.2   Create Administration Domains

This is performed in the Access Control > Administration Domains - Add - Step 1/2, General subtab in the Dynamic Activation GUI. For further information, see User Guide for Resource Activation, Reference [3].

A system administrator role with no rules defined is created.

Note:  

Always specify the IMSI and RID parameters. If MNP is not used in the network, MSISDN needs to be specified. If there is no MSISDN rule specified, then there is a performance impact on the provisioning flow. An extra CUDB lookup of IMSI based on MSISDN is performed.

Apart from the IMSI, RID and MSISDN parameters, it is possible to define rules for other parameters as well. The RID parameter is normally set to a single value.

The following attributes are restricted if their corresponding attribute is restricted:

If the IMSI attribute is restricted, then the NIMSI, IMSIS, IMSIALL, and NIMSIALL attributes are also restricted with the same restriction.

If the MSISDN attribute is restricted, then the AMSISDN, MMSISDN, MSISDNS, and MSISDNALL attributes are also restricted with the same restriction.

These rules are valid for each request except for the following - IMSIS, IMSIALL, NIMSIALL, MSISDNS, and MSISDNALL are not checked if it is a CLI request and RID is provided.

The following is an example of an Administration Rules file:

3 Administration Domains
1 IMSI number range and 1 MSISDN number range per Admin Domain
MNP is not used
 
The following is configured in the PG GUI.
Admin Domain 1:
RID=1
IMSI>= 123456700 AND IMSI <= 123456799
MSISDN >= 765432100 AND MSISDN <= 765432199

Admin Domain 2:
RID=2
IMSI>= 123456800 AND IMSI <= 123456899
MSISDN >= 765432200 AND MSISDN <= 765432299
 
Admin Domain 3:
RID=3
IMSI>= 123456900 AND IMSI <= 123456999
MSISDN >= 765432300 AND MSISDN <= 765432399

The Dynamic Activation GUI views from the preceding example are shown in Figure 3, Figure 4, and Figure 5.

3.4.3   Assign the Administration Domain to a User

This is performed in the > Access Control > Users submenu in the Dynamic Activation GUI.

It is not possible to assign an administration domain during the creation of the user. An administration domain is assigned when editing the created user.

A sysadm user must be connected to the sysadm administration domain. A sysadm user is to be connected to all other administration domains that are possible to target in the provisioning requests sent by the user.

3.5   Configuration of Access Capacity

Access capacity can be divided in three parts:

• Max MML connections
• Max CAI3G sessions
• Min HLR sustainable CSOs/sec

The following limits must be considered when configuring the system:

• 160 PG MML connections per payload node

  Note:  

  This is a default limit that can be changed. For information, see System Administrators Guide for Native Deployment, Reference [4].

  
  
• 25000 CAI3G sessions per cluster
• 300 CSOs/second per PL node in the cluster
• 250 CAI connections per port and blade.

3.5.1   MML Connections

The MML connections are defined either when adding or editing a user in the Dynamic Activation GUI. For more information about user configuration, see User Guide for Resource Activation, Reference [3].

If the use of MML connections in the system needs to be limited, then the limit must be configured per user. The MML connections must be divided between the users of the system. The number of users are divided per Administration Domains. The system administrator must track the number of users per Administration Domains.

5 Admin Domains
4 node PG cluster with 2 payload nodes => Max 160*2=320 PG MML 
connections for the system
Each Admin Domain has 10 users, that is in total 50 users
Therefore in this example the MML sessions parameter 
in the Dynamic Activation GUI.
could be set to 3 and there will still be spare MML connections

It is possible to set different values on each user. The system administrator must track total number of MML connections and the current number of MML connections per Administration Domains.

5 Admin Domains
4 node PG cluster with 2 payload nodes => Max 160*2=320 PG MML 
connections for the system
Admin Domain 1 has 1 user
Admin Domain 2 has 2 users
Admin Domain 3 has 3 users
Admin Domain 4 has 4 users
Admin Domain 5 has 5 users
The number of MML connections should be equally spread between 
the Admin Domains.
Therefore in this example the MML sessions parameter 
in the Dynamic Activation GUI.
could be set to the following (there will still be spare MML 
connections):
- the user in Admin Domain 1 is set to 30 MML connection;
- the users in Admin Domain 2 is set to 15 MML connections each;
- the users in Admin Domain 3 is set to 10 MML connections each;
- the users in Admin Domain 4 is set to 7 MML connections each;
- the users in Admin Domain 5 is set to 6 MML connections each.

3.5.2   CAI3G Sessions

The CAI3G sessions are defined either when adding or editing a user in the Dynamic Activation GUI. For more information about user configuration, see User Guide for Resource Activation, Reference [3].

If the use of the CAI3G sessions in the system needs to be limited, then the limit must be configured per user. The CAI3G sessions must be divided between the users of the system. The number of users is divided per Administration Domains. The system administrator must track the number of users per Administration Domains.

5 Admin Domains
4 node PG cluster with 2 payload nodes => Max 25000 CAI3G sessions 
for the system
Each Admin Domain has 10 users, that is in total 50 users.
Therefore in this example the CAI3G sessions parameter 
in the Dynamic Activation GUI.
could be set to 500 per user.

It is possible to set different values on each user. The system administrator must track the total number of CAI3G sessions and the current number of CAI3G sessions per Admin Domain.

5 Admin Domains
4 node PG cluster with 2 payload nodes => Max 25000 CAI3G 
sessions for the system
Admin Domain 1 has 1 user
Admin Domain 2 has 2 users
Admin Domain 3 has 3 users
Admin Domain 4 has 4 users
Admin Domain 5 has 5 users
The number of CAI3G sessions should be equally spread between 
the Admin Domains.
Therefore in this example the CAI3G sessions parameter in the 
GUI could be set to the following (there will still be spare 
MML connections):
- the user in Admin Domain 1 is set to 5000 CAI3G sessions;
- the users in Admin Domain 2 is set to 2500 CAI3G sessions each;
- the users in Admin Domain 3 is set to 1600 CAI3G sessions each;
- the users in Admin Domain 4 is set to 1200 CAI3G sessions each;
- the users in Admin Domain 5 is set to 1000 CAI3G sessions each.

3.5.3   CSOs Rate Limit

The CSO limitation can be set on user level, on Administration Domains level or on both levels. For more information about user and Administration Domains configuration, see User Guide for Resource Activation, Reference [3].

Configuration of CSOs can be done both on user level and Administration Domains level. The users connected to the Administration Domains share the configured number of CSOs for the Administration Domains. Configuration of CSOs on user level can be used to limit or extend the number of CSOs for a specific user.

5 Admin Domains
4 node PG cluster with 2 payload nodes => Max 300*2=600 CSOs/sec 
for the system
So in this example the Max CSOs/sec parameter in the 
Dynamic Activation GUI for each administration domain should be 
set to 120.
Each user should be connected to an administration domain.

5 Admin Domains
4 node PG cluster with 2 payload nodes => Max 300*2=600 CSOs/sec 
for the system
Each Admin Domain has 3 users with this divion of CSOs.
User 1 should have 5 CSOs/sec
User 2 should have 10 CSO/sec
User 3 should have the rest (105 CSOs/sec) for the Admin Domain.
This means that the following should be configured in the PG:
- the Max CSOs/sec parameter in the Dynamic Activation GUI.for 
each administration 
domain should be set to 120 CSOs;
- the Max CSOs/sec parameter in the Dynamic Activation GUI 
for user 1 should be 
set to 5 CSOs;
- the Max CSOs/sec parameter in the Dynamic Activation GUI 
for user 2 should be 
set to 10 CSOs.
Note that it is not necessary to set the parameter for user 3.
Each user should be connected to an administration domain.

3.6   Blocking CUDB for Backup

To ensure consistency during CUDB backup, certain provisioning operation towards CUDB needs to be blocked. For detailed information, see Section 25.

3.7   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for HLR/AUC/MNP/M2M provisioning.

• HLR-Subscriber
  • AUTHDMAND
  • DisabledPrintoutSuds
  • MaxRetries
  • RootDN
  • HLRNotificationPendBlock
  • HLRNotificationNumberOfRetries
  • HLRNotificationRetryFactor
  • HLRNotificationWaitTime
  • HLRNotificationTimeout
  • NPOwnNetworkPrefix
• HLR-Massive
  • DisabledPrintoutSuds
  • MaxParallelRequests
  • MaxRetries
  • RootDN
  • HLRNotificationPendBlock
  • HLRNotificationNumberOfRetries
  • HLRNotificationRetryFactor
  • HLRNotificationWaitTime
  • HLRNotificationTimeout
• HLR-Profile, HLR-Service-Associated-Data
  • MaxRetries
  • RootDN
• AUC-Subscriber
  • CSPSMAND
  • MaxRetries
  • RootDN
• AUC-Massive
  • MaxParallelRequests
  • MaxRetries
  • RootDN
• MNP
  • MaxParallelRequests
  • MaxRetries
  • RootDN
• M2M, M2M-Service-Profile
  • MaxParallelRequests
  • MaxRetries
  • RootDN

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

Note:  

Root DN is always configured to dc=operator,dc=com by default and must be changed to a value that matches the configured Root DN value in CUDB. The RootDn parameter is case-sensitive.

The Root DN value can either be set individual per Activation Logic target component or set on all Activation Logic target components by use of the Change All RootDN's To: parameter, see User Guide for Resource Activation, Reference [3].

3.8   Configuration for Massive Change Operation

The massive change operation distributes multi Notify Subscriber Data Change (NSDC) notifications to different HLR-FE nodes, the result triggers overall Core Network updates. When many NSDC notifications are sent to a specific HLR-FE, the network is affected.

If multiple HLR-FE nodes are deployed in the network of the operator and the massive change CLI command is used, it is recommended to do the following steps:

1. Define Network Element Groups in PG with these HLR-FE nodes.
2. Use a load-distribution strategy (such as Round-Robin) for Network Element Groups to distribute the notification loads towards HLR-FE nodes.

The parameter MaxParallelRequests also affects the massive change operation to specify how many subscribers in PG are updated in parallel.

3.9   Configuration for CAI3G Corresponding to MML Family

The CAI3G corresponding to MML family interface is by default disabled. It is possible to enable it in the Dynamic Activation GUI.

To enable the CAI3G corresponding to MML family interface, see chapter Activation Logic Control > Options in User Guide for Resource Activation, Reference [3].

4   Configuration for HSS Provisioning

To provision HSS, the CUDB and HSS-FEs need to be configured as described in the following subchapters.

4.1   Monolithic HSS/ISM Configuration

Monolithic HSS/ISM is configured by an NE or NE Group, NE routing, and Activation Logics property.

Network Element

An NE must be defined and configured for each HSS/ISM node that Dynamic Activation is connected to.

NE configuration is performed in the Network Elements > Network Elements submenu. Select LDAP as Protocol.

For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Routing

Routing is needed to find an NE from the business logic.

For HSS/ISM, the routing method RegularExpressionRouting and UnconditionalRouting are used according to the deployment.

Configure the routing according to Section 22.

4.2   Layered HSS Provisioning

4.2.1   CUDB Configuration

The CUDB NE is configured by configuring an NE, NE Group, and Routing. Figure 7 illustrates the CUDB configuration.

Network Element

An NE must be defined and configured for each CUDB node that Dynamic Activation is connected to. For further instructions, see Section 18.

Primary, secondary, and tertiary CUDB node must be configured as separate NE.

How an NE needs to be configured depends on the purpose of using the NE. For each CUDB, several NEs can be configured with different configuration settings. For example, the time to wait for a response after sending a request differs depending on if Individual Provisioning and Massive Updates are used, or if Massive Search is used. For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Supported protocols are: LDAP

Network Element Group

The configured primary, secondary, and tertiary NEs are grouped in an NE Group configured in Failover mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 18.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE Group from the business logic.

For CUDB UnconditionalRouting method is used.

Configure the Routing according to Section 22.

4.2.2   HSS Provisioning Notification Configuration

The HSS-FEs are configured by configuring an NE, NE Group, and Routing. Figure 8 illustrates HSS-FE configurations.

Network Element

An NE must be defined and configured for each HSS-FE that Dynamic Activation is connected to. For further instructions, see Section 20.

Supported protocols are: ProvisioningNotification

Network Element Group

The configured NEs are grouped in an NE Group configured in Round-Robin mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 20.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE Group from the business logic.

Configure the Routing according to Section 22.

4.2.3   Blocking CUDB for Backup

To ensure consistency during backup, certain provisioning towards CUDB needs to be blocked. For detailed information, see Section 25.

4.3   Creating User

Create a client application user according to instructions in Section 24.

4.4   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for HSS provisioning.

• IMS
  • ExMaxNumberOfContacts
  • ExAssociationId
  • ExValidation
  • RootDN
  • AllowSipUriWithoutDomain
• EPS-Massive
  • MaxParallelRequests
  • MaxRetries
  • RootDN
• EPS
  • ExARD
  • RootDN
• AVG
  • RootDN

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

Note:  

Root DN is always configured to dc=operator,dc=com by default and must be changed to a value that matches the configured Root DN value in CUDB. The RootDn parameter is case-sensitive.

The Root DN value can either be set individual per Activation Logic target component or set on all Activation Logic target components by use of the Change All RootDN's To: parameter, see User Guide for Resource Activation, Reference [3]

5   Configuration for ECAS Provisioning

5.1   ECAS Configuration

Monolithic ECAS is configured by an NE or NE Group, NE routing, and Activation Logics property.

Network Element

An NE must be defined and configured for each ECAS node that Dynamic Activation is connected to.

NE configuration is performed in the Network Elements > Network Elements submenu. Select HTTP as Protocol.

For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Routing

Routing is needed to find an NE from the business logic.

For ECAS, the routing method RegularExpressionRouting and UnconditionalRouting are used according to the deployment.

Configure the routing according to Section 22.

5.2   Creating User

Create a client application user according to instructions in Section 24.

5.3   Activation Logics Properties

This section contains the configuration for setting the ECAS command.

• IssuerDN
• SubjectDN
• EntityProfile
• CertProfile
• CertPEMFormat
• ProvisioningUri

For detailed information about each property in the preceding list and how to change the configuration data, refer to User Guide for Resource Activation, Reference [3].

6   Configuration for Wi-Fi Calling

6.1   Wi-Fi Calling Configuration

Wi-Fi Calling configuration consists of the following NEs or NE groups, routing, and activation logics property configuration:

• Monolithic HSS/ISM configuration, see Section 4.1
• IPWorks/AAA (NSD) configuration, see Section 9.1
• ECAS configuration, see Section 5.1

6.2   Creating User

Create a client application user according to instructions in Section 24.

6.3   Activation Logics Properties

The following list shows the required Wi-Fi Calling activation logics configuration:

• IPWorks AAA (NSD) configuration, see Section 9.1
• Monolithic HSS/ISM configuration, see Section 4.1
• ECAS configuration, see Section 5.1

The following list contains the Configuration Data of VoWifi activation logic:

• HSSSubscriberFormat
• GenericEricssonNonSIMSolution
• RevokeCertificateByUserName

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

6.4   IPWorks AAACluster Fault Management

The AAACluster provisioning aims to provision the same user subscription data in two separate AAA SS servers. The cluster logic sends AAA commands to two nodes defined in AAA groups in sequence and processes the two AAA nodes provisioning by specific cluster strategy. For details, refer to Solution Description Wi-Fi Calling, Reference [14].

6.4.1   Error Log

Once the request sent to the second AAA NE fails, the system logs the request into the error log file. Only the Create, Set, and Delete operations can be logged.

1. The error log file is located in the following path on each PG NGN node.

   /usr/local/pgngn/logs/failedrequests/aaa/

   When the log file size is greater than 20MB, the file is renamed as follows, so that the system can continue to log the request into the file:

   failedrequests.log:
   failedrequests.log.0
   failedrequests.log.1
   …
   

2. Run the following command on the first VM instance to consolidate the error commands into one file.

   $ /opt/dve/tools/nonsim/consolidateAAAErrorCommand.sh -c

3. Run the following command to clear error logs on the first VM instance and alarms are auto ceased.

   $ /opt/dve/tools/nonsim/consolidateAAAErrorCommand.sh -d

   Do you want to clear all error logs for all node. Please enter 'yes/no': yes

6.4.2   Second AAA Inconsistent Data Handling

Once the error logs are generated during the provisioning process, a specific alarm is raised to OSS. For details on the alarm, refer to Event and Alarm Handling, Reference [13].

The following process must be performed to cope with the data inconsistency in the second AAA NE. It is suggested that the process is followed in the network spare time since it affects traffic.

1. Disable the AAA provisioning by setting MaintenanceMode to YES in AAA JDV logics.
2. Run the consolidation script to fetch all failed AAA commands in a file, see Section 6.4.1. Once the error logs are successfully consolidated, the original error logs must be removed and the alarm is automatically ceased.
3. Run the AAA commands in bulk on the second AAA server and ensure the data consistency is fixed successfully. For more information, refer to IPWorks documentation.
4. Enable the AAA provisioning by setting MaintenanceMode to NO in AAA JDV logics.

7   Configuration for EIR Provisioning

To provision EIR, the CUDB needs to be configured as described in the following subchapters.

7.1   CUDB Configuration

The CUDB NE is configured by configuring an NE, NE Group, and Routing. Figure 10 illustrates the CUDB configuration.

Network Element

An NE must be defined and configured for each CUDB node that Dynamic Activation is connected to. For further instructions, see Section 18.

Primary, secondary, and tertiary CUDB node must be configured as separate Network Elements (NE).

How an NE needs to be configured depends on the purpose of using the NE. For each CUDB, several NEs can be configured with different configuration settings. For example, the time to wait for a response after sending a request differs depending on if Individual Provisioning and Massive Updates are used, or if Massive Search is used. For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Supported protocols are: LDAP

Network Element Group

The configured primary, secondary, and tertiary NEs are grouped in an NE Group configured in Failover mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 18.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE Group from the business logic.

For CUDB UnconditionalRouting method is used.

Configure the Routing according to Section 22.

7.2   Create User

Create a client application user according to instructions in Section 24.

7.3   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for EIR provisioning.

• CentralImeiDb
• NominationList
• RootDN

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

Note:  

Root DN is always configured to dc=operator,dc=com by default and must be changed to a value that matches the configured Root DN value in CUDB. The RootDn parameter is case-sensitive.

The Root DN value can either be set individual per Activation Logic target component or set on all Activation Logic target components by use of the Change All RootDN's To: parameter, see User Guide for Resource Activation, Reference [3]

8   Configuration for SAPC Provisioning

To provision SAPC, the CUDB or monolithic NE needs to be configured as described in the following subchapters.

8.1   Layered SAPC Provisioning Configuration

8.1.1   CUDB Configuration

The CUDB NE is configured by configuring an NE, NE Group, and Routing. Figure 11 illustrates the CUDB configuration.

Network Element

An NE must be defined and configured for each CUDB node that Dynamic Activation is connected to. For further instructions, see Section 18.

Primary, secondary, and tertiary CUDB node must be configured as separate Network Elements (NE).

Supported protocols are: LDAP

Network Element Group

The configured primary, secondary, and tertiary NEs are grouped in an NE Group configured in Failover mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 18.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE Group from the business logic.

For CUDB UnconditionalRouting method is used.

Configure the Routing according to Section 22.

8.1.2   SAPC-FE Configuration

The SAPC-FE are configured by configuring an NE, NE Group and Routing. Figure 12 illustrates the SAPC-FE configuration.

Network Element

An NE must be defined and configured for SAPC node that Dynamic Activation is connected to.

Primary and secondary SAPC node must be configured as separate Network Elements (NE).

NE configuration is performed in the Network Elements > Network Elements sub-menu. Select CF-HTTP in Protocol.

Note:  

When configuring this protocol parameter, HeartBeat Uri must be set to /profiles/online-charging-system, and HeartBeat accepted response code is 200. For more information about how to generate the Key store file, refer to section Certificates Management in Security Management Guide.

For more information about this configuration, refer to User Guide for Resource Activation, Reference [3].

Network Element Group

The configured NEs are grouped in an NE Group configured in Round-Robin mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 21.

The same NE can be assigned to several NE Groups.

Network Element

Routing is needed to find an NE from the business logic.

For SAPC-FE, the routing method UnconditionalRouting is used.

Configure the routing according to Section 22.

8.1.3   Create User

Create a client application user according to instructions in Section 24.

8.1.4   Blocking CUDB for Backup

To ensure consistency during backup, certain provisioning towards CUDB needs to be blocked. For detailed information, see Section 25.

8.1.5   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for layered SAPC provisioning.

The parameters for SAPC-Layered-Resource-Provisioning are as follows:

• MaxRetries
• RootDN

The parameter for SAPC-Service-Provisioning is as follows:

• FamilyProvisionCUDBFirst

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

Note:  

Root DN is always configured to dc=operator,dc=com by default and must be changed to a value that matches the configured Root DN value in CUDB. The RootDn parameter is case-sensitive.

The Root DN value can either be set individual per Activation Logic target component or set on all Activation Logic target components by use of the Change All RootDN's To: parameter, see User Guide for Resource Activation, Reference [3]

8.2   Monolithic SAPC Provisioning Configuration

8.2.1   NE Configuration

The monolithic SAPC NE is configured by configuring an NE and Routing. Figure 13 illustrates the NE configuration.

Network Element

An NE must be defined and configured for monolithic SAPC node that Dynamic Activation is connected to.

NE configuration is performed in the Network Elements > Network Elements submenu. Select a protocol according to the following table in Protocol.

(1)  When configuring this protocol parameter, HeartBeat Uri must be set to /profiles/online-charging-system, and HeartBeat accepted response code is 200. For more information about how to generate the Key store file, refer to section Certificates Management in Security Management Guide.

For more information about this configuration, refer to User Guide for Resource Activation, Reference [3].

Routing

Routing is needed to find an NE from the business logic.

The routing method UnconditionalRouting must be used according to the deployment.

Configure the Routing according to Section 22.

8.2.2   Create User

Create a client application user according to instructions in Section 24.

8.2.3   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for monolithic SAPC provisioning.

For monolithic cSAPC 16B, the parameter for CSAPC-Monolithic-Resource-Provisioning is as follows:

• RootDN

Note:  

The default value of RootDN is applicationName=EPC-EpcNode,nodeName=jambala and must be changed to a value that matches the configured Root DN value. The RootDn parameter is case-sensitive.

For monolithic SAPC 17A, the parameter for SAPC-Monolithic-Resource-Provisioning is as follows:

• OverwritingExistedSubscriber

Note:  

The default value of OverwritingExistedSubscriber is NO.

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

9   Configuration for IPWorks/AAA Provisioning

To provision IPWorks/AAA, the CUDB needs to be configured as described in the following subchapters.

9.1   Monolithic IPWorks/AAA (NSD) Configuration

Monolithic IPWorks AAA (NSD) is configured by an NE or NE Group, NE routing, and Activation Logics property.

Network Element

An NE must be defined and configured for each IPWorks/AAA (NSD) node that Dynamic Activation is connected to.

NE configuration is performed in the Network Elements > Network Elements submenu. Select SSH as Protocol.

For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Network Element Group

The configured two IPWorks AAA NEs are grouped in an NE group configured in Failover mode or AAACluster mode. The NE group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group. For details, see Table 9.

For Failover NE group configuration, the AAA activation logics configuration data must be set properly. For more information, refer to User Guide for Resource Activation, Reference [3].

Routing

Routing is needed to find an NE from the business logic.

For IPWorks/AAA (NSD), the routing method RegularExpressionRouting and UnconditionalRouting are used according to the deployment.

Configure the routing according to Section 22.

9.2   Layered IPWorks/AAA (NSD) Configuration

Layered IPWorks AAA (NSD) is configured by an NE or NE Group, NE routing, and Activation Logics property.

9.2.1   CUDB Configuration

The CUDB NE is configured by configuring an NE, NE Group, and Routing. Figure 16 illustrates the CUDB configuration.

Network Element

An NE must be defined and configured for each CUDB node that Dynamic Activation is connected to. For further instructions, see Section 18.

Primary, secondary, and tertiary CUDB nodes must be configured as separate NEs.

How an NE needs to be configured depends on the purpose of using the NE. For each CUDB, several NEs can be configured with different configuration settings. For example, the time to wait for a response after sending a request differs depending on if Individual Provisioning and Massive Updates are used, or if Massive Search is used.

For more information about this configuration, see User Guide for Resource Activation, Reference [3]

Supported protocols are: LDAP

9.2.2   Layered IPWorks AAA (NSD) Notification Configuration

The AAANSD-FEs are configured by configuring an NE, NE Group and Routing. Figure 17 illustrates AAANSD-FE configurations.

Network Element

An NE must be defined and configured for each AAANSD-FE that Dynamic Activation is connected to. For further instructions, see Section 20.

Supported protocols are: ssh

Network Element Group

The configured NEs are grouped in an NE group configured in Active-Active mode. The NE group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group. For details, see Section 20.

The same NE can be assigned to several NE Groups.

All the NEs in the NE group receives the request.

Routing

Routing is needed to find an NE from the business logic.

Configure the routing according to Section 22.

9.3   Layered IPWorks/AAA Configuration

The CUDB NE is configured by configuring an NE, NE Group, and Routing. Figure 18 illustrates the CUDB configuration.

Network Element

An NE must be defined and configured for each CUDB node that Dynamic Activation is connected to. For further instructions, see Section 18.

Primary, secondary, and tertiary CUDB node must be configured as separate Network Elements (NE).

How an NE needs to be configured depends on the purpose of using the NE. For each CUDB, several NEs can be configured with different configuration settings. For example, the time to wait for a response after sending a request differs depending on if Individual Provisioning and Massive Updates are used, or if Massive Search is used. For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Supported protocols are: LDAP

Network Element Group

The configured primary, secondary, and tertiary NEs are grouped in an NE Group configured in Failover mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 18.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE Group from the business logic.

For CUDB UnconditionalRouting method is used.

Configure the Routing according to Section 22.

9.4   Create User

Create a client application user according to instructions in Section 24.

9.5   Activation Logic Properties

9.5.1   Monolithic IPWorks AAA (NSD) Properties

This section contains the configuration for setting the AAA command retry function and AAA maintenance status.

AAA command retry function: AAA JDV logics can retry certain commands based on AAA error messages, retry times, and retry interval. Both the single AAA and AAA group configurations are applicable for this function.

The following configuration data properties are applicable:

• MaxRetry
• RetryErrorMessage
• MaintenanceMode
• RetryInterval

For detailed information about each property in the preceding list and how to change the configuration data, refer to User Guide for Resource Activation, Reference [3].

9.5.2   Layered IPWorks AAA (NSD) Properties

This section contains all the Configuration Data properties that are used for Layered IPWorks AAA (NSD) provisioning.

The following configuration data property is applicable:

• RootDN

Note:  

Root DN is always configured to  dc=operator,dc=com by default and must be changed to a value that matches the configured Root DN value in CUDB. The  RootDn parameter is case-sensitive. 

The Root DN value can either be set individual per Activation Logic target component or set on all Activation Logic target components by use of the  Change All RootDN's To: parameter. For details, refer to User Guide for Resource Activation, Reference [3].

9.5.3   Layered IPWorks AAA Properties

This section contains all the Configuration Data properties that are used for IPWorks/AAA provisioning.

The following configuration data property is applicable:

• RootDN

Note:  

Root DN is always configured to  dc=operator,dc=com by default and must be changed to a value that matches the configured Root DN value in CUDB. The  RootDn parameter is case-sensitive. 

The Root DN value can either be set individual per Activation Logic target component or set on all Activation Logic target components by use of the  Change All RootDN's To: parameter. For details, refer to User Guide for Resource Activation, Reference [3].

For detailed information about each property in the preceding list and how to change the configuration data, refer to User Guide for Resource Activation, Reference [3].

9.6   Layered IPWorks/AAA AVP Configuration

The configurable file AVPs.xml includes two kinds of AVPs that are supported, checklist and replylist. Each AVP has attribute name and type. Four types of AVP are supported: string, integer, ipaddr (IPv4), and IPv6.

The following is an example of AVPs.xml with adding new AVP Login-IP-Host. It is possible to modify the AVP names and also to delete AVPs. To delete an AVP, remove the specific AVP row.

<?xml version="1.0" encoding="UTF-8"?>
<AVPs>
  <checklist>
    <AVP name="User-Name" type="string" />
    <AVP name="User-Password" type="string" />
    <AVP name="CHAP-Password" type="string" />
    <AVP name="NAS-IP-Address" type="string" />
    <AVP name="Login-IP-Host" type="ipaddr" />
  </checklist> 
  <replylist>
   <AVP name="User-Name" type="string" />
   <AVP name="Service-Type" type="integer" />
   <AVP name="Framed-Protocol" type="integer" />
   <AVP name="Framed-IP-Address" type="ipaddr" />
   <AVP name="Framed-IP-Netmask" type="ipaddr" />
  </replylist>
</AVPs>

9.6.1   AVP Loading

Note:  

The following steps must be performed on any of the SC nodes.

The following step-list describes the procedure on how to load the AVPs:

1. Create a temp directory, for example:

   $ mkdir -p /tmp/AVP

   $ cd /tmp/AVP

2. Transfer the <Softare_Package>.tar.gz file, to the newly created /tmp/AVP directory.

   For example:

   $ cp /var/log/installfiles/<Softare_Package>.tar.gz /tmp/AVP/

3. Create a temp directory in /tmp/AVP/:

   $ mkdir -p temp

4. Untar the <Softare_Package>.tar.gz file:

   $ tar -xvf <Softare_Package>.tar.gz -C temp

5. Go to the /temp/var/log/installfiles/<Prod_Number>-<Version> directory:

   $ cd temp/var/log/installfiles<Prod_Number>-<Version>

6. Create a pg directory:

   $ mkdir -p pg

7. Untar the CXP9026216-<version>.tar.gz file:

   $ tar -xvf CXP9026216-<version>.tar.gz -C pg

8. Go to the /pg/home/bootloader/repository/ directory:

   $ cd pg/home/bootloader/repository/

9. Create a jdv directory:

   $ mkdir -p jdv

10. Untar the jdv-udc-assembly-<version>.tar.gz file:

    $ tar -xvf jdv-udc-assembly-<version>.tar.gz -C jdv

    All JDVs are now found in the jdv directory.

11. Go to the jdv directory:

    $ cd jdv

12. Unpack the JDV-AAA-Provisioning-<version>.jar file:

    $ jar -xvf JDV-AAA-Provisioning-<version>.jar

13. Copy the configurable files to a suitable catalog structure in /home/bootloader/CArepository/<JDV_Dir>.

    For example:

    $ mkdir -p /home/bootloader/CArepository/JDV_AAA_Provisioning/com/ericsson/dve/jdv/aaa/common

    $ cp ./META-INF/AVPs.xml /home/bootloader/CArepository/JDV_AAA_Provisioning/com/ericsson/dve/jdv/aaa/common

14. Modify the AVPs.xml file.

    Perform the modification as described in Section 9.6.

    Go to:

    $ cd /home/bootloader/CArepository/JDV_AAA_Provisioning/com/ericsson/dve/jdv/aaa/common

    Edit the file:

    $ vi AVPs.xml

15. Go to the /home/bootloader/repository/ directory:

    $ cd /home/bootloader/repository/

16. Untar the jdv-ca-properties-assembly-<version>.tar.gz file:

    $ tar -xvf jdv-ca-properties-assembly-<version>.tar.gz -C ../CArepository

17. Go to the /home/bootloader/CArepository/ directory:

    $ cd /home/bootloader/CArepository/

18. Rename the ca-template.properties file to ca.properties.

    For example:

    $ mv ca-template.properties ca.properties

19. Edit the ca.properties file so that it points to the directory with the new file example.

    Change the following line:

    $com.ericsson.dve.jdv.aaa.common.AVPs.xml =

    To:

    com.ericsson.dve.jdv.aaa.common.AVPs.xml = file:${ca.repository}/JDV_AAA_Provisioning/com/ericsson/dve/jdv/aaa/common/AVPs.xml

20. Create a tar.gz file, for example MY_NEW_CA-<version>.tar.gz, including the ca.properties file and the newly modified AVPs.xml file.

    For example:

    $ tar cvfz MY_NEW_CA-<version>.tar.gz ca.properties JDV_AAA_Provisioning/

    Note:  

    The naming of the new tar.gz file, must have the following format: <Name>-<version>.tar.gz

    
    
21. Change the owner and the group of the new tar.gz files.

    # chown actadm:activation /home/bootloader/CArepository/MY_NEW_CA-<version>.tar.gz

22. Add the new tar.gz file as a submodule to the dve-application module.

    For example:

    $ bootloader.py submodule add -n MY_NEW_CA-<version>.tar.gz -t caConfig -p dve-application --host <hostname>

    <hostname> is the hostname of the PL node to which the submodule is being added.

23. From an SC node, run the following command for all affected PL nodes, one by one, to activate the submodule.
    Warning!

    Wait for each PL node to be activated before starting with the next one, otherwise traffic disturbances occur. Do not run all.

    $ bootloader.py node activate --host <hostname>

    <hostname> is the hostname of the PL node to which the submodule is being activated.

10   Configuration for DAE Provisioning

To provision DAE, the CUDB and DAE-FEs need to be configured as described in the following subchapters.

10.1   CUDB Configuration

The CUDB NE is configured by configuring an NE, NE Group, and Routing. Figure 19 illustrates the CUDB configuration.

Network Element

An NE must be defined and configured for each CUDB node that Dynamic Activation is connected to. For further instructions, see Section 18.

Primary, secondary, and tertiary CUDB node must be configured as separate Network Elements (NE).

Supported protocols are: LDAP

Network Element Group

The configured primary, secondary, and tertiary NEs are grouped in an NE Group configured in Failover mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 18.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE Group from the business logic.

For CUDB UnconditionalRouting method is used.

Configure the Routing according to Section 22.

10.2   DAE Provisioning Notification Configuration

The DAE-FEs are configured by configuring an NE, NE Group, and Routing. Figure 20 illustrates a DAE-FE configuration.

Network Element

An NE must be defined and configured for each DAE-FE that Dynamic Activation is connected to. For further instructions, see Section 20.

Network Element Group

The configured NEs are grouped in an NE Group configured in Round-Robin mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 20.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE Group from the business logic.

Configure the Routing according to Section 22.

10.3   Create User

Create a user according to instructions in Section 24.

10.4   Blocking CUDB for Backup

To ensure consistency during backup, certain provisioning towards CUDB needs to be blocked. For detailed information, see Section 25.

10.5   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for DAE provisioning.

• RootDN

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

Note:  

Root DN is always configured to dc=operator,dc=com by default and must be changed to a value that matches the configured Root DN value in CUDB. The RootDn parameter is case-sensitive.

The Root DN value can either be set individual per Activation Logic target component or set on all Activation Logic target components by use of the Change All RootDN's To: parameter, see User Guide for Resource Activation, Reference [3]

11   Configuration for MTAS Provisioning

This section describes the configuration needed to enable provisioning of the following:

• Multimedia Telephony (MMTel) services in Multimedia Telephony Application Server (MTAS)
• SIP Trunking services in MTAS

For more information about the related provisioning operations, refer to MTAS Provisioning over CAI3G, Reference [9].

11.1   MTAS Configuration

The MTAS NE is configured by configuring an NE, NE Group, and routing. Figure 21 illustrates the MTAS configuration.

Network Element

An NE must be defined and configured for each MTAS or MTAS_SIPTrunking node that Dynamic Activation is connected to. For further instructions, see Section 21.

For MTAS NE, the request traffic URL, session control URL,are defined as http://<ip>:<port>/axis2/services. And the heartbeat URL is defined as http://<ip>:<port>/axis2/services/CAI3G?wsdl.

For MTAS_SIPTrunking NE, the request traffic URL, session control URL, and heartbeat URL are defined as http://<ip>:<port>/mtasstas

Table 3 lists the Network Element advanced parameter version to be set for each corresponding version of MTAS node. If the version parameter is empty, it uses the 17B version by default.

Primary, secondary, and tertiary MTAS node must be configured as separate NEs. For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Supported protocols are: CAI3G

Network Element Group

The configured NEs are grouped in an NE Group configured in Round-Robin mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 21.

Note:  

This is only applicable if UnconditionalRouting is used as routing method, not if RegularExpressionRouting is used.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE group from the business logic.

For MTAS and MTAS_SIPTrunking, the routing methods UnconditionalRouting and RegularExpressionRouting are used.

Configure the routing according to Section 22.

11.2   Create User

Create a user according to instructions in Section 24.

11.3   Activation Logic Properties

This section contains the Configuration Data properties that are configurable for MTAS provisioning.

• ErrorCodeMapping

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

12   Configuration for BCE Provisioning

To provision Business Communication Enabler (BCE), configure the BCE as described in the following subchapters.

For more information about the related provisioning operations, refer to BCE Provisioning over CAI3G, Reference [11].

12.1   BCE Configuration

The BCE NE is configured by configuring an NE, NE Group, and routing. Figure 22 illustrates the BCE configuration.

Network Element

Define and configure an NE for each BCE node that Dynamic Activation is connected to. For further instructions, see Section 21.

NE configuration is performed in the Network Elements >Network Elements submenu. Select HTTP as Protocol.

Configure the Content Encoding and Authentication Method parameters as none, otherwise the link can be down.

Select Customized Heartbeat to perform HTTP post heartbeat, and configure HTTP Post Body as follows:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:up="http://schemas.ericsson.com/edible/up/"><soapenv:Header /><soapenv:Body><up:getAllServiceProviders /></soapenv:Body></soapenv:Envelope>

For more information about this configuration, refer to User Guide for Resource Activation, Reference [3].

Supported protocols are: HTTP

Cluster Strategy

A cluster strategy instance is needed to be created. The strategy type is set to ActiveActive.

Assign the configured NEs to the cluster strategy instance. For instructions, refer to see User Guide for Resource Activation, Reference [3].

Routing

Routing is used to find an NE Group from the Business Logic.

BCE NE supports both the unconditional routing and regular expression routing.

Configure the Routing according to Section 22.

12.2   Create a User

For details on how to create a user, see Section 24.

12.3   Activation Logic Properties

This section contains the following Configuration Data properties that are configurable for BCE provisioning:

• BCE-Resource
  • CompanySettingName
  • GetCompanySetting

For detailed information about each preceding property and how to change the configuration data, refer to User Guide for Resource Activation, Reference [3].

13   Configuration for PGM Provisioning

To provision Presence, Group and Data Management (PGM), configure the PGM as described in the following subchapters.

For more information about the related provisioning operations, refer to PGM Provisioning over CAI3G, Reference [12].

13.1   PGM Configuration for Document Service

The PGM NE for Document service is configured by configuring an NE and routing. Figure 23 illustrates the PGM NE Configuration for Document service.

Network Element

Define and configure an NE for each PGM node that Dynamic Activation is connected to.

PGM NE Configuration for Document service is performed in the Network Elements >Network Elements submenu. Select HTTP as Protocol.

For PGM NEs, configure mandatory parameters (marked with *) only. It is not necessary to configure optional parameters.

For PGM NEs, configure the Content Encoding and Authentication Method parameters as none, otherwise the link can be down.

For more information about this configuration, refer to User Guide for Resource Activation, Reference [3].

Supported protocols are: HTTP

Routing

The Routing is used to find an NE from the Business Logic.

PGM NE supports both the unconditional routing and regular expression of which the attribute name is publicId.

Configure the Routing according to Section 22.

13.2   PGM Configuration for User Service

The PGM NE for User service is configured by configuring an NE and routing. Figure 22 illustrates the PGM NE configuration for User service.

Network Element

Define and configure an NE for each PGM node that Dynamic Activation is connected to.

PGM NE configuration for User service is performed in the Network Elements >Network Elements submenu. Select CAI3G as Protocol.

For PGM NEs, configure mandatory parameters (marked with *) only. It is not necessary to configure optional parameters.

For more information about this configuration, refer to User Guide for Resource Activation, Reference [3].

Supported protocols are: CAI3G

Routing

The Routing is used to find an NE from the Business Logic.

PGM NE supports both the unconditional routing and regular expression of which the attribute name is publicId.

Configure the Routing according to Section 22.

13.3   Create a User

For details on how to create a user, see Section 24.

13.4   Activation Logic Properties

This section contains the following Configuration Data properties that are configurable for PGM provisioning of Document service:

• BCE-Resource
  • X3GPPAssertedIdentity
  • Xcaproot

For detailed information about each preceding property and how to change the configuration data, refer to User Guide for Resource Activation, Reference [3].

14   Configuration for AIR Provisioning

This section describes the configuration needed to enable provisioning of the following:

• Account Information and Refill services in AIR

For more information about the related provisioning operations, refer to Charging Provisioning over CAI3G.

14.1   AIR Configuration

The AIR NE is configured by configuring an NE and routing. Figure 25 illustrates the AIR configuration.

Network Element

An NE must be defined and configured for each AIR node that Dynamic Activation is connected to.

NE configuration is performed in the Network Elements > Network Elements submenu. Select AIR-Connector as Protocol.

To perform HTTP post heartbeat, configure HeartBeat Post Body as follows:

<methodCall><methodName>GetCapabilities</methodName><params><param><value><struct></struct></value></param></params></methodCall>

For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Supported protocols are: AIR-Connector

Network Element Group

The configured NEs are grouped in an NE Group configured in Multiple AIR mode. The NE Group is used by the Business Logic as a logical NE.

Assign the configured NEs to an NE Group according to Section 21. The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE from the business logic.

For AIR, the routing method NumberSeriesRouting, NumberRangeRouting, and UnconditionalRouting are used according to the deployment.

Configure the routing according to Section 22.

14.2   Create User

Create a user according to instructions in Section 24.

14.3   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for AIR provisioning.

• AIR-Monolithic-Resource
  • ProvisioningUri

    This parameter is mandatory when performing AIR provisioning.

  • ChargingTimeZone
  • OriginOperatorID

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

15   Configuration for AF Provisioning

This section describes the configuration needed to enable provisioning of the following:

• Account Finder services in AF

For more information about the related provisioning operations, refer to Charging Provisioning over CAI3G.

15.1   AF Configuration

The AF NE is configured by configuring an NE and routing. Figure 26 illustrates the AF configuration.

Network Element

An NE must be defined and configured for each AF node that Dynamic Activation is connected to.

NE configuration is performed in the Network Elements > Network Elements submenu. Select DNS as Protocol.

For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Supported protocols are: DNS

Routing

Routing is needed to find an NE from the business logic.

For AF, the routing method NumberSeriesRouting, NumberRangeRouting, and UnconditionalRouting are used according to the deployment.

Configure the routing according to Section 22.

15.1.1   Create User

Create a user according to instructions in Section 24.

15.1.2   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for AF provisioning.

• AF-Monolithic-Resource
  • TTL

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

16   Configuration for IPWorks/ENUM Provisioning

This section describes the configuration needed to enable provisioning of the following:

• ENUM records in IPWorks
• Management DNS domain in IPWorks

It is recommended to configure either layered or monolithic IPWorks/ENUM provisioning on a Dynamic Activation. If both are configured, the Dynamic Activation has a preference for the layered IPWorks/ENUM configuration over the monolithic one.

For more information about the related provisioning operations, refer to IPWorks/ENUM Provisioning over CAI3G, Reference [10].

16.1   Monolithic IPWorks/ENUM Configuration

The IPWorks NE is configured by configuring an NE and routing. Figure 27 illustrates the monolithic IPWorks/ENUM configuration.

Network Element

An NE must be defined and configured for each IPWorks node that Dynamic Activation is connected to.

NE configuration is performed in the Network Elements > Network Elements submenu. Select CF-SSH as Protocol.

The Protocol parameter version is mandatory for IPWorks. Table 4 lists the Protocol parameter version to be set for each version of IPWorks ENUM node.

For more information about this configuration, see User Guide for Resource Activation, Reference [3].

Supported protocols are: CF-SSH

Cluster Strategy

A cluster strategy instance is needed to be created. The strategy type is set to ActiveActive.

Assign the configured NEs to the cluster strategy instance. For instructions, refer to see User Guide for Resource Activation, Reference [3].

Routing

Routing is needed to find an NE from the business logic.

For IPWorks, the routing method RegularExpressionRouting, NumberRangeRouting, and UnconditionalRouting are used according to the deployment.

Configure the routing according to Section 22.

16.2   Layered IPWorks/ENUM Configuration

To provision layered IPWorks/ENUM, the CUDB needs to be configured as described as follows.

The CUDB NE is configured by configuring an NE, NE Group, and Routing. Figure 28 illustrates the CUDB configuration.

Network Element

An NE must be defined and configured for each CUDB node that Dynamic Activation is connected to. For further instructions, see Section 18.

Primary, secondary, and tertiary CUDB node must be configured as separate Network Elements (NE).

Network Element Group

The configured primary, secondary, and tertiary NEs are grouped in an NE Group configured in Failover mode. The NE Group is used by the business logic as a logical NE.

The configured NEs must be assigned to an NE Group, see Section 18.

The same NE can be assigned to several NE Groups.

Routing

Routing is needed to find an NE Group from the business logic.

For CUDB UnconditionalRouting method is used.

Configure the Routing according to Section 22.

16.3   Create User

Create a user according to instructions in Section 24.

16.4   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for IPWorks/ENUM provisioning.

For both layered and monolithic IPWorks/ENUM provisioning:

DNSSubscription MO:

• Routeuserphone
• Enumdomain

For layered IPWorks/ENUM only:

• MaxRetries
• RootDN

  Note:  

  Root DN is always configured to dc=operator,dc=com by default and must be changed to a value that matches the configured Root DN value in CUDB. The RootDn parameter is case-sensitive.

  The Root DN value can either be set individual per Activation Logic target component or set on all Activation Logic target components by use of the Change All RootDN's To: parameter, see User Guide for Resource Activation, Reference [3]

  
  

For monolithic IPWorks/ENUM only:

DNSDomains MO:

• DnsDomainCreateCommands

  This parameter is mandatory when adding a DNS domain.

• DnsDomainDeleteCommands

  This parameter is mandatory when removing a DNS domain.

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

17   Configuration for DSC/ILF Provisioning

To provision Diameter Signaling Controller (DSC) over the Individual Locator Function (ILF) CAI3G interface, configure DSC/ILF as described in the following sections.

For more information about the related provisioning operations, refer to DSC/ILF Provisioning over CAI3G, Reference [15].

17.1   DSC/ILF Configuration

The DSC/ILF NE is configured by configuring an NE and routing. The following figure illustrates the DSC/ILF configuration.

Network Element

Configure the NEs though the Dynamic Activation GUI Network Elements > Network Elements submenu. Select CAI3G as Protocol.

Parameter WS-Security Mode is specialized for DSC/ILF NE. Configure the SSL/TLS and WS-Security Mode parameters as follows, otherwise the link can be down:

• For HTTP protocol, select WS-Security Mode and authentication username/password digest. Make sure that SSL/TLS is not selected.
• For HTTPs protocol, select SSL/TLS, WS-Security Mode, and authentication username/password text parameters.

For more information about the configuration, refer to User Guide for Resource Activation, Reference [3].

Routing

Routing is used to find an NE group from the business logic.

For DSC/ILF, the routing method NumberSeriesRouting, NumberRangeRouting, and UnconditionalRouting are used according to the deployment.

Configure the routing according to Section 22.

17.2   Create User

Create a user according to instructions in Section 24.

18   CUDB Configuration

NE configuration and NE Group configuration are performed in the Network Elements > Network Elements and Network Elements > Network Element Groups submenus of the Dynamic Activation GUI. For more detailed information about NE configuration, refer to User Guide for Resource Activation, Reference [3].

The recommended configuration of NE Groups is listed in Table 5. The same NE can be used in more than one NE Group.

18.1   Activation Logic Properties

This section contains all the Configuration Data properties that are configurable for CUDB provisioning.

• CUDB-IMSI-Changeover
  • AUTCHOVERMAND 
  • RootDN
  • MaxRetries
  • MNCLength 
• CUDB-SUBDEL
  • RootDN
  • MaxParallelRequests
• CUDB-Subscriber
  • RootDN
  • MaxRetries

For detailed information regarding each property presented in the preceding list and information on how to change the configuration data, see User Guide for Resource Activation, Reference [3].

19   Front End Configuration

NE configuration and NE Group configuration are performed in the Network Elements > Network Elements and Network Elements > Network Element Groups submenus of the Dynamic Activation GUI. For more detailed information about NE configuration, refer to User Guide for Resource Activation, Reference [3].

The recommended configuration of NE Groups is listed in Table 6. The same NE can be used in more than one NE Group.

20   Provisioning Notification NE Configuration

NE configuration and NE Group configuration are performed in the Network Elements > Network Elements and Network Elements > Network Element Groups submenus of the Dynamic Activation GUI. For more detailed information about NE configuration, refer to User Guide for Resource Activation, Reference [3].

The recommended configuration of NE Groups is listed in Table 7. The same NE can be used in more than one NE Group.

21   Standalone NE Configuration

NE configuration and NE group configuration are performed in the Network Elements > Network Elements and Network Elements > Network Element Groups submenus of the Dynamic Activation GUI. For more detailed information about NE configuration, refer to User Guide for Resource Activation, Reference [3].

The recommended configuration of NE groups is listed in Table 8. The same NE can be used in more than one NE group.

22   Routing Configuration

Routing is performed in the Network Elements > Routing submenu of the Dynamic Activation GUI. For more detailed information about routing, refer to User Guide for Resource Activation, Reference [3].

Routing is used to find a connection to an NE or NE Group from the business logic. Table 9 lists all NE Types. Routing method UnconditionalRouting is normally used, unless otherwise is stated.

(1)  PGM does not support NE group.

(2)  It is used for both msisdn and e164.

(3)  It is only used for e164.

23   Connection Robustness

The expectation on robustness for HLR/AUC/MNP/M2M/HSS provisioning is different for different tasks.

For individual provisioning, for example, the client expects to have feedback as soon as possible so that an operation does not block the rest of the provisioning activity.

For massive operations, the client expects the operation to be successful.

When defining retries behavior, take such aspects into consideration. For more information regarding retries, see Function Specification Resource Activation, Reference [8].

23.1   Individual Provisioning of HLR Subscription in CUDB

The following is an example for individual provisioning of HLR subscription in CUDB:

HLR FE retries behavior:
Number of Retries: 3
Function Busy Timer: 1000 ms
Retry Factor: 2

HLR FE Individual Provisioning Validation Group retries behavior:
Number of HLR FE in the group: 4
Retry delay: 500 ms
Retry factor: 2
MAX_SEND_ATTEMPTS: 6

CUDB NE retries behavior:
Number of Retries: 3
Retry Time Interval: 1000 ms
Retry Factor: 2

CUDB Individual Provisioning Group retries behavior:
Number of CUDB in the group: 3
Retry delay: 500 ms
Retry factor: 2
MAX_SEND_ATTEMPTS: 6

The diagram in Figure 30 shows the interaction between the involved Network Elements and delay between retries:

• CUDB 1 and 2 suffer from LDAP Busy, they are blacklisted after all three retries failed.
• CUDB group retries take effect to send the same operation towards the next not blacklisted CUDB in the group. The operation is successfully executed by CUDB 3.
• HLR FE 1, 2 and 3 suffer from Function Busy, they are blacklisted after all three retries failed.
• HLR FE group retries take effect to send the same operation towards the next not blacklisted HLR FE in the group. The operation is successfully executed by HLR FE 4.
• When subscriber data is updated in the CUDB, CUDB3 is directly used as CUDB1 and 2 are still blacklisted.

The calculations for this example setup are as follows:

• Data is fetched from CUDB after a total time of 15.5 seconds (7+0.5+7+1).
• Data validation is performed successful by HLR FE after a total time of 24.5 seconds (7+0.5+7+1+7+2).

Note:  

If a previously blacklisted CUDB gets whitelisted while PG is retrying on another CUDB, then PG is able to retry again on the newly whitelisted CUDB if necessary. If all CUDBs in the NE group get blacklisted, then PG still applies the group level delay and delay factor and then check if one of the CUDBs has got whitelisted. This is repeated until the configured MAX_SEND_ATTEMPTS on NE group level has been reached. This applies to all provisioning types.

In the worst case of the preceding example, a request to the CUDB is retried six times on the NE group level. It takes 57.5 seconds (7+0.5+7+1+7+2+7+4+7+8+7) for the CUDB to respond to that request.

23.2   Individual Provisioning of HLR Subscription in CUDB with Long Retry Time Interval

The following is an example for individual provisioning of HLR subscription in CUDB with Long Retry Time Interval:

Note:  

For other nodes, this sequence is the same towards CUDB without communication with HLR FE.

CUDB NE retries behavior:
Number of Retries: 3
Retry Time Interval: 1000 ms
Long Retry Time Interval: 15000 ms
Retry Factor: 2

The diagram in Figure 31 shows the interaction between the involved Network Elements and delay between retries:

• CUDB 1 suffers from LDAP Unwilling to perform.
• No failover and retry on CUDB group level.
• HLR FE 1 works.

The calculations for this example setup are as follows:

• Data is fetched from CUDB after a total time of 105 seconds (15+30+60).

23.3   HLR Massive Update

The following is an example for HLR massive update:

HLR FE retries behavior:
Number of Retries: 3
Function Busy Timer: 1000 ms
Retry Factor: 2

HLR FE Massive Update Validation Group retries behavior:
Number of HLR FE in the group: 7
Retry delay: 1000 ms
Retry factor: 4
MAX_SEND_ATTEMPTS: 6

CUDB retries behavior:
Number of Retries: 3
Retry Time Interval: 1000 ms
Retry Factor: 2

CUDB Massive Update Group retries behavior:
Number of CUDB in the group: 3
Retry delay: 1000 ms
Retry factor: 4
MAX_SEND_ATTEMPTS: 6

The diagram in Figure 32 shows the interaction between the involved Network Elements and delay between retries. In this example:

• Massive update is an asynchronous operation. Execution duration is less sensitive for the client than for an individual subscriber provisioning client.
• Successful massive search is the prerequisite for massive update. If error occurs during massive search, the operation is ended, which means no retry is performed here.
• HLR FE retries and CUDB retries have the same behavior as that for individual provisioning.
• For both the HLR FE group and CUDB group longer retry delay and higher delay factor are used to overcome the temporary errors, thus, improve the probability for a successful operation.

The calculations for this example setup are as follows:

• Data is fetched from CUDB after a total time of 19 seconds (7+1+7+4).
• Data validation is performed successful by HLR FE after a total time of 19 seconds (7+1+7+4).

Consider one request to the CUDB and worst case when all the six attempts on NE group level are made. Then it takes 383 seconds (7+1+7+4+7+16+7+64+7+256+7) for the CUDB to respond to that request.

23.4   Configuration of Network Element Retry

To set the bootloader configuration parameter in Table 10, follow the instructions in the step-list as follows.

Note:  

The parameter described in Table 10 is shared for all NE Types.

To set the bootloader configuration parameter, do the following:

1. On an SC node, log in as an administrator and execute the following command to set the parameter for a configuration:

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

   For example:

   $ bootloader.py config set --parameter @HTTP_REQUEST_TIMEOUT@ --value 5000

2. Restart the dve-application module, on all affected PL nodes, one by one, for the changes to take effect.
   Warning!

   Wait for each PL node to be activated before starting with the next one, otherwise traffic disturbances occur. Do not run all.

   From an SC node:

   $ bootloader.py node activate --host <hostname>

   <hostname> is the hostname of the PL node to activate.

3. To list configured bootloader configuration parameters, execute the following command:

   $ bootloader.py config list --show_all

For more information about NE retry configuration, see User Guide for Resource Activation, Reference [3].

23.5   Configuration of Network Element Group Retry

To configure Network Element Group Retry, each PL node in the cluster needs to be configured according to the instructions in this section.

To disable Network Element Group Retry, set the bootloader configuration parameter MAX_SEND_ATTEMPTS to 1.

To set the bootloader configuration parameters in Table 11, follow the instructions in the step-list as follows.

Note:  

The parameters described in Table 11 are shared for all NE Types.

(1)  This parameter is used for all NEs that store data in CUDB.

(2)  This parameter is only applicable for HLR.

(3)  This parameter is only applicable for HSS.

(4)  This parameter is used for all operations that interact with CUDB, HLR, and HSS.

(5)  Setting MAX_SEND_ATTEMPTS to 1 means NE Group Retry is disabled.

To set the different bootloader configuration parameters, do the following:

1. On an SC node, log in as an administrator and execute the following command to set the parameters for a configuration:

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

   For example:

   $ bootloader.py config set --parameter @MassiveTelnetRetryFactor@ --value 9

2. Restart the dve-application module, on all affected PL nodes, one by one, for the changes to take effect.
   Warning!

   Wait for each PL node to be activated before starting with the next one, otherwise traffic disturbances occur. Do not run all.

   From an SC node:

   $ bootloader.py node activate --host <hostname>

   <hostname> is the hostname of the PL node to activate.

3. To list configured bootloader configuration parameters, execute the following command:

   $ bootloader.py config list --show_all

24   Users

Create a user, set the correct authorities and add possible attribute rules. Update the policies to activate the changes.

This is performed in the Access Control > Users submenu in the Dynamic Activation GUI.

For more information see User Guide for Resource Activation, Reference [3].

25   CUDB Blocking for Backup

Dynamic Activation can receive a notification from CUDB so that certain provisioning towards CUDB is blocked during a CUDB backup. The purpose is to ensure consistency. The blocking and unblocking can either be triggered from the CUDB or manually. Manually by setting the BlockForCudbBackup attribute to true or false by use of a JMX client. When the backup is finished, the CUDB sets the BlockForCudbBackup attribute to false. This to allow all provisioning towards CUDB again.

It is necessary to create a default user with the purpose to communicate CUDB backup changes. Create a user with username cudb and select a password synchronized with CUDB.

This is performed in the Access Control > Users submenu in the GUI.

For more information see User Guide for Resource Activation, Reference [3].

There are template files located in /opt/dve/tools/jmxbatchclient/templates/ for get block, set block and set unblock.

The following CAI3G and MML commands are blocked by the CUDB backup block:

Note:  

If a command is executing when BlockForCudbBackup receives the value true, the command is not stopped.

JMX Client

Use the following command to get the status of BlockForCudbBackup:

$ sudo -u actadm /opt/dve/tools/jmxbatchclient/jbc-rmi.sh -Aadmin:admin service:jmx:rmi://<PS_JMX_Server_IP>:8995/jndi/rmi://<PS_JMX_Server_IP>:8100/connector /opt/dve/tools/jmxbatchclient/templates/BlockForCudbBackup-get.xml

Use the following command to set the status for BlockForCudbBackup to true:

$ sudo -u actadm /opt/dve/tools/jmxbatchclient/jbc-rmi.sh -Aadmin:admin service:jmx:rmi://<PS_JMX_Server_IP>:8995/jndi/rmi://<PS_JMX_Server_IP>:8100/connector /opt/dve/tools/jmxbatchclient/templates/BlockForCudbBackup-setBlock.xml

Use the following command to set the status for BlockForCudbBackup to false:

$ sudo -u actadm /opt/dve/tools/jmxbatchclient/jbc-rmi.sh -Aadmin:admin service:jmx:rmi://<PS_JMX_Server_IP>:8995/jndi/rmi://<PS_JMX_Server_IP>:8100/connector /opt/dve/tools/jmxbatchclient/templates/BlockForCudbBackup-setUnblock.xml

Reference List