CUDB Notifications

Contents

1Introduction
1.1Document Purpose and Scope
1.2Revision Information
1.3Target Groups
1.4Prerequisites
1.5Typographic Conventions

2
Overview
2.1Prerequisites
2.2Architecture
2.3Description
2.4Dependencies and Interactions

3
Operation and Maintenance
3.1Activation
3.2Configuration
3.3Fault Management
3.4Performance Management
3.5Security
3.6Logging

Glossary

Reference List

1   Introduction

This document provides a description of the optional notifications feature in the Ericsson Centralized User Database (CUDB).

1.1   Document Purpose and Scope

The purpose of this document is to describe the optional notifications feature from a functional and operational point of view.

1.2   Revision Information


Rev. A
Rev. B
Rev. C
Rev. D
Rev. E
Rev. F

Other than editorial changes, this document has been revised as follows:

1.3   Target Groups

As this document provides overall information about the notifications feature, it is intended for system developers, testers, administrators, or operators.

1.4   Prerequisites

Users of this document must have an overall knowledge of the CUDB system basics.

1.5   Typographic Conventions

Typographic conventions can be found in the following document:

2   Overview

The notifications feature is used to inform Front End (FE) applications about modifications in data they store in a CUDB system.

2.1   Prerequisites

This section is not applicable to this feature.

2.2   Architecture

The notifications feature works on a Distribution Entry (DE) basis to provide information about changes in the attribute data stored in entries below the DEs in the Lightweight Directory Access Protocol (LDAP) tree. In other words, it reports modifications of data stored in the Data Store (DS) layer of a certain DE or set of DEs.

Figure 1 shows the notifications module, its components, and relationships with other CUDB modules and external FEs.

Figure 1   Notifications Module

The notifications module subscribes to the database events to monitor attribute changes, check for certain attribute values, and retrieve attribute contents to build the notifications.

Notifications to applications are sent as Simple Object Access Protocol (SOAP) messages over Hypertext Transfer Protocol (HTTP). CUDB acts as the SOAP client and the applications FEs act as the SOAP servers (referred to as endpoints from now on). For more information on the CUDB SOAP interface, refer to CUDB SOAP Interwork Description, Reference [1].

Use of Transport Layer Security (TLS) key and certificate is also possible in the SOAP interface. For more information on security in CUDB, refer to CUDB Security and Privacy Management, Reference [2].

The notifications feature has the following configuration options:

The parameters above are configured through the CUDB configuration Command Line Interface (CLI).

The notifications module is deployed in all payloads. However, only two instances run in active-standby model. The rest of the instances are waiting to enter in standby mode in case one of the active-standby instances fail. The active entity monitors the database events to be notified by subscribing to the master replicas of the DSGs hosted by the CUDB node. When the active entity fails, the standby entity becomes active and monitors the events instead of the active. For more information on high availability, refer to CUDB High Availability, Reference [3].

The module gathers internal statistics on failed and successful operations. These statistics are downloaded to counters, which are managed by the Ericsson Simple Network Management Protocol (SNMP) Agent (ESA). Additionally, the module produces logging information about the performed operations and the operation errors.

2.3   Description

The notifications feature has the following three types of attributes:

It is possible to define as many notifications as needed, but each one of them must have at least one monitored attribute. A notification is triggered if a monitored attribute changes and if the checked attributes (if defined) fulfills the comparison condition. All the attributes included in the notification are related to the same DE, as the feature is DE-based. Section 3.2.4 shows an example of a notification definition.

A list of notification endpoints is also defined per notification. Each endpoint is characterized by a certain weight, which determines how often it receives notifications. Endpoints having a weight different from zero are included in a Weighted Round Robin (WRR) algorithm. This means, for example, if three endpoints (EP1, EP2 and EP3) are defined, each having weights 4, 2 and 1 respectively, then EP1 receives twice the number of notifications than EP2, and four times the number of notifications than EP3. On the other hand, if an endpoint has weight=0 set, it is excluded from the WRR algorithm and receives all of the notifications. Therefore, all the endpoints with weight=0 receive notifications in a broadcast. The order of WRR endpoints where notifications are being sent to is equal with the configuration order of the WRR endpoints in the configuration model.

2.4   Dependencies and Interactions

The notifications module works in an autonomous way in the CUDB system and does not interfere with the LDAP traffic operations performed by the system up to the characterized performance limits. However, the following limitations in the feature and interactions with other features must be considered:

Furthermore, there are some limitations about the lost notifications when the active instance dies. This loss is due to:

3   Operation and Maintenance

This section describes the Operation and Maintenance of the notifications feature.

For information on troubleshooting this feature, refer to CUDB Troubleshooting Guide, Reference [5].

3.1   Activation

This section describes the activation of the notifications feature.

3.1.1   Prerequisites

The notifications feature is activated through the CUDB configuration model. The necessary prerequisites and permissions are listed in CUDB Node Configuration Data Model Description, Reference [6].

3.1.2   Activating Notifications

The notifications feature activation status is determined by attribute enabled in class CudbNotifications of the CUDB configuration model. If this boolean attribute is set to false, the sending notification is avoided.

3.2   Configuration

The notifications module is configured by a set of classes and attributes defined in the CUDB configuration model to provide the feature configuration options.

3.2.1   Configuring Notifications

The types of configuration parameters related to the notifications module are as follows:

3.2.2   Notifications Parameters

CudbNotifications is the root class hosting all the configuration data related to the notifications feature. CudbNotifications contains the module configuration parameters, and all notifications defined in the CUDB system hang on it.

Notifications are defined by the CudbNotificationEvent class. This class has the same number of instances as the number of notifications created in the system and each instance contains the configuration data related to each notification, which is divided into the following two parts:

In object classes of check and related type, regular expressions cannot be used. When there is a need to check or include attributes that belong to the same entry as the monitored one, regular expressions should not be used and there must be as many configured notification events as there are different entries for monitored object classes.

The attributes in the CUDB Node Configuration Data Model Description, Reference [6] must be encoded as follows:

At least one instance of the CudbNotificationObjectClass, monitor, or monitorAll types must be defined per notification. But it is possible not to define the check and related instance types. The CUDB system does not check at configuration time if the configured attributes belong to one of the supported types (see Section 2.4).

The send field of the defined instances of CudbNotificationAttr acts as a sending flag for the related attribute. If it is true, the attribute name and value are sent in the notification. For multi-valued attributes, the complete set of values is sent. In case the attributes are included in the CudbNotificationObjectClass instances of the monitor or monitorAll types, the old attribute values are also sent.

If any of the LDAP attributes and object classes in the notification (either monitor, monitorAll, checked or included attributes) can not be retrieved from the database, the notification is not sent, and an error is reported.

For more information about these parameters, and generic SAF configuration model parameter handling directives, refer to CUDB Node Configuration Data Model Description, Reference [6].

3.2.3   Configuration Examples

This section provides different examples of configuring the dn attribute in monitor or monitorAll type CudbNotificationObjectClass classes.

In Example 1, a notification will be triggered for any LDAP entry whose complete DN contains the configured value.

Example 1   Configuring dn without DE DN Part

dn="EpsDynInfId=EpsDynInf,EpsStaInfId=EpsStaInf,serv=eps"

In Example 2, a notification will be triggered for any LDAP entry that matches the configured value, for example, for any mscId value.

Example 2   Using Regular Expression to Replace a Subscriber ID in DN of LDAP Entry

dn="EpsDynInfId=EpsDynInf,EpsStaInfId=EpsStaInf,serv=eps,mscId=.*,ou=multiscs,dc=operator,dc=com"

In Example 3, a notification will be triggered for any value of grpId.

Example 3   Using Regular Expressions to Configure dn without DE DN Part

dn="grpId=.*,serv=pcrf.*"

If this configuration must be restricted to only a few values of the grpId, use the OR operator:

Example 4   Using Regular Expressions with Logical Operators, First Method

dn="(grpId=id1|grpId=id2),serv=pcrf.*"

Or, to accomplish the same:

Example 5   Using Regular Expressions with Logical Operators, Second Method

dn="grpId=(id1|id2),serv=pcrf.*"

Example 6   Using Multiple Wildcards in dn Attribute

dn="recordId=.*,viewId=.*,fqdn=.*,ou=EnumDn.*,serv=enum,ou=servCommonData,dc=operator,dc=com"
Note:  
Any regular expression can be used to define the DN pattern. However, complex regular expressions should be used with caution to avoid unexpected notifications.

3.2.4   Preconfigured Notifications

An Evolved Packet Core (EPC) Mobility Notification is preconfigured in CUDB. It sends notifications to the Home Location Register (HLR) FE. EPC mobility support is an optional CUDB feature, as detailed in CUDB Technical Product Description, Reference [7].

The following attributes are involved in the preconfigured notification:

3.2.5   External Networks Connectivity

As notifications are sent outside the CUDB, it is needed to configure the network connectivity facilities in the system for communication towards the endpoints. For more information, refer to CUDB Node Network Description, Reference [8].

Additionally, eVIP routes for the endpoints must be added in the blades or Virtual Machines (VMs) where the notification processes are running, if they are not already established. Otherwise, the endpoints cannot be accessed. For more information, refer to CUDB System Administrator Guide, Reference [9].

It is also possible to configure how TCP sockets towards the endpoints are initialized per notification. For more information about configuring socket initialization, refer to CUDB SOAP Interwork Description, Reference [1].

3.3   Fault Management

This feature triggers the following alarms:

3.4   Performance Management

For more information on counters managed by the notifications module, refer to CUDB Counters List, Reference [12].

3.5   Security

It is possible to configure a TLS key and certification in the SOAP interface. For detailed information about security related parameters and security configuration, refer to CUDB Security and Privacy Management, Reference [2].

3.6   Logging

For more information on the log messages generated by the notifications module, refer to CUDB Node Logging Events, Reference [13].


Glossary

For the terms, definitions, acronyms and abbreviations used in this document, refer to CUDB Glossary of Terms and Acronyms, Reference [14].


Reference List

CUDB Documents
[1] CUDB SOAP Interwork Description.
[2] CUDB Security and Privacy Management.
[3] CUDB High Availability.
[4] CUDB Application Integration Guide.
[5] CUDB Troubleshooting Guide.
[6] CUDB Node Configuration Data Model Description.
[7] CUDB Technical Product Description.
[8] CUDB Node Network Description.
[9] CUDB System Administrator Guide.
[10] SOAP Notifications, Discarded Notifications.
[11] SOAP Notifications, Endpoint Unreachable.
[12] CUDB Counters List.
[13] CUDB Node Logging Events.
[14] CUDB Glossary of Terms and Acronyms.
Legal | © Ericsson AB 2016, 2017