7.7 Gateway Control Session Procedures
23.2033GPPPolicy and charging control architectureRelease 17TS
7.7.1 Gateway Control Session Establishment
7.7.1.0 General
There are two cases considered for Gateway Control Session Establishment:
1. The PCEF establishes the IP‑CAN Session during the Gateway Control session establishment. This happens when the UE attaches to the EPC for the first time and when the UE establishes a new PDN Connection.
2. There exists an established IP‑CAN Session corresponding to the Gateway Control Session being established. This happens when the BBERF changes, i.e. during BBERF relocation and handovers from and to GTP based EPC.
7.7.1.1 Gateway Control Session Establishment during Attach
Figure 7.7.1.1-1: Gateway Control Session Establishment during Attach
This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control Session Establishment between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-Id and roaming agreements.
In the non-roaming case (Figure 5.1-1) the V-PCRF is not involved.
1. The GW (BBERF) receives an indication that it must establish a Gateway Control Session.
2. The GW (BBERF) sends the PCRF a Gateway Control Session Establishment. The BBERF includes the following information: IP‑CAN Type, UE Identity, PDN Identifier (if known), IP address(es) (if known), an indication that leg linking shall be deferred (applicable for case 2b, as defined in clause 7.1), if available, the PDN Connection Identifier and if available, the IP‑CAN bearer establishment modes supported and the indication of BBERF support for the extended TFT filter format. The IP‑CAN Type identifies the type of access used by the UE. The UE’s identity and PDN Identifier requested are used to identify the subscriber and in PCRF selection to locate the PCRF function with the corresponding IP‑CAN session established by the PDN GW. The BBERF may also include the Default Bearer QoS and APN-AMBR (applicable for case 2b, as defined in clause 7.1). An indication that leg linking shall be deferred is included to inform the PCRF that linking the Gateway Control Session to a Gx session shall occur when a matching Gx message is received as described clause 6.2.1.0. Further information is supplied on an access specific basis, as described in the IP‑CAN specific Annexes.
NOTE: The BBERF support is a prerequisite for the PCRF enabling the possibility for usage of the extended TFT filter format in the IP-CAN session(s).
3. For GERAN/UTRAN accesses, if the PCRF is required to interact with the GW (PCEF), the PCRF waits until it gets informed about the establishment of the corresponding IP‑CAN session (step 7 of the IP‑CAN session establishment procedure) and performs a PCRF initiated IP‑CAN session modification procedure with the GW (PCEF).
4. The PCRF sends an Acknowledge Gateway Control Session Establishment to the GW (BBERF). The PCRF may include the following information: the chosen IP‑CAN bearer establishment mode, QoS Rules and Event Triggers. In case 2a a charging ID may be provided together with QoS rules. The QoS policy rules are employed by the GW (BBERF) to perform Bearer Binding. The Event Triggers indicate events that require the GW (BBERF) to report to the PCRF.
5. The QoS Rules and Event Triggers received by the GW (BBERF) are deployed. This will result in bearer binding being performed, according to the rules. This step may trigger IP‑CAN bearer establishment procedures. The details of bearer establishment are IP‑CAN specific.
6. An indication of Gateway Control Session Established is sent to the entity that triggered the initiation of the session.
7.7.1.2 Gateway Control Session Establishment during BBERF Relocation
Figure 7.7.1.2-1: Gateway Control Session Establishment during BBERF Relocation
This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control Session Establishment between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-Id and roaming agreements.
In the non-roaming case (Figure 5.1-1) the V-PCRF is not involved.
1. The target GW (BBERF) receives an indication that it must establish a Gateway Control Session.
2. The target GW (BBERF) sends the PCRF a Gateway Control Session Establishment. The BBERF includes the following information: IP‑CAN Type, UE Identity, PDN Identifier (if known), IP address(es) (if known), PDN Connection Identifier if available and, if available, the IP‑CAN bearer establishment modes supported. The IP‑CAN Type identifies the type of access used by the UE. The UE’s identity and PDN Identifier requested are used to identify the subscriber and in PCRF selection to locate the PCRF function with the corresponding IP‑CAN session established by the PDN GW. The BBERF may also include the Default Bearer QoS and APN-AMBR (applicable for case 2b, as defined in clause 7.1). If the handover state is unknown to the GW (BBERF), as described in TS 23.402 [18], the GW (BBERF) includes an indication to inform the PCRF that linking the Gateway Control Session to a Gx session shall be deferred as described clause 6.2.1.0 (applicable for case 2b, as defined in clause 7.1). Further information is supplied on an access specific basis, as described in the IP‑CAN specific Annexes.
3. If case 2b of clause 7.1 applies and the PCRF correlates the Gateway Control Session with an existing IP‑CAN session, it sends an Acknowledge Gateway Control Session Establishment to the target GW (BBERF). The PCRF may include the following information: QoS Rules and Event Triggers. The QoS policy rules are employed by the GW (BBERF) to perform Bearer Binding. The Event Triggers indicate events that require the GW (BBERF) to report to the PCRF. If the BBERF supports NW/UE bearer establishment mode, the PCRF provides to the new BBERF QoS rules corresponding to existing 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.
If case 2a of clause 7.1 applies, the PCRF sends an Acknowledge Gateway Control Session Establishment to the target GW (BBERF). The PCRF includes packet filters and QoS information for the CoA in order to establish the initial bearer, e.g. for the DSMIPv6 signalling. The PCRF may also include Event Triggers.
NOTE: The packet filters and QoS information provided at this step conceptually are not QoS rules as they are not associated with any IP-CAN session. However, it is a stage 3 issue if the packet filters and QoS information are communicated to the BBERF with the same information elements by which QoS rules are communicated.
4. The QoS Rules and Event Triggers received by the target GW (BBERF) are deployed. This will result in bearer binding being performed, according to the rules. This step may trigger IP‑CAN bearer establishment procedures. The details of bearer establishment are IP‑CAN specific.
5. An indication of Gateway Control Session Established is sent to the entity that triggered the initiation of the session.
6. The target GW (BBERF) initiates the IP‑CAN Bearer signalling if required for the QoS Rules and Event Triggers deployed in step 4.
7. The target GW (BBERF) receives the response for the IP‑CAN Bearer signalling.
8. The target GW (BBERF) sends the result of the QoS rule activation to the PCRF, indicating whether the resources requested have been successfully allocated.
9. If case 2b applies the source GW (BBERF) initiates the Gateway Control Session Termination procedure as defined in clause 7.7.2.1, if appropriate.
10. If the PCC rules previously provided to the GW (PCEF) need to be removed due to the result of the QoS rule activation as received in step 8, the PCRF updates the GW (PCEF). The PCRF first waits for the PCEF initiated IP‑CAN session modification procedure to provide the updates. If the IP‑CAN session modification procedure already occurred, the PCRF performs an IP‑CAN session modification procedure with the GW (PCEF).
11. If case 2a applies the PCRF initiates a Gateway Control and QoS Rules Provision procedure towards the target GW (BBERF) as defined in clause 7.7.4, if appropriate, in order to provide any QoS Rules based on the IP‑CAN session modification of step 10. In case 2a a charging ID may be provided together with QoS rules.
12. If case 2a applies the PCRF initiates a Gateway Control and QoS Rules Provision procedure towards the source GW (BBERF) as defined in clause 7.7.4, if appropriate, in order to remove any QoS Rules affected by the GW (BBERF) re-location. If there is no other IP‑CAN session established at the source GW (BBERF), the PCRF instead initiates the Gateway Control Session Termination procedure as defined in clause 7.7.2.2.
7.7.2 Gateway Control Session Termination
7.7.2.1 GW (BBERF)-Initiated Gateway Control Session Termination
Figure 7.7.2-1: BBERF-Initiated Gateway Control Session Termination
1. The GW (BBERF) is requested to terminate its Gateway Control Session.
2. The GW (BBERF) initiates a Gateway Control Session Termination towards the H-PCRF. If the GW (BBERF) is deployed in a visited network, this procedure is initiated by the GW (BBERF) to the V-PCRF. The V-PCRF forwards the information to the H-PCRF.
3. The H-PCRF replies to the GW (BBERF) with an Ack Gateway Control Session Termination. If the GW (BBERF) is deployed in a visited network, this information is sent by the H-PCRF to the V-PCRF. The V-PCRF forwards the information to the GW (BBERF).
4. The GW (BBERF) removes the QoS rules and Event triggers associated with the Gateway Control Session. This means the GW (BBERF) ceases its bearer binding and other Gateway Control functions associated with the QoS rules and Event Triggers.
5. The GW (BBERF) has completed terminating the session and can continue with the activity that prompted this procedure.
7.7.2.2 PCRF-Initiated Gateway Control Session Termination
Figure 7.7.2-2: PCRF-Initiated Gateway Control Session Termination
This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control Session Termination between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-Id and roaming agreements.
In the non-roaming case (Figure 5.1-1) the V-PCRF is not involved.
1. The PCRF is requested to terminate its Gateway Control Session.
2. The PCRF sends a PCRF-Initiated Gateway Control Session Termination to the GW (BBERF).
3. The GW (BBERF) removes the QoS rules and Event triggers associated with the Gateway Control Session. This means the GW (BBERF) ceases its bearer binding and other Gateway Control functions associated with the QoS rules and Event Triggers.
4. If the bearer(s) corresponding to the removed QoS rules are still established, the GW (BBERF) initiates an IP‑CAN specific bearer removal procedure.
5. The GW (BBERF) receives the response for the IP‑CAN specific bearer removal procedure.
6. The GW (BBERF) replies to the PCRF with an PCRF-Initiated Gateway Control Session Termination acknowledgement.
7.7.3 Gateway Control and QoS Rules Request
7.7.3.1 General
There are two cases considered for a Gateway Control and QoS Rules Request depending on the parameters the GW (BBERF) receives:
Case A: In case the GW (BBERF) action does not depend on the subsequent IP‑CAN session modification, the GW (BBERF) can acknowledge the request after interacting with the PCRF.
NOTE 1: If QoS rules have to be updated due to the event reporting, the PCRF shall use the Gateway Control and QoS Rules Provision procedure.
Case B: The GW (BBERF) is requested to obtain QoS rules for a Gateway Control Session or to deliver IP‑CAN-specific parameters or both.
Figure 7.7.3-1: Gateway Control and QoS Rules Request
NOTE 2: If QoS rules have to be updated for case A, the PCRF shall use the Gateway Control and QoS Rules Provision procedure (clause 7.7.4).
This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control and QoS Rules Request between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-Id and roaming agreements.
In the non-roaming case (Figure 5.1-1) the V-PCRF is not involved.
1. The GW (BBERF) is requested to either report an event or obtain QoS rules or both for a Gateway Control Session.
2. The GW (BBERF) sends a Gateway Control and QoS Rules Request to the PCRF and includes the new IP‑CAN bearer establishment modes if changed. The information sent by the GW (BBERF) to the PCRF includes: a request for resource authorization and/or a report corresponding to a deployed Event Trigger.
3. If the GW (BBERF) is only requested to report an event, the GW (BBERF) acknowledges the step 1 by sending a result to the entity that triggered this procedure.
4. The PCRF initiated IP‑CAN Session Modification Procedure may occur as the result of the Gateway Control and QoS Rules Request procedure, either to forward an Event Report to the GW (PCEF) or to issue new or revised PCC Rules and Event Triggers, or both an Event Report and a PCC Rules and Event Triggers provision.
5. If the GW (BBERF) asked for new QoS rules or IP‑CAN-specific parameters need to be delivered back to the GW (BBERF) or both, the PCRF sends a Gateway Control and QoS Rules Reply to the GW (BBERF). This interaction may include QoS Rules and Event Triggers. In case 2a a charging ID may be provided together with QoS rules.
If there are multiple BBFs associated with the IP‑CAN session and the request in Step 2 is from a non-primary BBERF (see clause 6.2.1.5), only QoS rules corresponding to already activated PCC rules are included in the reply. If a request from a non-primary BBERF results in an authorization of a new QoS rule or to a modification of an existing QoS rules, the PCRF shall reject the request.
6. The QoS Rules and Event Triggers, if any, received by the GW (BBERF) are deployed. This will result in bearer binding being performed, according to the rules. This may result in the binding of additional SDFs or a change in the binding of previously bound SDFs. Subsequent events corresponding to the Event Triggers will cause an Event Report to be delivered to the PCRF by means of a Gateway Control and QoS Rules Request procedure.
7. The GW (BBERF) initiates the IP‑CAN Bearer signalling if required for the QoS Rules and Event Triggers deployed in step 6.
8. The GW (BBERF) receives the response for the IP‑CAN Bearer signalling.
9. If the step 5 contained new and/or modified QoS Rules, the result of the QoS rule activation is returned to the PCRF, indicating whether the resources requested have been successfully allocated.
7.7.3.2 Event reporting for PCEF in visited network and locally terminated Gxx interaction
This procedure is only used for the event reporting for a PCEF in the visited network and when the Gxx interaction is locally terminated at the V-PCRF.
Figure 7.7.3-2: Event reporting for PCEF in visited network and locally terminated Gxx interaction
1. The GW (BBERF) is requested to report an event for a Gateway Control Session.
2. The GW (BBERF) sends a Gateway Control and QoS Rules Request to the V-PCRF and includes the new IP‑CAN bearer establishment modes if changed. The information sent by the GW (BBERF) to the V-PCRF includes a report corresponding to a deployed Event Trigger.
3. Since the GW (BBERF) is only requested to report an event, the GW (BBERF) acknowledges the message received in step 1 by sending a result message to the entity that triggered this procedure.
4. The V-PCRF forwards the report corresponding to a deployed Event Trigger to the PCEF.
5. A PCEF initiated IP‑CAN Session Modification Procedure may occur as the result of the received report, either to forward the report about the relevant deployed Event Trigger(s) to the H-PCRF or to request new or revised PCC Rules and Event Triggers, or both.
7.7.4 Gateway Control and QoS Rules Provision
Figure 7.7.4-1: Gateway Control and QoS Rules Provision
This procedure concerns both roaming and non-roaming scenarios. In the roaming case when a Gateway Control Session is used, the V-PCRF should proxy the Gateway Control and QoS Rules Provision between the BBERF in the VPLMN and the H-PCRF over S9 based on PDN-Id and roaming agreements.
In the non-roaming case (Figure 5.1-1) the V-PCRF is not involved.
1. The PCRF is requested to update the QoS Rules and Event triggers for a Gateway Control Session.
2. The PCRF sends a Gateway Control and QoS Rules Provision to the GW (BBERF). It will include QoS Rules and Event Triggers. In case 2a a charging ID may be provided together with QoS rules. If the service data flow is tunnelled at the BBERF, the information about the mobility protocol tunnelling encapsulation header may be included. It is also possible that this interaction includes an Event Report originating from the GW (PCEF) and relayed by the PCRF to the BBERF. This Event Report enables a GW (PCEF)-originating interaction to be sent by way of the PCC infrastructure to the BBERF in situations that communication is needed between the GW (PCEF) and the GW (BBERF) and no interface exists between the GWs.
3. The QoS Rules and Event Triggers received by the GW (BBERF) are deployed. This may result in bearer binding being performed, according to the rules. Subsequent events corresponding to the Event Triggers will cause an Event Report to be delivered to the PCRF by means of a Gateway Control and QoS Rules Request procedure.
4. The GW (BBERF) initiates the IP‑CAN Bearer signalling if required for the QoS Rules and Event Triggers deployed in step 3.
5. The GW (BBERF) receives the response for the IP‑CAN Bearer signalling.
6. The GW (BBERF) sends a Gateway Control and QoS Rules Provision Ack (Result) to the PCRF. The Result information element indicates whether the indicated QoS Rules could be implemented.
7. The PCRF has completed updating the session and can continue with the activity that prompted this procedure.
If there are multiple BBFs associated with the IP‑CAN session (see clause 6.2.1.5), then the processing of the response is as follows depending on whether the BBERF is a primary BBERF or a non-primary BBERF:
– If a primary-BBERF reports failure to install a QoS rule in Step 4, the PCRF also removes the same QoS rule from the non-primary BBERF(s) if any. The PCRF also removes the corresponding PCC rule from the PCEF.
– If a non-primary BBERF reports failure to install a QoS rule, the PCRF updates the enforcement status of the QoS rule for that particular BBERF in its record but does not perform any further action.