6.1 Overall description

23.2033GPPPolicy and charging control architectureRelease 17TS

6.1.0 General

The PCC architecture works on a service data flow level. The PCC architecture provides the functions for policy and charging control as well as event reporting for service data flows.

6.1.1 Binding mechanism

6.1.1.1 General

The binding mechanism is the procedure that associates a service data flow (defined in a PCC and QoS rule, if applicable, by means of the SDF template), to the IP‑CAN bearer deemed to transport the service data flow. For service data flows belonging to AF sessions, the binding mechanism shall also associate the AF session information with the IP‑CAN bearer that is selected to carry the service data flow.

NOTE 1: The relation between AF sessions and rules depends only on the operator configuration. An AF session can be covered by one or more PCC and QoS rules, if applicable (e.g. one rule per media component of an IMS session). Alternatively, a rule could comprise multiple AF sessions.

NOTE 2: The PCRF may authorize dynamic PCC rules for service data flows without a corresponding AF session. Such PCC rules may be statically configured at the PCRF or dynamically filled with the UE provided traffic mapping information.

NOTE 3: For PCC rules with application identifier, and for certain IP-CAN types, up-link traffic may be received on other/additional IP-CAN bearers than the one determined by the binding mechanism (further details provided in clause 6.2.2.2 and the IP-CAN specific annexes).

The binding mechanism creates bindings. The algorithm, employed by the binding mechanism, may contain elements specific for the kind of IP‑CAN.

The binding mechanism includes three steps:

1. Session binding.

2 PCC rule authorization and QoS rule generation, if applicable.

3. Bearer binding.

6.1.1.2 Session binding

Session binding is the association of the AF session information to one and only one IP‑CAN session.

The PCRF shall perform the session binding, which shall take the following IP‑CAN parameters into account:

a) The UE IPv4 address and/or IPv6 network prefix;

b) The UE identity (of the same kind), if present.

NOTE 1: In case the UE identity in the IP‑CAN and the application level identity for the user are of different kinds, the PCRF needs to maintain, or have access to, the mapping between the identities. Such mapping is not subject to specification within this TS.

c) The information about the packet data network (PDN) the user is accessing, if present.

For an IP-CAN session to the dedicated APN for UE-to-Network Relay connectivity (as defined in TS 23.303 [44]) and using IPv6 prefix delegation (i.e. the assigned IPv6 network prefix is shorter than 64) the PCRF shall perform session binding based on the IPv6 network prefix only. A successful session binding occurs whenever a longer prefix received from an AF matches the prefix value of the IP-CAN session. PCRF shall not use the UE identity for session binding for this IP-CAN session.

NOTE 2: For UE-to-Network Relay connectivity, the UE identity that the PCEF has provided (i.e. UE-to-Network Relay UE Identity) and a UE identity provided by the AF (i.e. Remote UE Identity) can be different, while the binding with the IP-CAN session is valid.

NOTE 3: In this Release of the specification the support for policy control of Remote UEs behind a ProSe UE-Network Relay using IPv4 is not available.

The PCRF shall identify the PCC rules affected by the AF session information, including new rules to be installed and existing rules to be modified or removed.

6.1.1.3 PCC rule authorization and QoS rule generation

PCC Rule authorization is the selection of the QoS parameters (QCI, ARP, GBR, MBR, etc.) for the PCC rules.

The PCRF shall perform the PCC rule authorization for complete dynamic PCC rules belonging to AF sessions that have been selected in step 1, as described in clause 6.1.1.2, as well as for PCC rules without corresponding AF sessions. Based on AF instructions (as described in clause 6.1.5) dynamic PCC rules can be authorized even if they are not complete (e.g. due to missing service information regarding QoS or traffic filter parameters).

The PCC rule authorization depends on the IP‑CAN bearer establishment mode of the IP‑CAN session and the mode (UE or NW) of the PCC rule:

– In UE/NW bearer establishment mode, the PCRF shall perform the authorization for all PCC rules that are to be handled in NW mode.

– In UE/NW bearer establishment mode, for PCC rules that are to be handled in UE mode or when in UE-only bearer establishment mode, the PCRF shall first identify the PCC rules that correspond to a UE resource request and authorize only these.

The PCRF shall compare the traffic mapping information of the UE resource request with the service data flow filter information of the services that are allowed for the user. Each part of the traffic mapping information shall be evaluated separately in the order of their related precedence. Any matching service data flow filter leads to an authorization of the corresponding PCC rule for the UE resource request unless the PCC rule is already authorized for a more specific traffic mapping information or the PCC rule cannot be authorized for the QCI that is related to the UE resource request (the details are described in the next paragraph). Since a PCC rule can contain multiple service data flow filters it shall be ensured by the PCRF that a service data flow is only authorized for a single UE resource request.

NOTE 1: For example, a PCC rule containing multiple service data flow filters that match traffic mapping information of different UE resource requests could be segmented by the PCRF according to the different matching traffic mapping information. Afterwards, the PCRF can authorize the different PCC rules individually.

The PCRF knows whether a PCC rule can be authorized for a single QCI only or a set of QCIs (based on SPR information or local configuration). If the processing of the traffic mapping information would lead to an authorization of a PCC rule, the PCRF shall also check whether the PCC rule can be authorized for the QCI that is related to the UE resource request containing the traffic mapping information. If the PCC rule cannot be authorized for this QCI, the PCRF shall reject the traffic mapping information unless otherwise stated in an access-specific Annex.

If there is any traffic mapping information not matching to any service data flow filter known to the PCRF and the UE is allowed to request for enhanced QoS for traffic not belonging to operator-controlled services, the PCRF shall authorize this traffic mapping information by adding the respective service data flow filter to a new or existing PCC. If the PCRF received an SDF filter identifier together with this traffic mapping information, the PCRF shall modify the existing PCC rule if the PCC rule is authorized for a GBR QCI.

NOTE 2: If the PCC rule is authorized for a non-GBR QCI, the PCRF may either create a new PCC rule or modify the existing PCC rule.

The PCC rule that needs to be modified can be identified by the service data flow filter the SDF filter identifier refers to. The requested QoS shall be checked against the subscription limitations for traffic not belonging to operator-controlled services.

If the PCRF needs to perform the authorization based on incomplete service information and thus cannot associate a PCC rule with a single IP‑CAN bearer, then the PCRF shall generate for the affected service data flow an individual PCC rule per IP‑CAN bearer that could carry that service data flow. Once the PCRF receives the complete service information, the PCC rule on the IP‑CAN bearer with the matching traffic mapping information shall be updated according to the service information. Any other PCC rule(s) previously generated for the same service data flow shall be removed by the PCRF.

NOTE 3: This is required to enable the successful activation or modification of IP‑CAN bearers before knowing the intended use of the IP‑CAN bearers to carry the service data flow(s).

For an IP‑CAN, where the PCRF gains no information about the uplink IP flows (i.e. the UE provided traffic mapping information contains no information about the uplink IP flows), the binding mechanism shall assume that, for bi-directional service data flows, both downlink and uplink packets travel on the same IP‑CAN bearer.

Whenever the service data flow template or the UE provided traffic mapping information change, the existing authorizations shall be re-evaluated, i.e. the authorization procedure specified in this clause, is performed. The re-evaluation may, for a service data flow, require a new authorization for a different UE provided mapping information.

Based on PCRF configuration or AF instructions (as described in clause 6.1.5) dynamic PCC rules may have to be first authorized for the default QCI/default bearer (i.e. bearer without UE provided traffic mapping information) until a corresponding UE resource request occurs.

NOTE 4: This is required to enable services that start before dedicated resources are allocated.

A PCC rule for a service data flow that is a candidate for vSRVCC according to TS 23.216 [28] shall have the PS to CS session continuity indicator set.

For the authorization of a PCC rule the PCRF shall take into account the IP‑CAN specific restrictions and other information available to the PCRF. Each PCC rule receives a set of QoS parameters that can be supported by the IP‑CAN. The authorization of a PCC rule associated with an emergency service and Restricted Local Operator Services shall be supported without subscription information (e.g. information stored in the SPR). The PCRF shall apply policies configured for the emergency service and Restricted Local Operator Services.

When both a Gx and associated Gxx interface(s) exist for an IP‑CAN session, the PCRF shall generate QoS rules for all the authorized PCC rules in this step. The PCRF shall ensure consistency between the QoS rules and PCC rules authorized for the same service data flow when QoS rules are derived from corresponding PCC rules.

When flow mobility applies for the IP-CAN Session, one IP‑CAN session may be associated to multiple Gateway Control Sessions with separate BBRFs. In this case, the PCRF shall provision QoS rules only to the appropriate BBERF based on IP flow mobility routing rules received from the PCEF.

6.1.1.4 Bearer Binding

Bearer binding is the association of the PCC rule and the QoS rule (if applicable) to an IP‑CAN bearer within that IP‑CAN session. This function resides in the Bearer Binding Function (BBF).

The Bearer Binding Function is located either at the BBERF or at the PCEF, depending on the architecture (see clause 5.1). The BBF is located at the PCEF if GTP is used as the mobility protocol towards the PCEF; otherwise, the BBF is located at the BBERF.

The Bearer Binding Function may also be located in the PCRF as specified in Annex A and Annex D (e.g. for GPRS running UE only IP‑CAN bearer establishment mode).

NOTE 1: For an IP‑CAN, limited to a single IP‑CAN bearer per IP‑CAN session, the bearer is implicit, so finding the IP‑CAN session is sufficient for successful binding.

For an IP‑CAN which allows for multiple IP‑CAN bearers for each IP‑CAN session, the binding mechanism shall use the QoS parameters of the existing IP‑CAN bearers to create the bearer binding for a rule, in addition to the PCC rule and the QoS rule (if applicable) authorized in the previous step.

The set of QoS parameters assigned in step 2, as described in clause 6.1.1.3, to the service data flow is the main input for bearer binding. The BBF should not use the same bearer for rules with different settings for the PS to CS session continuity indicator.

NOTE 2: When NBIFOM applies for the IP-CAN session, additional information has to be taken into account as described in clause 6.1.18.1.

The BBF shall evaluate whether it is possible to use one of the existing IP‑CAN bearers or not and whether initiate IP‑CAN bearer modification if applicable. If none of the existing bearers are possible to use, the BBF should initiate the establishment of a suitable IP‑CAN bearer. The binding is created between service data flow(s) and the IP‑CAN bearer which have the same QoS class identifier and ARP.

NOTE 3: The handling of a rule with MBR>GBR is up to operator policy (e.g. an independent IP‑CAN bearer may be maintained for that SDF to prevent unfairness between competing SDFs).

Requirements, specific for each type of IP‑CAN, are defined in the IP‑CAN specific Annex.

Whenever the QoS authorization of a PCC/QoS rule changes, the existing bindings shall be re-evaluated, i.e. the bearer binding procedures specified in this clause, is performed. The re-evaluation may, for a service data flow, require a new binding with another IP‑CAN bearer. The BBF should, if the PCRF requests the same change to the ARP/QCI value for all PCC/QoS Rules with the bearer binding to the same bearer, modify the bearer ARP/QCI value as requested.

NOTE 4: A QoS change of the default EPS bearer causes the bearer binding for PCC/QoS rules previously bound to the default EPS bearer to be re-evaluated. At the end of the re-evaluation of the PCC/QoS rules of the IP-CAN session, there needs to be at least one PCC rule that successfully binds with the default bearer.

6.1.2 Reporting

Reporting refers to the differentiated IP‑CAN resource usage information (measured at the PCEF/TDF) being reported to the online or offline charging functions.

NOTE 1: Reporting usage information to the online charging function is distinct from credit management. Hence multiple PCC/ADC rules may share the same charging key for which one credit is assigned whereas reporting may be at higher granularity if serviced identifier level reporting is used.

The PCEF/TDF shall report usage information for online and offline charging.

The PCEF/TDF shall report usage information for each charging key value.

For service data flow charging, for the case of sponsored data connectivity, the reports for offline charging shall report usage for each charging key, Sponsor Identity and Application Service Provider Identity combination if Sponsor Identity and Application Service Provider Identifier have been provided in the PCC rules.

NOTE 2: Usage reports for online charging that include Sponsor Identity and Application Service Provider Identity is not within scope of the specification in this release. Online charging for sponsored data connectivity can be based on charging key as described in Annex N.

The PCEF shall report usage information for each charging key/service identifier combination if service identifier level reporting is requested in the PCC/ADC rule.

NOTE 3: For reporting purposes when charging is performed by the PCEF:

a) the charging key value identifies a service data flow if the charging key value is unique for that particular service data flow, and

b) if the service identifier level reporting is present then the service identifier value of the PCC rule together with the charging key identify the service data flow.

The TDF shall report usage information for each charging key/service identifier combination if service identifier level reporting is requested in the ADC rule.

NOTE 4: For reporting purposes in case charging is performed by the TDF a) the charging key value identifies an application if the charging key value is unique for that application identified by ADC Rule and b) if the service identifier level reporting is present then the service identifier value of the ADC rule together with the charging key identify the application

NOTE 5: If operator applies this solution with both PCEF and TDF performing enforcement and charging for a single IP-CAN session, the PCRF is recommended to use a different charging keys provided to the PCEF and to the TDF.

For the case where the BBF locates in the PCEF, charging information shall be reported based on the result from the service data flow detection and measurement on a per IP‑CAN bearer basis.

For the case where the BBF is not located in the PCEF, charging information shall be reported based on the result from the service data flow detection and measurement, separately per QCI and ARP combination (used by any of the active PCC rules). In case 2a defined in clause 7.1, charging ID is provided to the BBERF via the PCRF if charging correlation is needed.

A report may contain multiple containers, each container associated with a charging key, charging key and Sponsor Identity (in case of sponsored connectivity) or charging key/service identifier.

6.1.3 Credit management

The credit management applies for online charging only and shall operate on a per charging key basis. The PCEF should initiate one credit management session with the OCS for each IP‑CAN Session subject to online charging, unless specified otherwise in an IP‑CAN specific annex. Alternatively, the PCEF may initiate one credit management session for each IP‑CAN bearer as defined in the applicable annex. The TDF should initiate one credit management session with the OCS for each TDF Session subject to online charging.

NOTE 1: Independent credit control for an individual service/application may be achieved by assigning a unique charging key value in the corresponding PCC/ADC rule.

The PCEF/TDF shall request a credit for each charging key occurring in a PCC/ADC rule. It shall be up to operator configuration whether the PCEF/TDF shall request credit in conjunction with the PCC/ADC rule being activated or when the first packet corresponding to the service/the application is detected. The OCS may either grant or deny the request for credit. The OCS shall strictly control the rating decisions.

NOTE 2: The term ‘credit’ as used here does not imply actual monetary credit, but an abstract measure of resources available to the user. The relationship between this abstract measure, actual money, and actual network resources or data transfer, is controlled by the OCS.

During IP‑CAN session establishment and modification, the PCEF shall request credit using the information after applying policy enforcement action (e.g. upgraded or downgraded QoS information), if applicable, even though the PCEF has not signalled it yet in the IP‑CAN.

It shall be possible for the OCS to form a credit pool for multiple (one or more) charging keys, applied at the PCEF/TDF, e.g. with the objective of avoiding credit fragmentation. Multiple pools of credit shall be allowed per IP‑CAN bearer/TDF session. The OCS shall control the credit pooling decisions. The OCS shall, when credit authorization is sought, either grant a new pool of credit, together with a new credit limit, or give a reference to a pool of credit that is already granted for that IP‑CAN bearer/TDF session. The grouping of charging keys into pools shall not restrict the ability of the OCS to do credit authorisation and provide termination action individually for each charging key of the pool. It shall be possible for the OCS to group service data flows/applications charged at different rates or in different units (e.g. time/volume/event) into the same pool.

For each charging key, the PCEF/TDF may receive credit re-authorisation trigger information from the OCS, which shall cause the PCEF/TDF to perform a credit re-authorisation when the event occurs. If there are events which can not be monitored in the PCEF/TDF, the PCEF/TDF shall provide the information about the required event triggers to the PCRF. If information about required event triggers is provided to the PCRF, it is an implementation option whether a successful confirmation is required from the PCRF in order for the PCEF/TDF to consider the credit (re-)authorization procedure to be successful. The credit re-authorisation trigger detection shall cause the PCEF/TDF to request re-authorisation of the credit in the OCS. It shall be possible for the OCS to instruct the PCEF/TDF to seek re-authorisation of credit in case of the events listed in table 6.1.

Table 6.1: Credit re-authorization triggers

Credit re-authorization trigger	Description	Applicable for
Credit authorisation lifetime expiry	The OCS has limited the validity of the credit to expire at a certain time.	PCEF, TDF
Idle timeout	The service data flow identified by a PCC Rules or the application identified by an ADC Rule has been empty for a certain time.	PCEF, TDF
PLMN change	The UE has moved to another operators’ domain.	PCEF, TDF
QoS changes	The QoS of the IP‑CAN bearer has changed.	PCEF
Change in type of IP‑CAN	The type of the IP‑CAN has changed.	PCEF, TDF
Location change (serving cell)	The serving cell of the UE has changed.	PCEF, TDF
Location change (serving area) (see note 2)	The serving area of the UE has changed.	PCEF, TDF
Location change (serving CN node) (see note 3)	The serving core network node of the UE has changed.	PCEF, TDF
Change of UE presence in Presence Reporting Area (see note 4)	The UE has entered or left a Presence Reporting Area	PCEF, TDF
NOTE 1: This list is not exhaustive. Events specific for each IP‑CAN are specified in Annex A, and the protocol description may support additional events. NOTE 2: A change in the serving area may also result in a change in the serving cell, and possibly a change in the serving CN node. NOTE 3: A change in the serving CN node may also result in a change in the serving cell, and possibly a change in the serving area. NOTE 4: The Presence Reporting Area(s) is provided by the OCS to the PCEF/TDF. The maximum number of PRA(s) per UE per PDN connection is configured in the OCS. The OCS may have independent configuration of the maximum number for Core Network pre-configured PRAs and UE-dedicated PRAs. The exact number(s) should be determined by operator in deployment.

If the Location change trigger is armed, the PCEF shall activate the relevant IP‑CAN specific procedure which reports any changes in location to the level indicated by the trigger. If credit-authorization triggers and event triggers require different levels of reporting of location change for a single UE, the location to be reported should be changed to the highest level of detail required. However, there should be no request being triggered for credit re-authorization to the OCS if the report received is more detailed than requested by the OCS.

NOTE 1: The access network may be configured to report location changes only when transmission resources are established in the radio access network.

The OCS determines at credit management session establishment/modification, based on local configuration, if the UE is located in an access type that supports reporting changes of UE presence in Presence Reporting Area. If the access type supports it, the OCS may subscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the credit management session.

NOTE 2: If Presence Reporting Area reporting is not supported, the OCS may instead activate Location change reporting at cell and/or serving area level but due to the potential increase in signalling load, it is recommended that such reporting is only applied for a limited number of subscribers.

When activating reporting for change of UE presence in Presence Reporting Area, the OCS provides all of the PRA Identifier(s) to be activated for Core Network pre-configured Presence Reporting Area(s) and additionally all of PRA Identifier(s) and the list(s) of its elements for UE- dedicated Presence Reporting Area(s). (See Table 6.4 in clause 6.4 for details of the PRA Identifier(s) and the list(s) of elements comprising each Presence Reporting Area). If OCS is configured with a PRA identifier referring to the list of PRA Identifier(s) within a Set of Core Network predefined Presence Reporting Areas as defined in TS 23.401 [17], it activates the reporting of UE entering/leaving the individual PRA in the Set of Core Network predefined Presence Reporting Areas without providing the complete set of individual PRAs.

The OCS may change (activate/modify/remove) the Presence Reporting Area(s) to be reported by providing the updated PRA Identifier(s) to PCEF. For UE dedicated PRAs, the OCS may also change the list(s) of Presence Reporting Area elements related to the PRA Identifier(s).

The OCS may unsubscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the credit management session.

The OCS may be notified during the life time of a credit management session that the UE is located in an access type where local OCS configuration indicates that reporting changes of UE presence in Presence Reporting Area is not supported. If so, the OCS unsubscribes to Change of UE presence in Presence Reporting Area, if previously activated.

Some of the re-authorization triggers are related to IP‑CAN bearer modifications. IP‑CAN bearer modifications, which do not match any credit re-authorization trigger (received from the OCS for the bearer) shall not cause any credit re-authorization interaction with the OCS.

If the PCRF set the Out of credit event trigger (see clause 6.1.4), the PCEF/TDF shall inform the PCRF about the PCC/ADC rules for which credit is no longer available together with the applied termination action.

6.1.4 Event Triggers

The Event Reporting Function (ERF) performs event trigger detection. When an event matching the event trigger occurs, the ERF shall report the occurred event to the PCRF. The Event Reporting Function is located either at the PCEF or, at the BBERF (if applicable) or, at the TDF for solicited application reporting (if applicable).

The event triggers define the conditions when the ERF shall interact again with PCRF after an IP‑CAN session establishment. The event triggers that are required in procedures shall be unconditionally reported from the ERF, while the PCRF may subscribe to the remaining events. Whether an event trigger requires a subscription by the PCRF is indicated in column 4 in table 6.2 below.

The PCRF subscribes to new event triggers or remove armed event triggers unsolicited at any time or upon receiving a request from the AF, an event report or rule request from the ERF (PCEF or BBERF or TDF) using the Provision of PCC Rules procedure or the Provision of QoS Rules procedure (if applicable) or the Provision of ADC Rules procedure (if applicable). If the provided event triggers are associated with certain parameter values then the ERF shall include those values in the response back to the PCRF. Event triggers are associated with all rules at the ERF of an IP‑CAN session (ERF is located at PCEF) or Gateway Control session (ERF is located at BBERF) or with Traffic Detection session (ERF is located in TDF). Event triggers determine when the ERF shall signal to the PCRF that an IP‑CAN bearer has been modified. It shall be possible for the ERF to react on the event triggers listed in table 6.2.

Table 6.2: Event triggers

Event trigger	Description	Reported from	Condition for reporting
PLMN change	The UE has moved to another operators’ domain.	PCEF	PCRF
QoS change	The QoS of the IP‑CAN bearer has changed (note 3).	PCEF, BBERF	PCRF
QoS change exceeding authorization	The QoS of the IP‑CAN bearer has changed and exceeds the authorized QoS (note 3).	PCEF	PCRF
Traffic mapping information change	The traffic mapping information of the IP‑CAN bearer has changed (note 3).	PCEF	Always set
Resource modification request	A request for resource modification has been received by the BBERF/PCEF (note 6).	PCEF, BBERF	Always set
Routing information change	The IP flow mobility routing information has changed (when IP flow mobility as specified in TS 23.261 [23] applies) or the PCEF has received Routing Rules from the UE (when NBIFOM as specified in TS 23.161 [43] applies) (note 11) (note 16).	PCEF	Always set (note 15)
Change in type of IP‑CAN (see note 1)	The access type of the IP‑CAN bearer has changed.	PCEF	PCRF
Loss/recovery of transmission resources	The IP‑CAN transmission resources are no longer usable/again usable.	PCEF, BBERF	PCRF
Location change (serving cell) (see note 10)	The serving cell of the UE has changed.	PCEF, BBERF	PCRF
Location change (serving area) (see notes 4 and 10)	The serving area of the UE has changed.	PCEF, BBERF	PCRF
Location change (serving CN node) (see notes 5 and 10)	The serving core network node of the UE has changed.	PCEF, BBERF	PCRF
Change of UE presence in Presence Reporting Area (see note 17)	The UE is entering/leaving a Presence Reporting Area	PCEF, BBERF	PCRF
Out of credit	Credit is no longer available.	PCEF, TDF	PCRF
Enforced PCC rule request	PCEF is performing a PCC rules request as instructed by the PCRF.	PCEF	PCRF
Enforced ADC rule request	TDF is performing an ADC rules request as instructed by the PCRF.	TDF	PCRF
UE IP address change (see note 9)	A UE IP address has been allocated/released	PCEF	Always set
Access Network Charging Correlation Information	Access Network Charging Correlation Information has been assigned.	PCEF	PCRF
Usage report (see note 7)	The IP-CAN session or the Monitoring key specific resources consumed by a UE either reached the threshold or needs to be reported for other reasons.	PCEF, TDF	PCRF
Start of application traffic detection and Stop of application traffic detection (see note 8)	The start or the stop of application traffic has been detected.	PCEF, TDF	PCRF
SRVCC CS to PS handover	A CS to PS handover has been detected	PCEF	PCRF
Access Network Information report	Access information as specified in the Access Network Information Reporting part of a PCC rule.	PCEF, BBERF	PCRF
Credit management session failure	Transient/Permanent Failure as specified by the OCS	PCEF, TDF	PCRF for PCEF, Always set for TDF
Addition / removal of an access to an IP-CAN session (note 11)	The PCEF reports when an access is added or removed	PCEF	Always set
Change of usability of an access (note 11)	The PCEF reports that an access becomes unusable or usable again (note 14)	PCEF	Always set
UE resumed from suspend state	The PCEF reports to the PCRF when it detects that the UE is resumed from suspend state.	PCEF	PCRF
NOTE 1: This list is not exhaustive. Events specific for each IP‑CAN are specified in clause A. NOTE 2: A change in the type of IP‑CAN may also result in a change in the PLMN. NOTE 3: Available only when the bearer binding mechanism is allocated to the PCRF. NOTE 4: A change in the serving area may also result in a change in the serving cell, and a change in the serving CN node. NOTE 5: A change in the serving CN node may also result in a change in the serving cell, and possibly a change in the serving area. NOTE 6: Available only when the IP‑CAN supports corresponding procedures for bearer independent resource requests. NOTE 7: Usage is defined as either volume or time of user plane traffic. NOTE 8: The start and stop of application traffic detection are separate event triggers, but received under the same subscription from the PCRF. For unsolicited application reporting, these event triggers are always set for the TDF. NOTE 9: If TDF for solicited application reporting is applicable, upon receiving this event report from PCEF, PCRF always updates the TDF. NOTE 10: Due to the potential increase in signalling load, it is recommended that such event trigger subscription is only applied for a limited number of subscribers. NOTE 11: Used when NBIFOM is supported by the IP-CAN session. Refer to clause 6.1.18 for the description of NBIFOM impacts to PCC. NBIFOM Routing Rules are defined in clause 6.12. NOTE 12: Void. NOTE 13: Void.. NOTE 14: Used in Network-initiated NBIFOM mode. The PCEF reports that an access becomes unusable or usable again are based on notifications received from the UE. This may correspond to the procedure "Access becomes Unusable and Usable" and to the procedure "IP flow mobility triggered by RAN Rule indication" defined in TS 23.161 [43]. NOTE 15: This event is always set when IFOM per TS 23.261 [23] applies or when NBIFOM per TS 23.161 [43] applies. In the latter case it applies in both Network-initiated NBIFOM mode and in UE-initiated NBIFOM mode. NOTE 16: In UE-initiated NBIFOM mode this event indicates that the UE has created, modified or deleted Routing Rules. In Network-initiated NBIFOM mode this event indicates that the UE requests the network to create, modify or delete Routing Rules. NOTE 17: The maximum number of PRA(s) per UE per PDN connection is configured in the PCRF. The PCRF may have independent configuration of the maximum number for Core Network pre-configured PRAs and UE-dedicated PRAs. The exact number(s) should be determined by operator in deployment.

If the Location change trigger is armed, the PCEF shall activate the relevant IP‑CAN specific procedure which reports any changes in location to the level indicated by the trigger. If credit-authorization triggers and event triggers require different levels of reporting of location change for a single UE, the location to be reported should be changed to the highest level of detail required. However, there should be no request being triggered for PCC rules or QoS rules (if applicable) update to the PCRF if the report received is more detailed than requested by the PCRF.

NOTE 1: The access network may be configured to report location changes only when transmission resources are established in the radio access network.

The PCRF determines at IP-CAN session establishment/modification, based on local configuration, if the UE is located in an access type that supports reporting changes of UE presence in Presence Reporting Area. If the access type supports it, the PCRF may subscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the IP-CAN session

NOTE 2: If Presence Reporting Area reporting is not supported, the PCRF may instead activate Location change reporting at cell and/or serving area level but due to the potential increase in signalling load, it is recommended that such reporting is only applied for a limited number of subscribers.

When activating reporting for change of UE presence in Presence Reporting Area, the PCRF provides all of the PRA Identifier(s) to be activated for Core Network pre-configured Presence Reporting Area(s) and additionally all of PRA Identifier(s) and list(s) of its elements for UE-dedicated Presence Reporting Area(s) (See Table 6.4 in clause 6.4 for details of the PRA Identifier(s) and the list(s) of elements comprising each Presence Reporting Area). Setting the Change of UE presence in Presence Reporting Area event trigger shall not preclude the PCRF from simultaneously setting another Location change event trigger. If PCRF is configured with a PRA identifier referring to the list of PRA Identifier(s) within a Set of Core Network predefined Presence Reporting Areas as defined in TS 23.401 [17], it activates the reporting of UE entering/leaving the individual PRA in the Set of Core Network predefined Presence Reporting Areas without providing the complete set of individual PRAs.

The PCRF may change (activate/modify/remove) the Presence Reporting Area(s) to be reported by providing the updated PRA Identifier(s) to PCEF. For UE dedicated PRAs, the PCRF may also change the list(s) of Presence Reporting Area elements related to the PRA Identifier(s).

The PCRF may unsubscribe to Change of UE presence in Presence Reporting Area at any time during the life time of the IP-CAN session.

The PCRF may be notified during the life time of an IP-CAN session that the UE is located in an access type where local PCRF configuration indicates that reporting changes of UE presence in Presence Reporting Area is not supported. The PCRF unsubscribes to Change of UE presence in Presence Reporting Area, if previously activated.

IP‑CAN bearer modifications, which do not match any event trigger, shall cause no interaction with the PCRF.

The QoS change event trigger shall trigger the PCRF interaction for all changes of the IP‑CAN bearer QoS. The QoS change exceeding authorization event trigger shall only trigger the PCRF interaction for those changes that exceed the QoS of the IP‑CAN bearer that has been authorized by the PCRF previously. The ERF shall check the QoS class identifier and the bandwidth.

The Resource modification request event trigger shall trigger the PCRF interaction for all resource modification requests not tied to a specific IP‑CAN bearer received by PCEF/BBERF. The resource modification request received by PCEF/BBERF may include request for guaranteed bit rate changes for a traffic aggregate and/or the association/disassociation of the traffic aggregate with a QCI and/or a modification of the traffic aggregate.

The routing information change event trigger shall trigger the PCRF interaction for any change in how the IP flow is routed. The routing information change received by the PCEF is specified in TS 23.261 [23] (i.e. IP flow mobility routing rules) or TS 23.161 [43] (i.e. Routing Rules).

The enforced PCC rule request event trigger shall trigger a PCEF interaction to request PCC rules from the PCRF for an established IP‑CAN session. This PCEF interaction shall take place within the Revalidation time limit set by the PCRF in the IP‑CAN session related policy information (clause 6.4).

The enforced ADC rule request event trigger shall trigger a TDF interaction to request ADC rules from the PCRF for an established TDF session for solicited application reporting. This TDF interaction shall take place within the ADC Revalidation time limit set by the PCRF in the TDF session related policy information (clause 6.4).

NOTE 3: The enforced PCC rule request and the enforced ADC rule request mechanisms can be used to avoid signalling overload situations e.g. due to time of day based PCC/ADC rule changes.

The UE IP address change event trigger applies to the PCEF only and shall trigger a PCEF interaction with the PCRF in case a UE IPv4 address is allocated or released during the lifetime of the IP‑CAN session.

The Access Network Charging Correlation Information event shall trigger the PCEF to report the assigned access network charging identifier for the PCC rules that are accompanied with a request for this event at activation.

To activate usage monitoring, the PCRF shall set the Usage report event trigger and provide applicable usage thresholds for the Monitoring key(s) that are subject to usage monitoring in the requested node (PCEF or TDF, solicited application reporting). The PCRF shall not remove the Usage report event trigger while usage monitoring is still active in the PCEF/TDF.

If the Usage report event trigger is set and the volume or the time thresholds, earlier provided by the PCRF, are reached, the PCEF or TDF (whichever received the event trigger) shall report this event to the PCRF. If both volume and time thresholds were provided and the thresholds, for one of the measurements, are reached, the PCEF or TDF shall report this event to the PCRF and the accumulated usage since last report shall be reported for both measurements.

The Start of application traffic detection and Stop of application traffic detection events shall trigger an interaction with PCRF once the requested application traffic is detected (i.e. Start of application traffic detection) or the end of the requested application traffic is detected (i.e. Stop of application traffic detection) unless it is requested within a specific PCC Rule or ADC Rule to mute such a notification for solicited application reporting or unconditionally in case of unsolicited application reporting. The application identifier and service data flow descriptions, if deducible, shall also be included in the report. An application instance identifier shall be included in the report both for Start and for Stop of application traffic detection when service data flow descriptions are deducible. This is done to unambiguously match the Start and the Stop events.

The SRVCC CS to PS handover event trigger shall trigger a PCEF interaction with the PCRF to inform that a CS to PS handover procedure has been detected. The PCRF shall ensure, as specified in TS 23.216 [28], to allow voice media over the default bearer during the course of the CS to PS SRVCC procedure.

At PCC rule activation, modification and deactivation the ERF shall send, as specified in the PCC/QoS rule, the User Location Report and/or UE Timezone Report to the PCRF.

NOTE 4: At PCC rule deactivation the User Location Report includes information on when the UE was last known to be in that location.

The PCRF shall send the User Location Report and/or UE Timezone Report to the AF upon receiving an Access Network Information report corresponding to the AF session from the ERF.

If the event trigger for Access Network Information reporting is set, the ERF shall check the need for access network information reporting after successful installation/modification or removal of a PCC/QoS rule or upon termination of the IP-CAN session/bearer. The ERF shall check the Access Network Information report parameters (User Location Report, UE Timezone Report) of the PCC/QoS rules and report the access network information received in the corresponding IP-CAN bearer establishment, modification or termination procedure to the PCRF. The ERF shall not report any subsequent access network information updates received from the IP‑CAN without any previous updates of related PCC/QoS rules unless the associated IP-CAN bearer or connection has been released.

If the ERF receives a request to install/modify or remove a PCC/QoS rule with Access Network Information report parameters (User Location Report, UE Timezone Report) set and there is no bearer signalling related to this PCC/QoS rule (i.e. pending IP-CAN bearer signalling initiated by the UE or bearer signalling initiated by the ERF), the ERF shall initiate a bearer signalling to retrieve the current access network information of the UE and forward it to the PCRF afterwards.

If the Access Network Information report parameter for the User Location Report is set and the user location (e.g. cell) is not available to the ERF, the ERF shall provide the serving PLMN identifier to the PCRF which shall forward it to the AF.

The Credit management session failure event trigger shall trigger a PCEF or TDF interaction with the PCRF to inform about a credit management session failure and to indicate the failure reason, and the affected PCC/ADC rules.

NOTE 5: As a result, the PCRF may decide about e.g. TDF session termination, IP-CAN session termination (via PCC rule removal), perform gating of services in the PCEF/TDF, switch to offline charging, rating group change, etc.

NOTE 6: For the PCEF the Credit management session failure event trigger applies to situations wherein the IP‑CAN session is not terminated by the PCEF due to the credit management session failure.

If the UE resumed from suspend state event trigger is set and the UE is resumed from suspend state in EPC, the PCEF shall report this event to the PCRF. The PCEF shall not report any subsequent UE resumed from suspend state updates received from the IP‑CAN to the PCRF. When receiving the event report that the UE is resumed, the PCRF may provision PCC Rules to the PCEF to trigger an IP-CAN Session modification procedure.

6.1.5 Policy Control

Policy control comprises functionalities for:

– Binding, i.e. the generation of an association between a service data flow and the IP‑CAN bearer transporting that service data flow;

– Gating control, i.e. the blocking or allowing of packets, belonging to a service data flow or specified by an application identifier, to pass through to the desired endpoint;

– Event reporting, i.e. the notification of and reaction to application events to trigger new behaviour in the user plane as well as the reporting of events related to the resources in the GW (PCEF);

– QoS control, i.e. the authorisation and enforcement of the maximum QoS that is authorised for a service data flow, an Application identified by application identifier or an IP‑CAN bearer;

– Redirection, i.e. the steering of packets, belonging to an application defined by the application identifier to the specified redirection address;

– IP‑CAN bearer establishment for IP‑CANs that support network initiated procedures for IP‑CAN bearer establishment.

In case of an aggregation of multiple service data flows (e.g. for GPRS a PDP context), the combination of the authorised QoS information of the individual service data flows is provided as the authorised QoS for this aggregate.

The enforcement of the authorized QoS of the IP‑CAN bearer may lead to a downgrading or upgrading of the requested bearer QoS by the GW (PCEF) as part of a UE-initiated IP‑CAN bearer establishment or modification. Alternatively, the enforcement of the authorised QoS may, depending on operator policy and network capabilities, lead to network initiated IP‑CAN bearer establishment or modification. If the PCRF provides authorized QoS for both, the IP‑CAN bearer and PCC rule(s), the enforcement of authorized QoS of the individual PCC rules shall take place first.

QoS authorization information may be dynamically provisioned by the PCRF or, if the conditions mentioned in clause 6.3.1 apply, it can be a predefined PCC rule in the PCEF. In case the PCRF provides PCC rules dynamically, authorised QoS information for the IP‑CAN bearer (combined QoS) may be provided. For a predefined PCC rules within the PCEF the authorized QoS information shall take affect when the PCC rule is activated. The PCEF shall combine the different sets of authorized QoS information, i.e. the information received from the PCRF and the information corresponding to the predefined PCC rules. The PCRF shall know the authorized QoS information of the predefined PCC rules and shall take this information into account when activating them. This ensures that the combined authorized QoS of a set of PCC rules that are activated by the PCRF is within the limitations given by the subscription and operator policies regardless of whether these PCC rules are dynamically provided, predefined or both.

For policy control, the AF interacts with the PCRF and the PCRF interacts with the PCEF as instructed by the AF. For certain events related to policy control, the AF shall be able to give instructions to the PCRF to act on its own, i.e. based on the service information currently available. The following events are subject to instructions from the AF:

– The authorization of the service based on incomplete service information;

NOTE 1: The QoS authorization based on incomplete service information is required for e.g. IMS session setup scenarios with available resources on originating side and a need for resource reservation on terminating side.

– The immediate authorization of the service;

– The gate control (i.e. whether there is a common gate handling per AF session or an individual gate handling per AF session component required);

– The forwarding of IP‑CAN bearer level information or events:

– Type of IP‑CAN (e.g. GPRS, etc.);

– Transmission resource status (established/released/lost);

– Access Network Charging Correlation Information;

– Credit denied.

NOTE 2: The credit denied information is only relevant for AFs not performing service charging.

To enable the binding functionality, the UE and the AF shall provide all available flow description information (e.g. source and destination IP address and port numbers and the protocol information). The UE shall use the traffic mapping information to indicate downlink and uplink IP flows.

If PCEF indicates that a PDN connection is carried over satellite access (of WB-E-UTRAN, NB-IoT or LTE-M RAT Types and specific values as defined in TS 23.401 [17]), the PCRF may take this information into account for the policy decision, e.g. together with any delay requirements provided by the AF.

6.1.6 Service (data flow) Prioritization and Conflict Handling

Service pre-emption priority enables the PCRF to resolve conflicts where the activation of all requested active PCC rules for services would result in a cumulative authorized QoS which exceeds the Subscribed Guaranteed bandwidth QoS.

For example, when supporting network controlled QoS, the PCRF may use the pre-emption priority of a service, the activation of which would cause the subscriber’s authorized QoS to be exceeded. If this pre-emption priority is greater than that of any one or more active PCC rules, the PCRF can determine whether the deactivation of any one or more such rules would allow the higher pre-emption priority PCC rule to be activated whilst ensuring the resulting cumulative QoS does not exceed a subscriber’s Subscribed Guaranteed Bandwidth QoS.

If such a determination can be made, the PCRF may resolve the conflict by deactivating those selected PCC rules with lower pre-emption priorities and accepting the higher priority service information from the AF. If such a determination cannot be made, the PCRF may reject the service information from the AF.

NOTE: Normative PCRF requirements for conflict handling are not defined. Alternative procedures may use a combination of pre-emption priority and AF provided priority indicator.

6.1.7 Standardized QoS characteristics

6.1.7.1 General

The service level (i.e., per SDF or per SDF aggregate) QoS parameters are QCI, ARP, GBR, and MBR.

Each Service Data Flow (SDF) is associated with one and only one QoS Class Identifier (QCI). For the same IP‑CAN session multiple SDFs with the same QCI and ARP can be treated as a single traffic aggregate which is referred to as an SDF aggregate. An SDF is a special case of an SDF aggregate. The QCI is scalar that is used as a reference to node specific parameters that control packet forwarding treatment (e.g. scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.) and that have been pre-configured by the operator owning the node (e.g. eNodeB). When required by operator policy, the eNodeB can be configured to also use the ARP priority level in addition to the QCI to control the packet forwarding treatment in the eNodeB for SDFs having high priority ARPs.

6.1.7.2 Standardized QCI characteristics

This clause specifies standardized characteristics associated with standardized QCI values. The characteristics describe the packet forwarding treatment that an SDF aggregate receives edge-to-edge between the UE and the PCEF (see figure 6.1.7‑1) in terms of the following performance characteristics:

1 Resource Type (GBR or Non-GBR);

2 Priority;

3 Packet Delay Budget;

4 Packet Error Loss Rate;

5 Maximum Data Burst Volume (for some GBR QCIs);

6 Data Rate Averaging Window (for some GBR QCIs).

Figure 6.1.7-1: Scope of the Standardized QCI characteristics for client/server (upper figure) and peer/peer (lower figure) communication

The standardized characteristics are not signalled on any interface. They should be understood as guidelines for the pre-configuration of node specific parameters for each QCI. The goal of standardizing a QCI with corresponding characteristics is to ensure that applications / services mapped to that QCI receive the same minimum level of QoS in multi-vendor network deployments and in case of roaming. A standardized QCI and corresponding characteristics is independent of the UE’s current access (3GPP or Non-3GPP).

The one-to-one mapping of standardized QCI values to standardized characteristics is captured in table 6.1.7-A and table 6.1.7-B. The main differences between the two parts are that, in contrast to Part A, Part B of Table 6.1.7 describes QCIs for which the Packet Error Loss Rate calculation includes those packets that are not delivered within the Packet Delay Budget; and, it provides additional information on the Data Rate Averaging Window as well as the Maximum Data Burst Volume that needs to be delivered within the Packet Delay Budget.

Table 6.1.7-A: Standardized QCI characteristics

QCI	Resource Type	Priority Level	Packet Delay Budget (NOTE 13)	Packet Error Loss Rate (NOTE 2)	Example Services
1 (NOTE 3)		2	100 ms (NOTE 1, NOTE 11)	10-2	Conversational Voice
2 (NOTE 3)	GBR	4	150 ms (NOTE 1, NOTE 11)	10-3	Conversational Video (Live Streaming)
3 (NOTE 3, NOTE 14)		3	50 ms (NOTE 1, NOTE 11)	10-3	Real Time Gaming, V2X messages Electricity distribution – medium voltage (e.g. clause 7.2.2 of TS 22.261 [51]) Process automation – monitoring (e.g. clause 7.2.2 of TS 22.261 [51])
4 (NOTE 3)		5	300 ms (NOTE 1, NOTE 11)	10-6	Non-Conversational Video (Buffered Streaming)
65 (NOTE 3, NOTE 9, NOTE 12)		0.7	75 ms (NOTE 7, NOTE 8)	10-2	Mission Critical user plane Push To Talk voice (e.g., MCPTT)
66 (NOTE 3, NOTE 12)		2	100 ms (NOTE 1, NOTE 10)	10-2	Non-Mission-Critical user plane Push To Talk voice
67 (NOTE 3, NOTE 12)		1.5	100 ms (NOTE 1, NOTE 10)	10-3	Mission Critical Video user plane
75 (NOTE 14)		2.5	50 ms (NOTE 1)	10-2	V2X messages
71		5.6	150ms (NOTE 1, NOTE 16)	10-6	"Live" Uplink Streaming (e.g. TS 26.238 [53])
72		5.6	300ms (NOTE 1, NOTE 16)	10-4	"Live" Uplink Streaming (e.g. TS 26.238 [53])
73		5.6	300ms (NOTE 1, NOTE 16)	10-8	"Live" Uplink Streaming (e.g. TS 26.238 [53])
74		5.6	500ms (NOTE 1, NOTE 16)	10-8	"Live" Uplink Streaming (e.g. TS 26.238 [53])
76		5.6	500ms (NOTE 1, NOTE 16)	10-4	"Live" Uplink Streaming (e.g. TS 26.238 [53])
5 (NOTE 3)		1	100 ms (NOTE 1, NOTE 10)	10-6	IMS Signalling
6 (NOTE 4)		6	300 ms (NOTE 1, NOTE 10)	10-6	Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.)
7 (NOTE 3)	Non-GBR	7	100 ms (NOTE 1, NOTE 10)	10-3	Voice, Video (Live Streaming) Interactive Gaming
8 (NOTE 5)		8	300 ms (NOTE 1)	10-6	Video (Buffered Streaming) TCP-based (e.g., www, e-mail, chat, ftp, p2p file
9 (NOTE 6)		9			sharing, progressive video, etc.)
10		9	1100 ms (NOTE 1, NOTE 17)	10-6	Video (Buffered Streaming) TCP-based (e.g. www, e-mail, chat, ftp, p2p file sharing, progressive video, etc.) and any service that can be used over satellite access with these characteristics
69 (NOTE 3, NOTE 9, NOTE 12)		0.5	60 ms (NOTE 7, NOTE 8)	10-6	Mission Critical delay sensitive signalling (e.g., MC-PTT signalling, MC Video signalling)
70 (NOTE 4, NOTE 12)		5.5	200 ms (NOTE 7, NOTE 10)	10-6	Mission Critical Data (e.g. example services are the same as QCI 6/8/9)
79 (NOTE 14)		6.5	50 ms (NOTE 1, NOTE 10)	10-2	V2X messages
80 (NOTE 3)		6.8	10 ms (NOTE 10, NOTE 15)	10-6	Low latency eMBB applications (TCP/UDP-based); Augmented Reality
NOTE 1: A delay of 20 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. This delay is the average between the case where the PCEF is located "close" to the radio base station (roughly 10 ms) and the case where the PCEF is located "far" from the radio base station, e.g. in case of roaming with home routed traffic (the one-way packet delay between Europe and the US west coast is roughly 50 ms). The average takes into account that roaming is a less typical scenario. It is expected that subtracting this average delay of 20 ms from a given PDB will lead to desired end-to-end performance in most typical cases. Also, note that the PDB defines an upper bound. Actual packet delays – in particular for GBR traffic – should typically be lower than the PDB specified for a QCI as long as the UE has sufficient radio channel quality. NOTE 2: The rate of non congestion related packet losses that may occur between a radio base station and a PCEF should be regarded to be negligible. A PELR value specified for a standardized QCI therefore applies completely to the radio interface between a UE and radio base station. NOTE 3: This QCI is typically associated with an operator controlled service, i.e., a service where the SDF aggregate’s uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. In case of E-UTRAN this is the point in time when a corresponding dedicated EPS bearer is established / modified. NOTE 4: If the network supports Multimedia Priority Services (MPS) then this QCI could be used for the prioritization of non real-time data (i.e. most typically TCP-based services/applications) of MPS subscribers. NOTE 5: This QCI could be used for a dedicated "premium bearer" (e.g. associated with premium content) for any subscriber / subscriber group. Also in this case, the SDF aggregate’s uplink / downlink packet filters are known at the point in time when the SDF aggregate is authorized. Alternatively, this QCI could be used for the default bearer of a UE/PDN for "premium subscribers". NOTE 6: This QCI is typically used for the default bearer of a UE/PDN for non privileged subscribers. Note that AMBR can be used as a "tool" to provide subscriber differentiation between subscriber groups connected to the same PDN with the same QCI on the default bearer. NOTE 7: For Mission Critical services, it may be assumed that the PCEF is located "close" to the radio base station (roughly 10 ms) and is not normally used in a long distance, home routed roaming situation. Hence delay of 10 ms for the delay between a PCEF and a radio base station should be subtracted from this PDB to derive the packet delay budget that applies to the radio interface. NOTE 8: In both RRC Idle and RRC Connected mode, the PDB requirement for these QCIs can be relaxed (but not to a value greater than 320 ms) for the first packet(s) in a downlink data or signalling burst in order to permit reasonable battery saving (DRX) techniques. NOTE 9: It is expected that QCI-65 and QCI-69 are used together to provide Mission Critical Push to Talk service (e.g., QCI-5 is not used for signalling for the bearer that utilizes QCI-65 as user plane bearer). It is expected that the amount of traffic per UE will be similar or less compared to the IMS signalling. NOTE 10: In both RRC Idle and RRC Connected mode, the PDB requirement for these QCIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques. NOTE 11: In RRC Idle mode, the PDB requirement for these QCIs can be relaxed for the first packet(s) in a downlink data or signalling burst in order to permit battery saving (DRX) techniques. NOTE 12: This QCI value can only be assigned upon request from the network side. The UE and any application running on the UE is not allowed to request this QCI value. NOTE 13: Packet delay budget is not applicable on NB-IoT or when Enhanced Coverage is used for WB-E-UTRAN (see TS 36.300 [19]). NOTE 14: This QCI could be used for transmission of V2X messages as defined in TS 23.285 [48]. NOTE 15: A delay of 2 ms for the delay between a PCEF and a radio base station should be subtracted from the given PDB to derive the packet delay budget that applies to the radio interface. NOTE 16: For "live" uplink streaming (see TS 26.238 [53]), guidelines for PDB values of the different QCIs correspond to the latency configurations defined in TR 26.939 [54]. In order to support higher latency reliable streaming services (above 500ms PDB), if different PDB and PELR combinations are needed these configurations will have to use non-standardised QCIs. NOTE 17: The worst case one way propagation delay for GEO satellite is expected to be ~270 ms, ~ 21 ms for LEO at 1200 km, and ~13 ms for LEO at 600 km. The UL scheduling delay that needs to be added is also typically a two way propagation delay e.g. ~540 ms for GEO, ~42 ms for LEO at 1200 km, and ~26 ms for LEO at 600 km. Based on that, the access network Packet delay budget is not applicable for QCIs that require access network PDB lower than the sum of these values when the specific types of satellite access are used (see TS 36.300 [19]). QCI-10 can accommodate the worst case PDB for GEO satellite type.

Table 6.1.7-B: Standardized QCI characteristics

QCI	Resource Type	Priority Level	Packet Delay Budget (NOTE B1)	Packet Error Loss Rate (NOTE B2)	Maximum Data Burst Volume (NOTE B1)	Data Rate Averaging Window	Example Services
82 (NOTE B6)	GBR	1.9	10 ms (NOTE B4)	10-4 (NOTE B3)	255 bytes	2000 ms	Discrete Automation (TS 22.278 [38], clause 8 bullet g, and TS 22.261 [51], table 7.2.2-1, "small packets")
83 (NOTE B6)		2.2	10 ms (NOTE B4)	10-4 (NOTE B3)	1354 bytes (NOTE B5)	2000 ms	Discrete Automation (TS 22.278 [38], clause 8 bullet g, and TS 22.261 [51], table 7.2.2-1, "big packets")
84 (NOTE B6)		2.4	30 ms (NOTE B7)	10-5 (NOTE B3)	1354 bytes (NOTE B5)	2000 ms	Intelligent Transport Systems (TS 22.278 [38], clause 8, bullet h, and TS 22.261 [51], table 7.2.2).
85 (NOTE B6)		2.1	5 ms (NOTE B8)	10-5 (NOTE B3)	255 bytes	2000 ms	Electricity Distribution- high voltage (TS 22.278 [38], clause 8, bullet i, and TS 22.261 [51], table 7.2.2 and Annex D, clause D.4.2).
NOTE B1: The PDB applies to bursts that are not greater than Maximum Data Burst Volume. NOTE B2: This Packet Error Loss Rate includes packets that are not successfully delivered over the access network plus those packets that comply with the Maximum Data Burst Volume and GBR requirements but which are not delivered within the Packet Delay Budget. NOTE B3: Data rates above the GBR, or, bursts larger than the Maximum Data Burst Volume, are treated as best effort, and, in order to serve other packets and meet the PELR, this can lead to them being discarded. NOTE B4: A delay of 1 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. NOTE B5: This Maximum Data Burst Volume value is set to 1354 bytes to avoid IP fragmentation on an IPv6 based, IPSec protected GTP tunnel to the eNB (the value is calculated as in Annex C of TS 23.060 [12] and further reduced by 4 bytes to allow for the usage of a GTP-U extension header). NOTE B6: This QCI is typically associated with a dedicated EPS bearer. NOTE B7: A delay of 5 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface. NOTE B8: A delay of 2 ms for the delay between a PCEF and a radio base station should be subtracted from a given PDB to derive the packet delay budget that applies to the radio interface.

The Resource Type determines if dedicated network resources related to a service or bearer level Guaranteed Bit Rate (GBR) value are permanently allocated (e.g. by an admission control function in a radio base station). GBR SDF aggregates are therefore typically authorized "on demand" which requires dynamic policy and charging control. A Non GBR SDF aggregate may be pre-authorized through static policy and charging control.

The Maximum Data Burst Volume, if defined for the QCI (see Table 6.1.7-B), is the amount of data which the RAN is expected to deliver within the part of the Packet Delay Budget allocated to the link between the UE and the radio base station as long as the data is within the GBR requirements. If more data is transmitted from the application, delivery within the Packet Delay Budget cannot be guaranteed for packets exceeding the Maximum Data Burst Volume or GBR requirements.

The Data Rate Averaging Window, if defined for the QCI (see Table 6.1.7-B), is the ‘sliding window’ duration over which the GBR and MBR for a GBR SDF aggregate shall be calculated (e.g. in the RAN, PDN-GW, and UE).

The Packet Delay Budget (PDB) defines an upper bound for the time that a packet may be delayed between the UE and the PCEF. For a certain QCI the value of the PDB is the same in uplink and downlink. The purpose of the PDB is to support the configuration of scheduling and link layer functions (e.g. the setting of scheduling priority weights and HARQ target operating points). Except for QCIs 82 and 83, the PDB shall be interpreted as a maximum delay with a confidence level of 98 percent. For services using QCI 82 or 83, a packet delayed by more than the PDB is included in the calculation of the PELR if the packet is within the Maximum Data Burst Volume and GBR requirements.

NOTE 1: The PDB denotes a "soft upper bound" in the sense that an "expired" packet, e.g. a link layer SDU that has exceeded the PDB, does not need to be discarded (e.g. by RLC in E-UTRAN). The discarding (dropping) of packets is expected to be controlled by a queue management function, e.g. based on pre-configured dropping thresholds.

The support for SRVCC requires QCI=1 only be used for IMS speech sessions in accordance to TS 23.216 [28].

NOTE 2: Triggering SRVCC will cause service interruption and/or inconsistent service experience when using QCI=1 for non-IMS services.

NOTE 3: Triggering SRVCC for WebRTC IMS session will cause service interruption and/or inconsistent service experience when using QCI=1. Operator policy (e.g. use of specific AF application identifier) can be used to avoid using QCI 1 for a voice service, e.g. WebRTC IMS session.

Services using a Non-GBR QCI should be prepared to experience congestion related packet drops, and, except for QCI 80, 98 percent of the packets that have not been dropped due to congestion should not experience a delay exceeding the QCI’s PDB. This may for example occur during traffic load peaks or when the UE becomes coverage limited. See Annex J for details. Packets that have not been dropped due to congestion may still be subject to non congestion related packet losses (see PELR below). Owing to its low latency objective, services using QCI 80 should anticipate that more than 2 percent of packets might exceed the PDB of QCI 80.

Except for services using QCI 82 or 83 services using a GBR QCI and sending at a rate smaller than or equal to GBR can in general assume that congestion related packet drops will not occur, and 98 percent of the packets shall not experience a delay exceeding the QCI’s PDB. Exceptions (e.g. transient link outages) can always occur in a radio access system which may then lead to congestion related packet drops even for services using a GBR QCI and sending at a rate smaller than or equal to GBR. Packets that have not been dropped due to congestion may still be subject to non congestion related packet losses (see PELR below). For services using QCI 82 or 83 a packet which is delayed by more than the PDB but is within the Maximum Data Burst Volume and GBR requirements, is counted as lost when calculating the PELR.

Every QCI (GBR and Non-GBR) is associated with a Priority level (see Table 6.1.7). The lowest Priority level value corresponds to the highest Priority. The Priority levels shall be used to differentiate between SDF aggregates of the same UE, and it shall also be used to differentiate between SDF aggregates from different UEs. Via its QCI an SDF aggregate is associated with a Priority level and a PDB. Scheduling between different SDF aggregates shall primarily be based on the PDB. If the target set by the PDB can no longer be met for one or more SDF aggregate(s) across all UEs that have sufficient radio channel quality then the QCI Priority level shall be used as follows: in this case a scheduler shall meet the PDB of an SDF aggregate on QCI Priority level N in preference to meeting the PDB of SDF aggregates on next QCI Priority level greater than N, until the priority N SDF aggregate’s GBR (in case of a GBR SDF aggregate) has been satisfied.

Other aspects related to the treatment of traffic exceeding an SDF aggregate’s GBR are out of scope of this specification.

When required by operator policy, the eNodeB can be configured to use the ARP priority level in addition to the QCI priority level to determine the relative priority of the SDFs in meeting the PDB of an SDF aggregate. This configuration applies only for high priority ARPs as defined in clause 6.1.7.3.

NOTE 4: The definition (or quantification) of "sufficient radio channel quality" is out of the scope of 3GPP specifications.

NOTE 5: In case of E-UTRAN a QCI’s Priority level, and when required by operator policy, the ARP priority level may be used as the basis for assigning the uplink priority per Radio Bearer (see TS 36.300 [19] for details).

The Packet Error Loss Rate (PELR) defines an upper bound for the rate of SDUs (e.g. IP packets) that have been processed by the sender of a link layer protocol (e.g. RLC in E‑UTRAN) but that are not successfully delivered by the corresponding receiver to the upper layer (e.g. PDCP in E‑UTRAN). Thus, the PELR defines an upper bound for a rate of non congestion related packet losses. The purpose of the PELR is to allow for appropriate link layer protocol configurations (e.g. RLC and HARQ in E‑UTRAN). For a certain QCI the value of the PELR is the same in uplink and downlink.

NOTE 6: The characteristics PDB and PELR are specified only based on application / service level requirements, i.e., those characteristics should be regarded as being access agnostic, independent from the roaming scenario (roaming or non-roaming), and independent from operator policies.

6.1.7.3 Allocation and Retention Priority characteristics

The QoS parameter ARP contains information about the priority level, the pre-emption capability and the pre-emption vulnerability. The priority level defines the relative importance of a resource request. This allows deciding whether a bearer establishment or modification request can be accepted or needs to be rejected in case of resource limitations (typically used for admission control of GBR traffic). It can also be used to decide which existing bearers to pre-empt during resource limitations.

NOTE 1: The ARP priority level can be used in addition to the QCI to determine the transport level packet marking, e.g. to set the DiffServ Code Point of the associated EPS bearer, as described in TS 23.401 [17].

NOTE 2: When required by operator policy, the eNodeB can be configured to use the ARP priority level in addition to QCI priority level to control the packet forwarding treatment for SDFs having high priority ARPs.

The range of the ARP priority level is 1 to 15 with 1 as the highest level of priority. The pre-emption capability information defines whether a service data flow can get resources that were already assigned to another service data flow with a lower priority level. The pre-emption vulnerability information defines whether a service data flow can lose the resources assigned to it in order to admit a service data flow with higher priority level. The pre-emption capability and the pre-emption vulnerability can be either set to ‘yes’ or ‘no’.

The ARP priority levels 1-8 should only be assigned to resources for services that are authorized to receive prioritized treatment within an operator domain (i.e. that are authorized by the serving network). The ARP priority levels 9-15 may be assigned to resources that are authorized by the home network and thus applicable when a UE is roaming.

NOTE 3: This ensures that future releases may use ARP priority level 1-8 to indicate e.g. emergency and other priority services within an operator domain in a backward compatible manner. This does not prevent the use of ARP priority level 1-8 in roaming situation in case appropriate roaming agreements exist that ensure a compatible use of these priority levels.

6.1.8 Termination Action

The termination action applies only in case of online charging. The termination action indicates the action, which the PCEF/TDF should perform when no more credit is granted. A packet that matches a PCC rule/ADC rule, indicating a charging key for which no credit has been granted, is subject to a termination action.

The defined termination actions include:

– Allowing the packets to pass through;

– Dropping the packets;

– The PCEF/TDF Default Termination Action;

– The re-direction of packets to an application server (e.g. defined in the termination action).

NOTE: Such a re-direction may cause an application protocol specific asynchronous close event and application protocol specific procedures may be required in the UE and/or AF in order to recover, e.g. as specified in RFC 2616 for HTTP.

The Default Termination Action for all charging keys, for which no more credit is granted and there is no specific termination action shall be pre-configured in the PCEF/TDF according to operator’s policy. For instance, the default behaviour may consist of allowing packets of any terminated service to pass through the PCEF/TDF.

The OCS may provide a termination action for each charging key over the Gy interface. Any previously provided termination action may be overwritten by the OCS. A termination action remains valid and shall be applied by the PCEF/TDF until all the corresponding PCC/ADC rules of that charging key are removed or the corresponding IP‑CAN bearer is removed (for GPRS the PDP context).

The OCS shall provide the termination action to the PCEF/TDF before denying credit; otherwise the PCEF/TDF default termination action will be performed.

6.1.9 Handling of packet filters provided to the UE by PCEF/BBERF

The network shall ensure that the traffic mapping information negotiated with the UE reflects the bearer binding of PCC/QoS rules, except for those extending the inspection beyond what can be signalled to the UE. The PCC/QoS rules may restrict what traffic is allowed compared to what is explicitly negotiated with the UE. The PCRF may, per service data flow filter, indicate that the PCEF/BBERF is required to explicitly signal the corresponding traffic mapping information to the UE, e.g. for the purpose of IMS precondition handling at the UE. In absence of that indication, it is a PCEF/BBERF decision whether to signal the traffic mapping information that is redundant from a traffic mapping point of view.

NOTE 1: A new/modified PCC/QoS rule can cause that previously redundant, and therefore omitted, traffic mapping information to cease being redundant and causing the PCEF/BBERF to signal the corresponding traffic mapping information to the UE.

NOTE 2: In order to signal a specific traffic mapping to a PDP context/EPS bearer without any previous TFT, if the operator policy is to continue allowing previously allowed traffic on that bearer, TFT filters that correspond to the previous traffic mapping need to be introduced as well.

NOTE 3: The PCEF/BERF can use all SDF filters for the generation of traffic mapping information. However if the number of SDF filters for an IP-CAN bearer exceeds the maximum number of filters that may be signalled to the UE (e.g. as specified in TS 24.008 [50]) another bearer needs to be established and a rebinding of PCC rules to bearers (by PCEF/BBERF) or even the splitting of the SDF template into two or more PCC rules (by PCRF) may be required.

The traffic mapping information (e.g. TFT filters for GPRS and EPS) that the network provides to the UE shall include the same content as the corresponding SDF filters in the SDF template received over the Gx/Gxx interface. The representation/format of the packet filters provided by the network to the UE is access-system dependent and may vary between accesses and may also be different from the representation/format of the SDF filters in the SDF template on the Gx/Gxx interface.

NOTE 4: After handover from one access-system to another, if the UE needs to determine the QoS provided in the target access to the pre-existing IP flows in the source access, the UE can perform packet filter comparison between the packet filters negotiated in the old access and those provided by the target access during QoS resource activation.

NOTE 5: If UE initiated procedures are supported and handover between access systems is to be supported, the content of the packet filters provided on the Gx/Gxx interface by the PCRF is restricted to the packet filter fields that all the accesses can provide to the UE.

In case traffic mapping information is required for a dedicated bearer and in the PCC/QoS rules corresponding to the bearer there is no SDF filter for the uplink direction having an indication to signal corresponding traffic mapping information to the UE, the PCEF/BBERF derives traffic mapping information based on implementation specific logic (e.g. traffic mapping information that effectively disallows any useful packet flows in uplink direction as described in clause 15.3.3.4 of TS 23.060 [12]) and provides it to the UE.

NOTE 6: For GPRS and EPS, the state of TFT packet filters, as defined in TS 23.060 [12], for an IP-CAN session requires that there is at most one bearer with no TFT packet filter for the uplink direction.

NOTE 7: This PCEF behaviour covers also the case that a PCC rule with an application identifier is the only PCC rule that is bound to a dedicated bearer.

NOTE 8: For a default bearer, the PCEF/BBERF will not add traffic mapping information that effectively disallows any useful packet flows in uplink direction on its own. Traffic mapping information is only generated from SDF filters which have an indication to signal corresponding traffic mapping information to the UE.

6.1.10 IMS Emergency Session Support

6.1.10.1 Architecture model and Reference points

Emergency bearer services (i.e. IP-CAN session for the IMS emergency services) are provided by the serving network to support IMS emergency when the network is configured to support emergency services. Emergency services are network services provided through an Emergency APN and may not require a subscription depending on operator policies and local regulatory requirements. For emergency services the architecture for the non-roaming case as described in clause 5.1 is the only applicable architecture model.

For emergency services, the Sp reference point does not apply.

Emergency services are handled locally in the serving network. Therefore the S9 reference point does not apply.

6.1.10.2 PCC Rule Authorization and QoS rule generation

The PCC Rule Authorization and QoS Rule generation function selects QoS parameters that allow prioritization of IMS Emergency sessions. If an IMS Emergency session is prioritized the QoS parameters shall contain an ARP value that is reserved for intra-operator use of IMS Emergency services.

6.1.10.3 Functional Entities

6.1.10.3.1 PCRF

The PCRF shall determine based on the PDN-id if an IP-CAN Session concerns an IMS emergency session.

For an IP-CAN session serving an IMS emergency session, the PCRF makes authorization and policy decisions that restrict the traffic to emergency destinations, IMS signalling and the traffic to retrieve user location information (in the user plane) for emergency services. An IP-CAN session serving an IMS emergency session shall not serve any other service and shall not be converted to/from any IP-CAN session serving other services.

If the UE IP address belongs to an emergency APN, the PCRF does not perform subscription check; instead it utilizes the locally configured operator policies to make authorization and policy decisions.

For IMS, it shall be possible for the PCRF to verify that the IMS service information is associated with a UE IP address belonging to an emergency APN. If the IMS service information does not contain an emergency related indication and the UE IP address is associated with an emergency APN, the PCRF shall reject the IMS service information provided by the P‑CSCF (and thus to trigger the release of the associated IMS session), see TS 23.167 [21].

The PCRF performs according to existing procedure:

– If IMS service information containing an emergency related indication is received from the P‑CSCF with an UE IP address associated to an Emergency APN, the PCRF initiates an IP-CAN session Modification Request for the IP‑CAN session serving the IMS session to the PCEF to provide PCC Rule(s) that authorize media flow(s).

– At reception of an indication that the IMS emergency session is released from the P-CSCF, the PCRF removes the PCC rule(s) for that IMS session with an IP‑CAN session Modification Request.

In addition, upon Rx session establishment the PCRF shall provide the IMEI(SV) (if available) and the EPC-level subscriber identifiers (IMSI, MSISDN) (if available), received from the PCEF at IP-CAN session establishment, if so requested by the P-CSCF.

6.1.10.3.2 PCEF

The PCEF initiates the IP‑CAN Session termination if the last PCC rule for this IP‑CAN session is removed according to existing procedure.

In addition, at reception of an IP‑CAN Session Modification Request triggered by the PCRF for an IP‑CAN session serving an IMS emergency session that removes all PCC rules with a QCI other than the default bearer QCI and the QCI used for IMS signalling, the PCEF shall start a configurable inactivity timer (e.g., to enable PSAP Callback session). When the configured period of time expires the PCEF shall initiate an IP‑CAN Session Termination Request for the IP‑CAN session serving the IMS Emergency session.

If a PCRF-Initiated IP‑CAN Session Modification Request, providing new PCC rule(s) with a QCI other than the default bearer QCI and the QCI used for IMS signalling, the PCEF shall cancel the inactivity timer.

6.1.10.3.3 P-CSCF

The P‑CSCF performs according to existing procedure:

– At reception of an indication that an IMS emergency session is established, the P‑CSCF sends IMS service information to the PCRF.

– At reception of an indication that an IMS emergency session is released, the P‑CSCF interacts with the PCRF to revoke the IMS service information.

In addition, the P‑CSCF shall include an emergency related indication when providing IMS service information to the PCRF; see TS 23.167 [21].

Moreover, the P-CSCF upon Rx session establishment may request the PCRF to provide the IMEI(SV) and the EPC-level subscriber identifiers (IMSI, MSISDN) corresponding to the Rx session.

NOTE: The IMEI(SV) and the EPC-level subscriber identifiers (IMSI, MSISDN) can be used to support authentication of roaming users in deployments with no IMS-level roaming interfaces or to support PSAP callback functionality for anonymous IMS emergency sessions, as described in TS 23.167 [21].

6.1.10.4 PCC Procedures and Flows

At Indication of IP-CAN Session Establishment that includes a PDN-id that identifies an Emergency APN the PCRF ignores subscription information from the SPR. The PCRF uses locally configured operator policies to make authorization and policy decisions.

At Indication of IP-CAN Session Establishment and Gateway Control Session Establishment, the user identity (e.g. IMSI) may not be available, or can not be authenticated. In this case, the IMEI shall be used to identify the UE.

An IP-CAN session for an emergency service shall be restricted to the destination address(es) associated with the emergency service only.

6.1.10a Restricted Local Operator Services Support

Restricted Local Operator Services (i.e. IP-CAN session for the Restricted Local Operator Services) (as specified in TS 23.221 [55]) are provided by the serving network when the network is configured to support Restricted Local Operator Services.

The PCC handling of Restricted Local Operator Services is very similar to that of emergency service as specified in clause 6.1.10 with the following differences:

– RLOS APN and IMS RLOS session are used for Restricted Local Operator Services.

– Architecture model and Reference points (clause 6.1.10.1).

Restricted Local Operator Services do not require a subscription.

– PCC Rule Authorization and QoS rule generation (clause 6.1.10.2).

The Restricted Local Operator Services is not a prioritized services, and the ARP can be determined based on operator policy.

– Functional Entity: PCRF (clause 6.1.10.3.1).

The PCRF shall determine based on the RLOS APN if an IP-CAN Session relates to an IMS RLOS session.

– Functional Entity: PCEF (clause 6.1.10.3.2).

Duration of PDN connection for RLOS is controlled through local policies in PCEF. Handling of inactivity timer for the emergency PDN connection is not applicable for RLOS.

– Functional Entity: P-CSCF (clause 6.1.10.3.3).

Indication of IMS RLOS session is used.

– PCC Procedures and Flows (clause 6.1.10.4).

The PDN-id identifies an RLOS APN.

6.1.11 Multimedia Priority Service Support

6.1.11.1 Architecture model and Reference points

Subscription data for MPS is provided to PCC through the Sp reference point. To support MPS service, the PCRF shall subscribe to changes in the MPS subscription data for Priority EPS Bearer Service. Dynamic invocation for MPS is provided from an AF, using the Priority indicator, over Rx.

6.1.11.2 PCC rule authorization and QoS rule generation

For MPS service, the PCRF shall generate the corresponding PCC/QoS rule(s) with the ARP/QCI parameters as appropriate for the prioritized service.

For non-MPS service, the PCRF shall generate the corresponding PCC/QoS rule(s) as per normal procedures, without consideration whether the MPS Priority EPS Bearer Service is active or not, but upgrade the ARP/QCI values suitable for MPS when the Priority EPS Bearer Service is invoked. When the Priority EPS Bearer Service is revoked, the PCRF shall change the ARP/QCI values modified for Priority EPS Bearer Service to appropriate values.

NOTE 1: The above statements for the Priority EPS Bearer Service are also applicable for the MPS for Data Transport Service.

Whenever one or more AF sessions of an MPS service are active within the same PDN connection, the PCRF shall ensure that the ARP priority level of the default bearer is at least as high as the highest ARP priority level used by any authorized PCC rules belonging to an MPS service. If the ARP pre-emption capability is enabled for any of the authorized PCC rules belonging to an MPS service, the PCRF shall also enable the ARP pre-emption capability for the default bearer.

NOTE 2: This ensures that services using dedicated bearers are not terminated because of a default bearer with a lower ARP priority level or disabled ARP pre-emption capability being dropped during mobility events.

NOTE 3: This PCRF capability does not cover interactions with services other than MPS services.

6.1.11.3 Priority EPS Bearer Service

The MPS Priority EPS Bearer Service targets the ARP and/or QCI of bearer(s), enabling the prioritization of all traffic on the same bearer.

The PCRF shall, at the activation of the Priority EPS Bearer Service:

– modify the ARP of the default bearer as appropriate for the Priority EPS Bearer Service under consideration of the requirement described in clause 6.1.11.2; and

– if modification of the QCI of the default bearer is required, modify the QCI of the default bearer as appropriate for the Priority EPS Bearer Service; and

– modify the ARP of PCC/QoS Rules installed before the activation of the Priority EPS Bearer Service to the ARP as appropriate for the Priority EPS Bearer Service under consideration of the requirement described in clause 6.1.11.2; and

– if modification of the QCI of the PCC/QoS Rules is required, modify the QCI of the PCC/QoS Rules installed before the activation of the Priority EPS Bearer Service to the QCI as appropriate for the Priority EPS Bearer Service.

The PCRF shall, at the deactivation of the Priority EPS Bearer Service:

– modify the ARP of the default bearer to an appropriate value according to PCRF decision under consideration of the requirement described in clause 6.1.11.2; and

– if modification of the QCI of the default bearer is required, modify the QCI of the default bearer to an appropriate value according to PCRF decision; and

– for PCC/QoS rules modified due to the activation of Priority EPS bearer service:

– modify the ARP to an appropriate value according to PCRF decision under consideration of the requirement described in clause 6.1.11.2; and

– if modification of the QCI of PCC/QoS Rules is required, modify the QCI to an appropriate value according to PCRF decision.

6.1.11.4 Bearer priority for IMS Multimedia Priority Services

In addition to the mechanism specified in clause 6.1.11.2, IMS Multimedia Priority Services may require upgrade of the dedicated IM CN signalling bearer and the default bearer, e.g. in order to mitigate the IP-CAN session termination due to resource limitation at a location change the default bearer and dedicated IM CN signalling bearer may need an upgraded ARP.

At reception of the indication that the IMS Signalling Priority is set for the IP-CAN Session or at reception of service authorization from the P-CSCF (AF) including an MPS session indication and the service priority level the PCRF shall under consideration of the requirement described in clause 6.1.11.2:

– modify the ARP of the default bearer as appropriate for the IMS Multimedia Priority Service; and

– if upgrade of the dedicated IM CN signalling bearer is required, modify the ARP in all the PCC/QoS rules that describe the IM CN signalling traffic to the value appropriate for IMS Multimedia Priority Services.

When the PCRF detects that the P-CSCF (AF) released all the MPS session and the IMS Signalling Priority is not set for the IP-CAN session the PCRF shall under consideration of the requirement described in clause 6.1.11.2:

– modify the ARP of the default bearer to an appropriate value according to PCRF decision; and

– modify the ARP in all PCC/QoS Rules that describe the IM CN signalling traffic to an appropriate value according to PCRF decision.

6.1.11.5 Bearer priority for MPS for Data Transport Service

MPS for Data Transport Service enables the prioritization of all traffic on the default bearer and other bearers upon AF request. The QoS modification to the default bearer and other bearers is done based on operator policy and regulatory rules by means of local PCRF configuration.

NOTE 1: If no configuration is provided, MPS for Data Transport Service applies only to the default bearer.

Upon receipt of an MPS for Data Transport Service invocation/revocation request from the UE, the AF or the PCRF authorizes the request. If the UE has an MPS subscription, MPS for Data Transport Service is authorized by the AF or the PCRF, based on AF decision. If the Service User is using a UE that does not have an MPS subscription, the AF authorizes MPS for Data Transport Service.

– In the case that the AF authorizes the MPS for Data Transport Service request, after successful authorization, the AF sends the MPS for Data Transport Service request to the PCRF over Rx for QoS modifications, including an indication that PCRF authorization is not needed. In this case, the PCRF shall not perform a subscription check for MPS for Data Transport Service requests. The AF also indicates to the PCRF whether the request is for invoking or revoking MPS for Data Transport Service.

– In the case that the AF does not authorize the MPS for Data Transport Service request, the AF sends the request over Rx to the PCRF for authorization and QoS modifications, including an indication that PCRF authorization is needed. In this case, the PCRF shall perform an MPS subscription check for the MPS for Data Transport Service request. The AF also indicates whether the request is for invoking or revoking MPS for Data Transport Service. The PCRF will inform the AF when the UE does not have an MPS subscription associated with the request.

After successful authorization by either AF or PCRF as described above, the PCRF shall, at the activation of MPS for Data Transport Service over Rx, perform the same steps for QoS modifications as described in clause 6.1.11.3 for the activation of the Priority EPS Bearer Service.

NOTE 2: To keep the PCC rules bound to the default bearer, the PCRF can either modify the ARP/QCI of these PCC rules accordingly or set the Bind to Default Bearer PCC rule attribute.

The PCRF shall inform the AF of the success or failure of the MPS for Data Transport Service invocation/revocation request.

The PCRF shall at the deactivation of MPS for Data Transport Service over Rx perform the same steps described in clause 6.1.11.3 for the deactivation of the Priority EPS Bearer Service.

If the bearers are deactivated for other reasons than an AF request, the PCRF shall notify the AF by terminating the Rx session.

The AF may also request an SDF for priority signalling between the UE and the AF, where the AF includes the Priority indicator over Rx, in order to enable the PCRF to set appropriate QoS values for the signalling bearer.

6.1.12 ADC rule authorization

ADC Rule authorization refers to the PCRF decision about which predefined and/or dynamic ADC rules to activate for a TDF session and is only applicable in case of solicited application reporting.

It may also comprise the selection of parameters (monitoring key, enforcement actions etc.) for dynamic ADC rules to be applied once the traffic is detected.

User profile configuration, received within subscription information, indicating whether application detection and control can be enabled, shall be taken into account by PCRF, when deciding on ADC rule authorization.

NOTE 1: The enforcement actions are only applicable in case of solicited application reporting.

NOTE 2: For unsolicited application reporting, all ADC rules pre-provisioned at TDF are authorized.

6.1.13 Redirection

Redirection of application traffic is an option applicable in the TDF or the PCEF enhanced with ADC.

PCRF may control redirection by provisioning and modifying dynamic ADC rules over the Sd interface for a TDF, or dynamic PCC rules over the Gx interface for a PCEF enhanced with ADC. The PCRF may enable/disable redirection and set a redirect destination for every dynamic ADC rule or PCC rule.

Redirect information (redirection enabled/disabled and redirect destination) within a PCC Rule or within an ADC rule respectively, instructs the PCEF enhanced with ADC, or the TDF whether or not to perform redirection towards a specific redirect destination. The redirect destination may be provided as part of the dynamic PCC/ADC Rule, or may be preconfigured in the PCEF enhanced with ADC or the TDF. A redirect destination provided in a dynamic PCC/ADC Rule overrides the redirect destination preconfigured in the PCEF enhanced with ADC or in the TDF for this PCC/ADC Rule.

The redirection is enforced by the PCEF enhanced with ADC or the TDF on uplink application’s traffic matching the ADC or PCC rule for which redirection is enabled.

6.1.14 Resource sharing for different AF sessions

The P-CSCF (i.e. AF) may indicate to the PCRF that media of an AF session may share resources with media belonging to other AF sessions according to TS 23.228 [39]. For every media flow, the P-CSCF may indicate that the media flow may share resources in both directions or in one direction only (UL or DL).

The PCRF makes authorization and policy decisions for the affected AF sessions individually and generates a PCC/QoS rule for every media flow in any AF session.

If the PCRF received identical indication(s) for resource sharing for multiple AF sessions, the PCRF may request the PCEF/BBERF to realize resource sharing for the corresponding set of PCC/QoS rules. The PCRF provides a DL and/or UL sharing indication with the same value for those PCC/QoS Rules that are candidate to share resources according to the direction of resource sharing indicated by the AF.

For each direction, the PCEF/BBERF shall take the highest GBR value from each set of PCC/QoS Rules related with the same sharing indication for this direction and bound to the same bearer and uses that value as input for calculating the GBR of the bearer. For each direction, the PCEF/BBERF may take the MBR value of the most demanding PCC/QoS Rule included in each set of PCC Rules related with the same sharing indication for this direction and bound to the same bearer and uses that as input for calculating the MBR of the bearer.

The AF session termination or modification procedure that removes media flows triggers the removal of the corresponding PCC/QoS Rules from the PCEF/BBERF. The PCEF/BBERF shall recalculate the GBR (and MBR) value of the bearer whenever a set of PCC/QoS Rules with the same sharing indication changes.

Resource sharing is applied as long as there are at least two active PCC/QoS rules with the same sharing indication bound to the same bearer.

Resource sharing for different AF sessions is possible only if the P-CSCF, the PCRF and the PCEF/BBERF support it.

NOTE: This procedure assumes that applications/service logic must do the necessary coordination, e.g. pause sending or employ gating, to avoid service data flows interfering and to ensure that multiple flows comply with the combined QoS parameters.

6.1.15 Reporting of RAN user plane congestion information

6.1.15.1 General

RAN User Plane Congestion Information (RUCI) is reported to the PCRF to enable the PCRF to take the RAN user plane congestion status into account for policy decisions.

The RUCI includes the following information:

– The IMSI identifying the UE impacted by congestion;

– eNB identifier, ECGI or SAI identifying the eNB, E-UTRAN cell or Service Area, respectively, serving the UE.

NOTE: Whether in case of E-UTRAN the eNB identifier or the ECGI is included in the RUCI is up to operator configuration in the RCAF.

– APN for which congestion information is reported;

– Congestion level or an indication of the "no congestion" state.

6.1.15.2 Reporting restrictions

Depending on the operator’s congestion mitigation policy, it may not be necessary to have RUCI reporting for all users. An operator shall be able to specify restrictions for RUCI reporting on a per UE per APN basis. Reporting restrictions can be used to activate or deactivate the RUCI reporting. Reporting restrictions can also be used to limit RUCI reporting. This is achieved by defining one or more sets of congestion levels, such that the RCAF indicates only that the UE experiences a congestion level within the given set but does not indicate the congestion level itself within that set. The sets must be non-overlapping such that a congestion level belongs to a single set only. Reporting restrictions can also be used to deactivate reporting of the congested cell’s identifier as part of the RUCI.

NOTE: The support for the reporting restrictions is optional, and used only if both the PCRF and the RCAF support this feature.

6.1.15.3 UE mobility between RCAFs

A RCAF is assumed to serve a geographical area. A UE may move from the area handled by one RCAF to an area handled by a different RCAF. RCAF nodes cannot detect mobility by themselves: an RCAF node cannot differentiate whether a UE that is no longer affected by congestion has moved to another RCAF or not. When a given RCAF indicates no congestion to the PCRF for a given UE on the Np interface, this should be interpreted as no congestion experienced at the given RCAF which does not exclude that another RCAF may report that the same UE experiences congestion.

Consistent operation for UE mobility is ensured by applying the following rules at the PCRF.

– The PCRF maintains the RCAF which has last indicated that the UE is affected by congestion.

– When a new RCAF indicates that the UE is affected by congestion, the PCRF sends a message to the old RCAF to explicitly release context at the old RCAF.

6.1.16 Negotiation for future background data transfer

The AF may contact the PCRF via the SCEF (and the Nt interface) to request a time window and related conditions for future background data transfer.

NOTE 1: The SCEF may contact any PCRF in the operator network.

The AF request shall contain an ASP identifier, the volume of data to be transferred per UE, the expected amount of UEs, the desired time window and optionally, network area information (e.g. list of cell ids, TAs/RAs).

NOTE 2: A 3rd party application server is typically not able to provide any specific network area information and if so, the AF request is for the whole operator network.

The PCRF shall first retrieve all existing transfer policies stored for any ASP from the SPR. Afterwards, the PCRF shall determine, based on the information provided by the AF and other available information (e.g. network policy, congestion level (if available), load status estimation for the required time window and network area, existing transfer policies) one or more transfer policies.

A transfer policy consists of a recommended time window for the background data transfer, a reference to a charging rate for this time window and optionally a maximum aggregated bitrate (indicating that the charging according to the referenced charging rate is only applicable for the aggregated traffic of all involved UEs that stays below this value). Finally, the PCRF shall provide the transfer policies to the AF together with a reference ID. If the AF received more than one transfer policy, the AF shall select one of them and inform the PCRF about the selected transfer policy.

NOTE 3: The maximum aggregated bitrate (optionally provided in a transfer policy) is not enforced in the network. The operator may apply offline CDRs processing (e.g. combining the accounted volume of the involved UEs for the time window) to determine whether the maximum aggregated bitrate for the set of UEs was exceeded by the ASP and charge the excess traffic differently.

NOTE 4: It is assumed that the 3rd party application server is configured to understand the reference to a charging rate based on the agreement with the operator.

The selected transfer policy is finally stored by the PCRF in the SPR together with the reference ID and the network area information. The same or a different PCRF can retrieve this transfer policy and the corresponding network area information from the SPR and take them into account for future decisions about transfer policies for background data related to the same or other ASPs.

At the time the background data transfer is about to start, the AF provides for each UE the reference ID together with the AF session information to the PCRF (via the Rx interface). The PCRF retrieves the corresponding transfer policy from the SPR and derives the PCC rules for the background data transfer according to this transfer policy.

NOTE 5: The AF will typically contact the PCRF for the individual UEs to request sponsored connectivity for the background data transfer.

NOTE 6: A transfer policy is only valid until the end of its time window. The removal of outdated transfer policies from the SPR is up to implementation.

6.1.17 Traffic Steering Control

Traffic steering control is triggered by the PCRF initiated request and consists in applying a specific (S)Gi-LAN traffic steering policy for traffic detected based on application level information or service data flow level information for the purpose of steering the subscriber’s selected traffic to appropriate (S)Gi-LAN service functions deployed by the operator or 3rd party service provider.

The PCRF uses one or more pieces of information such as network operator’s policies, user subscription, user’s current RAT, network load status, application identifier, time of day, UE location, APN, related to the subscriber session and the application traffic as input for selecting a traffic steering policy.

The PCRF controls traffic steering in the PCEF, TDF or TSSF by provisioning and modifying traffic steering control information. Traffic steering control information consists of a traffic description and a reference to a traffic steering policy that is configured in the PCEF, TDF or TSSF.

The PCEF, TDF or TSSF performs necessary actions to enforce the traffic steering policy referenced by the PCRF. For enforcing the traffic steering policy, the PCEF, TDF or TSSF may support traffic steering related functions as defined by other standard organizations. The mechanism used for routing the traffic between the service functions within the (S)Gi-LAN, is out of 3GPP scope.

The traffic steering control may be deployed using PCEF only, using TDF only, or using TSSF only, or using a combination of PCEF/TDF and TSSF.

When a combination of PCEF/TDF with traffic steering control feature and TSSF is deployed, the PCEF/TDF is utilized for application detection and packet marking while traffic steering is done using TSSF. In this case the PCC/ADC Rules provided to the PCEF/TDF for application detection shall be at application level while the traffic steering control information provided to the TSSF for traffic detection and steering control shall be at service data flow level only, i.e. the Application identifier and Traffic steering policy identifier shall be included over Gx/Sd reference point for detection of the traffic and packet marking, and the Service data flow filter(s) and Traffic steering policy identifier shall be included over St reference point for traffic steering control. The value used for packet marking at the PCEF/TDF (according to the Traffic steering policy identifier received from the PCRF) shall be the same as the one within the Service data flow filter (using filter information described in clause 6.2.2.2) that is sent to the TSSF and used for traffic steering. Alternatively, the Application Identifier may be used for traffic detection at the TSSF. In this case the value used for packet marking at the PCEF/TDF (according to the Traffic steering policy identifier received from the PCRF) shall be the same as the one configured in the TSSF for that Application Identifier.

NOTE 1: The above principle also enables a deployment scenario in which the PCEF/TDF acts as an uplink traffic classifier while the downlink traffic classifier, located in (S)Gi-LAN, acts only at service data flow filter level. This deployment scenario is applicable for applications with deducible service data flow filters only. In this case, the PCEF/TDF deduces the downlink service data flow description and communicates the related information to the downlink classifier.

NOTE 2: The SDF filter(s) can be used for traffic detection at the TSSF when the PCEF/TDF is configured to do packet marking and forwarding using ToS or TC values in the IP header. The Application Identifier can be used when the PCEF/TDF is configured to do packet marking and forwarding using e.g. GRE or NSH.

6.1.18 PCC support of NBIFOM

6.1.18.1 General

Clause 6.1.18 refers to Network Based IP Flow Mobility as described in TS 23.161 [43].

When PCC control for NBIFOM applies for an IP-CAN session:

– Multiple IP-CAN types (3GPP EPS and Non 3GPP EPS) may be simultaneously associated with the same IP-CAN session.

– The PCRF sends PCC rules including NBIFOM related information as defined in clause 6.3.1.

– In UE-initiated NBIFOM mode this is based on Routing Rules received from the UE.

– For network-initiated NBIFOM mode, the PCRF determines the NBIFOM related information for a PCC rule as defined in clause 6.2.1.1 (including information about UE requested mapping of IP flows to an access, Change of usability of an Access).

– A change of access may trigger the modification of the charging key or the monitoring key in a PCC rule if access dependent charging or usage monitoring is required by the operator.

– The PCRF decides whether NBIFOM applies for the IP-CAN session, based on information about the support for NBIFOM received from the PCEF and operator policies that may take into account subscription information.

– The PCEF notifies the PCRF when an access is added or removed using the event trigger defined in clause 6.1.4.

– The PCEF notifies the PCRF when an access becomes Unusable or Usable again or when the move-to-WLAN or move-from-WLAN event occurs, both events are notified to the PCRF using the event trigger "Change of the usability of an access" as defined in clause 6.1.4.

– The PCRF may reject the NBIFOM Routing Rules received from the UE based on user subscription.

In following conditions the PCRF mentioned above is the H-PCRF:

– The UE is served by its HPLMN, or

– The PDN connection is served by a PGW in the Home PLMN (Home Routed roaming configuration), or

– The PDN connection is served by a PGW in the V-PLMN (LBO configuration), and S9 is deployed and the V-PCRF supports NBIFOM. In that case, the V-PCRF acts as a relay of information.

The PCRF mentioned above is the V-PCRF in the case when, through roaming agreement, the HPLMN operator allows the VPLMN operator to operate the V-PCRF without S9; this includes authorization of roamers to use NBIFOM. In that case, network control related with subscription such as checking the total usage allowance does not apply.

NOTE 1: If the Home operator wants to enforce control of the NBIFOM functionality on a PDN connection by the H-PCRF, the Home operator should ensure that the Home Routed roaming configuration applies to this PDN connection.

NOTE 2: NBIFOM may be deployed without PCC support. This is defined in TS 23.161 [43].

In a multi access IP-CAN session, every PCC Rule is associated to one allowed access within the IP-CAN session. The information about the allowed access may be explicitly included in the PCC Rule, within the Allowed Access Type. Otherwise, the default NBIFOM access for the traffic on the IP-CAN session shall be applied as allowed access for a PCC rule. The bearer binding mechanism in the PCEF shall, in addition to the requirements defined in 6.1.1.4, ensure that a PCC Rule is associated to an IP-CAN bearer belonging to the allowed access.

The PCEF may provide the following information for each access in a multi access IP-CAN session:

– Location of the subscriber as defined in clauses A.4, H.3 and H.4.

– A serving PLMN identifier as defined in clauses A.4, H.3 and H.4.

– RAT type as defined in clauses A.4, H.3 and H.4.

For the purpose of usage monitoring in the PCEF when NBIFOM applies for an IP-CAN session, the PCRF may receive an individual Monitoring key per access from SPR.

6.1.18.2 NBIFOM impacts on IP-CAN procedures

PCC support of NBIFOM requires following modifications to IP-CAN session procedures:

– IP-CAN session establishment.

During the IP-CAN session establishment, the PCEF informs the PCRF about the UE and network support of NBIFOM and the requested NBIFOM mode (defined in TS 23.161 [43]). The PCRF takes a policy decision on whether NBIFOM may apply to the IP-CAN session (the hPCRF decides the NBIFOM mode according to TS 23.161 [43]) and informs the PCEF about its decision.

– Addition of an access.

When the PCEF receives both a handover request and a NBIFOM indication from the UE, the PCEF initiates an IP-CAN Session Modification procedure, to:

– Notify the PCRF about the addition of an access to the IP-CAN session together with the IP-CAN type and the RAT type of this access. If UE-initiated NBIFOM mode was selected at IP-CAN session establishment the notification contains also the default NBIFOM access selected by the UE.

– Notify the PCRF with the NBIFOM Routing Rules, if the UE included Routing Rules with the access addition request in UE-initiated NBIFOM mode.

The PCRF takes policy decisions and communicates them to the PCEF:

– The PCRF may reject the addition of the access if the multi-access IP-CAN session would correspond to an invalid combination of IP-CAN and RAT Types or is not allowed by the subscription. In this release of the specification the only allowed combination corresponds to the UE using a 3GPP access and a WLAN access.

– If network-initiated NBIFOM mode was selected at IP-CAN session establishment, the PCRF indicates the default NBIFOM access to the PCEF.

– In UE-initiated NBIFOM mode the PCRF verifies the default NBIFOM access provided by the UE. If it complies with the subscription the PCRF provides this default NBIFOM access to the PCEF. If not, the PCRF selects a different default NBIFOM access and provides it to the PCEF.

– In UE-initiated NBIFOM mode, the PCRF may receive NBIFOM Routing Rules created by the UE. The PCRF may reject a NBIFOM Routing Rule due to subscription limitations. Otherwise, the PCRF determines for each NBIFOM Routing Rule the impacted PCC rule and provides or modifies this PCC rule.

– The PCRF shall ensure that there is at least one PCC Rule that can be bound to the default bearer of each access.

– Removal of an access.

When the PCEF is informed about the removal of an access of a multi-access IP-CAN session, the PCEF initiates an IP-CAN Session Modification procedure, to notify the PCRF about the removal of an access together with the IP-CAN type and the RAT type of this access. The PCRF determines the affected PCC rules and replies with updated PCC Rules or informs about the PCC Rules that are to be removed.

The PCC rules corresponding to the removed access are then modified or deleted by the PCEF accordingly. This shall not trigger the sending of Routing Rules deletion to the UE in Network-initiated NBIFOM mode.

NOTE 2: The UE deletes the Routing Rules locally in case of removal of access as described in TS 23.161 [43].

NOTE 3: The PCRF can also decide to trigger the removal of an access by updating or removing all PCC rules that are bound to this access. The removal of all PCC Rules bound to an access removes the access unless there are PCC Rules not known to the PCRF defined in the PCEF for this particular access.

– Network-initiated IP flow mobility within a PDN connection (Network-initiated NBIFOM mode).

When a multi-access IP-CAN session has been set-up in Network-initiated NBIFOM mode, the PCRF may at any time determine that flows should be moved from a source access to a target access. In that case, the PCRF provides updated PCC Rules with a modified Allowed Access Type and the Routing Rule Identifier using an IP-CAN Session Modification procedure (i.e. the Allowed Access Type can be added, changed or removed).

The PCRF request triggers the sending of Routing Rules creation (when the Allowed Access Type is added) or Routing Rules modification (when the Allowed Access Type is changed) to the UE which may be rejected by the UE due to local radio conditions. In that case the PCRF gets notified which PCC rules cannot be modified. This notification from the PCEF contains an indication of the cause of the rejection received from the UE.

The PCRF request triggers the sending of Routing Rules deletion to the UE when the Allowed Access Type is removed.

– UE-initiated IP flow mobility within a PDN connection (UE-initiated NBIFOM mode).

When the PCEF has received a request from the UE to create / modify / delete a Routing Rule, the PCEF initiates an IP-CAN Session Modification procedure and provides the Routing Rule received from the UE to the PCRF as an NBIFOM Routing Rule. The PCRF may reject an NBIFOM Routing Rule received from the UE due to subscription limitations. Otherwise the PCRF determines and updates the impacted PCC rule (as described in 6.12.2) and provides the updated PCC rule to the PCEF.

– UE requested mapping of IP flows to an access (Network-initiated NBIFOM mode).

This procedure is only used in Network-initiated NBIFOM mode when the UE wants to request the network to apply specific mappings of IP flows to an access.

When the PCEF has received a request from the UE to have the network create / modify / delete a Routing Rule, the PCEF initiates an IP-CAN Session Modification procedure and provides the information received from the UE to the PCRF as an NBIFOM Routing Rule. The PCRF may reject an NBIFOM Routing Rule received from the UE due to subscription limitations. Otherwise the PCRF determines and updates the impacted PCC rule (as described in clause 6.12.2) and provides the updated PCC rule to the PCEF. The updated PCC rule triggers the sending of a Routing Rules creation / modification / deletion to the UE (as described above for Network-initiated IP flow mobility).

– Indication that an access becomes unusable / usable again or indication of move-to-WLAN / move-from-WLAN (Network-initiated NBIFOM mode).

The PCEF initiates an IP-CAN Session Modification procedure to notify the PCRF about the change of usability of an access to the PCRF. For every PCC rule that is currently bound to this access, the PCRF shall either change the Allowed Access Type and provide the updated PCC rule to the PCEF or remove this PCC rule. This triggers the sending of Routing Rules modification to the UE. If the PCRF receives an indication that an access become usable again, The PCRF may update the PCC rules, e.g. by changing the Allowed Access Type and provide the updated PCC rules to the PCEF. This triggers the sending of Routing Rules modification to the UE.

– Reporting Access Network Information to the AF.

The PCRF reports to the AF only Access Network Information associated with one access even though different media of the AF session are carried by different accesses.

If the PCRF has received a request for Access Network Information from the AF and PCC rules related with the AF request are bound to multiple accesses, the PCRF selects one PCC rule to be associated with Access Network Information reporting from the PCEF. The selected PCC rule should correspond to the 3GPP access: Using the 3GPP access reduces the risk of getting non-trustable location information from the S2b access of the IP-CAN session.

– UE resource request for a multi-access IP-CAN session.

When the UE wants to request the network to allocate resources for one or more IP flows in the non-default NBIFOM access, the UE shall provide a corresponding Routing Rule in the same request in the UE-initiated mode. Without such Routing Rule, the network shall reject the UE resource request.

NOTE 4: UE resource requests in the default NBIFOM access do not require a Routing Rule as the generated PCC rule will be bound to dedicated bearer in this access.

– PCRF initiated IP-CAN session modification.

When network-initiated NBIFOM mode applies and the PCRF modifies the service data flow filter or precedence in a PCC rule for which a corresponding Routing Rule exists, the PCEF shall also modify this Routing Rule at the UE accordingly.

When network-initiated NBIFOM mode applies and the PCRF removes a PCC rule for which a corresponding Routing Rule exists, the PCEF shall also remove the corresponding Routing Rule at the UE.

When UE-initiated NBIFOM mode applies and if a new PCC rule is created due to the request from the network (e.g. request from the AF or application detection information from the PCEF/TDF), the PCRF shall determine that the new PCC rule is bound to the default access. UE may initiate IP flow mobility request to bind the IP flow to another access later.

6.1.19 Resource reservation for services sharing priority

To enable the usage of the same bearer, an AF may indicate to the PCRF that a media flow of an AF session is allowed to use the same priority as media flows belonging to other AF sessions (instead of the service priority provided for this media flow). In this case, the AF will provide a priority sharing indicator in addition to the application identifier and the service priority. For MCPTT, the service priority and the priority sharing indicator are defined in TS 23.179 [46]. The priority sharing indicator is used to indicate what media flows are allowed to share priority.

The PCRF makes authorization and policy decisions for the affected AF sessions individually and generates a PCC/QoS rule for every media flow as specified in clause 6.1.1.3. The application identifier and the service priority are used to calculate the ARP priority. The AF may also provide suggested pre-emption capability and vulnerability values per media flow to the PCRF. The ARP pre-emption capability and the ARP pre-emption vulnerability are set according to operator policies and regulatory requirements, also taking into consideration the application identifier and suggested values, when provided by the AF. The priority sharing indicator is stored for later use.

For PCC/QoS rules with the same QCI assigned and having an associated priority sharing indicator, the PCRF shall try to make authorization and policy decisions taking the priority sharing indicator into account and modify the ARP of these PCC/QoS rules as follows, (the original ARP values are stored for later use):

– The modified ARP priority is set to the highest of the original priority among all the PCC/QoS rules that include the priority sharing indicator;

– The modified ARP pre-emption capability is set if any of the original PCC/QoS rules have the ARP pre-emption capability set;

– The modified ARP pre-emption vulnerability is set if all the original PCC/QoS rules have the ARP pre-emption vulnerability set.

NOTE 1: Having the same setting for the ARP parameter in the PCC/QoS rules with the priority sharing indicator set enables the usage of the same bearer. Furthermore, a combined modification of the ARP parameter in the PCC/QoS rules ensures that a bearer modification is triggered when a media flow with higher service priority starts.

If the PCRF receives an indication that a PCC/QoS rule provisioning or modification failed (due to resource reservation failure) then, the PCRF may apply pre-emption and remove active PCC/QoS rules from the PCEF and then retry the PCC/QoS rule provisioning or modification procedure. If the PCRF does not apply pre-emption, the AF is notified using existing procedures (as defined in clause 6.1.5) that the resource reservation for the new media flow failed.

The AF may optionally provide pre-emption control information, including pre-emption capability and vulnerability values, in addition to the priority sharing indicator to the PCRF. If so, the PCRF shall apply pre-emption and remove active PCC/QoS rules according to this information when receiving an indication that a PCC/QoS rule provisioning or modification failed. The pre-emption control information indicates:

– whether media flows sharing priority are candidates to being pre-empted taking into account pre-emption capability and vulnerability values;

– how to perform pre-emption among multiple potential media flow candidates of same priority: most recently added media flow, least recently added media flow, media flow with highest requested bandwidth in the AF request.

6.1.20 Management of Packet Flow Descriptions using the PFDF

The Management of Packet Flow Descriptions (PFDs) enables the PCEF and TDF to perform accurate application detection when PFDs are provided by an ASP (via the SCEF and the PFDF) and then to apply enforcement actions as instructed in the PCC/ADC Rule.

The operator is able to configure pre-defined PCC/ADC Rules in the PCEF/TDF or dynamic PCC/ADC Rules in the PCRF that include at least an application identifier for service data flow or application detection, charging control information, i.e. charging key and optionally the Sponsor identifier or the ASP identifier or both. Depending on the service level agreements between the operator and the Application Server Provider, it may be possible for the ASP to provide individual PFDs or the full set of PFDs for each application identifier maintained by the ASP to the PCEF/TDF via the SCEF and the PFDF. The PFDs become part of the application detection filters in the PCEF/TDF and therefore are used as part of the logic to detect traffic generated by an application. The ASP may remove or modify some or all of the PFDs which have been provisioned previously for one or more application identifiers. When a removed/modified PFD was used to detect application traffic related to an application identifier in a PCC/ADC Rule of an IP-CAN/TDF session and the PCEF/TDF has reported the application start as described in clause 4.5 to the PCRF for the application instance corresponding to this PFD, the PCEF/TDF shall report the application stop to the PCRF for the corresponding application instance identifier if the removed/modified PFD in PCEF/TDF results in that the stop of the application instance is not being able to be detected.

NOTE 1: The management of Packet Flow Descriptions is optional, and is only used if the PFDF is deployed and the PCEF or the TDF supports this feature.

Each PFD may be identified by a PFD id. A PFD id is unique in the scope of a particular application identifier. There may be different PFD types associated to an application identifier, see TS 23.682 [42] for the definition of PFD.

The PFDs may be retrieved by PCEF/TDF from PFDF in "pull" mode or may be provisioned from PFDF to the PCEF/TDF in "push" mode.

When the "push" mode is used, the PFDF distributes PFDs for each application identifier to those PCEFs/TDFs that enable access to those applications. The PFDF may be configured with the list of PCEFs/TDFs where PFDs should be distributed. There are three methods to provision PFDs from the PFDF to the PCEF/TDF, as described in clause 7.12.2:

a) Push of whole PFDF state according to operator configuration in PFDF (e.g., provision per day according to operator configuration);

b) Selective push of an ASP change in the PFD set (i.e. ASP changes the PFD set while operator configuration defines when to push);

c) Selective push of an ASP change in the PFD set according to ASP request (i.e. ASP indicates to push changes in a PFD set within the time interval indicated by the Allowed Delay as described in TS 23.682 [42]).

NOTE 2: In all cases listed above, how to protect the PCEF/TDF from overload during the procedure to provision PFDs is up to Stage 3.

The SCEF may be configured with a minimum allowed delay based on SLA to authorize the allowed delay provided by the ASP, as defined in TS 23.682 [42].

When the "pull" mode is used, at the time a PCC/ADC Rule with an application identifier for which PFDs provisioned by the PFDF are not available is activated or provisioned, the PCEF/TDF requests all PFDs for that application identifier from the PFDF. The PFDs retrieved for an application identifier from the PFDF are cached in the PCEF/TDF with an associated caching timer to control how long the PFDs are valid. When the caching timer elapses, if there are still active PCC/ADC rules that refer to the corresponding application identifier, the PCEF/TDF reloads the PFD(s) from the PFDF. When the PCEF/TDF removes the last PCC/ADC rule that refers to the corresponding application identifier, or when the caching timer expires and no PCC/ADC rule refers to the application identifier, the PCEF/TDF may remove the PFD(s) related with the application identifier.

NOTE 3: It is assumed that all PCEF(s)/TDF(s) and PFDF(s) in an operator network are configured with the same default caching time value to be applied for all application identifiers.

Within one PLMN, "push" mode only, "pull" mode only, or a combination of "pull" and "push" mode may be supported if the feature is supported.

When the "pull" mode is used, the PFDF may provide to the PCEF/TDF a caching time value per application identifier. The PCEF/TDF receives the caching time value together with the PFD(s) from the PFDF over Gw/Gwn and applies this value for the application identifier instead of the configured default caching time value. In case no caching time value is received from PFDF, the PCEF/TDF uses the configured default caching time value.

NOTE 4: The configuration of a caching time value per application identifier PFDF is based on the SLA between the operator and the ASP.

When only "pull" mode is supported in one PLMN, if the Allowed Delay is shorter than the caching time value stored for this application identifier, or shorter than the default caching time if no application-specific caching time is stored, the PFDF sends a response to SCEF with an indication that the Allowed Delay cannot be met. The PFDF may still store the PFD(s) and if so, indicate this to the SCEF. The PFDF shall also include the caching time value in the response to the SCEF. The SCEF shall forward the indication that the PFDF stored the PFD(s) (if available) and the caching time value to the ASP when informing that the Allowed Delay could not be met.

If the PFDs are managed by local O&M procedures, PFD retrieval is not used; otherwise, the PFDs retrieved from PFDF overrides any PFDs pre-configured in the PCEF/TDF. If all PFDs retrieved from the PFDF are removed for an application identifier, the pre-configured PFDs shall be applied again for the application identifier. The PCEF/TDF may differentiate the need for PFD retrieval based on operator configuration in the PCEF/TDF.

The AF requests including an application identifier may trigger the activation or provisioning of a PCC/ADC Rule in the PCEF/TDF by the PCRF based on operator policies.

6.1.21 3GPP PS Data Off

This feature, when activated by the user, prevents downlink traffic and may prevent uplink traffic via 3GPP access except for 3GPP PS Data Off Exempt Services.

NOTE 1: Preventing uplink packets that don’t belong to 3GPP Data Off Exempt Services in PDN GW implies that the exempt uplink packets in the UE have traversed the Serving GW but get dropped in the PDN GW. If this happens, it’s not possible to verify accounting information collected at the Serving GW for inter-operator charging. However, the subscriber may not be charged for those packets.

The 3GPP PS Data Off Exempt Services are a set of operator services, defined in TS 22.011 [49], that are the only allowed services in downlink direction when the 3GPP PS Data Off feature has been activated by the user.

When PCRF is deployed, it shall be configured with the list of 3GPP PS Data Off Exempt Services and the event trigger of 3GPP PS Data Off status change is used to inform the PCRF about every change of the 3GPP PS Data Off status.

NOTE 2: The PCRF can be configured with a list of 3GPP PS Data Off Exempt Services per APN. The list of 3GPP PS Data Off Exempt Services for an APN can also be empty, or can allow for any service within that APN, according to operator policy.

NOTE 3: The PCRF can be configured with up to two lists of 3GPP PS Data Off Exempt Services for UEs in HPLMN and for UEs camping in any VPLMNs using mechanism as specified in clause 6.2.1.1.

NOTE 4: For the PDN connection used for IMS services, the 3GPP Data Off Exempt Services are enforced in the IMS domain as specified TS 23.228 [39]. Policies configured in the PCRF need to ensure that IMS services are allowed when the 3GPP Data Off status of the UE is set to "activated", e.g. by treating any service within a well-known IMS APN as 3GPP PS Data Off Exempt Services.

When the PCRF is informed about the activation of 3GPP PS Data Off, it shall update the PCC rules in such a way that only packets for services belonging to the list of 3GPP PS Data Off Exempt Services are forwarded while all other packets are discarded.

NOTE 5: In order for the PCEF to prevent the services that do not belong to the list of 3GPP PS Data Off Exempted Services, if the services are controlled by dynamic PCC rules, the PCRF could modify the PCC rules by setting the gate status to "closed" for the downlink and optionally uplink directions in all active dynamic PCC rules or remove those dynamic PCC rules. If the services are controlled by predefined PCC rules, the PCRF can deactivate those predefined PCC rules. PCC rule with wild-carded service data flow filters can be among the PCC rules that are modified, removed or deactivated in that manner. In this case, it can be necessary that the PCRF at the same time installs or activates PCC rules for data-off exempt services.

NOTE 6: For example, four PCC rules (A, B, C, D) are active for a PDN connection with PCC rule A representing a 3GPP PS Data Off Exempt Service. When 3GPP PS Data Off is activated, the PCRF could either modify PCC rules B, C and D if they are dynamic PCC rules by closing the gate in downlink and optionally in uplink direction or remove/deactivate PCC rules B, C and D if they are predefined PCC rules. PCC rule A does not need to be changed as it represents 3GPP PS Data Off Exempt Service. Assuming that PCC rule B contained wild-carded service data flow filters which has enabled some 3GPP PS Data Off Exempt Service is removed or deactivated, an additional PCC rule E can be installed or activated as well to enable the downlink traffic for that 3GPP PS Data Off Exempt Service.

NOTE 7: The network configuration can ensure that at least one PCC Rule is bound to the default bearer when Data Off is activated in order to avoid deletion of an existing PDN connection or in order not to fail a PDN connection establishment.

When the PCRF receives service information from the AF, in addition to what is specified in clause 6.2.1.0, PCRF shall check if the requested service information belongs to the 3GPP PS Data Off Exempt Services. If the requested service belongs to 3GPP PS Data Off Exempt Services, PCRF shall continue as specified in clause 6.2.1.0. If the requested service doesn’t belong to the 3GPP PS Data Off Exempt Services, PCRF shall reject the service request.

When the PCRF is informed about the deactivation of 3GPP PS Data Off, it shall perform policy control decision as specified in clause 6.2.1.0 and perform PCC rule operations as specified in clause 6.3.2 2 to make sure that the services are allowed according to user’s subscription and operator policy (irrespective of whether they belong to the list of 3GPP PS Data Off Exempt Services).

When PCRF is not deployed, predefined PCC rules, as example, can be configured in the PCEF to ensure the following:

– when the PCEF is informed about activation of 3GPP PS Data Off, only packets for services belonging to the list of 3GPP PS Data Off Exempt Services are forwarded while all other packets are discarded. The list of 3GPP PS Data Off Exempt Services for UEs camping in HPLMN and the list of 3GPP PS Data Off Exempt Services for UEs camping in VPLMN can be different, and

– When PCEF is informed about deactivation of 3GPP PS Data Off, downlink packets are forwarded according to the operator policy for the subscriber.

NOTE 8: For example, the PCEF can be configured with three sets of predefined PCC rules: one set for UEs with 3GPP PS Data Off status "inactive", the second set for UE camping in the HPLMN with 3GPP PS Data Off status "active", and the third set for UEs camping in the VPLMN with 3GPP PS Data Off status "active". The set of predefined PCC rules for UE 3GPP PS Data Off status "active" can be equivalent to the set of predefined PCC rules for UE 3GPP PS Data Off status "inactive" with the following two differences: All services belonging to the list of 3GPP PS Data Off Exempt Services can be represented by PCC rule(s) which allows the traffic to pass while in all other PCC rules (not belonging to the list of 3GPP PS Data Off Exempt Services) the gate status can be "closed" for the downlink direction. When the PCEF is informed about the change of UE 3GPP PS Data Off status, it can replace the currently active set of predefined PCC rules with the other set of predefined PCC rules.

When the UE 3GPP PS Data Off status is "active" and a handover from one access-system to another occurs, the PCRF performs the above operations so that the downlink traffic for services not belonging to the list of 3GPP PS Data Off Exempt Services is only prevented via the 3GPP access.

When NBIFOM applies for the IP-CAN session, the PCRF shall not modify PCC rules associated to the IP-CAN type "Non 3GPP EPS".