Contents

1   Introduction

This section is an introduction to this document. It contains information about the prerequisites, purpose, scope, and target group for the document. This section also contains explanations of typographic conventions used in this document.

1.1   Purpose and Scope

This document gives a brief introduction to the optional feature FAJ 901 792 Ericsson™ DAE – DLA FE, Layered Data Access Enabler (DAE) provisioning solution, provided by Ericsson Dynamic Activation (EDA).

1.2   Target Group

The target group for this document is as follows:

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

For information about the different target groups, see Library Overview, Reference [2]

1.3   Typographic Conventions

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

2   Overview

Dynamic Activation is an Ericsson solution for the common provisioning regardless of the vendor and network technology. Dedicated features in Dynamic Activation provide the provisioning interface for DAE.

DAE is using the Data Layered Architecture for storage of subscriber and profile data. Data Layered Architecture (DLA) is a solution that allows separation of application logic and data storage into different nodes. The DAE node is, in a DLA deployment, configured as a Front End (FE). The FE contains the application logic and connection to an external Back End Database (BEDB). The BEDB contains the application user data storage (subscriber data) and is accessible from the DAE-FE. In the Ericsson DLA, solution the Centralized User Database (CUDB) is used as BEDB. CUDB provides a common centralized database for multiple application data. The Dynamic Activation system is in charge of provisioning the CUDB.

The DAE solution contains three components:

• CUDB - for storing purposes.
• Dynamic Activation - providing the provisioning functionality.
• DAE-FE - for executing the traffic logic

An overview of the DAE solution is shown in Figure 1.

As shown in Figure 1:

Dynamic Activation exposes a Customer Administration Interface Third Generation (CAI3G) interface for provisioning of DAE data. This interface is consumed by a Business Support System (BSS) or any other system for management of devices.

Dynamic Activation uses Lightweight Directory Access Protocol (LDAP) interface towards Centralized User Database (CUDB) for storing of device subscription and profile data. All the data associated with DAE is stored in the CUDB. The traffic logic is executed on the application servers, the DAE - Front End (FE). Dynamic Activation handles the provisioning aspects.

2.1   Data Model DAE

The general view of the provisioning data model used in DAE is shown in Figure 2.

• The "ou=deviceGroupProfiles" entry contains multiple deviceGroupProfileId entries, one for each deviceGroupProfile. One deviceGroupProfileId entry contains the parameter settings for this specific deviceGroupProfile, as well as subentries for the three types of access control lists supported by DAE. Each of the three types of access control lists contains multiple ACLRuleId entries, one for each access control rule.
• The identities object contains all the identities related to the MultiServiceConsumer (MultiSC). The different identities are used to identify and access MultiSC.
• MultiSC represents the entity which consumes one or more telecommunication services. The services it can contain below itself are the DAE; Authentication/Authorization/Accounting (AAA), Authentication (Auth), and Circuit Switched/Packet Switched (CSPS).
• The mscCommonData object contains information of deviceGroupProfiles that are used by MultiSCs.
• MultiSC Identities, a special entry under the MultiSC entry. This entry gathers all the shared identities used to identify the MultiSC for the different services and a mask per identity indicating for which services the identity has been defined.
• The Service object contains information related to the services consumed by the MultiSC. An instance of this object must be created for every service consumed by the MultiSC.
• The DAE Subscription has both provisioning data, "cn=provisioningData" as well as traffic data, "ou=trafficData". Each Subscription has a reference to a deviceGroupProfile that contains settings information for a specific device. The traffic data below "ou=trafficData" is created and modified by the DAE node. During deletion of the DAE Subscription Dynamic Activation deletes all entries below "ou=trafficData" recursively.

2.2   Data Model Management

Dynamic Activation is responsible to:

• Map the CAI3G order to the LDAP objects in the data model for a subscriber. There are attributes that have a different format in the CAI3G interface and in the LDAP schema.
• Check and add default values to attributes that are required (mandatory) in CUDB but optional in CAI3G.
• Handle identities and alias under root identities entry, generate identity for MultiSC (IMSI and MultiSC ID) and validate their relations for a given subscriber.
• Create the service object AAA each time a MultiSC is created in CUDB. The AAA object (and optional objects below AAA) is removed each time a MultiSC is deleted. AAA-specific data is added below AAA object and an IP address alias is added by services during traffic. The IP address is not managed by Dynamic Activation.

2.3   DAE Functionality

DAE provides functionality for full and secure internet connectivity between enterprise applications and mobile devices. It provides functionality for exposing each device as a public DNS address and IP address on the Internet. This is so that applications can initiate communication towards the device even though the device itself is using a private IP address. Two types of services are provided by DAE, port forwarding and http/https forwarding. The port forwarding service provides access to any TCP or UDP service port while the http/https forwarding service particularly handles http/https traffic.

DAE provides support for authorizing the enterprise applications, translating the address information and forward all incoming traffic to the correct device. The authorization of enterprise applications is configured in access control lists for traffic initiated from enterprise applications towards devices (“inbound traffic”) and traffic initiated from devices towards enterprise applications (“outbound traffic”).

2.4   DAE Provisioning Functions

The DAE Provisioning solution provides by default the following functions:

• Single point of provisioning:

  Internal provisioning complexity for DAE is hidden by offering the CAI3G to the user.

• Syntax, schematics check and validation of provisioned data:

  Dedicated features in Dynamic Activation make sure that the provisioned data is of correct type (for example IP address format and allowed TCP/UDP service names), and that all mandatory parameters are present in the provisioning requests.

• Uniform provisioning interface:

  CAI3G is offered for provisioning of DAE data. Through the CAI3G provisioning interface, it is possible to perform the Create, Set, Get, and Delete operations.

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

  For information about CAI3G DAE provisioning, refer to the following document, Layered DAE Provisioning over CAI3G, Reference [1].

• Error handling:

  During the provisioning process, an error can occur that leads to partial execution of a provisioning operation. The partiallysucceededoperations.log file contains the partially successful request and the subsequent southbound operations. Since the sequence of operations was not successful, this causes inconsistency in the CUDB. Correct the inconsistency manually. For more information about the repair procedure, see CUDB Subscription Repair and Remove Procedures, Reference [3].

For provisioning of DAE data, the following Customer Service Orders (CSOs) are supported through the CAI3G interface:

• Create/Set/Get/Delete DAE Subscription.
• Create/Set/Get/Delete DeviceGroupProfile.

2.4.1   DAE Subscription

This provisioning function interacts directly with the CUDB by use of Create/Set/Get/Delete methods and is handling the entries attached to the mscId entry. It writes to the serv=dae entry and its subentries. The only thing that can be modified or fetched is the deviceGroupProfileId that is referred.

• The Create operation creates a Subscription that points to a DeviceGroupProfile.
• The Get operation returns the current DeviceGroupProfileId using the provided IMSI value.
• The Set operation can change the subscription to use a different DeviceGroupProfile.
• The Delete operation removes the DAE subscription from the CUDB.

2.4.2   Device Group Profile

This provisioning function interacts directly with the CUDB by use of Create/Set/Get/Delete methods and is only handling the deviceGroupProfileId entry and its subentries.

• The Create operation creates a DeviceGroupProfile in the CUDB.
• The Get operation returns an existing DeviceGroupProfile.
• The Set operation modifies existing DeviceGroupProfile with new attribute values.
• The Delete operation removes a DeviceGroupProfile that exist in the CUDB.

  Note:  

  It is not allowed to delete a DeviceGroupProfile that is in use, that is, a DeviceGroupProfile that is referred from a DAE Subscription.

  
  

2.4.2.1   Access Control Lists

Access Control Lists (ACL) are managed as a part of a DeviceGroupProfile, using the CAI3G Create/Set/Get DeviceGroupProfile operations. Three different ACLs can be created for a DeviceGroupProfile:

• deviceInitOutound controlling traffic initiated from devices.
• daePortForwInbound controlling port forwarding traffic initiated from applications.
• httpForwInbound controlling http/https forwarding traffic initiated from applications.

Each ACL policy rule within an ACL can be added, updated, or removed individually.

• Adding a policy rule is performed using Create or Set DeviceGroupProfile.
• Modifying an existing policy rule is performed using Set DeviceGroupProfile.
• Deleting one policy rule is done using Set DeviceGroupProfile.

2.4.3   Notifications

DAE is keeping an internal cache of data for subscribers and Device Group Profiles that are currently in use in traffic. Thus, when something is changed in CUDB for an existing subscriber or DeviceGroupProfile, DAE needs to update the cache. Dynamic Activation supports this by sending notifications to DAE when something is changed, including both the old and new data in the notification request. The following tasks trigger a notification towards DAE:

• A DeviceGroupProfile is modified.
• A DeviceGroupProfile is deleted.
• Policies are changed (ACL rules are added, modified, or deleted) in a DeviceGroupProfile.
• A single device DAE Subscription is deleted.

If it is not possible for Dynamic Activation to send notification to DAE, an alarm is triggered. The alarm is to make customer aware that notification about the changes has not been sent.

If DAE is down, Dynamic Activation stops sending notifications and events.

Dynamic Activation maintains a list of provisioning events that triggers a notification request to the DAE-FE. The list is fetched from a DAE-FE Service Notification Configuration File. This contains the LDAP objects or attributes or both and conditions that must be fulfilled to send the notification message.

Dynamic Activation detects if a notification configuration file has been updated and activates the changed configuration automatically. For details, see System Administrators Guide for Native Deployment, Reference [4].

Reference List

Ericsson Documents
[1] Layered DAE Provisioning over CAI3G, 22/155 19-CSH 109 628 Uen
[2] Library Overview, 18/1553-CSH 109 628 Uen
[3] CUDB Subscription Repair and Remove Procedures, 4/1553-CSH 109 628 Uen
[4] System Administrators Guide for Native Deployment, 1/1543-CSH 109 628 Uen