6.8 Application Detection and Control Rule
23.2033GPPPolicy and charging control architectureRelease 17TS
6.8.1 General
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.
NOTE 1: The method to perform the detection, in particular for the Start and Stop, may extend beyond the IP header and is out of scope for this document.
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.
Table 6.8: The Application Detection and Control rule information
|
Information name |
Description |
Category |
PCRF permitted to modify for a dynamic ADC rule |
Applicable reference point |
|---|---|---|---|---|
|
ADC Rule identifier |
Uniquely identifies the ADC rule within a TDF/TSSF session. It is used between PCRF and TDF/TSSF for referencing ADC rules. |
Mandatory |
No |
Sd, St |
|
Application detection |
This clause defines the detection and the application name. |
Sd, St |
||
|
Precedence |
For 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. |
Optional |
Yes |
Sd, 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) |
No |
Sd, St |
|
Service data flow filter list |
A list of service data flow filters for the detection of the traffic. |
Conditional (NOTE 5) |
No |
Sd, St |
|
Mute for notification |
Defines whether application’s start or stop notification is to be muted. |
Optional |
No |
Sd |
|
Usage Monitoring Control |
This clause describes identities required for Usage Monitoring Control. |
Sd |
||
|
Monitoring key |
The PCRF uses the monitoring key to group applications that share a common allowed usage. |
Optional |
Yes |
Sd |
|
Indication of exclusion from session level monitoring |
Indicates that the application shall be excluded from the TDF session usage monitoring. |
Optional |
Yes |
Sd |
|
Enforcement control |
This clause defines how the TDF shall apply enforcement actions for the detected application traffic. |
Sd |
||
|
Gate status |
The gate status indicates whether the detected application may pass (Gate is open) or shall be discarded (Gate is closed) at the TDF. |
Optional |
Yes |
Sd |
|
UL-maximum bit rate |
The uplink maximum bit rate authorized for the application traffic |
Optional |
Yes |
Sd |
|
DL-maximum bit rate |
The downlink maximum bit rate authorized for the application traffic |
Optional |
Yes |
Sd |
|
Redirect |
Redirect state of detected application traffic (enabled/disabled) |
Optional |
Yes |
Sd |
|
Redirect Destination |
Controlled Address to which detected application traffic should be redirected when redirect is enabled |
Conditional (NOTE 1) |
Yes |
Sd |
|
DSCP value |
Downlink packets of detected application traffic shall be marked with this DSCP value. |
Optional (NOTE 4) |
Yes |
Sd |
|
Charging |
This clause defines identities and instructions for charging and accounting that is required for an access point where application usage charging is configured |
Sd |
||
|
Charging key |
The charging system (OCS or OFCS) uses the charging key to determine the tariff to apply for the application. |
Optional |
Yes |
Sd |
|
Service identifier |
Identifies one or more applications to the charging system. |
Optional |
Yes |
Sd |
|
Sponsor Identifier |
An 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 Identifier |
An 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) |
Yes |
Sd |
|
Charging method |
Indicates the required charging method for the ADC rule. Values: online, offline or neither. |
Conditional (NOTE 3) |
No |
Sd |
|
Measurement method |
Indicates 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. |
Optional |
Yes |
Sd |
|
Service identifier level reporting |
Indicates that separate usage reports shall be generated for this Service identifier. Values: mandated or not required. |
Optional |
Yes |
Sd |
|
Traffic Steering Enforcement Control |
This 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). |
Optional |
Yes |
Sd, 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.
NOTE 2: The PCRF has to ensure that there is no dynamically provided ADC rule that has the same Rule identifier value as any of the predefined ADC rules.
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.
NOTE 3: The operator shall ensure that overlap between the predefined ADC rules can be resolved based on precedence of each predefined ADC rule in the TDF. For dynamic ADC rules, if precedence is not preconfigured in the TDF, the PCRF shall ensure that overlap between the dynamic ADC rules can be resolved based on precedence of each dynamic ADC rule.
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.
NOTE 4: The same application identifier value could be used for a dynamic ADC rule and a predefined ADC rule or for multiple predefined ADC rules.
NOTE 5: The configuration of the Application Identifier in the TDF can include the set of information required for encrypted traffic detection as defined in Annex X.
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.
NOTE 6: The maximum bit rate is an average value, which is measured over some time period. Services may generate media with variable bitrate. The policing function should take such bitrate variations into account.
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.
NOTE 7: Assigning the same Charging key for several applications implies that the charging does not require the credit management to be handled separately.
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.
NOTE 8: The Service Identifier need not have any relationship to service identifiers used on the AF level, i.e. is an operator policy option.
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.
6.8.2 Application Detection and Control rule operations over Sd
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.
NOTE: In this case, the PCRF omission of an attribute that has a prior value will erase that attribute from the rule.