An Sd session towards a TDF can be established per IP-CAN session only if the PCEF that initiates the IP-CAN session does not support ADC based on PCC rules enhanced with ADC.

To support an Sd session for an IP-CAN session initiated from a PCEF, make sure that the adcSupport attribute is not set to"true" at DiameterNode level.

The PCEF configuration to support Dynamic Policy Control in Sd is the same configuration needed to support Dynamic Policy Control in Rx. For further details refer to the Dynamic Policy Control (Rx) and Configuration Guide for Dynamic Policy Control (Rx) documents.

The procedure to configure the set of policy controls that the SAPC applies for a PCEF node is detailed in Configuration Guide for Access and Charging Control (Gx). The Dynamic Policy Control over Sd refers to the following controls:

• To enable support for dynamic PCC Rules in the PCEF based on notifications received over the Sd set dynamicServiceSupport attribute to "true" at DiameterNode level.

• Additionally, set the following policy controls related to Sd dynamic services:

  • BEARER_QOS, to allocate QoS information to Sd dynamic services

  • SERVICE_CHARGING, to allocate charging information to Sd dynamic services

When the SAPC establishes an Sd session towards a TDF, the TDF connection details can be received over the Gx interface during the Gx session establishment or can be previously configured in the SAPC.

A TDF is configured in the SAPC including the Diameter realm and Diameter host or the TDF IP address, as shown in Example 1.

Example 1   Sd TDF Node Configuration

<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>
                    <Tdfs>
                        <tdfsId>1</tdfsId>
                            <Tdf>
                                <tdfId>tdf1</tdfId>
                                <host>TDFNodeHostname1.tdf1gpprealm.com</host>
                                <realm>tdf1gpprealm.com</realm>
                            </Tdf>
                            <Tdf>
                                <tdfId>tdf2</tdfId>
                                <ipAddress>192.168.14.42</ipAddress>
                            </Tdf>
                            <Tdf>
                                <tdfId>tdf3</tdfId>
                                <host>TDFNodeHostname3.tdf3gpprealm.com</host>
                                <realm>tdf3gpprealm.com</realm>
                                <ipAddress>192.168.14.43</ipAddress>
                            </Tdf>
                    </Tdfs>
                </DiameterNodes>
            </Network>
        </PolicyControlFunction>
    </ManagedElement>
    </config>
</edit-config>

Once the SAPC identifies that an Sd session has to be established, and in case the TDF diameter routing details are not provided during the Gx session establishment, the SAPC needs to find the TDF intended to provide ADC to the PCEF that is requesting the IP-CAN session establishment.

To indicate to the TDF that the SAPC is about to start or stop application reporting, the SAPC always sends APPLICATION_START and APPLICATION_STOP event trigger values to the TDF during the Sd session establishment.

There is no need to configure any eventTriggers attribute at subscriber, dataplan, or SAPC level.

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

The SAPC only supports the following type of services in the Sd interface:

• Static: predefined in the TDF, activated by the SAPC, and identified by the ADC-Rule-Name AVP or the ADC-Rule-Base-Name AVP in Sd interface.

Service Access Control applied over a content containing ADC rules determines the services to be monitored on a particular Sd session. It happens in a similar way that Service Access Control applied over a content containing PCC rules determines the services to be authorized for a particular Gx session.

The services over Sd applicable to a subscriber must be known by the SAPC. These services must be provisioned for the subscriber or the dataplan in the subscribedContents attribute of the subscriber or dataplan. Refer to Configuration Guide for Access and Charging Control (Gx) for more information.

Table 2 shows the policy types related to service access, which can be used and configured in the SAPC for service access over Sd.

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

• Unconditionally: provision adcRuleName in the content resource

• Conditionally: configure static-access polices as explained in chConfigStaticServicePolicies

In addition to the dynamic services activated in the SAPC based on the information coming from the AF (using the Rx interface), the SAPC supports dynamic services activated in the SAPC based on the information coming from the TDF (using the Sd interface) and dynamically provisioned towards the GGSN/PDN-GW.

For further information regarding the provisioning of dynamic services, refer to the Dynamic Policy Control (Rx) and Configuration Guide for Dynamic Policy Control (Rx) documents.

The SAPC needs to determine a service identifier corresponding to the dynamic service activated by TDF events. The service identifier is relevant to perform dynamic service qualification afterwards. For further information on how to configure the conditions to determine such a service identifier, see Configuration Guide for Dynamic Policy Control (Rx).

The SAPC uses the following information received over the Sd interface for Dynamic Service Classification:

• TDF application identifier

• TDF application instance identifier

• Server IP address

• Server port

The output result is the identifier of the service. The association between dynamic services and the information provided by the TDF is flexible, and requires a detailed knowledge about the TDF-Application-Identifier or TDF-Application-Instance-Identifier data, or both that trigger the activation of dynamic services in the SAPC.

To provision policies for Dynamic Service Classification for Sd, use the values summarized in the following table:

The result of service classification in Sd is successful if the SAPC matches the application detection information (which includes the TDF application identifier, TDF application instance identifier, and the flow information, provided in the CC-Request Update command from the TDF) with any of the configured rules in the applicable policies:

• Use the /locators/resources/tdf-detected-application/contexts/service-classification URI in the provisioning REST API containing:

  • In the policies attribute, the names of the policies involved in the classification

• For each policy, use the policies URI in the provisioning REST API:

  • Choose any-match as the ruleCombiningAlgorithm attribute.

    The any-match attribute means that the result of the policy contains the output attribute of all the rules included in the policy with the "true" result.

  • In the rules attribute, add the names of the rules for this policy.

• For each rule, use the rules URI in the provisioning REST API:

  • In the condition attribute, include the TDF application identifier, the TDF application instance identifier, the server IP address and/or the server port used to identify the service. The SAPC uses this information to determine whether an evaluated application detection information matches the rule or not. Use the expression language detailed in Configuration Guide for Subscription and Policies. See appendix B for a complete list of the policy tags that can be used.

  • In the attrName attribute of the outputAttributes object, include the "service" value

  • In the attrValue attribute of the outputAttributes object, include the service identifier result of Dynamic Service Classification

  When several rules in a policy are met for different application detection information, the process returns the list of service identifiers of all matched rules.

Table 6 shows examples for dynamic service classification for Sd, whose columns contain the input and output information elements. The rows in the table are evaluated in order.

Figure 2 shows the required configuration for two services ("Skype_audio" and "Skype_video") in one policy and for the "Facebook_streaming" service in a different policy:

Figure 2   Example of Configuration to Classify the Skype Audio and Video and Facebook Streaming Services

Example 7 shows the configuration corresponding to the services and conditions described in Table 6:

Example 7   Configuration of Classification Policies for Dynamic Services in Sd

# ---------------------------------------------
PUT /rules/classifySkypeAudio
{
	"condition" : "(TdfData.tdfAppId == \"skype\")&&(TdfData.tdfAppInstanceId == \"audio\")",
	"outputAttributes" : 
	[
		{
			"attrName" : "service",
			"attrValue" : "\"Skype_audio\"",
			"result" : "permit"
		}
	],
	"ruleName" : "classifySkypeAudio"
}

PUT /rules/classifySkypeVideo
{
	"condition" : "(TdfData.tdfAppId == \"skype\")&&(TdfData.tdfAppInstanceId == \"video\")",
	"outputAttributes" : 
	[
		{
			"attrName" : "service",
			"attrValue" : "\"Skype_video\"",
			"result" : "permit"
		}
	],
	"ruleName" : "classifySkypeVideo"
}

PUT /policies/pClassifySkype
{
	"policyName" : "pClassifySkype",
	"ruleCombiningAlgorithm" : "any-match",
	"rules" : [ "classifySkypeAudio", "classifySkypeVideo" ]
}

PUT /rules/classifyFacebookStreaming
{
	"condition" : "(TdfData.tdfAppId == \"facebook\")&&(TdfData.port == \"995\")",
	"outputAttributes" : 
	[
		{
			"attrName" : "service",
			"attrValue" : "\"Facebook_streaming\"",
			"result" : "permit"
		}
	],
	"ruleName" : "classifyFacebookStreaming"
}

PUT /policies/pClassifyFacebook
{
	"policyName" : "pClassifyFacebook",
	"ruleCombiningAlgorithm" : "any-match",
	"rules" : [ "classifyFacebookStreaming" ]
}

PUT /locators/resources/tdf-detected-application/contexts/service-classification 
{ 
   "policies" : [ "pClassifySkype", "pClassifyFacebook" ] 
}

Dynamic services over Sd can be qualified with QoS or charging data either statically or using policy conditions. The SAPC first evaluates the service qualification policies, but if there are not applicable policies, or the policies are not fulfilled, the SAPC obtains the QoS and charging profiles statically assigned to the dynamic service.

In scenarios where dynamic services do not require a dedicated bearer, but are installed on the default IP-CAN session bearer, it may be required to configure the QoS of the default bearer in connection with the establishment of dynamic services on the IP-CAN session.

The configuration of bearer QoS control is described in Configuration Guide for Bearer QoS and Bandwidth Management. In addition, the following specific QoS selection tags are defined in connection with dynamic services based on notifications received from the Rx and Sd interfaces:

• maxDynQosProfile that returns a QoS profile composed of the highest value for every field in the QoS profile, out of the values obtained for each dynamic PCC Rule running in the IP-CAN session

• sumDynQosProfile that returns a QoS profile composed of the sum of the throughput parameters (GBRs and MBRs) out of the values obtained for each dynamic PCC Rule running in the IP-CAN session, and selecting the highest value in the rest of the QoS parameters

The SAPC can be configured to reevaluate the access and charging policy decisions taken for the IP-CAN and Sd session based on the successful resource allocation of dynamic services.

The configuration of access and charging policy control is described in Configuration Guide for Access and Charging Control (Gx). In addition, the following policy tag is defined in connection with dynamic services based on notifications received from the Rx and Sd interfaces:

• AccessData.subscriber.service["serviceName"].isRunning that indicates if a dynamic service is running in the IP-CAN session. This allows the SAPC to take policy decisions depending on a given dynamic service is running or not.

Example 11 shows how application detection can be used to upgrade the default bearer QoS when specific application traffic is detected by the TDF and reported to the SAPC.

The ADC rule configured in the "Netflix" content is activated in the TDF for subscribers belong to "Bronze" subscriber group. When the TDF notifies the SAPC about the start of the application identified as "NetflixStream", the SAPC updates the default bearer QoS in the PCEF.

Example 11   Default Bearer QoS Upgrade

PUT /contents/Netflix
{
   "contentName" : "Netflix",
   "adcRuleName" : "2000",
   "adcRuleType" : 0
}

PUT /dataplans/Bronze
{
 	"dataplanName" : "Bronze",
   "subscribedContents" :
   [
      {
         "contentName" : "Netflix",
         "redirect" : false
      }
   ],
	   "staticQualification" : 
	   {
		   "maxBearerQosProfileId" : "MaxBearerQoS",
		   "minBearerQosProfileId" : "MinBearerQoS"
	   }
}

PUT /profiles/ip-can-session-qos/MinBearerQoS
{
   "arpPci" : true,
   "arpPriorityLevel" : 3,
   "arpPvi" : false,
   "mbrDownlink" : 512,
   "mbrUplink" : 512,
   "profileId" : "MinBearerQoS",
   "qci" : 6
}

PUT /profiles/ip-can-session-qos/MaxBearerQoS
{
   "arpPci" : true,
   "arpPriorityLevel" : 3,
   "arpPvi" : false,
   "mbrDownlink" : 1024,
   "mbrUplink" : 1024,
   "profileId" : "MaxBearerQoS",
   "qci" : 6
}

PUT /profiles/ip-can-session-qos/UpgradeBearerQoS
{
   "arpPci" : true,
   "arpPriorityLevel" : 3,
   "arpPvi" : false,
   "mbrDownlink" : 2048,
   "mbrUplink" : 2048,
   "profileId" : "UpgradeBearerQoS",
   "qci" : 6
}


PUT /rules/rQosUpgrade
{
   "condition" : "(TdfData.tdfApp[\"NetflixStream\"].isStarted)",
   "outputAttributes" : 
   [
      {
         "attrName" : "max-qos",
         "attrValue" : "BearerQosProfile[\"UpgradeBearerQoS\"]",
         "result" : "permit"
      }   ],
	"ruleName" : "rQosUpgrade"
}

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

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

Example 12 shows how application detection can be used to allocate a dedicated bearer, when specific application traffic is detected by the TDF and reported to the SAPC.

The ADC rule configured in the "YouTube" content is activated in the TDF for subscribers belong to "Premium" subscriber group. When the TDF notifies the SAPC about the starting of the application identified as "YouTubeStream" and delivered from the remote server using ports in the range of 1000-2000, the SAPC requests to initiate a dedicated bearer in the PCEF.

Example 12   YouTube Dedicated Bearer Allocation"

PUT /profiles/content-charging/Char_YouTube
{
	"chargingServiceId" : 301,
	"profileId" : "Char_YouTube",
	"ratingGroup" : 301,
	"reportingLevel" : 1
}

PUT /profiles/content-qos/QoS_YouTube
{
	"arpPriorityLevel" : 7,
	"profileId" : "QoS_YouTube",
	"qci" : 2
}

PUT /contents/YouTube
{
	"contentName" : "YouTube",
	"staticQualification" : 
	{
		"contentChargingProfileId" : "Char_YouTube",
		"contentQosProfileId" : "QoS_YouTube"
	}
}

PUT /rules/rule_YouTube
{
	"condition" : "(TdfData.tdfAppId == \"YouTubeStream\") && inRange(TdfData.port,\"1000-2000\")",
	"outputAttributes" : 
	[
		{
			"attrName" : "service",
			"attrValue" : "\"YouTube\"",
			"result" : "permit"
		}
	],
	"ruleName" : "rule_YouTube"
}

PUT /policies/policy_YouTube
{
	"policyName" : "policy_YouTube",
	"ruleCombiningAlgorithm" : "any-match",
	"rules" : [ "rule_YouTube" ]
}

PUT /locators/resources/tdf-detected-application/contexts/service-classification
{
	"policies" : [ "policy_YouTube" ]
}