The SAPC supports user and password authentication when connecting to the external database. For details, see Configure LDAP User Authentication.

Entities can relate ones to others in a chained way. There are two different ways of making relations among application objects:

• Structural: Entity Data Source can be nested, by using their fields, that is, an Entity Data Source field refer to another Entity Data Source. Next an example:

  def Entity1( arg1) {
      dataSource = {
       url = ...;
     }
     fieldDef = {
       id           = arg( "arg1" );
       field1       = dataSourceField("...");
       field2       = dataSourceField("...");
       entity2Data  = Entity2( id );
     }
  }
  
  
  def Entity2( arg2 ) {
      dataSource = {
       url = ...;
     }
     fieldDef = {
       id           = arg( "arg2" );
       fieldA       = dataSourceField("...");
       fieldB       = dataSourceField("...");
     }
  }

  The use of this case within a policy condition is as follows: Entity1.entity2Data.fieldA.

  These relationships (marked by the left sides of fieldDef block) are provided at installation time in the SAPC and the operator must not change them. The operator has the flexibility to define how to map to the physical actual data model (right sides using dataSourceField).

• Dynamic: For entities that are not predefined in advanced in the SAPC, their relationship can be established by configuration.

Figure 5   Chaining Entities

To perform a search, the SAPC supports single or composed keys. Entities can be linked based on a primary key (single input argument) scheme or based on composed key (multiple input arguments). The output result from a query done to locate an Entity, can be used as input parameter for another Entity search.

The SAPC can use as such keys data received from traffic messages (like MSISDN, UE IP Address, location, IMEI, APN) or obtained from another Entity. For more flexibility, the SAPC can also use policy functions (specified in Configuration Guide for Subscription and Policies) to transform these keys.

Next figure summarizes the relations among the main preconfigured Entities and other relevant application objects:

Figure 6   Subscriber, Subscriber Group and Service Relations

To process a traffic request corresponding for a Subscriber, the SAPC executes the following procedure:

1. The SAPC starts looking for the subscriber profile: for Subscriber (and its chained Entities), entries can be located used input arguments in two exclusive ways:

   • Single key: with a unique argument and no default value. The SAPC needs to consider an argument (key) for the subscriber. The SAPC uses the following procedure to determine the subscriber key:

     1. The SAPC looks first if it is configured the SubscriberIdentity Entity Data Source, using as argument the value for the subscriber identifier received within the traffic request. If this is found, the adminId field from that entity is used as the argument for the Subscriber entity.

     2. If SubscriberIdentity is not found, the SAPC looks for the Subscriber entity, using as argument the value received within the traffic request.

     Note:

     The SAPC uses the following traffic identifiers: Subscription-Id AVP requests.

     Example: def Subscriber (argId)

   • Multiple keys: with several arguments.

     Examples:

     def Subscriber (arg1, arg2='AccessData.bearer.accessPoint')

2. The SAPC makes a search for each of the active groups of the subscriber. The SAPC business logic also uses an implicit "global" group for all subscribers. So, an extra query to fetch the "global" subscriber group data is done.

3. The SAPC makes a query for each of the services defined in the subscriber and active subscriber groups.

The use of Entity Data Sources allows the SAPC to evaluate policy conditions using data not known in advance, and such data can be stored in an external database.

Next figure explains the syntax of how new Entity attributes can be used inside policy conditions.

Figure 7   Example of Entity Tags to Be Used in a Policy Condition

Different pieces of the SAPC subscriber profile data can be located in different repositories, but with some considerations.

Only the subscriber data that are chained by chained Entities can be hosted in different repositories, given that each Entity Data Source can have a different data location defined.

Subscriber data extensions (for use in policy condition evaluation) through operator-specific information can only be located in the same repository where the subscriber is located. The advantage of this is that updates in the extended fields, trigger a reauthorization (through SOAP notification in case of LDAP access).

It is also possible to put subscriber data extension in a different repository, creating an entity for the subscriber. It is possible to refer directly to this entity or it is possible to chain it in the Subscriber entity. But updates in the data attribute pointed by this configured entity does not always trigger a subscriber reauthorization.

It is possible to configure new data (not related to subscriber) being stored in the SAPC internal database for its use within policy conditions.

For example, the operator wants to check if a flag called flatRate is true, and if a request is being processed during promotion months. And the operator wants to store such extra data in the internal database provided by the SAPC.

Figure 9   Subscriber Data Extension Stored in internal database

For the configuration details, see Configure Extra Data In internal database.

It is possible to distribute different entries of the same application object in different repositories. This is possible using multiple input arguments (see Configure Keys for Application object Searches). However, it is not possible to mix different database access technologies (for example some subscribers in LDAP and some other subscribers in internal database).

An example: some Subscribers are physically stored in LDAP Repository 1 or 2 depending on the country, according to Figure 10.

Figure 10   Subscribers Distributed By Country

To achieve this, it is needed to use several input parameters, and use a new Entity Data Source as extra argument to locate Subscribers that returns as output result the repository in which each subscriber is distributed. See Example 6 for the configuration details.

It is not possible to store some Subscribers in an external database (for example LDAP) and some others internally in the SAPC internal database. The reason is that the same Entity Data Source definition is used for both set of subscribers and its data location cannot point to different database access technologies.

Figure 11   Not Possible to Mix Different Types of Repositories

The SAPC imposes a fixed application object data model, the one provided at installation time.

Furthermore, for external LDAP, Ericsson recommends as the optimal physical database schema (fully verified), the one for UDC (see Integration in User Data Consolidation). There are some constraints in mentioned schema. For example, Subscriber groupdIds field must be multivalued.

Not Needed Data

When an application object related to a particular function is not used, it is not needed to complete all its fieldDefs; it is possible to modify the SAPC preconfigured Entity Data Source, to leave empty the right side of the fieldDef.

As example, next figure shows how to skip end-user notifications and fair usage data:

Figure 12   Shortcut for not Needed Data

For the optimal physical data model in an LDAP repository, read Integration in User Data Consolidation: it contains the LDAP data model (DIT and schema) for Subscriber profile data, and the corresponding Entity Data Sources configuration. It also explains error, connection handling, database failover, and failback mechanisms that the SAPC supports with LDAP.

Ericsson recommends that the DIT schema has the less number of levels as possible. It is also recommended to gather under the same object class, as many data as possible representing Subscriber profile.

To reduce the number of accesses and retrieve several entries at once, it is possible to use some standard LDAP features such as scope, filtering, and alias de-referencing. Its use depends on the support of such functions in the external LDAP repository and on the particular operator data model, see Lightweight Directory Access Protocol, RFC 4511.

Next figure shows the different LDAP scopes.

Figure 13   LDAP Scopes

To minimize the number of searches, multiple object entries can be fetched using the same LDAP query. To do that:

• Use subtree scope, to get all object classes under a particular DIT node.

• Use alias to obtain as well the objects stored in a different DIT branch. The use of alias implies some extra provisioning in the external LDAP repository (by using alias (never/always/search/find) and extensibleObject object classes).

It is possible to use one or several input arguments (keys) to support composed indexes when retrieving Entities from external database in a flexible way. These arguments are the variable parts that can be used to perform the query towards the external database.

The input arguments are the first thing specified in the Entity Data Source, in definition attribute, between parenthesis before the dataSource block.

Default values for the input arguments can be specified (in the same way as in a programming language) using ='<default_value>' notation.

It is possible to use as default value any of the supported policy expressions according to the policy language specified in Configuration Guide for Subscription and Policies.

Some examples of input arguments are:

'AccessData.subscriber.id'
'AccessData.subscriber.ueIpAddress'
'AccessData.subscriber.locationInfo.sgsnAddress'
'AccessData.userEquipmentInfo.model'
'AccessData.bearer.accessPoint'

For newly defined Entities, default values can be used in every argument.

def Subscriber ( arg1='AccessData.subscriber.id',
                 arg2 = 'Subscriber.birthDate' ){
   dataSource = { ... }
   fieldDef ={
      id = dataSourceField("id"); 
      groups = dataSourceField("dataplans");
      trafficIds = dataSourceField("trafficIds");
      sharedDataplan = dataSourceField("sharedDataplanId"); 
      subscribedServices = dataSourceField("subscribedContents");
      blacklistServices  = dataSourceField("deniedContents");
      ...
      activationDate     = dataSourceField("name:subscriptionDate");
      cellID             = dataSourceField("name:cellId");
      birthDate          = dataSourceField("name:birth");
   }
 }

Previous example shows that default argument for arg2 in Subscriber Entity makes a reference to birthDate attribute of Subscriber Entity itself.

Entity Data Sources provided at installation time cannot be deleted. They can be modified, but the following restrictions apply to their content:

Figure 16   Example of Preconfigured Subscriber Entity Data Source

The complete list of fieldDef attributes for an Entity, can be get by COM, getting the corresponding EDSourceId instance.

• The eDSourceId value cannot be modified.

• The Entity Data Source name in the definition attribute cannot be modified.

• The field names (left sides) defined within the fieldDef section in the definition attribute cannot be changed neither removed. The right sides can be modified, with the consideration that they have to be of the same type.

  Do!

  The names of the LDAP attributes used in the right sides of the fieldDef section, are case-sensitive, they have to match exactly with the external LDAP schema.

To write Subscriber usage accumulators in an LDAP repository, but Family usage accumulators in internal database, define AccumulatedUsage Entity Data Source pointing to LDAP, and AccumulatedUsageSharedDataplan to internal database. For configuration details, see Example 8.

To apply this fallback, follow the steps explained for unknown subscriber in Configuration Guide for Subscription and Policies, with the following exception: leave the usageLimits field empty using empty string "".

Assure that SubscriberUnknown and GroupsToSubscriberUnknown Entity Data Sources point to the SAPC internal database (url="internaldb:") .

Next example illustrates the case where before retrieving a Subscriber instance from an LDAP repository, the argument (MSISDN) is transformed by substituting the two first characters by '06'. If the original argument was 34701234567890, the transformed one is 06701234567890, and the last one is the used to retrieve the Subscriber data from the repository.

def Subscriber( argId = 
    'strcat("06", substr((AccesData.subscriber.id), 2, 0))' ) { 
  dataSource = { 
    url = "ldap://10.20.30.40:7323/o=company,c=es?";
    query = "(msisdn={argId})";
  } 
  fieldDef = {
     ...
  }
}

For the detailed configuration to hold application Subscriber objects in an external LDAP server (CUDB), the optimal data model can be found in Integration in User Data Consolidation.

The rest of examples provided in this section, show configuration examples for a generic LDAP server, for the shake of learning.

Example 7 is an Entity Data Source definition for a new entity that only contains constants:

Example 7   NodeConstants Entity

<edit-config>
    <target>
    <running />
    </target>
    <config>
   <ManagedElement xmlns="urn:com:ericsson:ecim:ComTop">
    <managedElementId>1</managedElementId>
    <dnPrefix>dc=ManagedElement</dnPrefix>
    <networkManagedElementId>1</networkManagedElementId>
    <userLabel>Managed Element</userLabel>
    <PolicyControlFunction xmlns="urn:com:ericsson:ecim:sapcmom">
      <policyControlFunctionId>1</policyControlFunctionId>
         <EntityData xmlns="urn:com:ericsson:ecim:entitydatamom">
            <entityDataId>1</entityDataId>
            <EDSources xmlns="urn:com:ericsson:ecim:edsourcesmom">
               <eDSourcesId>1</eDSourcesId>
                  <EDSource xmlns="urn:com:ericsson:ecim:edsourcemom" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
                     <eDSourceId>NodeConstants</eDSourceId>
                     <definition>
     def NodeConstants (  )
    {
      dataSource = { url = ""; query = ""; }
      fieldDef = { 
	    countryCode = "34"; 
		maxBitRate = "8000";
	  } 
    }
                   </definition>
               </EDSource>
            </EDSources>
         </EntityData>
   </PolicyControlFunction>
   </ManagedElement>
   </config>
</edit-config>

See Configure Subscriber Data Extension in Configuration Guide for Subscription and Policies.

Example 8 shows how to configure Entity Data Sources to read and write usage accumulators related to subscribers from an external LDAP, but usage accumulators for a shared dataplan in the SAPC internal database.

Example 8   Subscriber accumulators

<edit-config>
    <target>
    <running />
    </target>
    <config>
   <ManagedElement xmlns="urn:com:ericsson:ecim:ComTop">
    <managedElementId>1</managedElementId>
    <dnPrefix>dc=ManagedElement</dnPrefix>
    <networkManagedElementId>1</networkManagedElementId>
    <userLabel>Managed Element</userLabel>
    <PolicyControlFunction xmlns="urn:com:ericsson:ecim:sapcmom">
      <policyControlFunctionId>1</policyControlFunctionId>
         <EntityData xmlns="urn:com:ericsson:ecim:entitydatamom">
            <entityDataId>1</entityDataId>
            <EDSources xmlns="urn:com:ericsson:ecim:edsourcesmom">
               <eDSourcesId>1</eDSourcesId>
                  <EDSource xmlns="urn:com:ericsson:ecim:edsourcemom" xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
                    <eDSourceId>AccumulatedUsage</eDSourceId>
                      <definition>
   def AccumulatedUsage ( argId ) {
      dataSource ={
        url = "ldap://10.20.30.40:389/
            accumId={argId},
            ou=SAPC,mscId={argId},ou=multiServiceConsumer,
            ou=Customer_DB,dc=myDomain,dc=com";
        query = "?scope=sub?(objectclass = *)?{alias=always;entry=serv=PCRF,
            mscId={argId},ou=multiServiceConsumer,
            ou=Customer_DB,dc=myDomain,dc=com;}";
      }
      fieldDef = {
         id = dataSourceField("accumId");
         data = dataSourceField("accumData");
      }
    }
                   </definition>
                 </EDSource>
			 </EDSources>
         </EntityData>
   </PolicyControlFunction>
   </ManagedElement>
   </config>
</edit-config>

For the detailed configuration to read and write session context from an external LDAP, see Integration in User Data Consolidation.

This section contains some examples on how the tags defined in Entity Data Source can be used within policy conditions.

In a scenario with external database, the SAPC can raise the following alarm:

• Connection Failure to external database.

Not applicable.