6.2.1 Policy Control and Charging Rules Function (PCRF)

23.2033GPPPolicy and charging control architectureRelease 17TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

6.2.1.0 General

The PCRF encompasses policy control decision and flow based charging control functionalities.

The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF and/or TDF.

The PCRF provides network control regarding the application detection, gating, QoS and application based charging (except credit management) towards the TDF and the PCEF enhanced with ADC.

The PCRF shall apply the security procedures, as required by the operator, before accepting service information from the AF.

The PCRF shall decide whether application traffic detection is applicable, as per operator policies, based on user profile configuration, received within subscription information.

The PCRF shall decide how certain service/application traffic shall be treated in the PCEF and in the TDF, if applicable, and ensure that the PCEF user plane traffic mapping and treatment is in accordance with the user’s subscription profile.

If Gxx applies, the PCRF shall provide QoS rules with identical service data flow templates as provided to the PCEF in the PCC rules. If the service data flow is tunnelled at the BBERF, the PCRF shall provide the BBERF with information received from the PCEF to enable the service data flow detection in the mobility tunnel at the BBERF. In case 2a, defined in clause 7.1, the PCRF may also provide to the BBERF the charging ID information received from the PCEF. If IP flow mobility as specified in TS 23.261 [23] applies, the PCRF shall, based on IP flow mobility routing rules received from the PCEF, provide the authorized QoS rules to the applicable BBERF as specified in clause 6.1.1.3.

The PCRF should for an IP‑CAN session derive, from IP‑CAN specific restrictions, operator policy and SPR data, the list of permitted QoS class identifiers and associated GBR and MBR limits for the IP‑CAN session.

The PCRF may check that the service information provided by the AF is consistent with both the operator defined policy rules and the related subscription information as received from the SPR during IP‑CAN session establishment before storing the service information. The service information shall be used to derive the QoS for the service. The PCRF may reject the request received from the AF when the service information is not consistent with either the related subscription information or the operator defined policy rules and as a result the PCRF shall indicate that this service information is not covered by the subscription information or by operator defined policy rules and may indicate, in the response to the AF, the service information that can be accepted by the PCRF (e.g. the acceptable bandwidth). In the absence of other policy control mechanisms outside the scope of PCC, it is recommended that the PCRF include this information in the response.

When receiving service information from the AF, the PCRF may temporarily reject the AF request (e.g. if the service information is not consistent with the operator defined policy rules for the congestion status of the user). To temporarily reject the AF request the PCRF shall indicate a re-try interval to the AF. When receiving a re-try interval from the PCRF the AF shall not send the same service information to the PCRF again (for the same IP‑CAN session) until the re-try interval has elapsed.

NOTE 1: How the PCRF derives the re-try interval is up to implementation.

In this Release, the PCRF supports only a single Rx reference point, i.e. there is one AF for each AF session.

The PCRF authorizes QoS resources. The PCRF uses the service information received from the AF (e.g. SDP information or other available application information) and/or the subscription information received from the SPR to calculate the proper QoS authorization (QoS class identifier, bitrates). The PCRF may also take into account the requested QoS received from the PCEF via Gx interface.

NOTE 2: The PCRF provides always the maximum values for the authorized QoS even if the requested QoS is lower than what can be authorized.

The Authorization of QoS resources shall be based on complete service information unless the PCRF is required to perform the authorization of QoS resources based on incomplete service information. The PCRF shall after receiving the complete service information, update the affected PCC rules accordingly.

The PCRF may use the subscription information as basis for the policy and charging control decisions. The subscription information may apply for both session based and non-session based services.

The PCRF determines whether a Gx session from the PCEF is to be linked with a Gateway Control Session from the BBERF by matching the IPv4 address and/or IPv6 network prefix and conditionally the UE Identity, PDN Connection ID and PDN ID towards open Gateway Control Sessions. When IP flow mobility as specified in TS 23.261 [23] applies, one Gx session may be linked with multiple Gateway Control Sessions.

If the BBERF does not provide any PDN ID at the Gateway Control Session Establishment, then the PCRF maintains Gateway Control Session to Gx session linking to the Gx sessions where the assigned CoA and UE Identity (if available over Gxx) are equal. The PCRF and BBERF shall be capable of separating information for each IP‑CAN session within the common Gateway Control Session.

If the BBERF provides a PDN ID at the Gateway Control Session Establishment, then the PCRF maintains Gateway Control Session to Gx session linking where the UE identity and PDN ID are equal. If the BBERF provides a PDN ID at Gateway Control Session establishment, it may also indicate in the Gateway Control Session establishment that the PCRF shall not attempt linking the new Gateway Control Session with an existing Gx session immediately. If the PCRF receives such an indication, it keeps the new Gateway Control Session pending and defers linking until an IP-CAN session establishment or an IP-CAN session modification with matching UE Identity, PDN ID and IP-CAN type arrives via Gx.

If the BBERF provides a PDN ID and a PDN Connection ID at the Gateway Control Session establishment, then the PCRF maintains Gateway Control Session to Gx session linking where the UE identity, PDN Connection ID and PDN ID are equal.

When a BBERF establishes multiple Gateway Control Sessions for the same PDN ID and the IP‑CAN type changes, the PCRF assumes that this constitutes inter-system BBERF relocations of existing Gateway Control Sessions. The BBERF may supply UE IPv4 address and/or IPv6 network prefix (if known) that can be used for linking the new Gateway Control Session to the existing Gx session. If the UE IPv4 address and/or IPv6 network prefix is/are not provided in the new Gateway Control Session establishment, the PCRF shall defer the linking with existing Gx session until receiving an IP-CAN Session modification with matching UE Identity, IP‑CAN type, PDN Connection ID, and PDN ID.

The PCRF determines which case applies as described on clause 7.1.

If an AF requests the PCRF to report on the signalling path status, for the AF session, the PCRF shall, upon indication of loss of resources from the PCEF, for PCC rules corresponding to the signalling traffic notify the AF on changes to the signalling path status. The PCRF needs to have the knowledge of which PCC rules identify signalling traffic.

Negotiation of IP‑CAN bearer establishment mode takes place via Gx for 3GPP IP‑CANs. For non-3GPP IP‑CANs specified in TS 23.402 [18] negotiation of bearer establishment mode takes place via Gx when GTP is used and via Gxx for the rest of the cases. For other accesses supporting multiple IP‑CAN bearer establishment modes, if Gxx applies, the negotiation takes place via Gxx, otherwise via Gx. To support the different IP‑CAN bearer establishment modes (UE-only or UE/NW) the PCRF shall:

– shall set the IP‑CAN bearer establishment mode for the IP‑CAN session based on operator configuration, network and UE capabilities;

– shall, if the bearer establishment mode is UE/NW, decide what mode (UE or NW) shall apply for a PCC rule and resolve race conditions between for requests between UE-initiated and NW-initiated requests;

NOTE 3: For an operator-controlled service, the UE and the PCRF may be provisioned with information indicating which mode is to be used.

– may reject a UE request that is already served by a NW-initiated procedure in progress. When rejecting a UE-initiated request by sending a reject indication, the PCRF shall use an appropriate cause value which shall be delivered to the UE.

NOTE 4: This situation may e.g. occur if the PCRF has already triggered a NW-initiated procedure that corresponds to the UE request.

– guarantee the precedence of dynamic PCC rules with SDF template containing SDF filter(s) (and optionally also for SDF templates consisting of an application identifier) for network controlled services in the service data flow detection process at the PCEF by setting the PCC rule precedence information to appropriate values.

If an AF requests the PCRF to report on the change of type of IP‑CAN, the PCRF shall provide to the AF the information about the IP‑CAN type the user is currently using and upon indication of change of IP‑CAN type, notify the AF on changes of the type of IP‑CAN. In the case of 3GPP IP‑CAN, the information of the Radio Access Technology Type (e.g. UTRAN) shall be also reported to the AF. If IP flow mobility as specified in TS 23.161 [43] or in TS 23.261 [23] applies, the PCRF shall provide to the AF the new IP-CAN type information together with the affected service information. When IP flow mobility is allowed within an IP‑CAN session, the PCRF shall only report to an AF the IP‑CAN type change when the IP flow mobility applies to the service information provided by this AF.

NOTE 5: The PCRF can also use the dynamic or pre-defined PCC Rules related to the IMS signalling to request Access Network Information reporting. This can be used to support e.g., regulatory requirements for SMS over IP, where the IMS network (i.e. P‑CSCF) needs to retrieve the user location and/or UE Time Zone information. Note that due to regulatory requirements, the Access Network Information can be requested for SMS over IP, impacting a large number of PDN Connections, that can lead to significant increase in signalling load when the Access Network Information is requested from the Access Node (e.g. MME).

If an AF requests the PCRF to report Access Network Information, the PCRF shall set the Access Network Information report parameters in the corresponding PCC rule(s) or QoS rule(s) and provision them together with the corresponding event trigger to the PCEF or BBERF as per procedure in clause 7.4.2. For those PCC rule(s) or QoS rule(s) based on preliminary service information the PCRF may assign the QCI and ARP of the default bearer to avoid signalling to the UE. In addition the SDF filter(s) shall not be marked as to be used for signalling to the UE as traffic mapping information.

If an AF requests the PCRF to report Access Network Information, The PCRF shall also set the corresponding event trigger to the PCEF or BBERF as per procedure in clause 7.4.2. The PCRF shall, upon receiving the subsequent Access Network Information report corresponding to the AF session from the PCEF or BBERF, forward the Access Network Information as requested by the AF.

If an AF requests the PCRF to report the PLMN identifier where the UE is currently located, then the PCRF shall provide the PLMN identifier to the AF if available.Otherwise, the PCRF shall provision both the corresponding PCC rules and QoS Rules if applicable, and the event trigger to report PLMN change to the PCEF. The PCRF shall, upon receiving of the PLMN identifier from the PCEF forward this information to the AF as defined in the procedures in clause 6.1.4.

If an AF requests the PCRF to report Access Network Charging Correlation Information, the PCRF shall provide to the AF the Access Network Charging Correlation Information, which will identify the usage reports that include measurement for the flows, once the Access Network Charging Correlation Information is known at the PCRF. If not known in advance, the PCRF subscribes for the Access Network Charging Correlation Information event for the applicable PCC rule(s), unless a single charging identifier per IP-CAN session is used as described below.

The PCEF provides at IP‑CAN session establishment both a charging identifier and an optional indication that the charging identifier is the only one for that IP‑CAN session, as defined in clause 5.1.3 of TS 32.251 [9]. In absence of the indication there is a separate charging identifier for each IP‑CAN bearer to identify usage reports that include measurements for flows served by each individual bearer. When the PCEF indicates that a single charging identifier is used for the IP‑CAN session, the PCRF uses the charging identifier received at IP‑CAN session establishment to provide Access Charging Correlation information to the AF for all flows, instead of subscribing to the Access Network Charging Correlation Information event trigger for the applicable PCC Rule(s) as described above.

If Gxx applies and the PCEF provided information about required event triggers, the PCRF shall provide these event triggers to the BBERF and notify the PCEF of the outcome of the provisioning procedure by using the PCRF initiated IP‑CAN Session Modification procedure, as defined in clause 7.4.2. The PCRF shall include the parameter values received in the response from the BBERF in the notification to the PCEF. When multiple BBERFs exist (e.g. in IP flow mobility case), the PCEF may subscribe to different or common set of event triggers at different BBERFs; when the PCRF receives event notification from any BBERF, the PCRF shall include both the parameters values received from the BBERF and also the information for identifying the BBERF in the notification to the PCEF.

If Sd applies and the TDF provided information about required event triggers, the PCRF shall provide these event triggers to the PCEF or BBERF, if Gxx applies, and notify the TDF of the outcome of the provisioning procedure within the PCEF initiated IP‑CAN Session Modification procedure, as defined in clause 7.4.1. The PCRF shall include the parameter values, received in the response from the PCEF/BBERF, in the notification to the TDF. The relevant Event Triggers are: PLMN change, Location change, Change in type of IP‑CAN, RAT type change, SGSN change, Serving GW change, User CSG Information change in CSG cell, User CSG Information change in subscribed hybrid cell, User CSG Information change in un-subscribed hybrid cell, Change of UE presence in Presence Reporting Area.

NOTE 6: For IP flow mobility feature enabled, the TDF doesn’t have accurate information about the location and the type of RAT the user is attached to.

When the PCRF gets an event report from the BBERF that is required by the PCEF, the PCRF shall forward this event report to the PCEF.

When the PCRF gets an Event Report from the PCEF/BBERF that is required by the TDF, the PCRF shall forward this Event Report to the TDF.

The PCRF may support usage monitoring control. Usage is defined as either volume or time of user plane traffic.

The PCRF may receive information about total allowed usage per PDN and UE from the SPR, i.e. the overall amount of allowed resources (based either on traffic volume and/or traffic time) that are to be monitored for the PDN connections of a user. In addition information about total allowed usage for Monitoring key(s) per PDN and UE may also be received from the SPR. For the purpose of usage monitoring per access type , the PCRF receives an individual Monitoring key per access type from SPR.

For the purpose of usage monitoring control the PCRF shall request the Usage report trigger and provide the necessary usage threshold(s), either volume threshold, time threshold, or both volume threshold and time threshold, upon which the requested node (PCEF or TDF) shall report to the PCRF. The PCRF shall decide if and when to activate usage monitoring to the PCEF and TDF.

The PCRF may provide a Monitoring time to the PCEF/TDF for the Monitoring keys(s) and optionally specify a subsequent threshold value for the usage after the Monitoring time.

If the PCEF reports usage before the Monitoring time is reached, the Monitoring time is not retained by the PCEF. Therefore the PCRF may again provide a Monitoring time and optionally the subsequent threshold value for the usage after the Monitoring time in the response.

It shall be possible for the PCRF to request a usage report from the requested node (PCEF or TDF).

NOTE 7: The PCRF ensures that the number of requests/following policy decisions provided over Gx/Sd reference point do not cause excessive signalling load by e.g. assigning the same time for the report only for a preconfigured number of IP-CAN/TDF sessions.

Once the PCRF receives a usage report from the requested node (PCEF or TDF) the PCRF shall deduct the value of the usage report from the totally allowed usage for that PDN and UE (in case usage per IP-CAN session is reported). If usage is reported from the TDF or the PCEF, the PCRF shall deduct the value of the usage report from the totally allowed usage for individual Monitoring key(s) for that PDN and UE (in case of usage for one or several Monitoring keys is reported).

NOTE 8: The PCRF maintains usage thresholds for each Monitoring key and IP‑CAN session that is active for a certain PDN and UE. Updating the total allowanced usage after the PCEF reporting, minimizes the risk of exceeding the usage allowance.

If the PCEF or TDF reports usage for a certain Monitoring key and if monitoring shall continue for that Monitoring key then the PCRF shall provide new threshold value(s) in the response to the PCEF or TDF respectively. If Monitoring time and subsequent threshold value are used then the PCRF provides them to the PCEF or TDF as well.

The PCRF may provide a new volume threshold and/or a new time threshold to the PCEF or TDF, the new threshold values overrides the existing threshold values in the PCEF or TDF.

If monitoring shall no longer continue for that Monitoring key, then the PCRF shall not provide a new threshold in the response to the PCEF / TDF.

NOTE 9: If the PCRF decides to deactivate all PCC rules or ADC rules associated with a certain Monitoring key, then the conditions defined in clause 6.6.2 for continued Monitoring will no longer be fulfilled for that Monitoring key.

If all IP-CAN session of a user to the same APN is terminated, the PCRF shall store the remaining allowed usage, i.e. the information about the remaining overall amount of resources, in the SPR.

The PCRF may authorise an application service provider to request specific PCC decisions (e.g. authorisation to request sponsored IP flows, authorisation to request QoS resources). For sponsored data connectivity (see Annex N), the PCRF may receive a usage threshold from the AF.

If the AF specifies a usage threshold, the PCRF shall use the Sponsor Identity to construct a Monitoring key for monitoring the volume, time, or both volume and time of user plane traffic, and invoke usage monitoring on the PCEF/TDF. The PCRF shall notify the AF when the PCEF/TDF reports that a usage threshold for the Monitoring key is reached provided that the AF requests to be notified for this event. If the usage threshold is reached, the AF may terminate the AF session or provide a new usage threshold to the PCRF. Alternatively, the AF may allow the session to continue without specifying a usage threshold. If the AF decides to allow the session to continue without specifying a usage threshold, then monitoring in the PCEF/TDF shall be discontinued for that monitoring key by the PCRF, unless there are other reasons for continuing the monitoring.

If the AF revokes the service information and the AF has notified previously a usage threshold to the PCRF, the PCRF shall report the usage up to the time of the revocation of service authorization.

If the IP-CAN session terminates and the AF has specified a usage threshold then the PCRF shall notify the AF of the accumulated usage (i.e. either volume, or time, or both volume and time) of user plane traffic since the last usage report.

The PCRF performs authorizations based on sponsored data connectivity profiles stored in the SPR. If the AF is in the operator’s network and is based on the OSA/Parlay-X GW (TS 23.198 [24]), the PCRF is not required to verify that a trust relationship exists between the operator and the sponsors.

If the H-PCRF detects that the UE is accessing the sponsored data connectivity in the roaming scenario with home routed access, it may allow the sponsored data connectivity in the service authorization request, reject the service authorization request, or initiate the AF session termination based on home operator policy.

NOTE 10: Sponsored data connectivity is not supported in the roaming with visited access scenario in this Release.

If the AF request includes an AF application identifier then, based on the operator policies the PCRF may trigger the activation of a predefined PCC/ADC Rule or provide a dynamic PCC/ADC rule with an appropriate application identifier in the PCEF/TDF.

For the solicited application reporting, it is PCRF’s responsibility to coordinate the PCC rules and QoS rules, if applicable, with ADC rules in order to ensure consistent service delivery.

The PCRF uses the information relating to subscriber spending available in the OCS as input for policy decisions related to e.g. QoS control, gating or charging conditions.

The PCRF uses the RUCI received from the RCAF as input for policy decisions.

If the AF contacts the PCRF via the SCEF (and the Nt interface) to request a time window and related conditions for future background data transfer, the PCRF shall determine possible transfer policies (as described in clause 6.1.16) and send them to the AF together with a reference ID. If the AF received more than one transfer policy, the AF selects one of them and informs the PCRF about the selected transfer policy. The PCRF shall store the selected transfer policy in the SPR together with the reference ID and the network area information. Whenever the PCRF receives a reference ID from the AF during a subsequent transfer of AF session information (via the Rx interface), the PCRF shall retrieve the corresponding transfer policy from the SPR and apply it as one of the inputs for policy decisions for this IP-CAN session.

The PCRF uses one or more pieces of information defined in the clause 6.2.1.1 as input for the selection of traffic steering policies used to control the steering of the subscriber’s traffic to appropriate (S)Gi-LAN service functions.

NOTE 11: In order to allow the PCRF to select and provision an application based traffic steering policy, the reporting of detected applications to the PCRF or any other information such as the RAT type, the RUCI etc. defined in clause 6.2.1.1 can be used.

At reception of the IMS service information from the P-CSCF, if configured through policy, the PCRF determines the Maximum Packet Loss Rate for UL and DL based on the IMS service information and taking into account information defined in TS 26.114 [45] and sends it to PCEF along with the PCC rule for the voice media.

NOTE 12: Based on local configuration, the PCRF sets the Maximum Packet Loss Rate (UL, DL) corresponding to either the most robust codec configuration (e.g., codec, mode, redundancy) or the least robust codec configuration of the negotiated set in each direction.

6.2.1.1 Input for PCC decisions

The PCRF shall accept input for PCC decision-making from the PCEF, the BBERF if present, the TDF if present, the SPR and if the AF is involved, from the AF, as well as the PCRF may use its own predefined information. These different nodes should provide as much information as possible to the PCRF. At the same time, the information below describes examples of the information provided. Depending on the particular scenario all the information may not be available or is already provided to the PCRF.

The PCEF and/or BBERF may provide the following information:

– Subscriber Identifier;

– The IMEI(SV) of the UE;

– IPv4 address of the UE;

– IPv6 network prefix assigned to the UE;

– NBIFOM Routing Rules (when NBIFOM as specified in TS 23.161 [43] applies);

– IP flow routing information (when IP flow mobility as specified in TS 23.261 [23] applies);

NOTE 1: IP flow routing information and NBIFOM Routing Rules are provided only by the PCEF.

– Change of usability of an Access (when NBIFOM as specified in TS 23.161 [43] applies);

– IP‑CAN bearer attributes;

NOTE 2: If IP flow mobility as specified in TS 23.161 [43] or in TS 23.261 [23] applies, an IP-CAN session may be active over multiple accesses and thus some IP‑CAN bearer attributes may have a different value depending on the access type;

– Request type (initial, modification, etc.);

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

NOTE 3: The Type of IP‑CAN parameter should allow extension to include new types of accesses.

– Location of the subscriber;

NOTE 4: See clause 6.1.4 for the description of this location information.

NOTE 5: Depending on the type of IP‑CAN, the limited update rate for the location information at the PCEF may lead to a UE moving outside the area indicated in the detailed location information without notifying the PCEF.

– A PDN ID;

– A PLMN identifier;

– IP‑CAN bearer establishment mode;

– 3GPP PS Data Off status.

The PCEF enhanced with ADC or the TDF may provide the following information:

– Detected application identifier;

– Allocated application instance identifier;

– Detected service data flow descriptions.

The SPR may provide the following information for a subscriber, connecting to a specific PDN:

– Subscriber’s allowed services, i.e. list of Service IDs;

– For each allowed service, a pre-emption priority;

– Information on subscriber’s allowed QoS, including:

– the Subscribed Guaranteed Bandwidth QoS;

– a list of QoS class identifiers together with the MBR limit and, for real-time QoS class identifiers, GBR limit.

– Subscriber’s charging related information;

– Spending limits profile containing an indication that policy decisions depend on policy counters available at the OCS that has a spending limit associated with it and optionally the list of relevant policy counters.

– Subscriber category;

– Subscriber’s usage monitoring related information;

– Subscriber’s profile configuration;

– Sponsored data connectivity profiles;

– MPS EPS Priority, MPS Priority Level (See TS 23.401 [17] for more detail on MPS Subscription);

– IMS Signalling Priority.

NOTE 6: The MPS Priority Level represents user priority.

NOTE 7: The MPS Priority Level is one among other input data such as operator policy for the PCRF to set the ARP value. The MPS EPS Priority, and MPS Priority Level are consistent with the corresponding parameters defined in the HSS.

The SPR may provide the following policy information related to an ASP (see clause 6.1.16):

– The ASP identifier;

– A transfer policy together with a reference ID, the volume of data to be transferred per UE, the expected amount of UEs and the network area information.

The AF, if involved, may provide the following application session related information, e.g. based on SIP and SDP:

– Subscriber Identifier;

– IP address of the UE;

– Media Type;

– Media Format, e.g. media format sub-field of the media announcement and all other parameter information (a= lines) associated with the media format;

– Bandwidth;

– Sponsored data connectivity information (see clause 5.2.1);

– Flow description, e.g. source and destination IP address and port numbers and the protocol;

– AF application identifier;

– AF Communication Service Identifier (e.g. IMS Communication Service Identifier), UE provided via AF;

– AF Application Event Identifier;

– AF Record Information;

– Flow status (for gating decision);

– Priority indicator, which may be used by the PCRF to guarantee service for an application session of a higher relative priority;

NOTE 8: The AF Priority information represents session/application priority and is separate from the MPS EPS Priority indicator.

– Emergency indicator;

– Indicator for Restricted Local Operator Services;

– Application service provider.

NOTE 9: The application service provider may be identified in numerous forms e.g. the AF application identifier or the host realm at Diameter level.

The OCS, if involved, may provide the following information for a subscriber:

– Policy counter status for each relevant policy counter.

The RCAF, if involved, may provide the following information for a subscriber:

– Subscriber Identifier.

– Identifier of the eNB, E-UTRAN cell or Service Area serving the subscriber.

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

NOTE 11: Depending on the RUCI reporting interval configured in the RCAF, a UE may move outside the area indicated without the RCAF immediately notifying the PCRF. The PCRF can avoid receiving information about the cell currently serving a UE from multiple sources (i.e. via the Np and the Gx interface) by deactivating reporting of the congested cell’s identifier over Np. In case PCRF receives information about the cell currently serving a UE via Np and Gx, then the information received via Gx is expected to take precedence.

– APNs.

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

In addition, the predefined information in the PCRF may contain additional rules based on charging policies in the network, whether the subscriber is in its home network or roaming, depending on the IP‑CAN bearer attributes.

The QoS Class Identifier (see clause 6.3.1) in the PCC rule is derived by the PCRF from AF or SPR interaction if available. The input can be SDP information or other available application information, in line with operator policy.

The Allocation/Retention Priority in the PCC Rule is derived by the PCRF from AF or SPR interaction if available, in line with operator policy.

6.2.1.2 Subscription information management in the PCRF

The PCRF may request subscription information from the SPR for an IP‑CAN session at establishment or a gateway control session at establishment. The subscription information may include user profile configuration indicating whether application detection and control should be enabled. The PCRF should specify the subscriber ID and, if available, the PDN identifier in the request. The PCRF should retain the subscription information that is relevant for PCC decisions until the IP‑CAN session termination and the gateway control session termination.

The PCRF may request notifications from the SPR on changes in the subscription information. Upon reception of a notification, the PCRF shall make the PCC decisions necessary to accommodate the change in the subscription and updates the PCEF and/or the BBERF and/or the TDF by providing the new PCC and/or QoS and/or ADC decisions if needed. The PCRF shall send a cancellation notification request to the SPR when the related subscription information has been deleted.

6.2.1.3 V-PCRF

6.2.1.3.1 General

The V-PCRF (Visited-Policy and Charging Rules Function) is a functional element that encompasses policy and charging control decision functionalities in the V-PLMN. The V-PCRF includes functionality for both home routed access and visited access (local breakout).

The V‑PCRF determines based on the subscriber identity if a request is for a roaming user.

A Gateway Control Session request received over the Gxx reference point may trigger a request over the S9 reference point from the V‑PCRF to the H‑PCRF.

If a Gateway Control Session establishment request is received that can not be bound to an existing Gx session then the associated IP‑CAN session is either home routed or it is visited access but the IP‑CAN session establishment request has not yet been received over Gx.

For this case the V-PCRF may determine based on PDN-Id carried in the GW control session and roaming agreements if the request shall be proxied to the H‑PCRF over S9 or not. The V-PCRF may choose not to proxy the Gateway Control Session Establishment only if the PDN-Id indicates the request is for visited access.

The Gateway Control Session Establishment request should only be proxied to the H‑PCRF over S9 in case the V‑PCRF is configured to do so e.g. based on roaming agreement.

NOTE: Proxying the Gateway Control Session Establishment makes the H‑PCRF aware of the Gateway Control Session and enables binding in case a subsequent IP‑CAN Session is established with home routed access or visited access.

If the V‑PCRF determines that a Gateway Control Session Establishment shall be proxied to the H‑PCRF over S9 then the reply from the H‑PCRF shall also be communicated back to the GW (BBERF) over Gxx.

In case the V‑PCRF determines that a Gateway Control Session Establishment request shall not be proxied, then the V‑PCRF shall respond to the request made by the GW (BBERF) without notifying the H‑PCRF.

If an IP‑CAN session establishment request is received for a roaming user over the Gx reference point, then the V‑PCRF shall conclude that the IP‑CAN session use visited access and act as described in clause 6.2.1.3.3.

NOTE 2: Through roaming agreement, the HPLMN operator may allow the VPLMN operator to operate the V‑PCRF without using the capabilities described in clause 6.2.1.3.3 (i.e. no S9 is used). In such case, the PCRF in the VPLMN has no access to subscriber policy information from the HPLMN, only static policies will apply based on roaming agreements. The VPCRF may also interact with the AF in the VPLMN in order to generate PCC Rules for services delivered via the VPLMN. V-PCRF uses locally configured policies according to the roaming agreement with the HPLMN operator as input for PCC Rule generation.

If a Gateway Control and QoS rules provision is received by the V‑PCRF over the S9 reference point for a Gateway Control session which is not associated, at the V-PCRF, with an existing Gx session, the V‑PCRF shall conclude that the IP‑CAN session associated with the Gateway Control session is home routed, and act as described in clause 6.2.1.3.2.

6.2.1.3.2 V-PCRF and Home Routed Access

The V-PCRF provides functions to proxy Gxx interactions between the BBERF and the H-PCRF as follows:

– Gateway Control Session establishment and termination;

– Gateway Control and QoS Policy Rules Provision;

– Gateway Control and QoS Rule Request.

The V-PCRF provides functions to enforce visited operator policies regarding QoS authorization requested by the home operator as indicated by the roaming agreements. The V-PCRF informs the H-PCRF when a request has been denied and may provide the acceptable QoS Information.

Within an IP‑CAN session, a different V-PCRF may be selected when a new Gateway Control Session is established.

6.2.1.3.3 V-PCRF and Visited Access (local breakout)

The V-PCRF provides functions to:

– Enforce visited operator policies regarding QoS authorization requested by the home operator e.g. on a per QCI or service basis as indicated by the roaming agreements. The V-PCRF informs the H-PCRF when a request has been denied and may provide the acceptable QoS Information for the service.

– When Gxx interaction is terminated locally at the V-PCRF, perform Gx to Gateway Control Session linking.

‑ When Gxx interaction is terminated locally at the V-PCRF, extract QoS rules (defined in clause 6.5) from PCC rules (defined in clause 6.3) provided by the H‑PCRF over the S9 reference point. The V‑PCRF provides updated PCC rules to the PCEF and QoS rules to the BBERF, if appropriate.

‑ For the case of AF in the VPLMN:

‑ Proxy Rx authorizations over the S9 reference point to the H‑PCRF;

‑ Relay event subscriptions and notifications between the H‑PCRF and V‑AF

When Gx interactions are proxied between the PCEF and the H-PCRF, the V-PCRF proxies:

– Indication of IP‑CAN Session Establishment and Termination;

– Policy and Charging Rule Provisioning;

– Request Policy and Charging Rules.

If a Gateway Control Session is used and if during the IP‑CAN Session Establishment the Gateway Control Session Establishment procedure was proxied to the H‑PCRF (according to the logic in clause 6.2.1.3.1), then the V‑PCRF shall also proxy all other Gateway Control Session procedures to the H‑PCRF.

If the Gateway Control Session was not proxied to the H‑PCRF then the V‑PCRF shall handle all Gateway Control Session procedures locally and not proxy them to the H‑PCRF. This has the following implications:

‑ An IP‑CAN Session modification may trigger the V‑PCRF to update the Gateway Control Session if required in order to maintain the alignment of PCC and QoS Rules.

‑ An IP‑CAN Session termination procedure may trigger the V‑PCRF to terminate the Gateway Control Session if the Gateway Control Session was established for the purpose of a single IP‑CAN session. Otherwise a Gateway Control and QoS Rules Provision procedure may be initiated to remove the QoS Rules associated with the IP‑CAN session.

‑ On receiving a Gateway Control and QoS Rules Request message from the BBERF, the V-PCRF performs the procedure described in clause 7.7.3.2 for the event reporting for PCEF in visited network and locally terminated Gxx interaction.

NOTE 1: The V-PCRF has to set the event triggers at the PCEF in a way that the PCEF would trigger a PCEF initiated IP‑CAN Session Modification Procedure if an interaction with the H-PCRF is required.

When Rx components are proxied between an AF in the VPLMN and the H‑PCRF, the V‑PCRF shall proxy service session information between the AF and the H‑PCRF.

The V-PCRF shall support functionality to generate ADC rules from the PCC rules providing application detection and control as instructed by the H‑PCRF over S9. The V‑PCRF shall provide updated PCC Rules to the PCEF, and generated ADC rules to the TDF, as appropriate in the VPLMN configuration.

NOTE 2: There may be situations where the TDF or PCEF enhanced with ADC is not able to detect the traffic requested by the H-PCRF. Prior agreements could be arranged to ensure that there is a common understanding of the meaning of application identifiers transferred between PLMNs.

The V‑PCRF shall install the event triggers in the PCEF, in the TDF and in the BBERF that were provided for the IP‑CAN session and install additional event triggers in the BBERF that are relevant only to the PCEF (i.e. such event triggers are typically set by the OCS) or the TDF. On receiving an Event report from the PCEF/BBERF, the V-PCRF forwards it to the TDF, if TDF has previously subscribed for it.

NOTE 3: Event reports over Gxx that are relevant only to the PCEF will not trigger a PCEF initiated IP‑CAN session modification procedure.

For UEs in a local breakout scenario, the RCAF may contact the V-PCRF with the RUCI information. Congestion information shall not be exposed via the S9 interface.

Within an IP‑CAN session the same V-PCRF remains for the whole lifetime of the IP‑CAN session.

6.2.1.4 H-PCRF

6.2.1.4.1 General

The H‑PCRF (Home‑Policy and Charging Rules Function) is a functional element that encompasses policy and charging control decision functionalities in the H‑PLMN and in the VPLMN. The H‑PCRF includes functionality for both home routed access and visited access (local breakout).

If a Gateway Control Session is used and a Gateway Control Session Establishment is indicated over S9, then one or more of the following cases applies:

1. One (or several) home routed IP‑CAN sessions are known to the H‑PCRF that can be bound to the Gateway Control session. For such IP‑CAN sessions, the H‑PCRF shall act as described in clause 6.2.1.4.2.

2. No IP‑CAN session is known to the H‑PCRF that can be bound to the Gateway Control session. This is the case when an IP‑CAN session establishment process has not yet been initiated over Gx or S9.

If an IP‑CAN Session Establishment is received over Gx then the H‑PCRF shall conclude that the IP‑CAN session is home routed and act as described in clause 6.2.1.4.2.

If an IP‑CAN Session Establishment is received over S9 then the H‑PCRF shall conclude that the IP‑CAN session use visited access and act as described in clause 6.2.1.4.3.

6.2.1.4.2 H-PCRF and Home Routed Access

The H‑PCRF shall use the S9 reference point to proxy information to the BBERF via the V‑PCRF for the following related Gxx procedures:

‑ Gateway Control Session establishment and termination;

‑ Gateway Control and QoS Policy Rules Provision;

‑ Gateway Control and QoS Rule Request.

If an IP‑CAN session termination is received over the Gx reference point, then the H‑PCRF shall initiate a Gateway Control Session Termination procedure over S9 if the Gateway Control Session was established for the purpose of a single IP‑CAN session. Otherwise a Gateway Control and QoS Rules Provision procedure may be initiated over S9 to remove the QoS Rules in the BBERF associated with the IP‑CAN session.

6.2.1.4.3 H-PCRF and Visited Access (Local Breakout)

The H‑PCRF shall use the S9 reference point to proxy information to the PCEF (and indirectly also to the BBERF when the Gateway Control Session is not proxied to the H-PCRF, and indirectly also to the TDF) via the V‑PCRF for the following related Gx procedures:

– Indication of IP‑CAN Session Establishment and Termination messages;

– Policy and Charging Rule Provisioning messages;

– Request Policy and Charging Rules messages.

When the Gateway Control Session is proxied to the H-PCRF, the H PCRF shall use the S9 reference point to proxy information to the BBERF via the V PCRF for the following related Gxx procedures:

– Indication of Gateway Control Session Establishment and Termination messages;

– QoS Rules Provisioning messages;

– Request QoS Rules messages.

The H-PCRF shall generate PCC rules for application traffic detection, notification and policy control when the TDF is located in the VPLMN.

The H‑PCRF should generate PCC rules for both of the cases when the AF is located in the VPLMN and when the AF is located in the HPLMN. The H‑PCRF provides the PCC rules to the V‑PCRF over the S9 reference point.

6.2.1.5 Handling of Multiple BBFs associated with the same IP‑CAN session

6.2.1.5.1 Handling of two BBFs associated with the same IP-CAN session during handover

The procedures specified in this clause apply when the case of multiple BBFs occurs during handovers. The two BBFs can be located in two separate BBERFs, or one BBF is located in the PCEF and the other one in a BBERF. If the PCRF determines that there is more than one BBF associated with the same IP‑CAN session, the PCRF handles the multiple BBFs as follows:

– The PCRF classifies the BBERF which reports the same IP‑CAN type as that reported by the PCEF as the primary BBERF and a BBERF that reports an IP‑CAN type different from that reported by the PCEF as non-primary BBERF. If there are more than one BBERFs that report the same IP‑CAN type as that reported by the PCEF, the BBERF that last created the GW Control Session with the PCRF is classified as the primary BBERF and other BBERF(s) are classified as non-primary BBERF(s).

NOTE 1: During handover where the BBF moves from a BBERF to the PCEF (e.g. handover from PMIP to GTP), when the PCEF reports a new IP-CAN type, the BBERF is classified as a non-primary BBERF. There is no primary BBERF but the active BBF is in the PCEF.

NOTE 2: During handover where the BBF moves from the PCEF to a BBERF (e.g. handover from GTP to PMIP), when the BBERF creates a Gateway Control Session, it is classified as a non-primary BBERF. This BBERF subsequently gets classified as the primary BBERF when the PCEF reports an IP‑CAN type which is the same as that reported by the BBERF.

– When a new (primary/non-primary) BBERF supporting NW/UE bearer establishment mode creates a GW Control session, the PCRF provides to the new BBERF QoS rules corresponding to SDFs. For a change of IP‑CAN type, the QoS parameters of some of the QoS rules may be changed or some QoS rules may not be provided to the new BBERF, e.g. depending of the capability of the target RAT. When a new (primary/non-primary) BBERF supporting only UE bearer establishment mode creates a GW Control session, the PCRF authorizes the setup of the default bearer and only pushes down QoS rules in response to specific requests from the BBERF.

NOTE 3: After completion of the handover procedure to the new BBERF, the UE can still initiate the access specific procedures to modify or release the resources that were originally allocated based on UE-initiated resource allocation. Such operations and the associated changes to QoS rules are handled following the normal UE-initiated resource management procedures.

NOTE 4: To facilitate the UE’s determination of QoS resources in the target access allocated to pre-existing IP flows the access system is required to provide packet filters with the same content as that in the SDF template filters received over the Gx/Gxx interface (see clause 6.1.9).

– If the BBF is located in any of the BBERF, the PCRF keeps track of QoS rules activation by all the BBERFs. The PCRF updates PCC rules to the PCEF based on activation status of QoS rules in the primary BBERF.

– If the primary-BBERF reports failure to activate a QoS rule, the PCRF also removes the same QoS rule from the non-primary BBERFs, if any are already installed, and the corresponding PCC rule from the PCEF. If a non-primary BBERF reports failure to install a QoS rule, the PCRF updates the status for that particular BBERF in its record but does not perform any further action.

– When path-switch occurs and the PCEF informs the PCRF of a new IP‑CAN type, if a BBERF is re-classified as a primary BBERF, the PCRF may update QoS rules in the BBERF corresponding to the PCC rules in the PCEF.

– For the case of UE initiated resource reservation through the non-primary BBERF: If a non-primary BBERF request results in a change of the QoS rules active in the primary-BBERF, e.g. creation of a new QoS rule or results in modification of an existing QoS rule, then the PCRF shall reject the request.

6.2.1.5.2 Handling of multiple BBFs with IP-CAN session flow mobility

The procedures specified in this clause apply when the case of multiple BBFs occurs during flow mobility scenarios as specified in TS 23.261 [23]. The multiple BBFs can be located in either separate BBERFs, or one BBF is located in the PCEF and the other ones in separate BBERFs. If the PCRF determines that there is more than one BBF associated with the same IP‑CAN session due to flow mobility, the PCRF handles the multiple BBFs as follows:

– The default route may be associated with one of the BBFs. The PCRF does not differentiate between primary and secondary BBF.

– If, based on routing information received from the PCEF, the PCRF determines that the bearer binding for a service data flow is located in a BBERF, the PCRF provides QoS rules for bearer binding to the appropriate BBERF/BBF. Each service data flow is associated with one BBF based on the routing information. If no explicit routing information for a service data flow is available from the PCEF, the PCRF provides PCC/QoS rules for the service data flow based on the default route.

– When the route of a service data flow changes from one source BBF to another target BBF, the PCRF removes the QoS rules related to the service data flow from the source BBF (if the source BBF is located in a BBERF) and provisions the QoS rules related to the service data flow to the target BBF (if the target BBF is located in a BBERF).

– The PCRF may select different bearer establishment mode for different BBFs. Provision of PCC/QoS rules to a specific BBF follows the rule provision procedures based on the bearer establishment mode selected for that BBF.