Content for  TS 23.203  Word version:  19.0.0

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 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. 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. 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 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 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;
• 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.
• 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 or in TS 23.261 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. 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. 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. 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). 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). 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. 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), 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. 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. 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 and sends it to PCEF along with the PCC rule for the voice media.

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 applies);
• IP flow routing information (when IP flow mobility as specified in TS 23.261 applies);
• Change of usability of an Access (when NBIFOM as specified in TS 23.161 applies);
• IP-CAN bearer attributes;
• Request type (initial, modification, etc.);
• Type of IP-CAN (e.g. GPRS, etc.);
• Location of the subscriber;
• 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 for more detail on MPS Subscription);
• IMS Signalling Priority.

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;
• Emergency indicator;
• Indicator for Restricted Local Operator Services;
• Application service provider.

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.
• 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.

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.