Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.203  Word version:  17.2.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   6.1.4…   6.1.7…   6.1.10…   6.1.17…   6.2…   6.2.2…   6.2.3…   6.3   6.4…   6.8…   7…   7.3…   7.4…   7.7…   7.7.3…   7.8…   A…   A.4…   D…   P…   P.4.2.4…   P.7…   P.7.5…   P.8   Q…   S…   S.7…   S.8.8   T…

 

6.8  Application Detection and Control Rule |R11|p. 120

6.8.1  Generalp. 120

The Application Detection and Control rule (ADC rule) comprises the information that is required in order to:
  • identify the rule;
  • detect the Start and Stop of traffic for a certain application;
  • apply enforcement actions and charging for the application traffic detected by the rule;
  • apply charging for the application traffic detected by the rule.
ADC rules are applicable over the Sd reference point. Over the Sd reference point, the ADC rules are used to support application detection and control as defined in clause 4.5 including traffic steering control as defined in clause 4.8.
ADC Rules are also applicable over the St reference point. Over the St reference point, the ADC rules are used to transfer traffic steering control information as defined in clause 6.11.1.
ADC rules definitions are assumed to be directly provisioned into the TDF or TSSF and referenced by the PCRF with the ADC Rule identifier.
Two types of ADC rules exist: Predefined and dynamic ADC rules. A predefined ADC rule is constant and shall not be changed. For a dynamic ADC rule, some parameters can be provided and modified by the PCRF as defined in Table 6.8.
There are defined procedures for activation, modification and deactivation of ADC rules (as described in clause 6.8.2). The PCRF may activate, modify and deactivate an ADC rule at any time. The modification procedure is applicable to dynamic ADC rules only.
The operator defines the ADC rules.
Table 6.8 lists the information contained in an ADC rule that can be exchanged over the Sd and St reference point, including the information element name, the description, whether the PCRF may modify this information in a dynamic ADC rule which is active in the TDF and the applicable reference point (i.e. Sd and/or St) for the corresponding information element. The Category field indicates if a certain piece of information is mandatory or not for the construction of an ADC rule, i.e. if it is possible to construct an ADC rule without it.
Information name Description Category PCRF permitted to modify for a dynamic ADC rule Applicable reference point
ADC Rule identifierUniquely identifies the ADC rule within a TDF/TSSF session. It is used between PCRF and TDF/TSSF for referencing ADC rules.MandatoryNoSd, St
Application detectionThis clause defines the detection and the application name.Sd, St
PrecedenceFor ADC, the precedence is only relevant for the enforcement, i.e. when multiple ADC rules overlap, only the enforcement, reporting of application starts and stops, monitoring, and charging actions of the ADC rule with the highest precedence shall be applied.OptionalYesSd, St
Application identifier (NOTE 2)References the corresponding application detection filter for the detection of the service data flow. References the corresponding application, for which the rule applies.Conditional (NOTE 5)NoSd, St
Service data flow filter listA list of service data flow filters for the detection of the traffic.Conditional (NOTE 5)NoSd, St
Mute for notificationDefines whether application's start or stop notification is to be muted.OptionalNoSd
Usage Monitoring ControlThis clause describes identities required for Usage Monitoring Control.Sd
Monitoring keyThe PCRF uses the monitoring key to group applications that share a common allowed usage.OptionalYesSd
Indication of exclusion from session level monitoringIndicates that the application shall be excluded from the TDF session usage monitoring.OptionalYesSd
Enforcement controlThis clause defines how the TDF shall apply enforcement actions for the detected application traffic.Sd
Gate statusThe gate status indicates whether the detected application may pass (Gate is open) or shall be discarded (Gate is closed) at the TDF.OptionalYesSd
UL-maximum bit rateThe uplink maximum bit rate authorized for the application trafficOptionalYesSd
DL-maximum bit rateThe downlink maximum bit rate authorized for the application trafficOptionalYesSd
RedirectRedirect state of detected application traffic (enabled/disabled)OptionalYesSd
Redirect DestinationControlled Address to which detected application traffic should be redirected when redirect is enabledConditional (NOTE 1) YesSd
DSCP valueDownlink packets of detected application traffic shall be marked with this DSCP value.Optional (NOTE 4) YesSd
ChargingThis clause defines identities and instructions for charging and accounting that is required for an access point where application usage charging is configuredSd
Charging keyThe charging system (OCS or OFCS) uses the charging key to determine the tariff to apply for the application.OptionalYesSd
Service identifierIdentifies one or more applications to the charging system.OptionalYesSd
Sponsor IdentifierAn identifier, provided from the AF which identifies the Sponsor, used for sponsored flows to correlate measurements from different users for accounting purposes.Conditional (NOTE 7)Yes
Application Service Provider IdentifierAn identifier, provided from the AF which identifies the Application Service Provider, used for sponsored flows to correlate measurements from different users for accounting purposes.Conditional (NOTE 7)YesSd
Charging methodIndicates the required charging method for the ADC rule.
Values: online, offline or neither.
Conditional (NOTE 3)NoSd
Measurement methodIndicates whether the application data volume, duration, combined volume/duration or event shall be measured.
This is applicable for reporting, if the charging method is online or offline.
OptionalYesSd
Service identifier level reportingIndicates that separate usage reports shall be generated for this Service identifier.
Values: mandated or not required.
OptionalYesSd
Traffic Steering Enforcement ControlThis part describes identities required for Traffic Steering Enforcement Control.Sd, St
Traffic steering policy identifier(s)Reference to a pre-configured traffic steering policy at the TDF/TSSF (NOTE 6).OptionalYesSd, St
NOTE 1:
If Redirect is enabled.
NOTE 2:
For every ADC rule this information is pre-configured in the TDF.
NOTE 3:
Mandatory if there is no default charging method for the TDF session. It is possible to activate both online and offline charging for the same ADC Rule.
NOTE 4:
See Annex U for details regarding how to apply policy and charging control for an application detected and marked by the TDF in the downlink direction (typically application with non-deducible service data flows).
NOTE 5:
Either Application identifier or Service data flow filter list shall be included.
NOTE 6:
The Traffic steering policy identifier can be different for uplink and downlink direction. If two Traffic steering policy identifiers are provided, then one is for uplink direction, while the other one is for downlink direction.
NOTE 7:
Applicable to sponsored data connectivity.
The ADC Rule identifier shall be unique for an ADC rule within a TDF/TSSF session.
The Precedence defines, if multiple ADC rules overlap, which ADC Rule shall be applied for the purpose of enforcement, reporting of application start and stop, monitoring, and charging. When a dynamic ADC rule and a predefined ADC rule have the same precedence, the dynamic ADC rule takes precedence. For dynamic ADC rules, the Precedence shall be either preconfigured at the TDF/TSSF or provided dynamically by the PCRF within the ADC Rules.
The Application identifier references the corresponding application detection filter that is used for matching user plane packets. It is also used for identifying the application, for which the rule applies, during reporting to the PCRF. The same application identifier value can occur in more than one ADC rule. If so, the PCRF shall ensure that there is at most one ADC rule active per application identifier value at any time.
Instead of Application identifier, the Service data flow filter list may be provided which comprises one or more Service data flow filters and is used by the TDF or TSSF to identify the packets belonging to a detected traffic. The format of the Service data flow filter is described in clause 6.2.2.2, except the filters extending the inspection to look further into the packet and/or define other operations as those are identified by Application Identifier.
The Mute for notification defines whether notification of application's start or stop shall be muted to the PCRF. Absence of this parameter means that start/stop notifications shall be sent.
The Monitoring Key is the reference to a resource threshold. Any number of ADC Rules may share the same monitoring key value. The monitoring key values for each application shall be operator configurable.
The Indication of exclusion from session level monitoring indicates that the application shall be excluded from the TDF session usage monitoring.
The Gate status indicates whether the TDF shall let detected application traffic pass through (gate is open) the TDF or the TDF shall discard (gate is closed) the application traffic.
The UL maximum-bitrate indicates the authorized maximum bitrate for the uplink component of the detected application traffic.
The DL maximum-bitrate indicates the authorized maximum bitrate for the downlink component of the detected application traffic.
The Redirect indicates whether the uplink part of the detected application traffic should be redirected to a controlled address.
The Redirect Destination indicates the target redirect address when Redirect is enabled.
The DSCP value indicates the value with which a TDF marks downlink application traffic identified by an ADC rule.
The Charging key is the reference to the tariff for the application. Any number of ADC Rules may share the same charging key value. The charging key values for each application shall be operator configurable.
The Service identifier identifies one or more applications to the charging system. ADC Rules may share the same Service identifier value. The service identifier provides the most detailed identification specified for application based charging.
The Sponsor Identifier indicates the (3rd) party organization willing to pay for the operator's charge for connectivity required to deliver a service to the end user.
The Application Service Provider Identifier indicates the (3rd) party organization delivering a service to the end user.
The Charging method indicates whether online charging, offline charging, or both are required or the application is not subject to any end user charging. If the charging method identifies that the application is not subject to any end user charging, a Charging key shall not be included in the ADC rule for that application, along with other charging related parameters. If the charging method is omitted, the TDF shall apply the default charging method as determined at TDF session establishment (see clause 6.4a). The Charging method is mandatory if there is no default charging method for the TDF session.
The Measurement method indicates what measurements apply for charging for ADC rule.
The Service Identifier Level Reporting indicates whether the TDF shall generate reports per Service Identifier. The TDF shall accumulate the measurements from all ADC rules with the same combination of Charging key/Service Identifier values in a single report.
The Traffic Steering Policy Identifier(s) is a reference to a pre-configured traffic steering policy at the TDF/TSSF as defined in clause 6.11.1.
Up

6.8.2  Application Detection and Control rule operations over Sdp. 126

Application Detection and Control rule operations apply to solicited reporting and consist of activation, modification and deactivation of ADC rules.
Activation: The PCRF provides the ADC Rule identifier to the TDF. The PCRF may provide data for usage monitoring and enforcement control for a dynamic ADC rule.
An active ADC rule means that:
  • The application traffic, matching the corresponding application, can be detected; and
  • Start or stop of application traffic is reported to the PCRF, if applicable and requested by the PCRF; the notification for Start may include service data flow filters, if possible to provide; and the application instance identifier associated with the service data flow filter; and
  • Monitoring and enforcement, as specified within the rule, is applied.
The PCRF may, at any time, modify an active, dynamic ADC rule.
The PCRF may, at any time, deactivate an active ADC rule. The TDF session termination shall deactivate all ADC rules for that IP-CAN session.
Application Detection and Control rule activation/deactivation operations can also be performed in a deferred mode. An ADC rule may have either a single deferred activation time, or a single deferred deactivation time or both.
An ADC rule with only a deferred activation time shall be inactive until that time. An ADC rule with only a deferred deactivation time shall be active until that time. When the rule activation time occurs prior to the rule deactivation time, the rule is inactive until the activation and remains active until the deactivation time occurs. When the rule deactivation time occurs prior to the rule activation time, the rule is initially active until the deactivation time, then remains inactive until the activation time, and then becomes active again. An inactive ADC rule, that has not been activated yet, is still considered to be installed, and may be removed by the PCRF.
The PCRF may modify a currently installed dynamic ADC rule, including setting, modifying or clearing its deferred activation and/or deactivation time.
When modifying a dynamic ADC rule with a prior and/or new deferred activation and/or deactivation time, the PCRF shall provide all attributes of that rule, including attributes that have not changed.
Up

6.9  Policy decisions based on spending limits |R11|p. 127

Policy decisions based on spending limits is a function that allows PCRF taking actions related to the status of policy counters that are maintained in the OCS.
The identifiers of the policy counters that are relevant for a policy decision in the PCRF may be stored in the PCRF or possibly in SPR. The PCRF is configured with the actions associated with the policy counter status that is received from OCS.
The PCRF may request the status of policy counters in the OCS using the Initial or Intermediate Spending Limit Report Request Procedure. The OCS provides the current status of the requested policy counters to the PCRF. The OCS may in addition provide one or more pending statuses for a requested policy counter together with the time they have to be applied. The PCRF shall immediately apply the current status of a policy counter. A pending status of a policy counter shall autonomously become the current status of a policy counter at the PCRF when the indicated corresponding time is reached. Subsequently provided information for pending statuses of a policy counter shall overwrite the previously received information.
The PCRF may subscribe to spending limit reporting for policy counters from the OCS using the Initial or Intermediate Spending Limit Report Request procedure. If spending limit reporting for a policy counter is enabled, the OCS shall notify the PCRF of changes in the status of this policy counter (e.g. daily spending limit of $2 reached) and optionally pending statuses of this policy counter together with their activation time (e.g. due to a billing period that will expire at midnight). The PCRF may cancel spending limit reporting for specific policy counter(s) using the Intermediate Spending Limit Report Request procedure, or for all policy counter(s) using the Final Spending Limit Report Request procedure.
The PCRF uses the status of each relevant policy counter, and optional pending policy counter statuses if known, as input to its policy decision to apply operator defined actions, e.g. change the QoS (e.g. downgrade APN-AMBR), modify the PCC/QoS/ADC Rules to apply gating or change charging conditions.
Up

6.11  Traffic Steering Control Information |R13|p. 128

6.11.1  Generalp. 128

The traffic steering control information comprises the information that is required to enable traffic steering for a detected application or service data flow. The traffic steering control information is transferred:
  • From the PCRF to the PCEF within PCC rules over Gx reference point;
  • From the PCRF to the TDF within ADC rules over Sd reference point;
  • From the PCRF to the TSSF within ADC rules over St reference point.
Table 6.11 lists the components of traffic steering control information, and their corresponding information names in PCC/ADC rule.
Component of traffic steering control information Corresponding information name in ADC rule (NOTE 1) Corresponding information name in PCC rule (NOTE 2)
Rule NameADC Rule IdentifierRule identifier
Description of TrafficApplication Identifier or Service data flow filter listService Data Flow Template
Traffic steering policy identifier(s) (NOTE 3)Traffic steering policy identifier(s) (NOTE 3)Traffic steering policy identifier(s) (NOTE 3)
PrecedencePrecedencePrecedence
NOTE 1:
The information definition refers to Table 6.8.
NOTE 2:
The information definition refers to Table 6.3.
NOTE 3:
The Traffic steering policy identifier can be different for uplink and downlink direction. If two Traffic steering policy identifiers are provided, then one is for uplink direction, while the other one is for downlink direction.
The Traffic Steering Policy Identifier is a reference to traffic steering policy locally configured at the PCEF/TDF/TSSF. The traffic steering policy identifies, explicitly or implicitly, a specific set of service functions and their order via which the traffic, identified by the description of traffic included in the traffic steering control information, needs to be steered in the (S)Gi-LAN.
For traffic steering control at the PCEF, the PCC Rule operations described in the clause 6.3.2 apply.
For traffic steering control at the TDF, the ADC Rule operations over Sd described in the clause 6.8.2 apply.
For traffic steering control at the TSSF, the Traffic Steering Control operations over St described in the clause 6.11.2 apply.
Up

6.11.2  Traffic Steering Control Operations over Stp. 128

Traffic steering control operations over St consists of provisioning, modification, and removal of traffic steering control information.
Provisioning: Provisioning of traffic steering control information to the TSSF includes the activation of traffic steering policy, so that the traffic detected by the service data flow filter list or the application identifier can be steered in the SGi-LAN according to the information associated with the traffic steering policy identifier. The PCRF provides the UE IP address and the associated APN when provisioning of traffic steering control information to the TSSF. The TSSF uses the APN to determine the PDN.
When using ADC Rules, the following applies:
  • For pre-defined ADC rules in TSSF, the PCRF provides the ADC Rule identifier(s) to the TSSF;
  • For dynamic ADC Rules, the PCRF provides traffic steering control information within the ADC rules to the TSSF.
Modification: The PCRF may modify traffic steering control information to change the traffic steering policy identifier(s), the precedence, the service data flow filters or application identifier.
When using ADC Rules, the PCRF may modify a dynamic ADC rule.
Removal: The PCRF may, at any time, remove traffic steering control information.
When using ADC Rules, the PCRF may remove ADC Rule(s).
Up

6.12  NBIFOM Routing rule |R13|p. 129

6.12.1  Generalp. 129

The NBIFOM routing rule comprises the information about the UE request to associate an access type to a service data flow filter. The NBIFOM routing rules are provided by the PCEF to the PCRF during IP-CAN session establishment or modification.
The PCEF derives NBIFOM routing rules based on the Routing Rules received from the UE (when UE-initiated NBIFOM mode applies) or based on requests from the UE to have the network create / modify / delete Routing Rules (when Network-initiated NBIFOM mode applies), as described in TS 23.161.
Table 6.12 lists the information contained in an NBIFOM routing rule, including the information name, the description and whether the PCEF may modify this information in an updated version of the rule. The Category field indicates if a certain piece of information is mandatory or not.
Information name Description Category PCEF permitted to modify in an update
Routing Rule identifierUniquely identifies the routing rule within an IP-CAN session.MandatoryNo
Routing informationThis clause defines the method for detecting packets belonging to a flow and the route for the flow.
Routing Rule PriorityDetermines the order, in which the routing filters are applied.MandatoryYes
Routing FilterA packet filter for the detection of IP flows.MandatoryYes
Routing Access InformationThe access type that the matching IP flows intend to use.MandatoryYes
The Routing Rule identifier shall be unique for a NBIFOM routing rule within an IP-CAN session. It is set to the Routing Rule identifier assigned by the UE when UE-initiated NBIFOM mode applies as specified in TS 23.161 or by the PCRF when Network-initiated NBIFOM mode applies.
The Routing Rule Priority defines in what order the NBIFOM routing rules are used by the PCRF to determine where to route a service data flow. The Routing Rule Priority is set according to the information provided by the UE as specified in TS 23.161.
The Routing Filter comprises a single packet filter, containing information for matching IP flows. The format of the routing filter is the same as the service data flow filter described in clause 6.2.2.2. The Routing Filter is set according to the information provided by the UE as specified in TS 23.161.
The Routing Access Information indicates the IP-CAN type that the IP flows matching the Routing Filter of this NBIFOM routing rule intend to use.
Up

6.12.2  NBIFOM Routing rule operationsp. 130

NBIFOM routing rule operations consist of creation, modification and removal of a NBIFOM routing rule.
At creation of a NBIFOM routing rule, the PCEF provides the NBIFOM routing rule information to the PCRF. The PCRF checks if there is a PCC Rule with a corresponding service data flow template installed in the PCEF. If it is so, the PCRF updates the Allowed Access Type in this PCC Rule according to the Routing Access Information. Otherwise a new PCC Rules is created with a service data flow filter equal to the Routing Filter, a precedence according to the Routing Rule Priority and the Allowed Access Type set to the Routing Access Information and then installed in the PCEF.
The PCRF shall store the relation between the Routing Rule identifier and the corresponding PCC rule. The PCRF may also reject a NBIFOM routing rule according to operator policy.
The modification of a NBIFOM routing rule to change the Routing Filter or the Routing Rule Priority triggers the PCRF to modify the service data flow filter or precedence in the corresponding installed PCC Rule accordingly.
The modification of a NBIFOM routing rule to change the Routing Access Information triggers the PCRF to change the Allowed Access Type in the corresponding installed PCC Rule accordingly.
The removal of a NBIFOM routing rule triggers the PCRF to remove the corresponding PCC Rule if the PCC rule creation was triggered by this NBIFOM routing rule. Otherwise, the PCRF removes only the Allowed Access Type in this PCC Rule.
Up

Up   Top   ToC