Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.203  Word version:  17.2.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   6.1.4…   6.1.7…   6.1.10…   6.1.17…   6.2…   6.2.2…   6.2.3…   6.3   6.4…   6.8…   7…   7.3…   7.4…   7.7…   7.7.3…   7.8…   A…   A.4…   D…   P…   P.4.2.4…   P.7…   P.7.5…   P.8   Q…   S…   S.7…   S.8.8   T…

 

6.2  Functional entitiesp. 74

6.2.1  Policy Control and Charging Rules Function (PCRF)p. 74

6.2.1.0  Generalp. 74

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 TS 32.251, clause 5.1.3. 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.
Up

6.2.1.1  Input for PCC decisionsp. 79

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

6.2.1.2  Subscription information management in the PCRFp. 82

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

6.2.1.3  V-PCRF |R8|p. 82

6.2.1.3.1  Generalp. 82
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.
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.
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.
Up
6.2.1.3.2  V-PCRF and Home Routed Accessp. 83
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.
Up
6.2.1.3.3  V-PCRF and Visited Access (local breakout)p. 83
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.
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.
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.
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.
Up

6.2.1.4  H-PCRF |R8|p. 84

6.2.1.4.1  Generalp. 84
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.
Up
6.2.1.4.2  H-PCRF and Home Routed Accessp. 84
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.
Up
6.2.1.4.3  H-PCRF and Visited Access (Local Breakout)p. 85
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.
Up

6.2.1.5  Handling of Multiple BBFs associated with the same IP CAN session |R8|p. 85

6.2.1.5.1  Handling of two BBFs associated with the same IP-CAN session during handover |R10|p. 85
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).
  • 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.
  • 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.
Up
6.2.1.5.2  Handling of multiple BBFs with IP-CAN session flow mobility |R10|p. 86
The procedures specified in this clause apply when the case of multiple BBFs occurs during flow mobility scenarios as specified in TS 23.261. 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.
Up

Up   Top   ToC