Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑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… 
7.4 IP CAN Session Modification  7.4.1 IP CAN Session Modification; GW (PCEF) initiated  7.4.2 IP CAN Session Modification; PCRF initiated  7.5 Update of the subscription information in the PCRF  7.6 PCRF Discovery and Selection 
...

 

7.4  IP CAN Session Modification  p. 140

7.4.1  IP CAN Session Modification; GW (PCEF) initiated  p. 140

This clause describes the signalling flow for the IP-CAN Session modification initiated by the GW (PCEF). These modifications include IP-CAN bearer establishment and termination as well as modification if the triggering conditions given to the PCEF are fulfilled.
For the PCEF enhanced with ADC, the reason for such a modification may be that a start or stop of application traffic that matches with one of the activated PCC Rules is detected.
The AF may be involved. An example of the scenario is authorization of a session-based service for which an IP-CAN Session is also modified.
Copy of original 3GPP image for 3GPP TS 23.203, Fig. 7.4: IP-CAN Session Modification; GW (PCEF) initiated
Figure 7.4: IP-CAN Session Modification; GW (PCEF) initiated
(⇒ copy of original 3GPP image)
Up
This procedure concerns both roaming and non-roaming scenarios. In the roaming case when home routed access applies (Figure 5.1-3) or if case 2a applies (as defined in clause 7.1) for Local Breakout (Figure 5.1-4), when a Gateway Control Session is used, the H-PCRF may initiate a Gateway Control and QoS Rules Provisioning procedure towards the BBERF and proxy the information through the V-PCRF over S9.
For case 2b in the Local Breakout scenario (Figure 5.1-4) and if the Gateway Control Session is terminated locally at the V-PCRF, the V-PCRF shall initiate the Gateway Control and QoS Rules Provisioning procedure locally without notifying the H-PCRF. For this case the V-PCRF shall proxy the Indication and Acknowledge of IP-CAN Session Modification over S9 between the PCEF in the VPLMN and the H-PCRF. If the AF is located in the VPLMN for this scenario, the V-PCRF shall proxy AF session signalling over S9 between the AF and the H-PCRF.
In the non-roaming case (Figure 5.1-1) the V-PCRF is not involved at all.
Step 1.
Optionally, the AF provides/revokes service information to the PCRF due to AF session signalling. The AF may subscribe at this point to notification of bearer level events related to the service information.
Step 2.
The PCRF stores the service information and responds with the Acknowledgement to the AF.
Step 3.
The GW (PCEF) may receive IP-CAN session signalling for IP-CAN Session modification. PDN Connection Identifier may be included in the IP-CAN session signalling.
Step 4.
The GW (PCEF) makes a decision to trigger IP-CAN Session modification either caused by the previous step or based on an internal decision or, e.g. if the GW (PCEF) enhanced with ADC, has detected the start/ stop of application traffic, requested by one of the activated PCC Rules.
Step 5.
The GW (PCEF) determines that the PCC interaction is required and sends an Indication of IP-CAN Session modification (Event Report, affected PCC Rules, if available, the PDN Connection Identifier) to the PCRF together with, if available, User Location Information and/or UE Time Zone and RAN/NAS Release Cause and, if changed, the new IP-CAN bearer establishment modes supported. If there is a limitation or termination of the transmission resources for a PCC Rule, the GW (PCEF) reports this to the PCRF. If flow mobility applies, the GW (PCEF) may include updated IP flow mobility routing information for any IP flows; the GW (PCEF) also provides an indication if default route for the IP-CAN session is changed.
Step 6.
The PCRF correlates the request for PCC Rules with the IP-CAN session and service information available at the GW (PCEF).
Step 7.
The PCRF may need to report to the AF an event related to the transmission resources if the AF requested it at initial authorisation.
Step 8.
The AF acknowledges the event report and/or responds with the requested information.
Step 9.
If the PCRF determines a change to policy counter status reporting is required, it may alter the subscribed list of policy counters using the Initial, Intermediate or Final Spending Limit Report Request procedures as defined in clauses 7.9.1, 7.9.2 and 7.9.3.
Step 10.
The PCRF makes the authorization and policy decision.
Step 11.
For the TDF solicited application reporting, the steps 11-14 take place. The PCRF provides all new ADC decisions to the TDF. This may include ADC Rules activation, deactivation and modification, if traffic steering control over Sd applies, ADC Rules may contain traffic steering control information. This may also include the list of Event triggers and also Event Report for the Event triggers, if reported by the PCEF/BBERF to the PCRF, if the TDF has previously subscribed for such an Event Report. In case of local breakout, the V-PCRF shall provide ADC rules generated from PCC Rules providing application detection and control as instructed by the H-PCRF over S9.
For unsolicited application reporting and if the PCRF has recorded the release of an IPv4 address in step 5, the PCRF terminates the related Sd session.
Step 12.
If online charging is applicable for the TDF, the TDF may request credit for new charging keys from the OCS and/or may inform the OCS about re-authorization trigger if the event occurs and/or may issue final reports and return remaining credit for charging keys no longer active to the OCS.
Step 13.
If OCS was contacted by the TDF, the OCS provides the credit information to the TDF, and/or acknowledges the credit report.
Step 14.
The TDF sends an Ack (accept or reject of the ADC rule operation(s)) to inform the PCRF about the outcome of the actions related to the decision(s) received in step 11. The Ack also includes the list of Event Triggers to report, including the case when the OCS provides any credit re-authorisation trigger, e.g. PLMN change, Location change (serving CN node), which cannot be monitored at the TDF. The Event Triggers indicate to the PCRF what events to be forwarded from the PCRF to the TDF, once PCRF gets the corresponding Event Report from the PCEF/BBERF.
Step 15.
If traffic steering control over St applies, the PCRF determines if traffic steering control information needs to be modified/provisioned for the IP-CAN session; the PCRF provides to the TSSF the traffic steering control information associated to the UE IPv4 address and/or to the UE IPv6 prefix.
Step 16.
The TSSF sends an acknowledgement to the PCRF to inform the PCRF about the outcome of the actions related to the traffic steering control information received in step 15.
Step 17.
The PCRF sends an Acknowledge of IP-CAN Session modification (PCC Rules, Event Triggers and, if changed, the chosen IP-CAN bearer establishment mode) to the GW (PCEF). If traffic steering control over Gx applies, PCC Rules may contain traffic steering control information. The GW (PCEF) enforces the decision. If the TDF provided a list of Event Triggers to the PCRF in the previous step, the PCRF shall also provide those Event Triggers to the PCEF.
Step 18.
If online charging is applicable for the PCEF, the GW (PCEF) may request credit for new charging keys from the OCS and/or may inform the OCS about re-authorization trigger if the event occurs and/or may issue final reports and return remaining credit for charging keys no longer active to the OCS.
Step 19.
If OCS was contacted by the PCEF, the OCS provides the credit information to the GW (PCEF), and/or acknowledges the credit report.
Step 20.
The GW (PCEF) acknowledges or rejects any IP-CAN Session signalling received in step 3.
An IP-CAN bearer establishment is accepted if at least one PCC rule is active for the IP-CAN bearer and in case of online charging credit was not denied by the OCS. Otherwise, the IP-CAN bearer establishment is rejected.
An IP-CAN bearer termination is always acknowledged by the GW (PCEF).
An IP-CAN bearer modification not upgrading the QoS and not providing traffic mapping information is always acknowledged by the GW (PCEF). An IP-CAN bearer modification is accepted if the provided traffic mapping information is accepted by the PCRF. Otherwise, the IP-CAN bearer modification is rejected.
In case of a GW (PCEF) internal decision the GW (PCEF) initiates any additional IP-CAN Session signalling required for completion of the IP-CAN Session modification (applicable to case 1).
In case the IP-CAN session modification is due to the BBF transitioning from a BBERF in the source access-network to the PCEF, the PCEF initiates IP-CAN bearer signalling to activate bearers in the target access network (applicable to case 1).
Step 21.
The GW (PCEF) receives the response for the IP-CAN Session signalling request (applicable to case 1).
Step 22.
The GW (PCEF) sends a Provision Ack (accept or reject of the PCC rule operation(s)) to inform the PCRF about the outcome of the GW (PCEF) actions related to the decision(s) received in step 15.
Step 23.
Based on the result of PCC rule operations, the PCRF decides whether to initiate a Gateway Control and QoS Rules provision procedure as defined in clause 7.7.4, if required to keep the PCC and QoS rules aligned (applicable to cases 2a and 2b, as defined in clause 7.1).
If there are multiple BBERFs associated with the IP-CAN session, this step is performed with all the affected BBERFs.
Step 24.
If the AF requested it, the PCRF notifies the AF of related bearer level events (e.g. transmission resources are established/released/lost).
Step 25.
The AF acknowledges the notification from the PCRF.
Up

7.4.2  IP CAN Session Modification; PCRF initiated  p. 143

This clause describes the signalling flow for the IP-CAN Session modification initiated by the PCRF. The AF or TDF or the OCS or the TSSF may be involved. An example of PCRF inputs that may trigger the procedure include:
  • Initiation and authorization of a session-based service for which an IP-CAN Session is modified.
  • A change in the status of a policy counter.
IP-CAN Session handling and handling of PCC rules for non-session based services, and also general handling of PCC rules that are not subject to AF-interaction or TDF-interaction is also applicable here.
Copy of original 3GPP image for 3GPP TS 23.203, Fig. 7.5: IP-CAN Session Modification; PCRF initiated
Figure 7.5: IP-CAN Session Modification; PCRF initiated
(⇒ copy of original 3GPP image)
Up
This procedure concerns both roaming and non-roaming scenarios. In the roaming case when home routed access applies (Figure 5.1-3) or if case 2a applies (as defined in clause 7.1) for Local Breakout (Figure 5.1-4), when a Gateway Control Session is used, the V-PCRF shall proxy Gateway Control and QoS Rules Request between the BBERF in the VPLMN and the H-PCRF over S9. For this case the H-PCRF may also initiate a Gateway Control and QoS Rules Provisioning procedure towards the BBERF in the VPLMN and proxy the information via the V-PCRF over S9.
For case 2b in the Local Breakout scenario (Figure 5.1-4) and if the Gateway Control Session is terminated locally at the V-PCRF, the V-PCRF shall reply to/initiate Gateway Control Session and QoS Rules Request/Provisioning procedures locally without notifying the H-PCRF. For this case the V-PCRF shall proxy the Policy and Charging Rules Provisioning and Acknowledge over S9 between the PCEF in the VPLMN and the H-PCRF. If the AF is located in the VPLMN for this scenario, the V-PCRF shall proxy AF session signalling over S9 between the AF and the H-PCRF.
In the non-roaming case (Figure 5.1-1) the V-PCRF is not involved at all.
Step 1a.
Optionally, the AF provides/revokes service information to the PCRF due to AF session signalling. The AF may subscribe at this point to notification of bearer level events related to the service information. The AF may also provide a reference ID to a transfer policy that the AF previously negotiated with the PCRF (as described in clauses 6.1.16 and 7.11.1).
Step 1b.
Alternatively, optionally, for TDF, e.g. the TDF detects the start/stop of an application traffic that matches with one of the active ADC Rules.
For solicited application reporting, if the start/stop of application traffic detection Event Trigger was received from the PCRF and the reporting is not muted for the ADC rule, the TDF shall provide application information to the PCRF, including the application identifier, start or stop of application traffic detection event trigger and, for the start of application's traffic detection, the service data flow descriptions, if deducible. Additionally, the application instance identifier should be included in the report both for Start and for Stop of application traffic detection, when the service data flow descriptions are provided.
For unsolicited application reporting, the Sd reports the same application information to the PCRF unconditionally. The TDF establishes a new Sd session if it detects an application for an IPv4 address or IPv6 address for which no corresponding Sd session exists.
Step 1c.
Alternatively, optionally, the OCS provides a Spending Limit Report to the PCRF as described in clause 7.9.4.
Step 1d.
Alternatively, optionally, the RCAF provides a Congestion Report to the PCRF as described in clause 7.10.1.
Step 2a.
The PCRF stores the service information if available and responds with the Acknowledgement to the AF. This is applicable to 1a case.
Step 3.
If the PCRF determines a change to policy counter status reporting is required, it may alter the subscribed list of policy counters using the Initial, Intermediate or Final Spending Limit Report Request procedures as defined in clauses 7.9.1, 7.9.2 and 7.9.3.
Step 4.
The PCRF makes the authorization and policy decision. If the AF provided a reference ID to a transfer policy in step 1a, the PCRF shall retrieve the corresponding transfer policy from the SPR before making any decisions.
Step 5.
The PCRF may store the application information if provided and responds with an Acknowledgement to the TDF (for unsolicited application reporting) or a Sd session modification (for solicited application reporting). For the TDF solicited application reporting, the PCRF may provide a new ADC decision to the TDF. If the last ADC rule is deactivated, the PCRF requests the TDF to terminate the Sd session towards the PCRF. If there is no active Sd session yet between the TDF and the PCRF, the PCRF requests the TDF to establish the Sd session towards PCRF and provides an ADC decision to the TDF, if traffic steering control over Sd applies, ADC Rules may contain traffic steering control information. In case of local breakout, the V-PCRF shall provide ADC rules generated from PCC Rules providing application detection and control as instructed by the H-PCRF over S9.
Step 6.
If online charging is applicable for the TDF, the TDF may request credit for new charging keys from the OCS and/or may inform the OCS about re-authorization trigger if the event occurs and/or may issue final reports and return remaining credit for charging keys no longer active to the OCS.
Step 7.
If OCS was contacted by the TDF, the OCS provides the credit information to the TDF, and/or acknowledges the credit report.
Step 8.
For the TDF solicited application reporting, in the case of an existing on-going session, if requested by the PCRF the TDF sends a Provision Ack (accept or reject of the ADC Rule operation(s)). For a new session, the TDF sends an Ack. This is to inform the PCRF about the outcome of the actions related to the received ADC decision(s). The Provision Ack / Ack also includes the list of Event Triggers to report, including the case when the OCS provides any credit re-authorisation trigger, e.g. PLMN change, Location change (serving CN node), which cannot be monitored at the TDF. The Event Triggers indicate to the PCRF what events to be forwarded from the PCRF to the TDF, once PCRF gets the corresponding Event Report from the PCEF/BBERF.
Step 9.
If traffic steering control over St applies, the PCRF determines if traffic steering control information needs to be modified/provisioned for the IP-CAN session; the PCRF provides to the TSSF the traffic steering control information associated to the UE IPv4 address and/or to the UE IPv6 prefix.
Step 10.
The TSSF sends an acknowledgement to the PCRF to inform the PCRF about the outcome of the actions related to the traffic steering control information received in step 9.
Step 11.
If there is no Gateway Control and QoS Rules Reply pending and there is a need to provision QoS rules, the PCRF initiates a Gateway Control and QoS Rules Provision Procedure as defined in 7.7.4 (applicable to cases 2a and 2b, as defined in clause 7.1).
If there are multiple BBERFs associated with the IP-CAN session, Step 9 is performed with the BBERFs that support UE/NW bearer establishment mode.
Step 12.
The PCRF sends the Policy and Charging Rules Provision (PCC Rules, Event Trigger, Event Report) to the PCEF. If traffic steering control over Gx applies, the PCC Rules may contain traffic steering control information. If the TDF provided a list of Event Triggers to the PCRF in the previous step, the PCRF shall also provide those Event Triggers to the PCEF.
Step 13.
The PCEF enforces the decision.
Step 14.
If online charging is applicable for the PCEF, the PCEF may request credit for new charging keys from the OCS and/or may inform the OCS about re-authorization trigger if the event occurs and/or may return the remaining credit for charging keys no longer active to the OCS.
Step 15.
If OCS was contacted by the PCEF, the OCS provides the credit information to the PCEF, and/or acknowledges the credit report.
Step 16.
The GW (PCEF) may send an IP-CAN Bearer establishment, modification or termination request (applicable to case 1, as defined in clause 7.1).
An IP-CAN bearer modification is sent by the GW (PCEF) if the QoS of the IP-CAN bearer exceeds the authorized QoS provided by the PCRF in step 4.
An IP-CAN bearer termination request is sent by the GW (PCEF) if all PCC rules for an IP-CAN bearer have been removed.
Step 17.
The GW (PCEF) receives the response for the IP-CAN Bearer modification or termination request (applicable to case 1).
Step 18.
The PCEF sends Acknowledge Policy and Charging Rules Provisioning (accept or reject of the PCC rule operation(s)) to the PCRF.
Step 19.
If the AF requested it, the PCRF notifies the AF related bearer level events (e.g. transmission resources are established/released/lost).
Step 20.
The AF acknowledges the notification from the PCRF.
Up

7.4.3  Void

7.5  Update of the subscription information in the PCRF  p. 147

Copy of original 3GPP image for 3GPP TS 23.203, Fig. 7.6: Procedure for update of the subscription information in the PCRF
Figure 7.6: Procedure for update of the subscription information in the PCRF
(⇒ copy of original 3GPP image)
Up
Step 1.
The SPR detects that the related subscription profile of an IP-CAN session has been changed.
Step 2.
If requested by the PCRF, the SPR notifies the PCRF on the changed profile.
Step 3.
The PCRF responds to the SPR.
Step 4.
The PCRF stores the updated profile.
Step 5.
If the updated subscriber profile requires the status of new policy counters available at the OCS then an Initial/Intermediate Spending Limit Report Request is sent from PCRF as defined in clauses 7.9.1, and 7.9.2. If the updated subscriber profile implies that no policy counter status is needed an Intermediate Spending Limit Report Request is sent from PCRF, if this is the last policy counter status Final Spending Limit Report Request is sent from PCRF as specified in clause 7.9.3.
Step 6.
PCRF makes an authorization and policy decision.
Step 7.
The PCRF provides all new PCC decisions to the PCEF and BBERF (if applicable), using the PCRF initiated IP-CAN session modification procedure in clause 7.4.2. The PCRF also provides all new ADC decisions to the TDF, if applicable.
Up

7.6  PCRF Discovery and Selection |R8|  p. 148

7.6.1  General principles  p. 148

This clause describes the underlying principles for PCRF selection and discovery:
  • A single logical PCRF entity may be deployed by means of multiple and separately addressable PCRFs.
  • The H-PCRF must be able to correlate the AF service session information received over Rx with the right IP-CAN session (PCC Session binding).
  • The PCRF must be able to associate sessions established over the different reference points (Gx, Rx, S9, Gxa/Gxc, Sd, Np), for the same UE's IP-CAN session. The actual reference points that need to be correlated depend on the scenario (e.g. roaming, LBO etc.).
  • It shall be possible to deploy a network so that a PCRF may serve only specific PDN(s). For example, PCC may be enabled on a per APN basis.
    For the case 2a (as defined in clause 7.1), the same PCRF shall support all the PDNs for which PCC is enabled and for which there are potential users accessing by means of case 2a (as defined in clause 7.1).
    It shall also be possible to deploy a network so that the same PCRF can be allocated for all PDN connections for a UE.
  • A standardized procedure for contacting the PCRF is preferred to ensure interoperability between PCRFs from different vendors. The procedure may be specific for each reference point. The procedure shall enable the PCRF(s) to coordinate Gx, Rx and, when applicable, Gxa/Gxc, S9, Sd and Np interactions.
  • It shall allow that entities contacting the PCRF may be able to provide different sets of information about the UE and PDN connections. For example:
    • The AF has information about UE IP address and PDN but may not have user identity information.
    • The PDN GW has information about user identity (UE NAI), the APN and the UE IP address(es) for a certain PDN connection.
    • For case 2b as defined in clause 7.1, the S GW and trusted non-3GPP access has information about the user identity (UE NAI) and, the APN(s) but may not know the UE IP address(es).
    • For case 2a as defined in clause 7.1, the trusted non-3GPP access has information about the user identity (UE NAI) and the local IP address (CoA) but may not know the APN or UE IP address(es) (HoA).
    • The TDF (when the unsolicited application reporting applies) has the information about UE IP address, but may not have the UE identity.
    • The RCAF has the information about the user identity (IMSI) and the APN.
  • The DRA has information about the user identity (UE NAI), the APN, the UE IP address(es) and the selected PCRF address for a certain IP-CAN Session.
    When the DRA first receives a request for a certain IP-CAN Session (e.g. from the PDN GW), the DRA selects a suitable PCRF for the IP-CAN Session and stores the PCRF address. Subsequently, the DRA can retrieve the selected PCRF address according to the information carried by the incoming requests from other entities (e.g. the AF or the BBERF).
    When the IP-CAN Session terminates, the DRA shall remove the information about the IP-CAN Session. In case of the PCRF realm change, the information about the IP-CAN session stored in the old DRA shall be removed.
  • All PCRFs in a PLMN belong to one or more Diameter realms. Routing of PCC messages for a UE towards the right Diameter realm in a PLMN is based on standard Diameter routing, as specified in RFC 3588, i.e. based on UE-NAI domain part. A Diameter realm shall provide the ability of routing PCC messages for the same UE and PDN connection to the same PCRF based on the available information supplied by the entities contacting the PCRF.
  • A PLMN may be separated into multiple Diameter realms based on the PDN ID information or IP address range. In this case, the relevant information (PDN ID, IP address, etc) shall be used to assist routing PCC message to the appropriate Diameter realm.
  • Unique identification of an IP-CAN session in the PCRF shall be possible based on the (UE ID, PDN ID)-tuple , the (UE IP Address(es), PDN ID)-tuple and the (UE ID, UE IP Address(es), PDN ID).
  • Standard RFC 3588 mechanisms and components, e.g. Diameter agents, should be applied to deploy a network where the PCRF implementation specifics are invisible for Diameter clients. The use of Diameter agents, including Diameter redirect agents, shall be permitted, but the use of agents in a certain deployment shall be optional.
Up

7.6.2  Solution Principles  p. 149

In order to ensure that all Diameter sessions for Gx, S9, Gxa/Gxc, Rx, Sd (when the unsolicited application reporting applies) and Np for a certain IP-CAN session reach the same PCRF when multiple and separately addressable PCRFs have been deployed in a Diameter realm, an optional logical "Diameter Routing Agent (DRA)" function is enabled. This resolution mechanism is not required in networks that utilise a single PCRF per Diameter realm. The DRA has the following roles:
  • When deployed, DRA needs to be contacted at first interaction point for a given GW and IP-CAN session.
  • When deployed, the DRA is on the Diameter routing path when initiating a session with a PCRF over Gx, Rx, Gxa/Gxc, S9 and Sd.
  • The DRA is involved at IP-CAN session establishment by the PDN GW.
  • The DRA selects the PCRF at initial attach (IP-CAN session or Gateway Control session establishment).
  • The DRA is involved at Gateway Control session establishment by the S GW and trusted non-3GPP access.
  • The DRA selects the PCRF at unsolicited service reporting over Sd.
  • After IP-CAN session or Gateway Control Session establishment, the DRA ensures that the same PCRF is contacted for Rx, Gxa/Gxc, Gx, S9, Sd and Np.
  • The DRA keeps status of assigned PCRF for a certain UE and IP-CAN session.
  • It is assumed that there is a single logical DRA serving a Diameter realm.
  • In roaming scenarios, there is only a single VPCRF for all the PCC sessions (IP-CAN session, GW control sessions, AF session, etc.) belonging to a single PDN connection of the UE. The VPCRF shall be selected by a DRA in the visited PLMN.
Copy of original 3GPP image for 3GPP TS 23.203, Fig. 7.6-1: PCRF selection and discovery using DRA
Figure 7.6-1: PCRF selection and discovery using DRA
(⇒ copy of original 3GPP image)
Up
The DRA functionality should be transparent to the Diameter applications used on the Gx, Gxa/Gxc, S9, Rx, Sd or Np reference points.
In roaming scenario, home routed or local breakout, if the DRA is deployed, the vPCRF is selected by the DRA located in the visited PLMN, and the hPCRF is selected by the DRA located in the home PLMN.
The parameters available for the DRA to be able to determine the already allocated PCRF depend on the reference point over which the DRA is contacted, as described in clause 7.6.1.
Up

Up   Top   ToC