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.3  Policy and charging control rulep. 102

6.3.1  Generalp. 102

The Policy and charging control rule (PCC rule) comprises the information that is required to enable the user plane detection of, the policy control and proper charging for a service data flow. The packets detected by applying the service data flow template of a PCC rule form a service data flow.
Two different types of PCC rules exist: Dynamic rules and predefined rules. The dynamic PCC rules are provisioned by the PCRF via the Gx reference point, while the predefined PCC rules are directly provisioned into the PCEF and only referenced by the PCRF. The usage of predefined PCC rules for QoS control is possible if the BBF remains in the PCEF during the lifetime of an IP-CAN session. In addition, predefined PCC rules may be used in a non-roaming situation and if it can be guaranteed that corresponding predefined QoS rules are configured in the BBF and activated along with the predefined PCC rules.
There are defined procedures for activation, modification and deactivation of PCC rules (as described in clause 6.3.2). The PCRF may activate, modify and deactivate a PCC rule at any time, over the Gx reference point. However, the modification procedure is applicable to dynamic PCC rules only.
Each PCC rule shall be installed for a single IP-CAN bearer only (for further details about predefined PCC rules see clause 6.3.2).
The operator defines the PCC rules.
Table 6.3 lists the information contained in a PCC rule, including the information name, the description and whether the PCRF may modify this information in a dynamic PCC rule which is active in the PCEF. The Category field indicates if a certain piece of information is mandatory or not for the construction of a PCC rule, i.e. if it is possible to construct a PCC rule without it.
Information name Description Category PCRF permitted to modify for a dynamic PCC rule in the PCEF
Rule identifierUniquely identifies the PCC rule, within an IP-CAN session.
It is used between PCRF and PCEF for referencing PCC rules.
Mandatoryno
Service data flow detectionThis part defines the method for detecting packets belonging to a service data flow.
PrecedenceDetermines the order, in which the service data flow templates are applied at service data flow detection, enforcement and charging. (NOTE 9).Conditional (NOTE 13)yes
Service data flow templateEither a list of service data flow filters or an application identifier that references the corresponding application detection filter for the detection of the service data flow.Mandatory (NOTE 7)Conditional (NOTE 12)
Mute for notificationDefines whether application's start or stop notification is to be muted.Conditional (NOTE 8)No
ChargingThis part defines identities and instructions for charging and accounting that is required for an access point where flow based charging is configured.
Charging keyThe charging system (OCS or OFCS) uses the charging key to determine the tariff to apply to the service data flow.yes
Service identifierThe identity of the service or service component the service data flow in a rule relates to.yes
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 6)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 6)yes
Charging methodIndicates the required charging method for the PCC rule.
Values: online, offline or neither.
Conditional (NOTE 4) no
Measurement methodIndicates whether the service data flow data volume, duration, combined volume/duration or event shall be measured.
This is applicable to reporting, if the charging method is online or offline.
Note: Event based charging is only applicable to predefined PCC rules and PCC rules used for application detection filter (i.e. with an application identifier).
yes
Application Function Record InformationAn identifier, provided from the AF, correlating the measurement for the Charging key/Service identifier values in this PCC rule with application level reports.no
Service identifier level reportingIndicates that separate usage reports shall be generated for this Service identifier.
Values: mandated or not required
Yes
Policy controlThis part defines how the PCEF shall apply policy control for the service data flow.
Gate statusThe gate status indicates whether the service data flow, detected by the service data flow template, may pass (Gate is open) or shall be discarded (Gate is closed) at the PCEF.Yes
QoS class identifier Identifier for the authorized QoS parameters for the service data flow.
Values: see NOTE 1.
Conditional (NOTE 2) Yes
UL-maximum bitrateThe uplink maximum bitrate authorized for the service data flowConditional (NOTE 3) Yes
DL-maximum bitrateThe downlink maximum bitrate authorized for the service data flowConditional (NOTE 3) Yes
UL-guaranteed bitrateThe uplink guaranteed bitrate authorized for the service data flowYes
DL-guaranteed bitrateThe downlink guaranteed bitrate authorized for the service data flowYes
UL sharing indicationIndicates resource sharing in uplink direction with service data flows having the same value in their PCC ruleNo
DL sharing indicationIndicates resource sharing in downlink direction with service data flows having the same value in their PCC ruleNo
RedirectRedirect state of the service data flow (enabled/disabled)Conditional (NOTE 10)Yes
Redirect DestinationControlled Address to which the service data flow is redirected when redirect is enabledConditional (NOTE 11)Yes
ARPThe Allocation and Retention Priority for the service data flow consisting of the priority level, the pre-emption capability and the pre-emption vulnerabilityConditional (NOTE 5)Yes
Bind to Default BearerIndicates that the dynamic PCC rule shall always have its bearer binding with the default bearer.Conditional (NOTE 15)Yes
PS to CS session continuityIndicates whether the service data flow is a candidate for vSRVCC.ConditionalNo
Access Network Information Reportinghis part describes access network information to be reported for the PCC rule when the corresponding bearer is established, modified or terminated.
User Location ReportThe serving cell of the UE is to be reported. When the corresponding bearer is deactivated, and if available, information on when the UE was last known to be in that location is also to be reported.Yes
UE Timezone ReportThe time zone of the UE is to be reported.Yes
Usage Monitoring ControlThis part describes identities required for Usage Monitoring Control.
Monitoring keyThe PCRF uses the monitoring key to group services that share a common allowed usage.Yes
Indication of exclusion from session level monitoringIndicates that the service data flow shall be excluded from the IP-CAN session usage monitoringYes
Traffic Steering Enforcement ControlThis part describes identities required for Traffic Steering Enforcement Control.
Traffic steering policy identifier(s)Reference to a pre-configured traffic steering policy at the PCEF (NOTE 14).Yes
NBIFOM related control InformationThis part describes PCC rule information related with NBIFOM (defined in TS 23.161. Refer also to clause 6.1.18.
Allowed Access TypeThe access to be used for traffic identified by the PCC ruleYes
Routing Rule IdentifierThe Routing Rule identifier to be used in NBIFOM routing ruleNo
RAN support informationThis part defines information supporting the RAN for e.g. handover threshold decision.
UL Maximum Packet Loss RateThe maximum rate for lost packets that can be tolerated in the uplink direction for service data flow. It is defined in TS 23.401, clause 5.4.1. Conditional (NOTE 16)Yes
DL Maximum Packet Loss RateThe maximum rate for lost packets that can be tolerated in the downlink direction for service data flow. It is defined in TS 23.401, clause 5.4.1. Conditional (NOTE 16)Yes
NOTE 1:
The QoS class identifier is scalar and accommodates the need for differentiating QoS in all types of 3GPP IP-CAN. The value range is expandable to accommodate additional types of IP-CAN.
NOTE 2:
The QoS class identifier is mandatory when the bearer binding is allocated to the PCEF.
NOTE 3:
Mandatory when the QoS class identifier is of Resource Type GBR. Used to activate policy control on SDF level at the PCEF.
NOTE 4:
Mandatory if there is no default charging method for the IP-CAN session.
NOTE 5:
Mandatory when policy control on SDF level applies unless otherwise stated in an access-specific Annex.
NOTE 6:
Applicable to sponsored data connectivity.
NOTE 7:
Either service data flow filter(s) or application identifier shall be defined per each rule. application identifier can only be used for PCEF enhanced with ADC.
NOTE 8:
Optional and applicable only if application identifier exists within the rule.
NOTE 9:
For PCC rules based on an application detection filter, the precedence is only relevant for the enforcement, i.e. when multiple PCC rules overlap, only the enforcement, reporting of application starts and stops, monitoring, and charging actions of the PCC rule with the highest precedence shall be applied.
NOTE 10:
Optional and applicable only if application identifier exists within the rule.
NOTE 11:
If Redirect is enabled.
NOTE 12:
YES, in case the service data flow template consists of a set of service data flow filters. NO in case the service data flow template consists of an application identifier.
NOTE 13:
The Precedence is mandatory for PCC rules with SDF template containing SDF filter(s). For dynamic PCC rules with SDF template containing an application identifier, the precedence is either preconfigured in PCEF or provided in the PCC rule from PCRF.
NOTE 14:
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 15:
The presence of this attribute causes the QCI/ARP of the rule to be ignored. This attribute is defined for selected accesses as specified in the access specific Annexes.
NOTE 16:
Optional and applicable only for voice service data flow in this Release.
The Rule identifier shall be unique for a PCC rule within an IP-CAN session. A dynamically provided PCC rule that has the same Rule identifier value as a predefined PCC rule shall replace the predefined rule within the same IP-CAN session.
The Service data flow template may comprise any number of Service data flow filters. A Service data flow filter contains information for matching user plane packets. A Service data flow filter, provided from the PCRF, contains information elements as described in clause 6.2.2.2. The Service data flow template filtering information within an activated PCC rule is applied at the PCEF to identify the packets belonging to a particular service data flow.
Alternatively, the Service data flow template consists of an application identifier that references an application detection filter that is used for matching user plane packets. The application identifier is also identifying the application, for which the rule applies. The same application identifier value can occur in more than one PCC rule with the following restrictions:
  • The same application identifier value can be used for a dynamic PCC rule and one or multiple predefined PCC rules. If so, the PCRF shall ensure that there is at most one PCC rule active per application identifier value at any time.
The Mute for notification defines whether notification to the PCRF of application's starts or stops shall be muted. Absence of this parameter means that start/stop notifications shall be sent.
The Precedence defines in what order the activated PCC rules within the same IP-CAN session shall be applied at the PCEF for service data flow detection. When a dynamic PCC rule and a predefined PCC rule have the same precedence, the dynamic PCC rule takes precedence. For dynamic PCC rules that contain an application identifier, the Precedence shall be either preconfigured at the PCEF or provided dynamically by the PCRF within the PCC Rules.
For downlink packets all the service data flow templates, activated for the IP-CAN session shall be applied for service data flow detection and for the mapping to the correct IP-CAN bearer. For uplink packets the service data flow templates activated on their IP-CAN bearer shall be applied for service data flow detection (further details provided in clause 6.2.2.2 and the IP-CAN specific annexes).
The Charging key is the reference to the tariff for the service data flow. Any number of PCC Rules may share the same charging key value. The charging key values for each service shall be operator configurable.
The Service identifier identifies the service. PCC Rules may share the same service identifier value. The service identifier provides the most detailed identification, specified for flow based charging, of a service data flow.
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 service data flow is not subject to any end user charging. If the charging method identifies that the service data flow is not subject to any end user charging, a Charging key shall not be included in the PCC rule for that service data flow, along with other charging related parameters. If the charging method is omitted the PCEF shall apply the default charging method as determined at IP-CAN session establishment (see clause 6.4). The Charging method is mandatory if there is no default charging method for the IP-CAN session.
The Measurement method indicates what measurements apply to charging for PCC rule.
The Service Identifier Level Reporting indicates whether the PCEF shall generate reports per Service Identifier. The PCEF shall accumulate the measurements from all PCC rules with the same combination of Charging key/Service identifier values in a single report.
The Application function record information identifies an instance of service usage. A subsequently generated usage report, generated as a result of the PCC rule, may include the Application function record information, if available. The Application Function Record Information may contain the AF Charging Identifier and/or the Flow identifiers. The report is however not restricted to include only usage related to the Application function record information reported, as the report accumulates the usage for all PCC rules with the same combination of Charging key/Service identifier values. If exclusive charging information related to the Application function record information is required, the PCRF shall provide a service identifier, not used by any other PCC rule of the IP-CAN session at this point in time, for the AF session.
The Gate indicates whether the PCEF shall let a packet identified by the PCC rule pass through (gate is open) the PCEF, or the PCEF shall discard (gate is closed) the packet.
The QoS Class Identifier for the service data flow. The QoS class identifier represents the QoS parameters for the service data flow. The PCEF maintains the mapping between QoS class identifier and the QoS concept applied within the specific IP-CAN. The bitrate information is separate from the QoS class identifier value.
The bitrates indicate the authorized bitrates at the IP packet level of the SDF, i.e. the bitrates of the IP packets before any IP-CAN specific compression or encapsulation.
The UL maximum-bitrate indicates the authorized maximum bitrate for the uplink component of the service data flow.
The DL maximum-bitrate indicates the authorized maximum bitrate for the downlink component of the service data flow.
The UL guaranteed-bitrate indicates the authorized guaranteed bitrate for the uplink component of the service data flow.
The DL guaranteed-bitrate indicates the authorized guaranteed bitrate for the downlink component of the service data flow.
The 'Maximum bitrate' is used for enforcement of the maximum bit rate that the SDF may consume, while the 'Guaranteed bitrate' is used by the PCEF to determine resource allocation.
The UL sharing indication indicates that resource sharing in uplink direction for service data flows with the same value in their PCC rule shall be applied by the PCEF as described in clauses 6.1.14 and 6.2.2.4.
The DL sharing indication indicates that resource sharing in downlink direction for service data flows with the same value in their PCC rule shall be applied by the PCEF as described in clauses 6.1.14 and 6.2.2.4.
The Redirect indicates whether the uplink part of the service data flow should be redirected to a controlled address.
The Redirect Destination indicates the target redirect address when Redirect is enabled.
The Allocation and Retention Priority indicates the allocation, retention and priority of the service data flow. The ARP contains information about the priority level, the pre-emption capability and the pre-emption vulnerability. The Allocation and Retention Priority resolves conflicts of demands for network resources.
The Bind to Default Bearer indicates that the dynamic PCC rule shall be bound to the default bearer.
The PS to CS session continuity is present if the service data flow is a candidate for vSRVCC according to TS 23.216.
The access network information reporting parameters (User Location Report, UE Timezone Report) instruct the PCEF about what information to forward to the PCRF when the PCC rule is activated, modified or removed.
The Monitoring Key is the reference to a resource threshold. Any number of PCC Rules may share the same monitoring key value. The monitoring key values for each service shall be operator configurable.
The Indication of exclusion from session level monitoring indicates that the service data flow shall be excluded from the IP-CAN session usage monitoring.
The Traffic Steering Policy Identifier(s) is a reference to a pre-configured traffic steering policy at the PCEF as defined in clause 6.11.1.
The Allowed Access Type applies only in case of NBIFOM. The Allowed Access Type indicates the IP-CAN type that is to be used for the transfer of traffic identified by the PCC rule. The PCEF uses the Allowed Access Type as input for the bearer binding. When network-initiated NBIFOM mode applies, the PCEF shall also create / modify / delete a corresponding Routing Rule for such a PCC rule at the UE as described in clause 6.1.18.2. When the Allowed Access Type is not provided within a PCC rule, the traffic identified by the PCC rule is to be transferred on the default NBIFOM access.
The Routing Rule Identifier applies only in case of NBIFOM. The PCRF provides it to the PCEF only when network-initiated NBIFOM mode applies.
The UL Maximum Packet Loss Rate indicates the maximum rate for lost packets that can be tolerated in the uplink direction.
The DL Maximum Packet Loss Rate indicates the maximum rate for lost packets that can be tolerated in the downlink direction.
Up

6.3.2  Policy and charging control rule operationsp. 110

Policy and charging control rule operations consist of activation, modification and de-activation of PCC rules.
Activation of a dynamic PCC rule provides the PCC rule information to the PCEF via the Gx reference point.
Activation of a predefined PCC rule provides an identifier of the relevant PCC rule to the PCEF via the Gx reference point.
Activation of a predefined PCC rule, not known in the PCRF, may be done by the PCEF based on operator policy. The PCEF may only activate such predefined PCC rule if there are no UE provided traffic mapping information related to the IP-CAN bearer. Further restrictions regarding the usage of predefined PCC rules are described in clause 6.3.1.
An active PCC rule means that:
  • the service data flow template shall be used for service data flow detection;
  • the service data flow template shall be used for mapping of downlink packets to the IP-CAN bearer determined by the bearer binding;
  • the service data flow template shall be used for service data flow detection of uplink packets on the IP-CAN bearer determined by the bearer binding;
  • usage data for the service data flow shall be recorded (further details can be found in clause 6.1.2 Reporting and clause 6.1.3 Credit Management);
  • policies associated with the PCC rule, if any, shall be invoked.
  • for service data flow detection with an application detection filter, the start or the stop of the application traffic is reported to the PCRF, if applicable and requested by the PCRF. In that case, 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 filters.
A predefined PCC rule is known at least, within the scope of one access point.
A predefined PCC rule is bound to one and only one IP-CAN bearer per IP-CAN session. For a predefined PCC rule whose service data flow cannot be fully reflected for the uplink direction in terms of traffic mapping information sent to the UE, the PCEF may apply the uplink service data flow detection at additional IP-CAN bearers with non-GBR QCI of the same IP-CAN session. The deactivation of such a predefined PCC rule ceases its service data flow detection for the whole IP-CAN session.
The PCRF may, at any time, modify an active, dynamic PCC rule.
The PCRF may, at any time, deactivate an active PCC rule in the PCEF via the Gx reference point. At IP-CAN bearer termination all active PCC rules on that bearer are deactivated without explicit instructions from the PCRF to do so.
Policy and charging control rule operations can be also performed in a deferred mode. A PCC rule may have either a single deferred activation time, or a single deferred deactivation time or both.
A PCC rule with only a deferred activation time shall be inactive until that time. A PCC 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 PCC 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 PCC rule, including setting, modifying or clearing its deferred activation and/or deactivation time. When modifying a dynamic PCC 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.
Deferred activation and deactivation of PCC rules can only be used for PCC rules that belong to the IP-CAN bearer without traffic mapping information.
Deferred modification of PCC rules shall not be applied for changes of the QoS or service data flow filter information of PCC rules.
Up

Up   Top   ToC