7.4 IP‑CAN Session Modification
23.2033GPPPolicy and charging control architectureRelease 17TS
7.4.1 IP‑CAN Session Modification; GW (PCEF) initiated
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.
Figure 7.4: IP‑CAN Session Modification; GW (PCEF) initiated
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.
NOTE 1: The case when the AF resides in the VPLMN is not shown in the figure.
In the non-roaming case (figure 5.1-1) the V‑PCRF is not involved at all.
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.
NOTE 2: For the PCRF to generate the applicable events, the PCRF instructs the PCEF to report events related to the corresponding PCC rules. Such events are not shown in this sequence diagram.
2. The PCRF stores the service information and responds with the Acknowledgement to the AF.
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.
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.
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.
6. The PCRF correlates the request for PCC Rules with the IP‑CAN session and service information available at the GW (PCEF).
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.
8. The AF acknowledges the event report and/or responds with the requested information.
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.
10. The PCRF makes the authorization and policy decision.
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.
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.
13. If OCS was contacted by the TDF, the OCS provides the credit information to the TDF, and/or acknowledges the credit report.
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.
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.
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.
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.
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.
19. If OCS was contacted by the PCEF, the OCS provides the credit information to the GW (PCEF), and/or acknowledges the credit report.
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).
21. The GW (PCEF) receives the response for the IP‑CAN Session signalling request (applicable to case 1).
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.
NOTE 3: For Cases 2a and 2b, the rejection of PCC rule operation can only occur as a result of online charging interaction.
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.
24. If the AF requested it, the PCRF notifies the AF of related bearer level events (e.g. transmission resources are established/released/lost).
NOTE 4: Based on the outcome reported in this step the AF performs the appropriate action, e.g. starting charging or terminating the AF session.
25. The AF acknowledges the notification from the PCRF.
7.4.2 IP‑CAN Session Modification; PCRF initiated
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.
Figure 7.5: IP‑CAN Session Modification; PCRF initiated
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.
NOTE 1: The case when the AF resides in the VPLMN is not showed in the figure.
In the non-roaming case (figure 5.1-1) the V‑PCRF is not involved at all.
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).
NOTE 2: For the PCRF to generate the applicable events, the PCRF instructs the PCEF to report events related to the corresponding PCC rules. Such events are not shown in this sequence diagram.
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.
1c. Alternatively, optionally, the OCS provides a Spending Limit Report to the PCRF as described in clause 7.9.4.
1d. Alternatively, optionally, the RCAF provides a Congestion Report to the PCRF as described in clause 7.10.1.
NOTE 3: This step is not shown on the diagram.
2a. The PCRF stores the service information if available and responds with the Acknowledgement to the AF. This is applicable to 1a case.
NOTE 4: Without AF interaction, a trigger event in the PCRF may cause the PCRF to determine that the PCC rules require updating at the PCEF, e.g. change to configured policy.
NOTE 5: This procedure could also be triggered by the Gateway Control and QoS Rules Request procedure as described in clause 7.7.3.
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.
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.
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.
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.
7. If OCS was contacted by the TDF, the OCS provides the credit information to the TDF, and/or acknowledges the credit report.
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.
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.
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.
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.
NOTE 6: If there is a Gateway Control and QoS Rules Reply pending, e.g. this procedure was invoked from the Gateway Control and QoS Rules Request procedure as defined in clause 7.7.3, the PCRF shall use that opportunity for provisioning the applicable QoS rules. If there are multiple BBERFs associated with the IP‑CAN session, and the procedure was invoked by a Gateway Control and QoS Rules Request procedure from the primary BBERF, the PCRF may receive a Gateway Control and QoS Rules Request from the non-primary BBERFs.
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.
13. The PCEF enforces the decision.
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.
15. If OCS was contacted by the PCEF, the OCS provides the credit information to the PCEF, and/or acknowledges the credit report.
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.
17. The GW (PCEF) receives the response for the IP‑CAN Bearer modification or termination request (applicable to case 1).
18. The PCEF sends Acknowledge Policy and Charging Rules Provisioning (accept or reject of the PCC rule operation(s)) to the PCRF.
19. If the AF requested it, the PCRF notifies the AF related bearer level events (e.g. transmission resources are established/released/lost).
20. The AF acknowledges the notification from the PCRF.