Content for TS 23.203 Word version: 19.0.0
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.3 IP-CAN Session Termination
7.3.1 UE initiated IP-CAN Session termination
7.3.2 GW (PCEF) initiated IP-CAN Session termination
...
...
7.3 IP-CAN Session Termination p. 135
7.3.1 UE initiated IP-CAN Session termination p. 135
This procedure concerns both roaming and non-roaming scenarios. In the roaming case when home routed access is used (Figure 5.1-3) or if case 2a applies (as defined in clause 7.1) for Local Breakout (Figure 5.1-4), the V-PCRF should proxy the GW (BBERF) initiated Gateway Control Session Termination or the Gateway Control and QoS Rules Provision between the BBERF in the VPLMN and the H-PCRF. For those cases it is also the H-PCRF that initiates the PCRF initiated Gateway Control Session Termination procedure or the Gateway Control and QoS Rules Provision procedure and proxy the information over S9 to the BBERF through the V-PCRF.
For the Local breakout scenario (Figure 5.1-4) the V-PCRF shall proxy Indication and Acknowledge of IP-CAN Session Termination over S9 between the PCEF in the VPLMN and the H-PCRF. If the AF resides in the VPLMN, the V-PCRF shall proxy AF session signalling over S9 between the AF and the H-PCRF.
For the same scenario if either case 1 or case 2b applies (as defined in clause 7.1), the V-PCRF may respond to/initiate the Gateway Control Session procedures locally without notifying the H-PCRF.
In the non-roaming case (Figure 5.1-1) the V-PCRF is not involved at all.
Step 1.
If case 2b applies, the GW (BBERF) receives a request to remove the IP-CAN session. In case 2a, the request goes transparently through the GW (BBERF). In all cases, the GW (PCEF) receives a request to remove the IP-CAN session.
Step 2.
If case 2b applies, the GW (BBERF)-initiated GW Control Session Termination procedure as defined in clause 7.7.2.1 is initiated.
Step 3.
The GW (PCEF) indicates that the IP-CAN Session is being removed and provides relevant information to the PCRF.
Step 4.
The PCRF finds the PCC Rules that require an AF to be notified and removes PCC Rules for the IP-CAN session.
Step 5.
The GW (PCEF) removes all PCC Rules associated with the IP-CAN session.
Step 6.
The PCRF notifies the AF that there are no transmission resources for the service if this is requested by the AF.
Step 7.
The AF acknowledges the notification of the loss of transmission resources.
Step 8.
If this is the last IP-CAN session for this subscriber requiring policy counter status reporting, the Final Spending Limit Report Request as defined in clause 7.9.3 is sent. If any existing IP-CAN sessions for this subscriber require policy counter status reporting, the Intermediate Spending Limit Report Request as defined in clause 7.9.2 may be sent to alter the list of subscribed policy counters.
Step 9.
If there is an active Sd session between TDF and PCRF, the PCRF terminates it.
Step 10.
For the solicited application reporting, the TDF deactivates all the ADC Rules associated with the TDF session. The TDF acknowledges the termination request from the PCRF.
Step 11.
If online charging is applicable for the TDF, the TDF issues the final reports and returns the remaining credit to the OCS.
Step 12.
The OCS acknowledges the credit report and terminates the online charging session with the TDF.
Step 13.
The PCRF removes the information related to the terminated IP-CAN Session (subscription information etc.), and acknowledges to the GW (PCEF) that the PCRF handling of the IP-CAN session has terminated. This interaction is the response to the GW (PCEF) request in step 3.
Step 14.
The GW (PCEF) continues the IP-CAN Session removal procedure.
Step 15.
If case 2a applies, the GW Control and QoS Rules Provision procedure as defined in clause 7.7.4 may be initiated to remove the QoS rules associated with the IP-CAN session being terminated. This applies e.g. in case the Gateway Control Session shall remain to serve other IP-CAN sessions.
Alternatively, if case 2a applies and the PCRF determines that all QoS rules are to be removed and the Gateway Control Session shall be terminated, the PCRF-initiated GW Control Session Termination procedure as defined in clause 7.7.2.2 is initiated. This applies e.g. in case the UE is detached and the CoA acquired by the UE is not used for any other IP-CAN session.
Step 16.
If online charging is applicable for the PCEF, the PCEF issues the final reports and returns the remaining credit to the OCS.
Step 17.
The OCS acknowledges that credit report and terminates the online charging session with the PCEF.
Step 18.
The PCRF sends a cancellation notification request to the SPR if it has subscribed such notification. If all IP-CAN sessions of the user to the same APN are terminated, the PCRF stores the remaining usage allowance in the SPR.
Step 19.
The SPR sends a response to the PCRF.
Step 20.
If RUCI reporting from RCAF to PCRF is used, the PCRF sends a Release context request message to the RCAF using the previously stored identity of the RCAF.
Step 21.
RCAF acknowledges this by sending the Release context response message to the PCRF. The RCAF releases the context corresponding to the given UE for the given APN, including any reporting restrictions. This also implies that the RCAF does not indicate to the PCRF that the congestion state is over. In case of multiple PCRFs being in simultaneous use for a given UE, a Release context request message from a PCRF applies to the UE context specific to the given Np connection only, identified by the APN. The RCAF can completely release all context information for a given UE when it has released the context for each Np connection of the given UE.
Step 22.
If the PCRF has provided traffic steering control information to the TSSF for the IP-CAN session, the PCRF sends a request to the TSSF to remove the traffic steering control information associated to the UE IPv4 address and/or to the UE IPv6 prefix for the terminated IP-CAN session.
Step 23.
The TSSF acknowledges the removal of the traffic steering control information.
7.3.2 GW (PCEF) initiated IP-CAN Session termination p. 138
This procedure concerns both roaming and non-roaming scenarios. In the roaming case when home routed access is used (Figure 5.1-3) or if case 2a applies (as defined in clause 7.1) for Local Breakout (Figure 5.1-4), the V-PCRF should proxy the GW (BBERF) initiated Gateway Control Session Termination or the Gateway Control and QoS Rules Provision between the BBERF in the VPLMN and the H-PCRF. For those cases it is also the H-PCRF that initiates the PCRF initiated Gateway Control Session Termination procedure or the Gateway Control and QoS Rules Provision procedure and proxy the information over S9 to the BBERF through the V-PCRF.
For the Local breakout scenario (Figure 5.1-4) the V-PCRF shall proxy Indication and Acknowledge of IP-CAN Session Termination over S9 between the PCEF in the VPLMN and the H-PCRF. If the AF relies in the VPLMN, the V-PCRF shall proxy AF session signalling over S9 between the AF and the H-PCRF.
For the same scenario if either case 1 or case 2b applies (as defined in clause 7.1), the V-PCRF may respond to/initiate the Gateway Control Session procedures locally without notifying the H-PCRF.
In the non-roaming case (Figure 5.1-1) the V-PCRF is not involved at all.
Step 1.
The GW (PCEF) detects that IP-CAN Session termination is required.
Step 2.
The GW (PCEF) sends a request to remove the IP-CAN session.
Step 3.
If case 2b applies, the GW (BBERF)-initiated GW Control Session Termination procedure as defined in clause 7.7.2.1 is initiated.
Step 4.
The GW (PCEF) receives the response for the IP-CAN session removal.
Step 5.
The GW (PCEF) indicates the IP-CAN Session termination and provides the relevant information to the PCRF.
Step 6.
The PCRF finds the PCC Rules that require an AF to be notified.
Step 7.
The PCRF notifies the AF that there are no transmission resources for the service if this is requested by the AF.
Step 8.
The AF acknowledges the notification on the loss of transmission resources.
Step 9.
If this is the last IP-CAN session for this subscriber requiring policy counter status reporting, the Final Spending Limit Report Request as defined in clause 7.9.3 is sent. If any existing IP-CAN sessions for this subscriber require policy counter status reporting, the Intermediate Spending Limit Report Request as defined in clause 7.9.2 may be sent to alter the list of subscribed policy counters.
Step 10.
The GW (PCEF) removes all the PCC Rules associated with the IP-CAN session.
Step 11.
If there is an active Sd session between TDF and PCRF, the PCRF informs TDF about IP-CAN session termination.
Step 12.
For the solicited application reporting, the TDF deactivates all the ADC Rules associated with the TDF session. The TDF acknowledges the termination request from the PCRF.
Step 13.
If online charging is applicable for the TDF, the TDF issues the final reports and returns the remaining credit to the OCS.
Step 14.
The OCS acknowledges the credit report and terminates the online charging session with the TDF.
Step 15.
The PCRF removes the information related to the terminated IP-CAN Session (subscription information etc.), and acknowledges the IP-CAN Session termination.
Step 16.
If case 2a applies, the GW Control and QoS Rules Provision procedure as defined in clause 7.7.4 may be initiated to remove the QoS rules associated with the IP-CAN session being terminated. This applies e.g. in case the Gateway Control Session shall remain to serve other IP-CAN sessions.
Alternatively, if case 2a applies and the PCRF determines that the Gateway Control session shall be terminated, the PCRF-initiated GW Control Session Termination procedure as defined in clause 7.7.2.2 is initiated. This applies e.g. in case the UE is detached and the CoA acquired by the UE is not used for any other IP-CAN session.
Step 17.
If online charging is applicable for the PCEF, the PCEF issues final reports and returns the remaining credit to the OCS.
Step 18.
The OCS acknowledges the credit report and terminates the online charging session.
Step 19.
The PCRF sends a cancellation notification request to the SPR if it has subscribed such notification. If all IP-CAN sessions of the user to the same APN are terminated, the PCRF stores the remaining usage allowance in the SPR.
Step 20.
The SPR sends a response to the PCRF.
Step 21.
If RUCI reporting from RCAF to PCRF is used, the PCRF sends a Release context request message to the RCAF using the previously stored identity of the RCAF.
Step 22.
RCAF acknowledges this by sending the Release context response message to the PCRF. The RCAF releases the context corresponding to the given UE for the given APN, including any reporting restrictions. This also implies that the RCAF does not indicate to the PCRF that the congestion state is over. In case of multiple PCRFs being in simultaneous use for a given UE, a Release context request message from a PCRF applies to the UE context specific to the given Np connection only, identified by the APN. The RCAF can completely release all context information for a given UE when it has released the context for each Np connection of the given UE.
Step 23.
If the PCRF has provided traffic steering control information to the TSSF for the IP-CAN session, the PCRF sends a request to the TSSF to remove the traffic steering control information associated to the UE IPv4 address and/or the UE IPv6 prefix for the terminated IP-CAN session.
Step 24.
The TSSF acknowledges the removal of the traffic steering control information.
