Contents

1   Configure Access andCharging Overview

Figure 1 shows the main parts related to configuration and provisioning in the SAPC.

The purpose of this document is to provide guidelines to configure the SAPC for Access and Charging Control by providing configuration examples.

This document is not intended as an exhaustive guide to configure the SAPC for every possible scenario.

To understand general provisioning concepts and details regarding subscriptions and policies, refer toConfiguration Guide for Subscription and Policies.

The complete parameter list and details of all configured options of the SAPC are included in separate documents, refer to Managed Object Model (MOM) and Provisioning REST API.

Examples in this document cover the case of data configured in the SAPC internal repository. If an external repository is used, refer to Database Access.

Table 1 summarizes the configuration elements in the SAPC related to access and charging control.

1.1   Other Conventions

This document refers to some configuration and provisioning data.

To clarify which detailed data is managed by COM or by the REST API, this document uses the following conventions:

• Configuration: whenever referring to Managed Object Class (MOC).

  The detailed description of the object and attributes can be found in Managed Object Model (MOM).

  Example: set enableReauthsOnSubsChange attribute in class AppConfig.

  The tools or interfaces to manage these data in the SAPC are:

  1. NETCONF interface, refer to Ericsson NETCONF Interface.

     The configuration examples show the NETCONF file contents, using the following syntax:

     <edit-config>
       ...
       <config>
       <ManagedElement xmlns="urn:com:ericsson:ecim:ComTop">
       <managedElementId>1</managedElementId>
            ...
       </ManagedElement>
       </config>
     </edit-config>

  2. COM CLI, refer to Ericsson Command-Line Interface.
• Provisioning: mainly subscribers, subscriber groups (dataplans), services (contents), profiles, and policy-related data. The SAPC provides a REST API for them, see Provisioning REST API.

  This document uses the following terminology for them: <resource-name> URI in the provisioning REST API.

  Example: To provision subscriber groups, use the dataplan URI in the provisioning REST API.

  Provisioning examples show HTTP operations on REST resources with the following syntax:

  HTTP-Operation /resource-URI 
      {json content}

  where /resource-URI is the relative URI from the SAPC provisioning base URI detailed in Provisioning REST API.

  Example:

  PUT /dataplans/Gold   
  { "dataplanName" : "Gold",
    "subscribedContents" : [{"contentName" : "HTTP_Streaming",
                             "redirect" : false}]
  }

  Note:  

  To ease provisioning operations, the SAPC provides an HTTPS CLI client named resty, refer to Provisioning Tools.

  
  

2   Configuration Prerequisites

Before configuring the SAPC in an operational network, make sure that:

• CBA Components are installed
• The SAPC product software is installed
• The SAPC user performing configuration changes has thorough knowledge of the function

3   Configure Gx Diameter Network Data

Note:  

The Origin-Host, Origin-Realm, IP address and diameter port values are set during the SAPC installation procedure. Diameter data related to capabilities exchange (application and vendor identifiers) are provided at installation time, so that no manual procedure is needed.

3.1   Configure Gx PCEFs

The controls (for example IP-CAN Session Access Control, Service Access Control) that the SAPC execute when receiving Gx traffic, are configured at PCEF level. To define a PCEF, create a DiameterNode instance using the value sent by the PCEF in the Origin-Host AVP as the diameterNodeId key.

Note:  

The SAPC does not execute any default action for a control that is not configured on the Diameter node. The values in the controls attribute are detailed along SAPC Configuration Guide documents (including this document).

The following example shows a GGSN/PDN-GW configuration supporting IP-CAN Session Access Control, Service Access Control, and Bearer QoS Control:

<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>
            <Network xmlns="urn:com:ericsson:ecim:networkmom">
            <networkId>1</networkId>
                <DiameterNodes>
                <diameterNodesId>1</diameterNodesId>
                    <DiameterNode xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
                    <diameterNodeId>ggsnHostname.operator.com</diameterNodeId>
                        <controls>IP_CAN_SESSION_ACCESS</controls>
                        <controls>SERVICE_ACCESS_PCEF_TOD</controls>
                        <controls>BEARER_QOS</controls>
                        <dynamicServiceSupport>true</dynamicServiceSupport>
                    </DiameterNode>		
                </DiameterNodes>        
            </Network>
         </PolicyControlFunction>
    </ManagedElement>
    </config>
</edit-config>

 

3.1.1   Support for Interoperability with PCEFs Handling Gx Rel9 Versions 9.1.0 or 9.0.0

To provide support for Gx Rel9 versions 9.1.0 and 9.0.0, the operator can enable the gxRel91OrLowerCompatibility attribute. This attribute is configured at the DiameterNode level of the PCEF configuration.

When this attribute is enabled (set to true):

• The Flow-Description AVP uplink (direction 'in') inside Flow-Information is supported.
• The Flow-Direction AVP is not supported.

3.2   Configure PCEFs for Interworking with Clustered Diameter Systems

A clustered system is a logical system (for example, different hardware boards handling the same pool of UE IP addresses) sending Diameter traffic to the SAPC with different Origin-Host, but that from the point of view of the SAPC works as a single entity. This way, the SAPC considers a single peer for the incoming Diameter messages coming from the different Diameter peers (different Origin-Host) belonging to the same logical cluster and avoids considering the PCEFs as Multiple Gx.

In the same way, PCEFs working in redundancy mode (for example, one acting as active, and another one acting in standby), where they send different Origin-Host to handle the same pool of UE IP addresses can be grouped in a logical cluster.

To configure the different Origin-Host as a single logical system in the SAPC, do the following:

1. Create a single DiameterNode instance: the diameterNodeId attribute value (key), is the logical cluster identity that the SAPC internally considers as the PCEF identifier.
2. Set the value of the pattern to be matched with all the received Origin-Host in the clusterPattern attribute.

Example 2 shows a configuration of two clustered PCEFs.

On the one hand, the PCEF nodes sending Origin-Host values like PCEF-D-1.operator.com and PCEF-D-2.operator.com respectively, are grouped as pcefCluster from the SAPC point of view, sharing the operator.com ending as the clusterPattern value.

On the other hand, nodes sending Origin-Host values like operator-sasn-1.de.com and operator-sasn-2.de.com respectively, are grouped as sasnCluster, sharing the operator-sasn beginning as clusterPattern establishes.

<edit-config>
    <target>
        <running/>
    </target>
    <config>
    <ManagedElement xmlns="urn:com:ericsson:ecim:ComTop">
    <managedElementId>1</managedElementId>
        <PolicyControlFunction xmlns="urn:com:ericsson:ecim:sapcmom">
        <policyControlFunctionId>1</policyControlFunctionId>
            <Network xmlns="urn:com:ericsson:ecim:networkmom">
            <networkId>1</networkId>
                <DiameterNodes>
                <diameterNodesId>1</diameterNodesId>
                    <DiameterNode xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
                    <diameterNodeId>pcefCluster</diameterNodeId>
                        <controls>IP_CAN_SESSION_ACCESS</controls>
                        <controls>SERVICE_ACCESS_PCEF_TOD</controls>
                        <controls>BEARER_QOS</controls>
                        <clusterPattern>operator.com</clusterPattern>
                    </DiameterNode>		
                    <DiameterNode xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
                    <diameterNodeId>sasnCluster</diameterNodeId>
                        <controls>IP_CAN_SESSION_ACCESS</controls>
                        <controls>SERVICE_ACCESS_PCEF_TOD</controls>
                        <controls>BEARER_QOS</controls>
                        <clusterPattern>operator-sasn*</clusterPattern>
                    </DiameterNode>		
                </DiameterNodes>        
            </Network>
        </PolicyControlFunction>
    </ManagedElement>
    </config>
</edit-config>

 

Note:  

It is not needed to define a DiameterNode instance for each of the Origin-Host AVPs.

If several DiameterNode instances are configured, one with the complete value of the received Origin-Host AVP, and another one as cluster (with the Origin-Host value matching the clusterPattern attribute), the SAPC gives precedence to the cluster. The detailed DiameterNode instance is not used.

Example: the SAPC receives a Diameter message with Origin-Host = node1.myOperator.com, and the following DiameterNodes are configured:

DiameterNode=node1.myOperator.com
  controls = ...
  clusterPattern = ""

DiameterNode=clusterMyOperator
  controls = ...
  clusterPattern = "myOperator.com"

The SAPC uses the configuration of DiameterNode = clusterMyOperator, and ignores the configuration of DiameterNode = node1.myOperator.com.

3.3   Configure Multiple Gx Scenario

An IP-CAN session can be controlled by several PCEFs (different DiameterNode configured in the SAPC). The typical case for that is that each PCEF enforces a different set of controls. It is needed to configure the controls that each PCEF supports. When a Gx request is received, the controls supported by the PCEF are checked against what it is configured in the SAPC corresponding DiameterNode.

Note:  

The support for preconfigured and dynamic services has to be enabled only in one of the PCEFs (the one acting as the traffic gateway). Ensure that the dynamicServiceSupport attribute is set to true in only one DiameterNode. Otherwise, Gx traffic related to preconfigured or dynamic PCC rules can malfunction.

Example 3 shows how some controls are configured for these different PCEFs:

• A node (dpiHostname.operator.com) acting as a Peer to Peer (P2P) service identifier performing Deep Packet Inspection (DPI) that only supports Content Filtering.
• An Ericsson PDN/GW (ggsnHostname.operator.com) supporting all controls available in the Ericsson Gx+ interface.

<edit-config>
    <target>
        <running/>
    </target>
    <config>
    <ManagedElement xmlns="urn:com:ericsson:ecim:ComTop">
    <managedElementId>1</managedElementId>
        <PolicyControlFunction xmlns="urn:com:ericsson:ecim:sapcmom">
        <policyControlFunctionId>1</policyControlFunctionId>
            <Network xmlns="urn:com:ericsson:ecim:networkmom">
            <networkId>1</networkId>
                <DiameterNodes>
                <diameterNodesId>1</diameterNodesId>
                    <DiameterNode xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
                    <diameterNodeId>dpiHostname.operator.com</diameterNodeId>
                        <controls>CONTENT_FILTERING</controls>
                        <dynamicServiceSupport>false</dynamicServiceSupport>
                    </DiameterNode>	
                    <DiameterNode xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" nc:operation="merge">
                    <diameterNodeId>ggsnHostname.operator.com</diameterNodeId>
                        <controls>IP_CAN_SESSION_ACCESS</controls>
                        <controls>BEARER_QOS</controls>
                        <controls>SERVICE_ACCESS_PCEF_TOD</controls>
                        <controls>SERVICE_CHARGING</controls>						
                        <controls>SUBSCRIBER_CHARGING</controls>
                        <controls>USAGE_REPORTING</controls>						
                        <dynamicServiceSupport>true</dynamicServiceSupport>
                    </DiameterNode>		
                </DiameterNodes>        
            </Network>
        </PolicyControlFunction>
    </ManagedElement>
    </config>
</edit-config>

 

4   Configure Event Triggers Selection

4.1   Provision Unconditionally Event Triggers Selection

To indicate to the PCEFs which Gx event triggers are at the subscriber level, subscriber group level, or application level for which the SAPC is interested in receiving CCR Updates, set the eventTriggers attribute in the subscribers, dataplans, or global dataplans URI in the provisioning REST API.

Configuring the location change related event triggers (for example RAI change, TAI change, ECGI change, ULI change) at the subscriber or subscriber group level can minimize the network signalling compared to configuring them at the SAPC level.

Example 4 presents the configuration of an event triggers notification at the subscriber level.

PUT /subscribers/34610601307

{
	"subscriberId" : "34610601307",
	"eventTriggers": [2,7]
}

 

In the example above, the SAPC subscribes to RAT change and IP-CAN change event triggers for subscriber "34610601307".

Example 5 presents the configuration of an event trigger at the subscriber group level. In this example, the SAPC subscribes to SGSN change and IP-CAN change event triggers for the "Gold" subscriber group.

PUT /subscribers/34610601307

{
	"subscriberId" : "34610601307",
	"dataplans" : 
	[
		{
			"dataplanName" : "Gold"
		}
	]
}

PUT /dataplans/Gold

{
	"dataplanName" : "Gold",
	"eventTriggers": [0,7]
}
 

Example 6 presents the configuration of an event notification at SAPC level. In this example, the SAPC subscribes to SGSN change, RAT change, PLMN change, and successful resource allocation event triggers at application level.

PUT /dataplans/global
{
        "dataplanName" : "global",
        "eventTriggers" : [0,2,4,22]
}
 

4.2   Provision Event Trigger Selection Policies

To configure event triggers depending on conditions, create the needed policies using:

• For Global Policy locator:

  /locators/resources/any/contexts/event-triggers

• For Subscriber Group locator:

  /dataplans/<dataplanName>/locators/resources/any/contexts/event-triggers

• For Subscriber locator:

  /subscribers/<subscriberId>/locators/resources/any/contexts/event-triggers

• Within the outputAttributes object in the rule, set:
  • attrName attribute to event-triggers
  • attrValue to the event triggers list of values, comma separated.

Example 7 shows a subscriber policy for event triggers selection:

PUT /rules/DynamicEventTriggersSubscriber

{
	"condition" : "(AccessData.bearer.accessType==1000)",
	"outputAttributes" : 
	[
		{
			"attrName" : "event-triggers",
			"attrValue" : "\"13,48\"",
			"result" : "permit"
		}
	],
	"ruleName" : "DynamicEventTriggersSubscriber"
}

PUT /policies/DynamicEventTriggersPolicy

{
	"policyName" : "DynamicEventTriggersPolicy",
	"ruleCombiningAlgorithm" : "all-permit",
	"rules" : [ "DynamicEventTriggersSubscriber" ]
}

PUT /subscribers/34610601307/locators/resources/any/contexts/event-triggers

{
 "policies" : [ "DynamicEventTriggersPolicy"]
}

4.3   Combining Static Qualification and Policies for Event Triggers

The SAPC combines the event triggers from the dynamic selection and from the static selection together. From Example 4, Example 5, Example 6, and Example 7, the SAPC sends the following list of event trigger values:

0, 2, 4, 7, 13, 20, 22, 48

5   Provision Services

The services controlled by the SAPC must be provisioned. To provision services, use the contents URI in the provisioning REST API.

The SAPC supports the following types of services:

• Static

  Predefined in the PCEF, activated by the SAPC, and identified in Gx by the Charging-Rule-Name AVP or the Charging-Rule-Base-Name AVP.

• Preconfigured

  Locally set in the SAPC by the operator, downloaded from the SAPC towards the PCEF through Gx using the Charging-Rule-Definition AVP.

• Dynamic

  Dynamically generated (and modified) in the SAPC from information coming from the Application Function (AF) (by the Rx Interface). Dynamic services are downloaded from the SAPC to the PCEF through Gx using the Charging-Rule-Definition AVP.

  For more information, see Configuration Guide for Dynamic Policy Control (Rx).

The configuration elements related to service provisioning are:

• PCC rules
• Service Charging Data

5.1   Set PCC rules

To set a PCC rule for a static or preconfigured service (only a single PCC rule), fill the following attributes in the corresponding contents URI in the provisioning REST API:

1. Set the pccRuleName (unique identifier) attribute
2. For static PCC rules

   These PCC rules are identified by a name (Charging-Rule-Name AVP) or basename (Charging-Rule-Basename AVP). Both the name and basename must be the same as provisioned in the PCEF.

   1. When the PCC rule is identified by name, set value 0 in the pccRuleType attribute
   2. When basename is used, set value 1 in the pccRuleType attribute

   For IPv4v6 dual stack IP-CAN sessions, it is necessary to configure some filters in the PCEF to distinguish which PCC rule applies to IPv4 or IPv6.

3. For preconfigured PCC rules (identified by the Charging-Rule-Name AVP)
   1. Set value 2 in the pccRuleType attribute
   2. To provision the service data flows, use the flows attribute.

      For IPv4v6 dual stack IP-CAN sessions, it is also possible to define a single PCC rule that contains service data flows for both IPv4 and IPv6.

   3. To set the precedence of a PCC rule compared to other PCC rules running on the same IP-CAN session, set the precedence attribute.

      The precedence attribute can have values from 0 to 2⁵-1 meaning the five most significant bits of the priority (lower value means higher precedence). The precedence value is shifted 3 bits and added to the dynamic part.

      See Table 2 for information on AVP precedence values.

Example 8 provisions different services and PCC rules.

PUT /contents/Chat
{
	"contentName" : "Chat",
	"pccRuleName" : "1000",
	"pccRuleType" : 0
}

PUT /contents/Internet
{
	"contentName" : "Internet",
	"pccRuleName" : "2000",
	"pccRuleType" : 1
}

PUT /contents/Skype
{
	"contentName" : "Skype",
	"flows" : 
	[
		{
			"destIpAddr" : "any",
			"destPort" : "",
			"direction" : "dl",
			"flowName" : "1",
			"protocol" : "ip",
			"sourceIpAddr" : "10.220.100.1",
			"sourcePort" : "5001"
		},
		{
			"destIpAddr" : "10.220.100.1",
			"destPort" : "5002",
			"direction" : "ul",
			"flowName" : "2",
			"protocol" : "ip",
			"sourceIpAddr" : "any",
			"sourcePort" : ""
		},
		{
			"destIpAddr" : "any",
			"destPort" : "",
			"direction" : "dl",
			"flowName" : "3",
			"protocol" : "ip",
			"sourceIpAddr" : "2000:1111:2222:4444:5555:ABCD:7777:0002",
			"sourcePort" : "5001-5050"
		},
		{
			"destIpAddr" : "2000:1111:2222:4444:5555:ABCD:7777:0002",
			"destPort" : "5101-5150",
			"direction" : "ul",
			"flowName" : "4",
			"protocol" : "ip",
			"sourceIpAddr" : "any",
			"sourcePort" : ""
		}
	],
	"pccRuleName" : "5001",
	"pccRuleType" : 2
}

PUT /contents/Streaming
{
	"contentName" : "Streaming",
	"flows" : 
	[
		{
			"destIpAddr" : "any",
			"destPort" : "",
			"direction" : "dl",
			"flowName" : "1",
			"protocol" : "ip",
			"sourceIpAddr" : "192.168.1.2",
			"sourcePort" : "5001-5050"
		},
		{
			"destIpAddr" : "any",
			"destPort" : "",
			"direction" : "dl",
			"flowName" : "2",
			"protocol" : "ip",
			"sourceIpAddr" : "192.168.1.2",
			"sourcePort" : "5101-5150"
		}
	],
	"pccRuleName" : "4033",
	"pccRuleType" : 2,
	"staticQualification" : 
	{
		"contentChargingProfileId" : "cp_streaming"
	}
}

 

This example provisions the following services:

• A streaming service

  Preconfigured (rule type 2) service, not known by the PCEF, which runs on a set of downlink flows. The streaming server runs on IP address 192.168.1.2, and uses two different ranges of ports 5001–5050 and 5101–5150. It also has the charging data "cp_streaming".

  The ID of the PCC rule does not overlap with the IDs of the other static PCC rules.

• Skype (Voice over IP) service

  Preconfigured service with two different Charging-Rule-Name AVPs. This enables two "Skype" service flows, one for IPv4 at the "10.220.100.1" IP address, and another for IPv6 at the "2000:1111:2222:4444:5555:ABCD:7777:0002" IP address.

• A chat service

  Static service known by the PCEF. A static PCC rule identified by name (rule type 0) is sent to the PCEF.

• An internet service

  Static service known by the PCEF. A static PCC rule identified by basename (rule type 1) is used. It runs with no specific flows.

6   Configure IP-CAN Session Access Control

To configure IP-CAN session access depending on conditions, do the following:

1. Configure the controls attribute in the DiameterNode object class containing the IP_CAN_SESSION_ACCESS value.
2. Create the needed policies using:
   • For Global policy locator:

     /locators/resources/ip-can-session/contexts/access

   • For Subscriber group locator:

     /dataplans/<dataplanName>/locators/resources/ip-can-session/contexts/access

   • For Subscriber locator:

     /subscribers/<subscriberId>/locators/resources/ip-can-session/contexts/access

Note:  

It is not necessary to use outputAttributes.

Example 9 describes the provisioning of a policy to accept or reject operations on an IP-CAN session.

PUT /rules/IpCanSessionAccessControl_rule
{
	"condition" : "(AccessData.bearer.ipCanType == 5)",
	"ruleName" : "IpCanSessionAccessControl_rule"
}

PUT /policies/IpCanSessionAccessControl_policy
{
	"policyName" : "IpCanSessionAccessControl_policy",
	"ruleCombiningAlgorithm" : "permit-overrides",
	"rules" : [ "IpCanSessionAccessControl_rule" ]
}

PUT /dataplans/Gold/locators/resources/ip-can-session/contexts/access
{
	"policies" : [ "IpCanSessionAccessControl_policy" ]
}

PUT /dataplans/Gold
{
	"dataplanName" : "Gold"
}

PUT /subscribers/34600000001
{
	"dataplans" : 
	[
		
		{
			"dataplanName" : "Gold",
			"priority" : 1
		}
	],
	"subscriberId" : "34600000001"
}

 

In Example 9, the IP-CAN session is allowed if the IP-CAN type is 5 (3GPP-EPS) for the subscriber group with the "Gold" identifier. Otherwise, the request is rejected.

7   Configure Service Access Control

The services applicable to a subscriber must be known by the SAPC. These services must be provisioned for the subscriber or the subscriber group in the subscribedContents and deniedContents attributes of a subscriber or subscriber group.

If Time of Day (ToD) policies are used for Service Access Control, the PCEF or the PCRF (the SAPC) can be selected as the time controller.

To execute this task in the SAPC, set the controls attribute (DiameterNode object class) to either of the following values:

• SERVICE_ACCESS_PCEF_TOD: for PCEFs that support standard ToD procedures (handling of Revalidation-Time, Rule-Activation-Time, and Rule-Deactivation-Time AVPs according to Policy and Charging Control over Gx reference point, 3GPP TS 29.212).
• SERVICE_ACCESS_PCRF_TOD: for other cases where the SAPC controls time. The SAPC triggers new reauthorization when time conditions configured in policies are reached.

Set the dynamicServiceSupport attribute (DiameterNode object) to true to enable Gx traffic related to preconfigured or dynamic PCC rules (see Example 1).

7.1   Provision Policies for Service Authorization

To configure Service Authorization depending on conditions, create the needed policies using:

• For Global policy locator:

  /locators/resources/<contentName>/contexts/access

• For Subscriber group locator:

  /dataplans/<dataplanName>/locators/resources/<contentName>/contexts/access

• For Subscriber locator:

  /subscribers/<subscriberId>/locators/resources/<contentName>/contexts/access

Note:  

It is not necessary to use outputAttributes.

Note:  

Non-authorization codes can be used when the PCEF supports the Ericsson Gx+ interface.

To use non-authorization codes in Gx, the condition must follow the following format:

#((Condition), non-auth_code)

Where Condition is the normal condition, and the non-auth_code is the code that is returned by the SAPC if the condition is not fulfilled.

The prioritization of the non-authorization codes can be achieved using the priority of the rules within a policy. If a non-auth code must be returned before any other, the rule that contains the non-auth code must be provisioned in the first place in the rules array.

Table 3 contains the reason for each of the non-authorization codes.

7.1.1   Example of Service Authorization - Global Policy for Chat Service

A global policy, which applies to all the subscribers of Chat service is created in Example 10.

# Rule
PUT /rules/SAuth_Chat_Roaming
{
	"condition" : "#((AccessData.subscriber.locationInfo.sgsnAddress == \"172.168.3.4\"),2)",
	"ruleName" : "SAuth_Chat_Roaming"
}

PUT /rules/SAuth_Chat_TerminalBased
{
	"condition" : "#((AccessData.userEquipmentInfo.model==9632),5)",
	"ruleName" : "SAuth_Chat_TerminalBased"
}

PUT /policies/SAuth_ChatPolicy_1
{
	"policyName" : "SAuth_ChatPolicy_1",
	"ruleCombiningAlgorithm" : "deny-overrides",
	"rules" : [ "SAuth_Chat_Roaming", "SAuth_Chat_TerminalBased" ]
}

PUT /locators/resources/Chat/contexts/access
{
	"policies" : [ "SAuth_ChatPolicy_1" ]
}

The "Chat" service is authorized if the SGSN Address is "172.168.3.4" and terminal model is "9632". If any of the conditions is not fulfilled, the service is not authorized, and the SAPC sends a non-authorization code in the CCA. The priority of non-authorization code "2" is higher than non-authorization code "5". This is because inside the "SAuth_Chat_Policy_1" policy, the "SAuth_Chat_Roaming" rule is evaluated first, compared to the "Sauth_Chat_TerminalBased" rule.

7.1.2   Example of Service Authorization - Subscriber Policy for Streaming Service

PUT /rules/SAuth_Internet_AccessBased
{
	"condition" : "#((AccessData.bearer.accessType!=1000),6)",
	"ruleName" : "SAuth_Internet_AccessBased"
}

PUT /policies/SAuth_Internet_Policy_1
{
	"policyName" : "SAuth_Internet_Policy_1",
	"ruleCombiningAlgorithm" : "permit-overrides",
	"rules" : [ "SAuth_Internet_AccessBased" ]
}

PUT /subscribers/34600000001/locators/resources/Internet/contexts/access
{
	"policies" : [ "SAuth_Internet_Policy_1" ]
}

PUT /subscribers/34600000001
{
	"subscriberId" : "34600000001"
}

The "Internet" service is authorized for the subscriber if access is performed through UMTS Radio Access. If the condition is not fulfilled, the service is not authorized, and the SAPC includes the non-authorization code 6 (Operator reason 1) in the answer.

7.2   Configure One Time Redirect

This section only applies for authorized static services. To activate or deactivate one time redirect for a service, set the redirect attribute within the subscribedContents attribute in a subscribers or dataplans URI in the provisioning REST API.

7.3   Provision Static Service Policies

Together with the PCEF, the SAPC can assign and change the bandwidth limits and rating group for static services during an IP-CAN session lifetime, depending on flexible conditions for a subscriber or subscriber group.

Some examples of possible use cases are the following:

• Two different ratings can be applied to data services in the home network or in roaming for premium and professional subscribers
• Throttling the bandwidth to 128 Kbps for P2P file sharing in rush hours

A static service in the PCEF can be identified by several static service names. Each static service name in the PCEF assigns different characteristics (rating group, service bandwidth, and so on) to the service. The SAPC authorizes the static basename taking into account subscriber information, accumulated use, and roaming (location). The SAPC then selects the right Charging-Rule-Name in terms of bandwidth and rating group, depending on the conditions configured in the policies.

To configure Static Services depending on conditions, create the needed policies using:

• For Global policy locator:

  /locators/resources/<contentName>/contexts/static-access

• For Subscriber group locator:

  /dataplans/<dataplanName>/locators/resources/<contentName>/contexts/static-access

• For Subscriber locator:

  /subscribers/<subscriberId>/locators/resources/<contentName>/contexts/static-access

• Within the outputAttributes object in the rule, set:
  • attrName attribute to pcc-rule-id
  • attrValue to the charging rule name (pccRuleName value)

In Example 12, for the "OneGroup" subscriber group, the "Torrent" service is authorized when the subscriber is not roaming. Furthermore, depending on the subscriber consumed volume (details about Fair Usage Control are covered in Configuration Guide for Fair Usage), a different bandwidth and rating group are applied, by sending either CR-Name = 70001 or CR-Name = 70002 to the GGSN/PDN-GW.

# ---------------------------------------------
PUT /rules/rQualify1
{
	"condition" : "not(AccessData.subscriber.accumulatedUsage.reportingGroup[\"total\"].isLimitSurpassed[\"bidirVolume\"])",
	"outputAttributes" : 
	[
		{
			"attrName" : "pcc-rule-id",
			"attrValue" : "70001",
			"result" : "permit"
		}
	],
	"ruleName" : "rQualify1"
}

PUT /rules/rQualify2
{
	"condition" : "AccessData.subscriber.accumulatedUsage.reportingGroup[\"total\"].isLimitSurpassed[\"bidirVolume\"]",
	"outputAttributes" : 
	[
		{
			"attrName" : "pcc-rule-id",
			"attrValue" : "70002",
			"result" : "permit"
		}
	],
	"ruleName" : "rQualify2"
}

PUT /rules/rule_TorrentAccess
{
	"condition" : "#((AccessData.subscriber.locationInfo.countryCode == 34),2)",
	"ruleName" : "rule_TorrentAccess"
}

PUT /policies/pQualify
{
	"policyName" : "pQualify",
	"ruleCombiningAlgorithm" : "permit-overrides",
	"rules" : [ "rQualify1", "rQualify2" ]
}

PUT /policies/policy_TorrentAccess
{
	"policyName" : "policy_TorrentAccess",
	"ruleCombiningAlgorithm" : "permit-overrides",
	"rules" : [ "rule_TorrentAccess" ]
}

PUT /dataplans/OneGroup/locators/resources/torrent/contexts/static-access
{
	"policies" : [ "pQualify" ]
}

PUT /dataplans/OneGroup/locators/resources/torrent/contexts/access
{
	"policies" : [ "policy_TorrentAccess" ]
}

PUT /contents/torrent
{
	"contentName" : "torrent",
	"pccRuleName" : "70",
	"pccRuleType" : 1
}

PUT /dataplans/OneGroup
{
	"dataplanName" : "OneGroup",
	"subscribedContents" : 
	[
		{
			"contentName" : "torrent",
			"redirect" : false
		}
	]
}

The Access policy composed of "rule_TorrentAccess", "policy_TorrentAccess", and access context is configured if a flexible condition for the service authorization is needed. These policies are not needed if "torrent" service is always authorized (as it is provisioned in the subscribedContents attribute in the "OneGroup" subscriber group), and depending on the static-access policy conditions, the selection of different CR-Names for it is the desired behavior.

Bandwidth limits and rating group for static defined services can also be changed depending on time conditions. A specific bandwidth and rating group can be applied in flat hours, and a different bandwidth and rating group for the rest of the time. To achieve that, modify the condition attribute of the rules in Example 12. For example:

• for CR-Name = 70002:

  "condition" : "(now.time > "08:00:00") && (now.time < "18:00:01")"

• and for CR-Name = 70001: the condition would be

  "condition" : "(now.time < "8:00:01") || (now.time > "18:00:00")"

7.4   Rule Spaces

This section applies for Ericsson added-value (Ericsson Gx+ interface interface).

7.4.1   Provision Rule Spaces

A list of rule spaces and services (static PCC rules) belonging to that rule space can be configured in the SAPC.

The identifiers and the service definitions of the rule spaces must be the same in the SAPC and in the PCEF.

To define a rule space, create a rule-space URI in the provisioning REST API.

Example 13 presents the configuration of a rule space.

PUT /rule-spaces/RS_Roaming
{
	"contentNames" : [ "Chat", "Internet" ],
	"ruleSpaceName" : "RS_Roaming"
}

Example 13 defines that the " RS_Roaming" rule space containing the "Chat" and "Internet" services needs to be evaluated in the case of roaming.

7.4.2   Policies for Rule Space Negotiation

To configure Rule Space Negotiation depending on conditions, create the needed policies using:

• For Global policy locator:

  /locators/resources/service-domain/contexts/access

• For Subscriber group locator:

  /dataplans/<dataplanName>/locators/resources/service-domain/contexts/access

• For Subscriber locator:

  /subscribers/<subscriberId>/locators/resources/service-domain/contexts/access

• Within the outputAttributes object in the rule, set:
  • attrName attribute to rule-space
  • attrValue to the rule space name

Example 14 presents the configuration of a policy for rule space selection.

PUT /rules/RSSel_RuleRoaming
{
	"condition" : "AccessData.bearer.accessPoint!=\"OperatorNetwork_1\"",
	"outputAttributes" : 
	[
		{
			"attrName" : "rule-space",
			"attrValue" : "\"RS_Roaming\"",
			"result" : "permit"
		}
	],
	"ruleName" : "RSSel_RuleRoaming"
}

PUT /policies/RSSel_PolicyRoaming
{
	"policyName" : "RSSel_PolicyRoaming",
	"ruleCombiningAlgorithm" : "permit-overrides",
	"rules" : [ "RSSel_RuleRoaming" ]
}

PUT /dataplans/Gold/locators/resources/service-domain/contexts/access
{
	"policies" : [ "RSSel_PolicyRoaming" ]
}

"Gold" subscribers are explicitly subscribed to the streaming, Skype, and chat services, and indirectly subscribed to the internet service as it is defined in the "Global" subscriber group. The "RS_Roaming" rule space is selected for Gold subscribers, when they access APNs other than "OperatorNetwork_1".

The "RS_Roaming" rule space contains the "Internet" and "Chat" services, since these are the services considered for authorization.

8   Configure Service Charging Control

To execute this task in the SAPC, set the SERVICE_CHARGING value in the controls attribute (DiameterNode object class).

8.1   Static Services

To select different charging data for static services (PCC rules) in the PCEF, the SAPC allows the following options:

1. Unconditionally: use pccRuleName
2. Depending on conditions, see Section 7.3

8.2   Preconfigured Services

1. Configure Service Charging profiles. The values configured in these charging profiles are used to fill charging related AVPs within the Charging-Rule-Definition AVP. To define a charging profile, create a content-charging URI in the provisioning REST API.
2. To unconditionally associate a charging profile with a service:

   In a content, set the contentChargingProfileId attribute within the staticQualification object, with a value according to the profileId of a content-charging .

3. To configure Service Charging depending on conditions, create the needed policies using :
   • For Global policy locator:

     /locators/resources/<contentName>/contexts/charging

   • For Subscriber group locator:

     /dataplans/<dataplanName>/locators/resources/<contentName>/contexts/charging

   • For Subscriber locator:

     /subscribers/<subscriberId>/locators/resources/<contentName>/contexts/charging

   • Within the outputAttributes object in the rule, set:
     • attrName attribute to charging
     • attrValue to ServiceChargingProfile[\"<chargingProfileId>\"], where chargingProfileId is the profileId of a valid content-charging

Example 15 is an example for the configuration of charging profiles.

PUT /profiles/content-charging/ChargingType1
{
	"chargingServiceId" : 40000,
	"meteringMethod" : 0,
	"offlineEnabled" : false,
	"onlineEnabled" : true,
	"profileId" : "ChargingType1",
	"ratingGroup" : 1,
	"reportingLevel" : 0
}

PUT /profiles/content-charging/GlobalPrepaid
{
	"chargingServiceId" : 10000,
	"meteringMethod" : 2,
	"offlineEnabled" : false,
	"onlineEnabled" : true,
	"profileId" : "GlobalPrepaid",
	"ratingGroup" : 3,
	"reportingLevel" : 0
}

PUT /profiles/content-charging/TrafficBasedCharging
{
	"chargingServiceId" : 30000,
	"meteringMethod" : 1,
	"offlineEnabled" : true,
	"onlineEnabled" : false,
	"profileId" : "TrafficBasedCharging",
	"ratingGroup" : 4,
	"reportingLevel" : 1
}

PUT /profiles/content-charging/cp_streaming
{
	"meteringMethod" : 0,
	"offlineEnabled" : true,
	"onlineEnabled" : false,
	"profileId" : "cp_streaming",
	"ratingGroup" : 3,
	"reportingLevel" : 0
}

Example 8 shows how "Streaming" service is associated with a charging profile (Service Charging Control is provided): staticQualification contains contentChargingProfileId pointing to "cp_streaming" .

9   Provision Qualification Data for Subscriptions

General concepts on how to provision subscribers and subscriber groups are covered in Configuration Guide for Subscription and Policies.

9.1   Provision Qualification for Subscriber or Subscriber Group Unconditionally

Subscribers or subscriber groups can be qualified for access and charging, by associating a static profile that characterizes them, for example, assigning charging related data. This implies assigning profiles to subscribers or subscriber groups. Static QoS configuration is also part of the static qualification for subscriptions, which are explained in the Configuration Guide for Bearer QoS Control and Bandwidth Management.

To do that:

• Within subscribers or dataplans URI in the provisioning REST API, set or modify the staticQualification object.

Table 6 contains the particular details for each of the static (qualification data) subscriber or subscriber group profile.

(1)   To apply this functionality for the PCEF sending Gx requests to the SAPC, configure the controls attribute within the DiameterNode object class containing the CONTENT_FILTERING value.

(2)   To apply this functionality for the PCEF sending Gx requests to the SAPC, configure the controls attribute within the DiameterNode object class containing the SUBSCRIBER_CHARGING value.

9.2   Provision Qualification for Subscriber or Subscriber Group Conditionally (Depending on Policies)

Using policies, it is possible to use conditions to assign profiles to subscribers or subscriber groups. This can be done in addition to static qualification (see Table 6).

Set the output attribute of the rule to the desired value for the particular qualification data using the following table:

(1)   Do not configure ToD conditions within Subscriber Charging policies, as the SAPC does not perform time-based reauthorization.

Combining Conditional and Unconditional Qualification Data

If there are policies configured for a subscriber, their data prevail over the unconditional qualification data provisioned in the subscriber profile.

If there are policies configured for a subscriber group, their data prevail over the unconditional qualification data provisioned in the subscriber group profile.

10   Configure Subscriber Charging Control

1. To execute this task in the SAPC, configure the controls attribute in the DiameterNode object class with the SUBSCRIBER_CHARGING value
2. Provision a Charging System Profile (see Section 10.1)
3. Provision Subscriber Charging Profiles (see Section 10.2)
4. Configure Subscriber Charging Characteristics Information (see Section 10.3)
5. Configure the Charging Information to the subscriber or subscriber group unconditionally (see Section 10.4), conditionally (see Section 10.5), or both.

10.1   Provision Charging System Profiles

To provision a Charging System Profile, create a charging-system URI in the provisioning REST API.

10.2   Provision Subscriber Charging Profiles

A subscriber charging profile contains a reference to a charging system and type of charging (online or offline). This charging information can be associated with a subscriber or a subscriber group, and is provided by the SAPC to the PCEF.

To provision a Subscriber Charging Profile, create a subscriber-charging URI in the provisioning REST API with the following attributes:

• profileId
• onlineEnabled
• offllineEnabled
• chargingChars (see Section 10.3)
• chargingSystemProfileId

Note:  

The chargingSystemProfileId attribute must be set with the profileId of a previously provisioned charging-system URI in the provisioning REST API.

Example 16 describes the configuration of subscriber charging data.

PUT /dataplans/Gold2
{
	"dataplanName" : "Gold2",
	"staticQualification" : 
	{
		"subscriberChargingProfileId" : "chargingType01"
	}
}

PUT /profiles/subscriber-charging/chargingType01
{
	"chargingChars" : 987,
	"chargingSystemProfileId" : "ChargingSystem01",
	"offlineEnabled" : false,
	"onlineEnabled" : true,
	"profileId" : "chargingType01"
}

PUT /profiles/charging-system/ChargingSystem01
{
	"primaryOnline" : "primaryChargingHost.ericsson.com",
	"profileId" : "ChargingSystem01",
	"secondaryOnline" : "secondaryChargingHost.ericsson.com"
}

Example 16 configures a subscriber charging profile with "chargingType01" identifier and charging characteristic set to "987". This subscriber charging profile configures the subscriber as online in terms of charging. The subscriber charging profile establishes "ChargingSystem01" as the charging system associated with the subscriber. This charging system defines the primary and a secondary host for online charging. The charging profile is associated with the "Gold2" subscriber group.

10.3   Configure Charging Characteristics Information

The Charging Characteristics information configured in chargingChars attribute within the subscriberCharging URI in the provisioning REST API is downloaded to the PCEF in the CCA.

The value for charging characteristics is an integer, and if this value is higher than the expected size (65535), its value is truncated to 16 bits.

Charging characteristics data can also be received from the PCEF, and can then be used to evaluate policy conditions for service authorization. Ericsson recommends not to use this value if the charging characteristics for the subscriber is configured.

Note:  

This parameter is valid for Ericsson Gx+ interface.

10.4   Provision Unconditional Subscriber Charging Data to Subscriber or Subscriber Groups

To assign an unconditional charging profile to a subscriber or subscriber group, within the subscribers or dataplans URI in the provisioning REST API, set the subscriberChargingProfile attribute with the ID of a subscriber-charging profile provisioned in the SAPC.

10.5   Provision Conditional Subscriber Charging Data with Policies

To configure Subscriber Charging depending on conditions, create the needed policies using:

• For Global policy locator:

  /locators/resources/any/contexts/charging

• For Subscriber group locator:

  /dataplans/<dataplanName>/locators/resources/any/contexts/charging

• For Subscriber locator:

  /subscribers/<subscriberId>/locators/resources/any/contexts/charging

• Within the outputAttributes object in the rule, set:
  • attrName attribute to charging
  • attrValue to SubsChargingProfile[<subsChargingProfileId> where subsChargingProfileId is the ID of a valid subscriber-charging.

11   Configure Content Filtering Control

To configure Content Filtering Control, do the following:

1. To execute this task in the SAPC, configure the controls attribute in the DiameterNode object class with the "CONTENT_FILTERING" value.
2. To associate unconditionally a content filtering profile with a subscriber or subscriber group, see Section 11.1)
3. To associate content filtering depending on conditions, see Section 11.2)

11.1   Provision Content Filtering for Subscribers or Subscriber Groups

Set the contentFiltering attribute within the staticQualification object in a subscribers or dataplans URI in the provisioning REST API.

Example 17 describes how to associate statically a content filtering profile to a subscriber within the staticQualification object.

PUT /subscribers/34600000001
{
	"dataplans" : 
	[
		{
			"dataplanName" : "Gold"
		}
	],
	"deniedContents" : [ "Chat" ],
	"operatorSpecificInfos" : 
	[
		{
			"attributeName" : "age",
			"attributeValue" : "33"
		}
	],
	"staticQualification" : 
	{
		"contentFiltering" : "69"
	},
	"subscriberId" : "34600000001"
}

Example 17 provisions subscriber "34600000001" belonging to the "Gold" group and uses the operatorSpecificInfos object to indicate the age of the subscriber.

A contentFiltering (to be downloaded to the PCEF) set to "69" is also provisioned for the subscriber.

11.2   Provision Content Filtering Policies

To configure Content Filtering depending on conditions, create the needed policies using :

• For Global policy locator:

  /locators/resources/service-domain/contexts/content-filtering

• For Subscriber group locator:

  /dataplans/<dataplanName>/locators/resources/service-domain/contexts/content-filtering

• For Subscriber locator:

  /subscribers/<subscriberId>/locators/resources/service-domain/contexts/content-filtering

• Within the outputAttributes object in the rule, set:
  • attrName attribute to content-filtering-id
  • attrValue to the content filtering value

Example 18 describes the configuration of a policy to return content filtering profile.

PUT /rules/ContentFilteringRule1
{
	"condition" : "(Subscriber.subsAge > 17)",
	"outputAttributes" : 
	[
		{
			"attrName" : "content-filtering-id",
			"attrValue" : "9",
			"result" : "permit"
		}
	],
	"ruleName" : "ContentFilteringRule1"
}

PUT /policies/ContentFilteringPolicy1
{
	"policyName" : "ContentFilteringPolicy1",
	"ruleCombiningAlgorithm" : "permit-overrides",
	"rules" : [ "ContentFilteringRule1" ]
}

PUT /subscribers/34600000001/locators/resources/service-domain/contexts/content-filtering
{
	"policies" : [ "ContentFilteringPolicy1" ]
}

 

A policy is created for subscriber with identifier "34600000001", to return as content filtering profile identifier "9" when the age of the subscriber is greater than 17. The age of the subscriber is provisioned in the operatorSpecificInfos object within the subscribers URI in the provisioning REST API.

12   Configure Header Enrichment

The SAPC is able to send user-related information towards the GGSN/PDN-GW to be inserted in the HTTP headers of a particular request so that the service can use this information in its internal logic. One typical application is to provide the third-party applications with a user alias so the MSISDN is not disclosed to them.

The SAPC allows the operator to define any kind of data to be inserted.

This functionality is provided with the Ericsson Gx+ interface and when the SAPC is deployed together with an Ericsson PDN-GW product.

To use Header Enrichment, set the customerId attribute in the staticQualification object of a subscribers URI in the provisioning REST API.

13   Configure Presence Reporting Area

The operator can configure presence reporting area selection applicable to a subscriber or subscriber group by using static qualification data or dynamic policies.

When defining the presence reporting area, the identifier is made of 24 bits, where the most significant bit defines the mode (either UE dedicated or CN preconfigured PRA).

Therefore, the most significant bit is 0 (UE dedicated) or 1 (CN preconfigured PRA).

13.1   Provision Presence Reporting Area

To provision a presence reporting area, create a presence-reporting-area URI in the provisioning REST API.

PUT /profiles/presence-reporting-area/Area1

{
        "name" : "Area1",
        "praId" : 9000001,
        "elementsList":
	{
		"tais" : ["012.45.6789-6791"],
		"macroEnbs" : ["123.456.78901"],
		"homeEnbs" : ["234.567.8901234-8901235"],
		"ecgis" : ["345.678.9012345"],
		"rais" : ["456.789.123.45-46"],
		"sais" : ["567.890.1234.5678"],
		"cgis" : ["678.901.2345.6789-6790"]
	}
}

13.2   Provision Unconditional Presence Reporting Area to Subscriber or Subscriber Groups

To assign an unconditional presence reporting area to a subscriber or subscriber group, set the presenceReportingAreaNames attribute with the ID of a presence-reporting-area profile provisioned in the SAPC within the subscribers or dataplans URI in the provisioning REST API

13.3   Provision Conditional Presence Reporting Area with Policies

To configure Presence Reporting Area depending on conditions, create the needed policies using:

• For Global Policy locator:

  /locators/resources/any/contexts/location

• For Subscriber Group locator:

  /dataplans/<dataplanName>/locators/resources/any/contexts/location

• For Subscriber locator:

  /subscribers/<subscriberId>/locators/resources/any/contexts/location

• Within the outputAttributes object in the rule, set:
  • attrName attribute to presence-area
  • attrValue to PraProfile[\"Name\" ]

Example 20 shows the SAPC selecting a presence reporting area for a subscriber using the dynamic policy.

Note:  

Do not configure ToD conditions in PRA policies, as the SAPC does not perform ToD based reauthorization.

PUT /subscribers/34615800304

{
        "subscriberId" : "34615800304",
        "dataplans" :
        [
                {
                        "dataplanName" : "Silver"
                }
        ]
}

PUT /dataplans/Silver

{
        "dataplanName" : "Silver"
}

PUT /rules/PRASelectionGroup_Silver_rule

{
        "condition" : "(AccessData.bearer.accessType==1000)",
        "outputAttributes" :
        [

                {
                        "attrName" : "presence-area",
                        "attrValue" : "PraProfile[\"Area1\"]",
                        "result" : "permit"
                }
        ],
        "ruleName" : "PRASelectionGroup_Silver_rule"
}

PUT /policies/PRASelectionGroup_Silver

{
        "policyName" : "PRASelectionGroup_Silver",
        "ruleCombiningAlgorithm" : "permit-overrides",
        "rules" : [ "PRASelectionGroup_Silver_rule"]
}

PUT /dataplans/Silver/locators/resources/any/contexts/location

{
        "policies" : [ "PRASelectionGroup_Silver" ]
}

In Example 20, the SAPC defines the presence reporting area "Area1" for subscriber group "Silver" when the "Silver" subscribers' access is performed through the UTRAN Radio Access.

13.4   Configure Event Triggers for Presence Reporting Area

To subscribe the SAPC to presence area reporting event trigger, the SAPC has to include the CHANGE_OF_UE_PRESENCE_IN_PRESENCE_REPORTING_AREA_REPORT value within the Event-Trigger AVP of the Gx CCA-initial message.

For details on how to configure event triggers, see Section 4.

Example 21 shows how to configure the presence reporting area event trigger based on access conditions.

PUT /policies/DynamicEventTriggersPolicy

{
  "policyName" : "DynamicEventTriggersPolicy",
  "ruleCombiningAlgorithm" : "all-permit",
  "rules" : [ "DynamicEventTriggersRule" ]
}

PUT /rules/DynamicEventTriggersRule

{
  "condition" : "(AccessData.bearer.accessType != 1000)",
  "outputAttributes" : 
  [
   {
     "attrName" : "event-triggers",
     "attrValue" : "\"48\"",
     "result" : "permit"
   }
  ],
  "ruleName" : "DynamicEventTriggersRule"
}

14   Configuration Examples for Use Cases

14.1   Roaming Conditions

Simple conditions are used to detect roaming in some examples along this document. For example, AccessData.subscriber.locationInfo.countryCode == 34.

However, conditions to detect roaming cases can be more complex. For example, some operator may use lists of SGSN-MME IP addresses or multiple PLMN-identifiers.

Example 22, Example 23, and Example 24 show multiple roaming criteria using the Mobile Network Code part of the SGSN PLMN ID (using Extra Data in the internal database explained in Database Access) and the inRange function (detailed in Configuration Guide for Subscription and Policies):

PUT /operator-specific-infos/Roaming
{
	"infoList" : 
	[
		{
			"attributeName" : "networkCodes",
			"attributeValue" : "1-9"
		},
		{
			"attributeName" : "networkCodes",
			"attributeValue" : "12"			
		},	
		{
			"attributeName" : "networkCodes",
			"attributeValue" : "14-16"			
		},	
		{
			"attributeName" : "networkCodes",
			"attributeValue" : "21"			
		},                
		{
			"attributeName" : "networkCodes",
			"attributeValue" : "88"			
		}                   
	],
	"infoId" : "Roaming"
}

<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>Roaming</eDSourceId>
               <definition>
                 def Roaming( argId ) 
                 {
                   dataSource = 
                   {
                     url = "internaldb:";
                     query = "OperatorSpecificInfoPot:{argId}";
                   }
                   fieldDef = 
                   {
                     id = dataSourceField("argId");                     
                     nwCodes = dataSourceField("name:networkCodes");
                  }
                 }
               </definition>
             </EDSource>
            </EDSources>
          </EntityData>
        </PolicyControlFunction>
      </ManagedElement>
  </config>
</edit-config>

 

PUT /rules/ruleRoaming
{
	"condition" : "inRange(AccessData.subscriber.locationInfo.networkCode,
	                       Roaming[\"Roaming\"].nwCodes)",
	"ruleName" : "ruleRoaming"
}

14.2   Cell Congestion

The SAPC can use dynamic subscriber location information in policy decisions, together with cell congestion information provisioned in advance.

Figure 2 shows an overview of the configuration schema:

Figure 2 shows that the subscriber location information received in the SAPC over the Gx interface can be used to verify if the subscriber is in a congested cell. The congested cell identifiers are provisioned in a logical table inside the SAPC internal database, where the period or periods for which the cells are congested can also be set. An Entity Data Source is also needed so that the information about the congested cells can be used in policy conditions.

To use cell congestion in policies, perform the following steps:

1. To guarantee that the SAPC receives Gx CCR updates when the subscriber is moving, subscribe to the proper location change values of the Event-Trigger AVP: User Location change, RAI change, TAI change, and ECGI change.
   Warning!

   The subscription to location change related Event-Triggers AVP for all the SAPC subscribers causes a high amount of extra Gx CCR update signaling in the network. Dimension the SAPC properly or restrict the subscription of location change event triggers only for some subscribers or dataplans. See details in Section 4.

2. Configure cell congestion information (at least identities for congested cells) as explained in Extra Data in the internal database in Database Access:
   1. Set the congested cell information using the operator-specific-infos URI in the provisioning REST API.
   2. Define a new Entity Data Source pointing to the congested cell information.

   Note:  

   The way to locate the configured cell identities depends on the cellular network plan and the geographic type information received over Gx, according to the AccessData.subscriber.locationInfo.<tag> policy tag in Table 14.

   For example:

   • For 2G/3G access and geographic type CGI, the combination of location area code plus cell identity can be used.
   • For LTE access, the E-UTRAN cell identifier for geographic type ECGI can be used.
   • For 3GPP2 access, the cell identifier can be used.

   
   

   It is also possible to include periods of time for which the cells are congested, according to the syntax defined in the inPeriod function, refer to Configuration Guide for Subscription and Policies.

3. Provision a Bearer QoS Control policy containing as condition the congested cells information (using Entity Data Source syntax).

   For details about configuration of QoS profiles and Bearer QoS Control, see Configuration Guide for Bearer QoS Control and Bandwidth Management.

Example 25, Example 26, and Example 27 show configuration elements where some congested cells are defined and used in a policy:

PUT /operator-specific-infos/123-456
{
	"infoList" : 
	[
		{
			"attributeName" : "TimePeriod",
			"attributeValue" : "8:00:00,18:00:00"
		}
	],		
	"infoId" : "123-456"
}

PUT /operator-specific-infos/234-567
{
	"infoList" : 
	[
		{
			"attributeName" : "TimePeriod",
			"attributeValue" : "8:00:00,18:00:00"
		}
	],		
	"infoId" : "234-567"
}

PUT /operator-specific-infos/999-888
{
	"infoList" : 
	[
		{
			"attributeName" : "TimePeriod",
			"attributeValue" : "18:00:00,20:00:00"
		}
	],		
	"infoId" : "999-888"
}

<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>CongestedCells</eDSourceId>
               <definition>
                 def CongestedCells( argId='strcat(strcat(
                     AccessData.subscriber.locationInfo.locationAreaCode,"-"),
                     AccessData.subscriber.locationInfo.cellIdentity)')
                 {
                   dataSource = 
                   {
                     url = "internaldb:";
                     query = "OperatorSpecificInfoPot:{argId}";
                   }
                   fieldDef = 
                   {
                     id = dataSourceField("argId");
                     congestedPeriod = dataSourceField("name:TimePeriod");
                   }
                 }
               </definition>
             </EDSource>        
            </EDSources>
          </EntityData>
        </PolicyControlFunction>
      </ManagedElement>
  </config>
</edit-config>

 

Example 25 contains a couple of cells being congested from 08:00 until 18:00 and another one congested from 18:00 until 20:00. The cells are located using the subscriber location information received through Gx. The cell identifiers are composed of the Location Area Code and the Cell Identity for a 2G/3G 3GPP access.

Example 27 presents that the congested cells (and period of congestion) are considered to assign a lower Bearer QoS Profile. The condition evaluates the current time against the congested period of the cell where the subscriber is located. The subscriber location (concatenation of area code and cell identity) is passed to the CellCongestion Entity Data Source as default input argument.

PUT /rules/ruleCongestedCells
{
	"condition" : "(inPeriod(now.offset,CongestedCells.congestedPeriod))",
	"outputAttributes" : 
	[
		{
			"attrName" : "max-qos",
			"attrValue" : "BearerQosProfile[\"QosLower\"]",
			"result" : "permit"
		}
	],
	"ruleName" : "ruleCongestedCells"
}

PUT /policies/policyQosLower
{
	"policyName" : "policyQosLower",
	"ruleCombiningAlgorithm" : "permit-overrides",
	"rules" : [ "ruleCongestedCells" ]
}

PUT /locators/resources/ip-can-session/contexts/qos
{
	"policies" : [ "policyQosLower" ]
}

14.3   PDN Type and UE IP Address Conditions

The SAPC supports the following IP-CAN session connection types, according to the 3GPP Evolved Packet Core (EPC) architecture:

• IP-CAN session Type IPv4, where the UE is allocated an IPv4 address.
• IP-CAN session Type IPv6, where the UE is allocated an IPv6 prefix.
• IP-CAN session Type IPv4v6, where the UE is simultaneously allocated an IPv4 address and IPv6 prefix. This is called dual-stack connectivity.

The preceding information, together with the UE IPv4 address or IPv6 prefix can be used to make policy decisions. Hence, the SAPC provides some policy tags that can be used and configured in the condition of the rule URI in the provisioning REST API: AccessData.subscriber.ueIpAddress, ueIpv6Prefix, and ueIpAddressType.

For example, if the operator wants to evaluate when a subscriber is allocated a particular IPv4 address, use the following expression:

(AccessData.subscriber.ueIpAddressType == 0) && 
(AccessData.subscriber.ueIpAddress == "172.40.30.20")

To apply a different policy when a subscriber is allocated an IPv6 prefix within a given range, use the following condition expression:

(AccessData.subscriber.ueIpAddressType == 1) && 
inRange(AccessData.subscriber.ueIpv6Prefix,
"2001:0DB8:0000:0000:0000:0000:1428:57AB-2001:0DB8::FFFF:FFFF")

To identify a dual-stack IP-CAN session connection, use the following expression:

(AccessData.subscriber.ueIpAddressType == 2) && 
(AccessData.subscriber.ueIpAddress == "172.40.30.20") && 
(AccessData.subscriber.ueIpv6Prefix == "2001:0DB8:AE56:0034")

14.4   Presence Area Status Conditions

14.4.1   Use Case 1: Campus Zone Mobile Broadband

This use case describes an event when a user is assigned to mobile broadband access with high bandwidth when the user enters his or her campus zone.

The Campus_MIT_Group dataplan defines the presence reporting area corresponding to the campus geographical area. When a subscriber enters the campus zone, it activates the HighBearerQos group, which has a high QoS Profile. When this subscriber leaves the campus zone area, it activates the Qos_default group with a default QoS profile.

PUT /subscribers/34600000001

{
        "subscriberId" : "34600000001",
        "eventTriggers": [48],
        "dataplans" :
        [
                {
                        "dataplanName" : "Campus_MIT_Group"
                }
        ]
}

PUT /dataplans/Campus_MIT_Group

{
        "dataplanName" : "Campus_MIT_Group",
        "staticQualification" :
        {
                 "presenceReportingAreaNames": ["Campus_MIT"]
        }
}

PUT /profiles/ip-can-session-qos/Qos_default

{
        "mbrDownlink" : 64,
        "mbrUplink" : 32,
        "profileId" : "Qos_default",
        "qci" : 4
}

PUT /profiles/ip-can-session-qos/HighBearerQos

{
        "mbrDownlink" : 128,
        "mbrUplink" : 64,
        "profileId" : "HighBearerQos",
        "qci" : 5
}

PUT /profiles/presence-reporting-area/Campus_MIT

{
        "name" : "Campus_MIT",
        "praId" : 8388608
}


PUT /rules/PRAQosStatusInCampus_MIT

{
        "condition" : "(AccessData.subscriber.locationInfo.presenceReportingArea[\"Campus_MIT\"].isInArea)",
        "outputAttributes" :
        [

                {
                        "attrName" : "max-qos",
                        "attrValue" : "BearerQosProfile[\"HighBearerQos\"]",
                        "result" : "permit"
                }
        ],
        "ruleName" : "PRAQosStatusInCampus_MIT"
}

PUT /rules/PRAQosStatusOutCampus_MIT

{
        "condition" : "!(AccessData.subscriber.locationInfo.presenceReportingArea[\"Campus_MIT\"].isInArea)",
        "outputAttributes" :
        [

                {
                        "attrName" : "max-qos",
                        "attrValue" : "BearerQosProfile[\"Qos_default\"]",
                        "result" : "permit"
                }
        ],
        "ruleName" : "PRAQosStatusOutCampus_MIT"
}

PUT /policies/PRAQosStatusInPolicy

{
        "policyName" : "PRAQosStatusInPolicy",
        "ruleCombiningAlgorithm" : "permit-overrides",
        "rules" : [ "PRAQosStatusInCampus_MIT", "PRAQosStatusOutCampus_MIT"]
}

PUT /dataplans/Campus_MIT_Group/locators/resources/ip-can-session/contexts/qos

{
        "policies" : [ "PRAQosStatusInPolicy" ]
}

14.4.2   Use Case 2: Home Zone Mobile Broadband

This use case describes an event when a user is assigned to mobile broadband access with high bandwidth when the user enters his or her home zone, such as a residential area.

The HomeZoneGroup group is defined as the presence reporting area corresponding to the home zone geographical area. When a subscriber enters the home zone area, it activates the HighBearerQos group, which has a high QoS Profile. When this subscriber leaves the home zone area, it activates the Qos_default group with a default QoS profile.

PUT /subscribers/34600000002
{
  "subscriberId" : "34600000002",
  "eventTriggers": [48],
  "dataplans" :
  [
    {
      "dataplanName" : "HomeZoneGroup"
    }
  ],
  "staticQualification" :
  {
    "presenceReportingAreaNames": ["HomeZone"]
  }
}

PUT /dataplans/HomeZoneGroup
{
  "dataplanName" : "HomeZoneGroup"
}

PUT /profiles/ip-can-session-qos/Qos_default
{
  "mbrDownlink" : 64,
  "mbrUplink" : 32,
  "profileId" : "Qos_default",
  "qci" : 4
}

PUT /profiles/ip-can-session-qos/HighBearerQos
{
  "mbrDownlink" : 128,
  "mbrUplink" : 64,
  "profileId" : "HighBearerQos",
  "qci" : 5
}

PUT /profiles/presence-reporting-area/HomeZone
{
  "name" : "HomeZone",
  "praId" : 1388609,
	"elementsList":
	{
		"tais" : ["012.45.6789-6791"],
		"macroEnbs" : ["123.456.78901"],
		"homeEnbs" : ["234.567.8901234-8901235"],
		"ecgis" : ["345.678.9012345"],
		"rais" : ["456.789.123.45-46"],
		"sais" : ["567.890.1234.5678"],
		"cgis" : ["678.901.2345.6789-6790"]
	}
}

PUT /rules/PRAQosStatusInHomeZone
{
  "condition" : "(AccessData.subscriber.locationInfo.presenceReportingArea[Subscriber.presenceReportingAreaNames].isInArea)",
  "outputAttributes" :
  [
    {
      "attrName" : "max-qos",
      "attrValue" : "BearerQosProfile[\"HighBearerQos\"]",
      "result" : "permit"
    }
  ],
  "ruleName" : "PRAQosStatusInHomeZone"
}

PUT /rules/PRAQosStatusOutHomeZone
{
  "condition" : "!(AccessData.subscriber.locationInfo.presenceReportingArea[Subscriber.presenceReportingAreaNames].isInArea)",
  "outputAttributes" :
  [
    {
      "attrName" : "max-qos",
      "attrValue" : "BearerQosProfile[\"Qos_default\"]",
      "result" : "permit"
    }
  ],
  "ruleName" : "PRAQosStatusOutHomeZone"
}

PUT /policies/PRAQosStatusInPolicy
{
  "policyName" : "PRAQosStatusInPolicy",
  "ruleCombiningAlgorithm" : "permit-overrides",
  "rules" : [ "PRAQosStatusInHomeZone", "PRAQosStatusOutHomeZone"]
}

PUT /dataplans/HomeZoneGroup/locators/resources/ip-can-session/contexts/qos
{
  "policies" : [ "PRAQosStatusInPolicy" ]
}

14.5   Extended Event-Trigger for Tethering Detection Reporting over Gx

Example 30 shows the preferred way to support Extended Event-Trigger for Tethering Detection Reporting over Gx.

PUT /rules/DynamicTetheringEventTrigger

{
      "condition" : "not (contains(AccessData.bearer.eventTriggers, \"500\"))",
       "outputAttributes" : 
       [

            {

                 "attrName" : "event-triggers",

                  "attrValue" : "\"500\"",

                 "result" : "permit"

           }

      ],
        "ruleName" : "DynamicTetheringEventTrigger"
 }

PUT /policies/DynamicEventTriggersPolicy

{
      "policyName" : "TetheringEventTriggerPolicy",
      "ruleCombiningAlgorithm" : "all-permit",
      "rules" : [ "DynamicTetheringEventTrigger" ]
 }

PUT /locators/resources/any/contexts/event-triggers

{
       "policies" : [ "TetheringEventTriggerPolicy"]
 }

In this case, the SAPC subscribes to HOTSPOT_SHARE_START (500) in the IP-CAN session establishment. When a request message is received with the HOTSPOT_SHARE_START (500) event-trigger value, the SAPC unsubscribes from this event-trigger and does not subscribe again during the IP-CAN session lifetime, as the DynamicTetheringEventTrigger rule is evaluated to false.

Note:  

See the AccessData.bearer.eventTriggers policy tag for additional clarification.

15   Appendix A. Access and Charging Policy Types

Table 8, Table 9, Table 10, and Table 11 show the different policy types applicable to access and charging, which can be used in the SAPC.

16   Appendix B. Policy Tags

The following tags related to dynamic information about access and charging data can be used in the condition attribute of rules.

Note:  

There are also some other policy tags applicable to access and charging, which can be found in separate SAPC Configuration Guide documents.

16.1   Time and Date Tags

Time of day conditions can be used in policies. Refer to Configuration Guide for Subscription and Policies for more information.

16.2   Tags Related to Access and Charging

The following tags related to information about IP-CAN session can be used in the policy condition.

For the policy tags obtained from AVPs received in CCR messages (see Comments column), their values are kept during the session lifetime, unless new values of the AVPs are received in subsequent CCR-U/CCR-T messages.

(1)  For the particular case of HOTSPOT_SHARE_START (500) event-trigger value, the AccessData.bearer.eventTriggers tag checks if this event-trigger has been received in a CCR-Update during the IP-CAN session lifetime, instead of just checking the current message being processed.

(2)  Ericsson recommends not using this value if charging characteristics for the subscriber has been provisioned.

Reference List