4.5.2 Visited access case

29.2133GPPPolicy and charging control signalling flows and Quality of Service (QoS) parameter mappingRelease 17TS

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

4.5.2.1 New Gateway Control Session Establishment

The following signalling flow describes an example of a new BBERF initiating a GW control session establishment associated with an existing IP-CAN session.

Figure 4.5.2.1.1: Gateway Control Session Establishment during BBERF relocation

1. The target BBERF receives a message or indication to establish a Gateway Control Session.

2. The target BBERF initiates a Gateway Control Session with the V-PCRF by sending a CCR using the CC-Request-Type AVP set to the value INITIAL_REQUEST to the V-PCRF. The target BBERF provides information as detailed in clause 4a.5.1 of 3GPP TS 29.212 [9].

3. The V-PCRF stores the information received in the Diameter CCR and determines based on the UE identity information that the request is for a roaming user. The V-PCRF checks whether the V-PCRF is required to send the request to the H-PCRF based on the roaming agreements. The V-PCRF does not send the CCR to the H-PCRF to update the S9 session immediately if the Session-Linking-Indicator AVP was received indicating that the session linking has to be deferred.

4. If the Session-Linking-Indicator AVP was received indicating that the session linking has to be deferred, the linking between the Gateway Control Session and the Gx session shall be deferred. Otherwise, based on the information received the V-PCRF identifies multiple BBERF sessions for a particular IP-CAN session. The V-PCRF derives applicable QoS rules according to local policies and stores them.

For case 2a or if either the AN_GW_CHANGE or the IP-CAN_CHANGE event is subscribed by H-PCRF and this event trigger is received steps 5~8 are executed. Otherwise steps 5~8 are skipped.

5. The V-PCRF initiates an IP-CAN Session Modification procedure by sending a CCR to the H-PCRF with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The V-PCRF includes in the CCR the information received in step 2.

6. The H-PCRF stores the information received in the Diameter CCR. And the H-PCRF decides PCC rules for the BBERF and stores PCC rules.

7. The H-PCRF sends a Diameter CCA to the V-PCRF to provide the PCC rules. The H-PCRF sends applicable PCC rules. The H-PCRF includes the AN-GW-Address AVP if the PCC rules are applicable only for a single BBERF. If the PCC rules are applicable for all BBERF sessions this AVP is omitted.

8. If the steps 5~7 are executed, the V-PCRF enforces visited operator policies regarding QoS authorization requested by the H-PCRF as indicated by the roaming agreements.

Steps 8a and 8b are executed if the V-PCRF denies authorisation for one or more PCC rules.

8a. If V-PCRF denies authorization, it informs the H-PCRF by sending a CCR command including the Charging-Rule-Report AVP to indicate the PCC Rules that were not accepted, the Rule-Failure-Code AVP set to UNSUCCESSFUL-QoS-VALIDATION, and the acceptable QoS Information for the service.

8b. The H-PCRF may provide new modified PCC rules to the V-PCRF.

9. The V-PCRF acknowledges the Gateway Control Session and provisions policy decisions and event triggers to the target BBERF.

10. The BBERF installs the received QoS rules.

11. The target BBERF responds to the Gateway control session establishment request in step 1.

4.5.2.2 PCEF-Initiated IP-CAN session modification-Handover

The following signalling flow describe the case when an indication of handover is received by the PCEF and the H-PCRF derives QoS rules based on the type of BBERF (primary/non-primary)

Figure 4.5.2.2.1: PCEF-initiated IP-CAN session modification – Handover

1. The PCEF receives a message or indication that a handover occurred.

2. The PCEF initiates an IP-CAN Session Modification procedure by sending a CCR using the CC-Request-Type AVP set to the value UPDATE_REQUEST to the V-PCRF. The PCEF includes the AN_GW_CHANGE event trigger, and if applicable the IP-CAN_CHANGE event trigger as well, to indicate that handover has occurred.

3. The V-PCRF stores the information received in the Diameter CCR.

4. If there is a pending Gateway Control Session to be linked to a Gx session, the V-PCRF links Gateway Control Session with the Gx session according to clause 4a.5.6 of 3GPP TS 29.212 [9]. Otherwise based on the information received the V-PCRF identifies multiple BBERF sessions for a particular IP-CAN session.

5. Based on the information received the V-PCRF reclassifies primary/non-primary BBERFs according to the procedures defined in clause 4a.5.7 of 3GPP TS 29.212 [9].

If either the AN_GW_CHANGE or the IP-CAN_CHANGE event is subscribed by H-PCRF and this event trigger is received steps 6~9 are executed. Otherwise steps 6~9 are skipped.

6. The V-PCRF initiates an IP-CAN Session Modification procedure by sending a CCR to the H-PCRF with the CC-Request-Type AVP set to the value UPDATE_REQUEST. The V-PCRF includes in the CCR the information received in step 2.

7. The H-PCRF stores the information received in the Diameter CCR.

8. The H-PCRF decides PCC rules for the PCEF and stores PCC rules.

9. The H-PCRF sends a Diameter CCA to the V-PCRF to provide the PCC Rules. The H-PCRF sends applicable PCC rules. The H-PCRF includes the AN-GW-Address AVP if the PCC rules are applicable only for a single BBERF. If the PCC rules are applicable for all BBERF sessions this AVP is omitted.

10. If the steps 6~9 are executed, the V-PCRF enforces visited operator policies regarding QoS authorization requested by the H-PCRF as indicated by the roaming agreements.

Steps 10a and 10b are executed if the V-PCRF denies authorisation for one or more PCC rules.

10a. If V-PCRF denies authorization, it informs the H-PCRF by sending a CCR command including the Charging-Rule-Report AVP to indicate the PCC Rules that were not accepted, the Rule-Failure-Code AVP set to UNSUCCESSFUL-QoS-VALIDATION, and the acceptable QoS Information for the service.

10b. The H-PCRF may provide new modified PCC rules to the V-PCRF.

11. The V-PCRF acknowledges the IP-CAN session modification request by sending a Diameter CCA to the PCEF. The V-PCRF includes updated PCC rules and event triggers (if applicable)

12. The V-PCRF initiates the Gateway Control Session and QoS rules provisions by sending a Diameter RAR to the BBERF policy decisions and event triggers to the target BBERF.

13. The BBERF installs the received QoS Rules.

14. The BBERF acknowledges the Gateway Control and QoS Rules Provision request by sending a Diameter RAA to the V-PCRF.

4.5.2.3 PCEF-Initiated IP-CAN session modification – S2c-based IP flow mobility

The following signalling flow describes an example of S2c-based IP flow mobility. In this case, the H-PCRF receives an IP flow mobility event by the PCEF and derives QoS rules based on the IP flow mobility routing rules.

Figure 4.5.2.3.1: PCEF-initiated IP-CAN session modification – S2c-based IP flow mobility

1. The PCEF receives a message or indication that a handover occurred.

2. The PCEF initiates an IP-CAN Session Modification procedure by sending a CCR using the CC-Request-Type AVP set to the value UPDATE_REQUEST to the V-PCRF. The PCEF includes the ROUTING_RULE_CHANGE event trigger to indicate that a change in the IP flow mobility routing rules has occurred. The PCEF includes in the CCR Routing-Rule-Install and/or Routing-Rule-Removal AVPs.

3. The V-PCRF stores the information received in the Diameter CCR.

4. Based on the information received the V-PCRF determines that there is a change in the IP flow routing in the multiple BBERF(s) as described in clause 4a.5.7 of 3GPP TS 29.212 [9].

If either the AN_GW_CHANGE or the IP-CAN_CHANGE event is subscribed by H-PCRF and this event trigger is received steps 5~8 are executed. Otherwise steps 5~8 are skipped.

6. The H-PCRF stores the information received in the Diameter CCR.

7. The H-PCRF decides PCC rules for the PCEF and stores PCC rules. Based on the IP flow mobility routing rule as defined in clause 4a.5.7 of 3GPP TS 29.212 [9]

8. The H-PCRF sends a Diameter CCA to the V-PCRF to provide the PCC Rules. The H-PCRF sends applicable PCC rules.

9. If the steps 5~8 are executed, the V-PCRF establishes QoS Rules based on received IP flow mobility routing rules and enforces visited operator policies regarding QoS authorization requested by the H-PCRF as indicated by the roaming agreements.

Steps 9a and 9b are executed if the V-PCRF denies authorisation for one or more PCC rules.

9a. If V-PCRF denies authorization, it informs the H-PCRF by sending a CCR command including the Charging-Rule-Report AVP to indicate the PCC Rules that were not accepted, the Rule-Failure-Code AVP set to UNSUCCESSFUL-QoS-VALIDATION, and the acceptable QoS Information for the service.

9b. The H-PCRF may provide new modified PCC rules to the V-PCRF.

10. Step 11 through step 14: as specified in Figure 4.5.2.2.1: PCEF-initiated IP-CAN session modification‑ Handover are executed, as needed. If the IP flows were moved from one access to another (e.g. 3GPP to WLAN, or vice versa), the PCRF may also initiate a RAR command towards BBERF#1 to modify or release the related resources associated with the flows that were moved to BBERF#2.

4.5.2.4 Gateway Control Session Establishment and PCEF IP-CAN session modification – S2c-based IP flow mobility

The following signalling flow describes an example of IP flow mobility. In this case, the V-PCRF receives a Gateway Control session establishment by a BBERF and an IP flow mobility event by the PCEF. V-PCRF associates the IP‑CAN session to multiple Gateway Control Sessions and derives QoS rules based on the IP flow mobility routing rules.

Figure 4.5.2.4.1: Gateway Control Session Establishment and PCEF IP-CAN session modification – S2c-based IP flow mobility

1. Step 1 through step 10: as specified in Figure 4.4.1.1: Gateway Control Session Establishment are executed, as needed. The Gateway Control Session is established for BBERF #2. The Gateway Control Session for BBERF #1 was previously established.

NOTE: If the Gateway Control Session is established for WLAN access, only case 2a is possible.

2. The PCEF receives a message or indication that an IP flow mobility event occurred.

3. The PCEF initiates an IP-CAN Session Modification procedure by sending a CCR using the CC-Request-Type AVP set to the value UPDATE_REQUEST to the V-PCRF. The PCEF includes the ROUTING_RULE_CHANGE event trigger to indicate that a change in the IP flow mobility routing rules has occurred. The PCEF includes in the CCR Routing-Rule-Install and/or Routing-Rule-Removal AVPs.

4. The V-PCRF stores the information received in the Diameter CCR.

5. Based on the received information, the V-PCRF does not differentiate between primary and non-primary BBFs and determines that there are IP flows routed through multiple BBERF(s) as described in clause 4a.5.7 of 3GPP TS 29.212 [9].

If either the AN_GW_CHANGE or the IP-CAN_CHANGE event is subscribed by H-PCRF and this event trigger is received steps 6~9 are executed. Otherwise steps 6~9 are skipped.

7. The H-PCRF stores the information received in the Diameter CCR.

8. The H-PCRF decides PCC rules for the PCEF and stores PCC rules. Based on the IP flow mobility routing rule as defined in clause 4a.5.7 of 3GPP TS 29.212 [9].

9. The H-PCRF sends a Diameter CCA to the V-PCRF to provide the PCC Rules. The H-PCRF sends applicable PCC rules.

10. Step 9 through step 10: as specified in Figure 4.5.2.3.1: PCEF-initiated IP‑CAN session modification‑ IPFlow mobility are executed, as needed.