Contents

1   Introduction

This document describes the Ericsson reference data model for the basic and initial data maintained in the Ericsson Centralized User Database (CUDB). This document provides a detailed description of Lightweight Directory Access Protocol (LDAP) objects, classes, and directory entries including attribute description, format, allowed value range, and the allowed LDAP operations.

1.1   Scope

This document covers the following:

• CUDB data model description.
• Attributes and objects classes.
• CUDB DIT entries.
• Operations to handle CUDB data.

The description of any other application Front End (FE) specific data or internal CUDB data is out of the scope of this document.

1.2   Revision Information

1.3   Target Groups

This document is intended for users working with CUDB LDAP schemas. This document assumes the general knowledge of the LDAP standard.

1.4   Typographic Conventions

Typographic conventions can be found in the following document:

• Typographic Conventions

2   Overview

CUDB is the network entity in a layered architecture domain serving as central storage point for application FE data (Home Location Register FE or HLR-FE data, IMS data, and so on).

CUDB is built as LDAP directory server, containing the needed entries and attributes according to the defined schema for the different application FEs.

LDAP is a client-server based directory access protocol that provides both read and update access.

LDAP data information model provides the structures and data types necessary for building an LDAP directory tree.

This document describes the LDAP data provided in the following LDAP schema:

• /cluster/home/cudb/dataAccess/ldapAccess/ldapFe/config/schema/cudb.schema
• /cluster/home/cudb/dataAccess/ldapAccess/ldapFe/config/schema/application_counters.schema

3   CUDB Data Model Description

The following sections describe CUDB data model. For more information on LDAP data model, refer to CUDB LDAP Data Access, Reference [1].

3.1   CUDB Main Directory Information Tree

From LDAP modelling perspective in CUDB, the Directory Information Tree (DIT) is built into the following structures:

• CUDB root entry.
• Administration LDAP user data (out of the scope of this document).
• Identity data.
• Multi service consumer data.
• Association data.
• Multi service consumer common data.
• Service common data.

Figure 1 shows CUDB LDAP DIT.

CUDB has two built-in distribution entries: MSCs and Associations.

CUDB also defines custom distribution entries. Custom of distribution entries must fulfill the following requirement:

• When a distribution entry is provisioned, the following two optional attributes must be defined in any of the object classes it includes:
  • ZoneId.
  • DSUnitGroup.

For more information, refer to CUDB Node Configuration Data Model Description, Reference [3].

3.2   CUDB Application Counters Directory Information Tree

CUDB provides read-only access though the LDAP interface to the set of Application Counters (for more information, refer to CUDB Application Counters, Reference [4]) by means of exposing those counters in a separate LDAP DIT:

• Root Entry (ou=ApplicationCounter)
• Application Counters Group entries (dn: cn=<Counters Group Name>, ou=ApplicationCounter). These entries host no data
• Application Counters entries (dn: cn=<Application Counter Name>,cn=<Counters Group Name>, ou=ApplicationCounter) organized below their respective Counters Group parent entry, and hosting the Counters name and value.

Figure 2 shows the CUDB Licensing DIT.

The new backend of the LDAP FE for counters fetches the value of the column <Application Counter Name> from the table <Counters Group Name>, and puts it in the generic 'value' LDAP attribute. To fetch a counter value, the following LDAP search operation is used:

• Basedn: “ou=ApplicationCounter, cn=<CountersGroupId>, cn=<CounterId>”
• Scope: any (base/one/subtree will return the same)
• Filter: objectclass=* or cn=<CounterId> or CounterValue=* can be used

An example of an LDAP search operation is shown below:

 # ldapsearch -h pl_2_3 -D "cn=manager,dc=operator,dc=com" -w normal -b "cn=NSUBSCNT,cn=GRP_HLRSUBS,ou=ApplicationCounter" //
-s base # extended LDIF
 #
 # LDAPv3
 # base <cn=NSUBSCNT,cn=GRP_HLRSUBS,ou=ApplicationCounter> with scope baseObject
 # filter: (objectclass=*)
 # requesting: ALL
 #
 # NSUBSCNT, GRP_HLRSUBS, ApplicationCounter
 dn: cn=NSUBSCNT,cn=GRP_HLRSUBS,ou=ApplicationCounter
 objectClass: ApplicationCounter
 cn: NSUBSCNT
 CounterValue: 3924600
 # search result
 search: 2
 result: 0 Success
 # numResponses: 2
 # numEntries: 1

3.3   CUDB Root Entry

The Distinguished Name (DN) and Relative Distinguished Name (RDN) of the CUDB root entry are fully configurable at CUDB installation time.

3.4   CUDB LDAP Users and Groups

For application FEs to access the data stored in CUDB via the LDAP interface, one or more LDAP users must be defined with the corresponding credentials and configuration parameters. Application FEs may bind to the CUDB LDAP interface with one of these users and then send the corresponding LDAP operations to CUDB. Groups of users may optionally be defined to share access control rules between LDAP users. For more information on how LDAP users and LDAP users groups are defined in CUDB, refer to CUDB System Administrator Guide, Reference [5].

Due to the LDAP Data Views function, LDAP users that have an LDAP data view assigned to them can access the data through a custom DIT. Users without an assigned LDAP data view can access the data through the core DIT.

Note:  

The LDAP Data Views function can only be used if the Application Facilitator Value Package is available.

CUDB LDAP users and groups are defined through configuration. For more information, refer to CUDB Node Configuration Data Model Description, Reference [3].

Following are the administration data entries defined in CUDB:

• Admin container, "ou=admin,<CUDB root entry>"
• LDAP User data, "cudbUser=<CUDB LDAP user>,ou=admin,<CUDBroot entry>"
• LDAP Group data, "ou=<CUDB LDAP group>,ou=admin,<CUDBroot entry>"
• LDAP User data belonging to a LDAP Group, "cudbUser=<CUDB LDAP user>,ou=<CUDB LDAP group>,ou=admin,<CUDBroot entry>"

3.5   Identity Data

The different identities used to identify and access subscribers (typically MSC or Association) data are placed under ou=”identities” container level entry.

Following are two types of identity entries depending on how these entries are used as reference to an MSC or an Association:

• Primary identities: These entries are always aliases to another entry (typically to an MSC, an Association, or to a secondary identity). As primary identities serve this specific purpose, they are treated as special entries in CUDB in the sense that each type must be defined at installation time and entries are stored in a particular way to optimize the space taken by each entry. Besides this, primary identities can only be stored right under its type container which is populated at installation time. Moreover, CUDB supports a non standard behavior of the LDAP modify operations (alias de-referencing) when the entry to be modified contains a primary identity. For more details, see Section 6.
• Secondary identities: These entries are similar to primary identities in the sense that they are usually used to have references to other entries but the alias does not have to be in the identity itself but also below it. Unlike primary identities, these identities are not treated as special entries in CUDB. For example, a secondary identity could be an entry that contains subentries for different services where each subentry contains an alias referencing to a different MSC or Association.

Figure 3 provides an example of these primary and secondary identity entries.

Following are primary identity data entries defined in CUDB:

• Identity container, "ou = identities, <CUDBroot entry>"

Different containers for different types of identities might be defined related to identity data:

• Identity domain container, "dc=<identity type>, ou= identities, <CUDB root entry>"

  <identity type> can take any value. For example, msisdn, imsi, impi, impu, ipaddress,...

  The entry must contain at least an LDAP object class containing the attribute dc. For example, dcObject.

  Following is an example of container for MSISDN:

  "dc = msisdn, ou = identities, <CUDB root entry>"

Under each different container for the different types of identities alias entries per identity might be defined:

• Identity alias, "<identity type attribute name>=<identity value>, dc=<identity type>, ou = identities, <CUDB root entry>"

  <identity type attribute name> can take any name. For example, msisdn, imsi, impi, impu, ipaddress,...

  This attribute, its type and syntax and the LDAP object class are defined and provided in an LDAP schema by CUDB LDAP clients. The only condition is that the object class must be of type auxiliary.

  The entry must contain the 'alias' object class containing the attribute aliasedObjectName. For example, alias.

  Note:  

  As the 'alias' object class is a structural class, the <identity type attribute> can be added using the 'extensibleObject' object class. Auxiliary object class which, when present in an entry, permits the entry to optionally hold any attribute. The allowed attribute list of this class is implicitly the set of all attributes known to the server.

  
  

  Following is an example of MSISDN alias:

  "MSISDN =<MSISDNnumber>, dc = msisdn, ou = identities, <CUDB root entry>"

  The identity type attribute name must be the same as the identity type. In the above example, the identity type attribute name MSISDN matches the identity type msisdn.

3.6   Multi Service Consumer and Association Data

Specific data for each Multi Service Consumer (MSC) may be placed under different entries identified by the rdn: “mscId = <msc identifier>”. Different entries under this level are created for the different services the MSC is being serviced by.

Association data specific entries are identified by the rdn:"assocId=<associdentifier>". Similarly for the MSC's, different entries under this level are created for the different services the MSC is being serviced by.

Figure 4 provides an example of the MSC and association data.

The following entries are defined in CUDB, related to MSC data:

• Msc container, "ou = multiSCs,<CUDB root entry>"
• Msc's, "mscId = <mscId>, ou=multiSCs, <CUDBroot entry>"
• MSC data for different services can be placed under mscId entry in “serv=<service>, mscId = <mscId>, ou=multiSCs, <CUDB root entry>>", where <service> can take any value. For example, CSPS, Auth and so on.

The following entries are defined in CUDB, related to association data:

• Association container, "ou = associations, <CUDBroot entry>"
• Associations, "assocId = <assocId>, ou=associations,<CUDB root entry>"
• Association data for different services can be placed under assocId entry in “serv=<service>, assocId = <assocID>, ou=associations,<CUDB root entry>>", where <service> can take any value. For example, CSPS, EPS and so on.

Container entries "ou = multiSCs,<CUDB root entry>” and "ou = associations, <CUDBroot entry>” cannot be deleted since they are parent entries of CUDB Distribution Entries. For more information, refer to the "DEs" section of CUDB LDAP Data Access, Reference [1].

3.7   MSC Common Data

MSC common data contains data that is shared by a group of MSC's. It is placed under container level entry ou = mscCommonData. Different entries under this level are created for the different services which the MSC is being serviced by. Each of these entries is referenced by all the MSC's which share this common data using LDAP alias.

Figure 5 shows an example of MSC common data.

The following entries are defined in CUDB:

• Msc common data, " ou=mscCommonData, <CUDBroot entry>"

MSC common data for different services is placed under mscCommonData entry in specific msc common data placed under “serv=<service>,ou=mscCommonData, <CUDB root entry>”

3.8   Service Common Data

Service common data contains data that is shared at application FE level. Different entries under this level are created for different services.

Figure 6 shows an example of service common data.

The following entries are defined in CUDB:

• Service common data, " ou=servCommonData, <CUDB root entry>"

MSC common data for different services can be placed under mscCommonData entry.

• Specific service common data is placed under “serv=<service>,ou=servCommonData, <CUDB root entry>”

3.9   LDAP Views

Note:  

The LDAP Data Views function can only be used if the Application Facilitator Value Package is available.

CUDB supports different LDAP data views in order to support flexible data organization. If an LDAP user has an LDAP view assigned to it, then the user will access the data through that view.

Each LDAP data view has its own LDAP schema loaded into the CUDB, building a custom DIT. It also has a mapping file, which describes how the virtual entries of the specific view are composed from the attributes contained by the core DIT. The CUDB LDAP Data Views function makes it possible to show the data in different DITs accessible through the LDAP interface.

For more information, refer to CUDB LDAP Data Views, Reference [2].

3.9.1   Concepts

The following list contains the concepts used for LDAP views:

• Core DIT: Current way in CUDB of seeing the data stored in the MySQL cluster through the LDAP interface.
• Real entry: Entry in the CUDB core DIT.
• LDAP Data View (View): Configurable alternative tree-like representation of the data stored in the MySQL cluster, by defining entries composed by mapping of attributes from the core DIT.
• Virtual entry: Entry in a view, whose attributes are mapped from one or several real entries.
• One-to-one mapped entries: Fully writable virtual entries that have a direct matching entry in the core DIT. They have the same content as their core DIT counterparts.

4   Attributes and Object Classes

The following sections describe attributes and object classes used in the CUDB.

4.1   Attributes

Table 1 lists the attributes defined by CUDB, both for internal use and the benefit of applications storing data inside CUDB.

(1)  That CDC mechanism to work properly requires that all LDAP clients accessing the entry with CDC attribute use the logic described above. CDC attribute is defined in the schema as a multi-value integer type in order to support providing several values in the LDAP write requests, although one only value is actually written and persistent in the Database. In practical terms it is stored as single-defined but handled as multivalued while processing LDAP requests, therefore it should be defined as multivalued.

(2)  This attribute must be defined in any of the object classes included in the distribution entry.

4.2   Object Classes

An object class identifies a set of attributes in an entry in the DIT. Table 2 shows the object classes used in CUDB.

For more information on syntaxes and matching rules, refer to RFC 4517 LDAP: Syntaxes and Matching Rules, Reference [10].

4.3   Operational Attributes

The CUDB LDAP server supports the following operational attributes, which are detailed in Table 3:

• structuralObjectClass.
• createTimestamp.
• modifyTimestamp.

For more information about these attributes, refer to RFC 4512 LDAP: Directory Information Models, Reference [11].

(1)  These attributes may not be returned for all entries, check CUDB LDAP Data Access, Reference [1] for more information.

There are also CUDB-specific operational attributes, which are the following:

• nodeID: the ID of the node from where the entry was returned (relevant in case of proxied request).
• entryDS: the DS number from which the entry was read.

4.4   Limitations

Following are the limitations on attributes and object classes used in CUDB:

• The maximum number of object classes per entry that may be defined is 100.
• Inheritance is not supported between object classes.
• An object class must not have more than 121 attributes (the real limit is 127 but this margin is left in case, future releases require it for internal use).
• Object class capacity is limited to 8 KB. This limit does not include possible blobs in the object class.
• The attributes cannot store more than 4 KB except for octet string attributes which can hold up to 4 GB.

  Note:  

  The default maximum size for octetString and string attributes in CUDB is 255 octets. All attributes that are bigger than that or significantly smaller may indicate the minimum upper bound for the size between curly brackets "{ }" after the syntax OID. For more information, refer to RFC 4512 LDAP: Directory Information Models, Reference [11].

  DirectoryString and DN attributes use 3 B per character.

  
  
• Distribution entries cannot contain multi-valued attributes.
• The depth of the DIT, that is, the number of sublevels including the root is 12.
• The Relative Distinguish Names (RDNs) of any DN have a limit of 80 unicode characters.
• The maximum length of any DN is 512 unicode characters.
• Alias de-referencing in "subtree" or "onelevel" searches are not supported for the case where the aliases are in subentries under the base DN.
• Aliases in entries under distribution entries pointing to other entries under distribution entries are supported only if both are allocated under the same DSG. For more information, refer to CUDB LDAP Data Access, Reference [1].

5   CUDB DIT Entries

The following sections describe the predefined entries of the CUDB DIT created at installation time. It also contains entries expected to be created under these predefined entries using LDAP schema.

5.1   CUDB Admin Entry

CUDB admin container entry holds data for different CUDB LDAP users. Table 4 shows the CUDB admin entry.

5.2   Identities Container Entry

Identities container entry holds the different identities for the MSC grouped by identity domains. Table 5 shows the identities container entry.

5.3   Multi Service Consumer Container Entry

Multi service consumer container entry holds the entries containing data for all the MSCs in CUDB. Table 6 shows the multi service consumer container entry.

5.3.1   Multi Service Consumer Data Entry

Multi service consumer data container entry contains an MSC. Different sub-entries under this level are created for the different services which the MSC is being serviced by. Table 7 shows multi service consumer data entry.

5.3.2   Multi Service Consumer Data Service Entry

Multi service consumer data service entry is the container for the service specific related multi service consumer data in CUDB. Table 8 shows multi service consumer data service entry.

5.4   Associations Container Entry

Associations container entry is the container for the entries containing data for all the associations in CUDB. Table 9 shows associations container entry.

5.4.1   Association Data Entry

Association data entry contains an association. Different sub-entries under this level are created for the different services which the association is being serviced by. Table 10 shows association data entry.

5.4.2   Association Data Service Entry

Association data service entry is the container for the service specific related association data in CUDB. Table 11 shows association data service entry.

5.5   Multi Service Consumer Common Data Container Entry

Multi service consumer common data container entry is the container for the MSC common data in CUDB. Table 12 shows multi service consumer common data container entry.

5.5.1   Multi Service Consumer Common Data Service Entry

Multi service consumer common data service entry is the container for the service specific related service common data in CUDB. Table 13 shows multi service consumer common data service entry.

5.6   Service Common Data Container Entry

Service common data container entry is the container for the service common data in CUDB. Table 14 shows service common data container entry.

5.6.1   Service Common Data Service Entry

Service common data service entry is the container for the service specific related service common data in CUDB. Table 15 shows service common data service entry.

6   Operations

The following LDAP operations are used to handle CUDB data:

• Bind.
• Add.
• Delete.
• Modify.
• Search.
• Unbind.

The LDAP Data Views function uses the following LDAP operations when accessing data using the view:

• Modify-add: add attribute to a virtual entry, resulting a new attribute in the existing real entry.
• Modify-delete: delete an optional attribute from a virtual entry, resulting a deleted existing attribute in the real entry.
• Modify-replace: replace an attribute in a virtual entry, resulting a replaced attribute in the existing real entry. (If the attribute does not exist, the request is handled as modify-add. If no value is provided, the request is handled as modify-delete.)
• Search: searches involving data from both PLDB and DSG are not supported.

When accessing data through LDAP data views, special kinds of entries can be used, which are called one-to-one mapped entries.

One-to-one mapped entries are real entries with exactly the same contents as the virtual entries and they can be created, deleted, and their contents modified through views without any restriction other than the ones of a real entry.

Note:  

The LDAP Data Views function can only be used if the Application Facilitator Value Package is available.

There are certain special operations provided by CUDB with respect to standard LDAP operations.

CUDB does not support including the abstract ObjectClass top in LDAP modify operations. The abstract objectClass top in modify operations is optional, according to LDAP RFCs. In such case, CUDB returns the following error:

err=80, msgText=Object class not configured in OBJECT_CLASSES table

Alias de-referencing in LDAP modify operations for primary identities is a non standard behavior offered by CUDB. This behavior implies that the aliases found when resolving the target DN specified in an LDAP modify operation are always de-referenced if the original DN of the object to be modified contains a primary identity.

Following are the examples of alias de-referencing with a DN that contains a primary identity:

• serv=csps,IMSI=123456789,dc=imsi,ou=identities, <suffix>
• serv=csps,MSISDN=346162681,dc=msisdn,ou=identities, <suffix>

A CUDB LDAP modify over those two entries will result in the modification of the two entries being referenced by IMSI=123456789 and MSISDN=346162681 aliases. It means that both, mscId=id and assocId=id are going to be modified through their corresponding aliases, as depicted in Figure 7:

A standard behavior of the LDAP modify would not de-reference, meaning that, in the example above, no modification would take place in mscId=id and assocId=id. In this case the LDAP modify query returns an error saying that the required entry does not exist.

6.1   CUDB Shortcut in Search for Authentication Data

When a search operation is received from any CUDB LDAP client with the baseObject: dn: serv=Auth, IMSI =<IMSInumber>, dc = imsi, ou = identities, <CUDB root entry> and alias dereferencing is equal to "finding" or "always", then the operation is interpreted as if baseObject: dn: IMSI =<IMSInumber>, serv=Auth, IMSI =<IMSInumber>, dc = imsi, ou = identities, <CUDB root entry> was received instead.

The same applies for LDAP modify operations for the above baseObject.

6.2   Performing LDAP Search Below the Distributed Entry

The CUDB subscriber-centric data model (depicted in Figure 1) enables data consolidation by means of storing applications service profiles right below a distribution entry (mscId or asscoId).

Client applications only retrieve the data of their own service profiles (their application data model below serv=<service> entries) and are unaware of other populated profiles created at the same level below the distribution entry.

The CUDB search engine is optimized for the best performance to serve LDAP search operations that target individual entries, by using the distinguished name of the entry as search base object. Use this type of searches for the best performance.

To enhance the performance of LDAP subtree searches, the CUDB search engine implements an index optimization function for those search operations that drill the LDAP DIT down starting from a start base entry and fetch different LDAP entries. For more information, refer to the "LDAP Massive Search Indexes" section in CUDB Application Integration Guide, Reference [8].

To take full advantage of the index search optimization, always set the best possible search base for the LDAP operation, for example at the location in the directory tree from which the LDAP subtree search begins.

As a general recommendation, always start the subtree searches of applications from a serv=<service> entry or any other entry below it as the search base object. In other words, do not use subtree searches starting from the distribution entry, otherwise the scanning of every other service profiles and their child entries can cause significant performance drop.

6.3   Error Codes

CUDB LDAP interface supports the existing LDAP result codes described in the LDAP protocol specifications. For more information, refer to RFC 4511 LDAP: The Protocol, Reference [12].

Table 16 shows the LDAP result codes in CUDB, describing the possible causes for each error and possible actions about how to handle these errors from the client application perspective.

Note:  

The "Description" column is written in order to provide the most common reasons why the corresponding error is received. Note, that this description does not give all the possible problems. The message diagnostic text can provide more specific information about the error.

For additional information on causes due to overload, mastership change, unavailability or unreachability, refer to the following Facility Descriptions:

• CUDB LDAP Data Access, Reference [1]
• CUDB High Availability, Reference [7]

For more information on error codes, refer to CUDB LDAP Data Access, Reference [1].

6.4   LDAP Controls

The LDAPv3 allows clients and servers to use controls as a mechanism for extending an LDAP operation. A control is a way to specify additional information as part of a request and a response. For more information, refer to RFC 4511 LDAP: The Protocol, Reference [12].

6.4.1   ReadMode Control

CUDB LDAP interface supports ReadMode control with Object ID=1.3.6.1.4.1.193.169.3.3, which is used to override the LDAP read mode user settings for PLDB and DSG.

The ReadMode LDAP control is not supported for LDAP write operations, such as modify, add, or delete. If the Extension Control criticality in the write request is set to FALSE, the control is simply ignored and operation is processed normally. If the Extension Criticality is set to TRUE, the LDAP request will receive an err=12, msgText=critical extension is unavailable message.

In case of distributed or massive searches, that is, the search requests that are distributed to various DSGs, the ReadMode control content is always ignored regardless of criticality.

When ReadMode control is used by applications, the recommended setting for criticality is FALSE.

For more information, refer to RFC 4511 LDAP: The Protocol, Reference [12].

The ReadMode control has a numeric value, indicating a combination of readModeinPL and readModeinDS that will be applied to particular LDAP search request.

When a search request is received with ReadMode control, the read mode control values extracted take precedence over readModeInDS and readModeInPL values configured in LDAP user.

Glossary

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

Reference List