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 This document is based on 9/15534-HDA10403/9 with the following changes:
  • Updated hardware information.
Rev. B Other than editorial changes, this document has been revised as follows:
  • Section 2.2: Added information on sets of DEs.
  • Section 2.3: Added information on regular expression pattern.
  • Section 3.2.2: Updated information on CudbNotificationObjectClass and the monitor type.
  • Section 3.2.3: Added new section with examples of configuring new CUDB Notification Events using regular expressions.
Rev. C Other than editorial changes, this document has been revised as follows:
  • Section 3.2.2: Updated to reflect support of extended POSIX regular expressions.
  • Section 3.2.3.2: Updated to reflect support of POSIX regular expressions.

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 runs in redundancy active-standby model. 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:

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 are 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 new CUDB Notification Events using regular expressions.

3.2.3.1   Creating a New Notification Event

To create a new CUDB Notification Event, a new instance of the CudbNotificationEvent class must be added to the configuration model and the corresponding attributes must be set. For more information, refer to the "Class CudbNotificationEvent" section of CUDB Node Configuration Data Model Description, Reference [6].

Example 1, shown in COM CLI, presents CudBNotificationEvent=1 with eventId=”SAE-HLR” with defined one Notification Endpoint and five Notification Object Classes:

Example 1   CudBNotificationEvent=1 with eventId=”SAE-HLR”

>show verbose ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=1
CudbNotificationEvent=1
   cudbNotificationEventId="1"
   eventId="SAE-HLR"
   notificationString="mobilityEvent"
   userLabel=[] <empty>
   CudbNotificationEndPoint=1
   CudbNotificationObjectClass=1
   CudbNotificationObjectClass=2
   CudbNotificationObjectClass=3
   CudbNotificationObjectClass=4
   CudbNotificationObjectClass=5

Define all required elements (attributes, object/object classes and their attributes) of the new CudbNotificationEvent in its tree structure (Directory Information Tree, DIT) before starting to create a new Notification Event.

Example 2 presents a new CudbNotificationEvent=2 shown in COM CLI.

Example 2   New CudbNotificationEvent=2 shown in COM CLI

>show verbose ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2
CudbNotificationEvent=2
   cudbNotificationEventId="2"
   eventId="SAE-HSS"
   notificationString="mobilityEvent"
   userLabel=[] <empty>
   CudbNotificationEndPoint=1
   CudbNotificationObjectClass=1
   
>show verbose ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2,CudbNotificationEndPoint=1
CudbNotificationEndPoint=1
   name="Serv1"
   URI="http://127.0.0.1:8080"
   webService="/"
   weight=1

>show verbose ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2,CudbNotificationObjectClass=1
CudbNotificationObjectClass=1
   cudbNotificationObjectClassId="1"
   dn="serv=csps"
   name="CsPsLocationData"
   type="related"
   userLabel=[] <empty>
   CudbNotificationAttr=1

>show verbose ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2,⇒
CudbNotificationObjectClass=1,CudbNotificationAttr=1
CudbNotificationAttr=1
   cudbNotificationAttrId="1"
   name="SGSNNUM"
   send=true
   userLabel=[] <empty>
   value=""
(CudbNotificationObjectClass=1)>

As shown in Example 2, CudbNotificationEvent=2 will contain one CudbNotificationEndpoint=1 and one CudbNotificationObjectClass=1 with one CudbNotificationAttr=1.

Follow the steps below, shown in COM CLI, to insert a new Notification Event using the Object Model Modification procedure:

  1. Establish a CUDB CLI session towards the CUDB node by executing the ssh -l cudbadmin <CUDB_Node_OAM_IP_Address> command.

    Important: This procedure must be done in all CUDB nodes in the system.

  2. If there is no backup of the present configuration, perform the backup by executing the sudo cmw-configuration-persist command. If the backup is already updated, proceed to Step 3.
  3. Establish a CUDB configuration CLI session in the active SC. Use the commands below (their output is also shown) to find the active SC:
    sudo cudbHaState | grep COM | grep ACTIVE
    COM is assigned as ACTIVE in controller SC-1

    The active SC, (SC_2_1 in the example above) must be used for accessing the COM CLI by executing the sudo /opt/com/bin/cliss command.

  4. Set the configuration session by executing the configure command.
  5. Check if CudbNotifications are already enabled and exist in CudbNotificationsEvents.

    Use the show verbose command to show ManagedElement=1,CudbSystem=1,CudbNotifications=1:
    (config)>show verbose ManagedElement=1,CudbSystem=1,CudbNotifications=1
    CudbNotifications=1
    cudbNotificationsId="1"
    enabled=true <default>
    maxReattempts=3 <default>
    reattemptTime=1000 <default>
    userLabel=[] <empty>
    CudbNotificationEvent=1
    (config)>

    If CudbNotifications are not already enabled, execute the following commands:

    (config)>ManagedElement=1,CudbSystem=1,CudbNotifications=1,enabled=true
    (config)>commit

  6. Execute the following command sequence to add a new CUDB Notification Event (CudbNotificationEvent=2) in the CUDB configuration model:
    Note:  
    This is an example and must not be taken as a rule.

    >configure
    (config)>ManagedElement=1,CudbSystem=1,CudbNotifications=1,CudbNotificationEvent=2
    (config-CudbNotificationEvent=2)>eventId=SAE-HSS
    (config-CudbNotificationEvent=2)>notificationString=mobilityEvent
    (config-CudbNotificationEvent=2)>CudbNotificationEndPoint=1
    (config-CudbNotificationEndPoint=1)>name=Serv1
    (config-CudbNotificationEndPoint=1)>URI=http://127.0.0.1:8080
    (config-CudbNotificationEndPoint=1)>weight=1
    (config-CudbNotificationEndPoint=1)>up
    (config-CudbNotificationEvent=2)>CudbNotificationObjectClass=1
    (config-CudbNotificationObjectClass=1)>dn="serv=csps"
    (config-CudbNotificationObjectClass=1)>name=CsPsLocationData
    (config-CudbNotificationObjectClass=1)>type=related
    (config-CudbNotificationObjectClass=1)>CudbNotificationAttr=1
    (config-CudbNotificationAttr=1)>name=SGSNNUM
    (config-CudbNotificationAttr=1)>send=true
    (config-CudbNotificationAttr=1)>up
    (config-CudbNotificationObjectClass=1)>up
    (config-CudbNotificationEvent=2)>show verbose
    CudbNotificationEvent=2
    cudbNotificationEventId="2"
    eventId="SAE-HSS"
    notificationString="mobilityEvent"
    userLabel=[] <empty>
    CudbNotificationEndPoint=1
    CudbNotificationObjectClass=1

    Each operation is executed as a unique transaction.

  7. Commit the changes by executing the commit command.
  8. Check the log files to see the result of the operations. For more information, refer to CUDB Node Logging Events, Reference [7].
  9. Check the configuration changes with the show ManagedElement=1,CudbSystem=1,CudbNotificationEvent=2 command.
    Note:  
    Remember to use show verbose instead of show for not mandatory attributes that must have no set value, or for optional attributes whose value is set to the default one.

  10. Exit from the configuration mode by executing the end command.
  11. Exit from the CUDB configuration CLI console by executing the exit command.
Note:  
Configuration changes in the examples above can also be performed through the NETCONF client.

See Section 3.2.2 for more information about Notifications Parameters.

Refer to the Object Model Modification Procedure in CUDB Node Configuration Data Model Description, Reference [6] for more information on all the steps required to modify the object model (for example, on using the administrative operation applyConfig to activate the changes).

3.2.3.2   Using Regular Expressions

For using regular expressions to define monitor type CudbNotificationObjectClass classes, see Example 3, Example 4, Example 5, Example 6, and Example 7 .

Warning!

When using regular expressions to configure a partial DN, the configured regular expression is always compared to whole DN of modified entry, so using the ".*" wildcard at the end of regular expression is mandatory.

Example 3   Using Regular Expression to Define Whole DN of LDAP Entry

CudbNotificationObjectClass=1
   cudbNotificationObjectClassId="1"
   dn="EpsDynInfId=EpsDynInf,EpsStaInfId=EpsStaInf,serv=eps,mscId=.*,ou=multiSCs,dc=operator,dc=com"
   name="EpsDynInf"
   type="monitor"
   userLabel=[] <empty>
   CudbNotificationAttr=1

Notification will be triggered for any change of defined monitored attribute(s) in the EpsDynInf object class for every mscId.

Example 4   Using Regular Expressions in dn Attribute with Partial DN (without DE DN Part)

CudbNotificationObjectClass=2
   cudbNotificationObjectClassId="2"
   dn="(grpId=.*,serv=pcrf).*"
   name="PCRFServiceGroup"
   type="monitor"
   userLabel=[] <empty>
   CudbNotificationAttr=1

If the configuration in Example 4 must be restricted to only few values of grpId, the OR operator can be used.

Example 5   Using Regular Expressions with logical operators, in dn Attribute with Partial DN (without DE DN Part)

CudbNotificationObjectClass=2
   cudbNotificationObjectClassId="2"
   dn="((grpId=id1|grpId=id2),serv=pcrf).*"
   name="PCRFServiceGroup"
   type="monitor"
   userLabel=[] <empty>
   CudbNotificationAttr=1

Or, to accomplish the same:

Example 6   Using Regular Expressions with logical operators, in dn Attribute with Partial DN (without DE DN Part)

CudbNotificationObjectClass=2
   cudbNotificationObjectClassId="2"
   dn="(grpId=(id1|id2),serv=pcrf).*"
   name="PCRFServiceGroup"
   type="monitor"
   userLabel=[] <empty>
   CudbNotificationAttr=1

Notification will be triggered for any change of defined monitored attribute(s) in the PCRFServiceGroup object class for any value of grpId.

Example 7   Using Multiple Wildcards in dn Attribute with Whole DN

CudbNotificationObjectClass=3
   cudbNotificationObjectClassId="3"
   dn="recordId=.*,viewId=.*,fqdn=.*,ou=EnumDn.*,serv=enum,ou=servCommonData,dc=operator,dc=com"
   name="NAPTRRecord"
   type="monitor"
   userLabel=[] <empty>
   CudbNotificationAttr=1

Notification will be triggered for any change of defined monitored attribute(s) in the NAPTRRecord object class for any entry whose DN matches the defined pattern.

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 [8].

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 [9].

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 [10].

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 does not trigger any alarms.

3.4   Performance Management

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

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 [7].


Glossary

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


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 Node Logging Events.
[8] CUDB Technical Product Description.
[9] CUDB Node Network Description.
[10] CUDB System Administrator Guide.
[11] CUDB Counters List.
[12] CUDB Glossary of Terms and Acronyms.


Copyright

© Ericsson AB 2016, 2017. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.

Disclaimer

The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.

Trademark List
All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.

    CUDB Notifications