9.2.4 Deactivation Procedures

23.0603GPPGeneral Packet Radio Service (GPRS)Release 17Service descriptionStage 2TS

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

9.2.4.1 MS Initiated PDP Context Deactivation Procedure

The PDP Context Deactivation Initiated by MS procedures for A/Gb mode and Iu mode are illustrated in Figure 74 and Figure 75, respectively.

Figure 74: MS Initiated PDP Context Deactivation Procedure for A/Gb mode

NOTE 1: Steps 1, 2, 4 and 6 are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure step (A) is defined in clause 9.2.4.1A.

Figure 75: MS Initiated PDP Context Deactivation Procedure for Iu mode

NOTE 2: Steps 1, 4 and 5 are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure step (A) is defined in clause 9.2.4.1A.

1) The MS sends a Deactivate PDP Context Request (TI, Teardown Ind) message to the SGSN. If the MS deactivates the PDP context created by the PDP Context Activation Procedure, the Teardown Ind shall be sent.

2) In A/Gb mode security functions may be executed. These procedures are defined in clause "Security Function".

3) If the PDP Context was served by a GGSN, the SGSN sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind, CGI/SAI Information) message to the GGSN. If the MS in the Deactivate PDP Context Request message included Teardown Ind, then the SGSN deactivates all PDP contexts associated with this PDP address and the same APN by including Teardown Ind in the Delete PDP Context Request message. The GGSN removes the PDP context(s) and returns a Delete PDP Context Response (TEID) message to the SGSN. If the MS was using a dynamic PDP address allocated by the GGSN, and if the context being deactivated is the last PDP context associated with this PDP address, then the GGSN releases this PDP address and makes it available for subsequent activation by other MSs. The Delete PDP Context messages are sent over the backbone network. The GGSN may interact with the PCRF (refer to TS 23.203 [88]), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF. For PDP Context using a T6b connection to the SCEF the SGSN indicates to the SCEF that the connection for the MS is no longer available according to TS 23.682 [119].

4) The SGSN returns a Deactivate PDP Context Accept (TI) message to the MS. If this deactivates the last PDP context of the UE then an E-UTRAN capable MS not using CIoT GSM Optimization shall set its TIN to "P-TMSI". If PDP contexts remain for the MS, the SGSN recalculates the UE-AMBR and updates the RAN accordingly.

5) In Iu mode, radio access bearer release is done by the RAB Assignment procedure, if a RAB exists for this PDP context.

6) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause "BSS Context".

At GPRS detach, all PDP contexts for the MS are implicitly deactivated.

If the SGSN receives a Deactivate PDP Context Request (TI) message for a PDP context that is currently being activated, the SGSN shall stop the PDP Context Activation procedure without responding to the MS, and continue with the PDP Context Deactivation initiated by MS procedure.

The SGSN determines the Maximum APN Restriction for the remaining PDP contexts and stores this new value for the Maximum APN Restriction.

The CAMEL procedure call shall be performed, see referenced procedure in TS 23.078 [8b]:

C1) CAMEL_GPRS_PDP_Context_Disconnection.

The procedure returns as result "Continue".

9.2.4.1A MS- and SGSN Initiated Bearer Deactivation Procedure using S4

When MS- and SGSN initiates Bearer Deactivation procedure,

– If the Tear Down Indicator (Teardown Ind) is set, the procedure in clause 9.2.4.1A.1 is used.

– Otherwise, the procedure in clause 9.2.4.1A.2 is used.

The procedures described in figures 74a and figure 74b show only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedure given by clauses 9.2.4.1 and 9.2.4.2.

For Bearer Deactivation of PDP Context using a T6b connection to the SCEF the SGSN indicates to the SCEF that the connection for the MS is no longer available according to TS 23.682 [119].

9.2.4.1A.1 MS-and SGSN Initiated PDN connection Deactivation Procedure using S4

The procedure described in figure 74a is used when the MS/SGSN initiates PDN connection deactivation.

Figure 74a: MS- and SGSN Initiated PDN connection Deactivation Procedure using S4

NOTE 1: Steps A) and D) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure step (A1) is defined in TS 23.402 [90]. Steps B and C concern GTP based S5/S8.

A) The EPS Bearer in the Serving GW regarding this particular MS and the PDN are deactivated by the SGSN by sending Delete Session Request (TEID, EPS Bearer Identity, Teardown Ind, User Location Information), to the Serving GW. This message indicates that all bearers belonging to that PDN connection shall be released.

NOTE 2: The SGSN does not modify the ISR status even if the last PDP context is deactivated.

B) The Serving GW sends Delete Session Request (TEID, EPS Bearer Identity, Teardown Ind, User Location Information, User CSG Information) to the PDN GW. This message includes an indication that all bearers belonging to that PDN connection shall be released, i.e. the Teardown Ind. The PDN GW may interact with PCRF (refer to TS 23.203 [88]), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.

C) The PDN GW acknowledges the bearer deactivation to the S‑GW by sending a Delete Session Response (TEID).

D) The Serving GW acknowledges the bearer deactivation to the SGSN with Delete Session Response (TEID).

9.2.4.1A.2 MS-and SGSN Initiated Bearer Deactivation Procedure

The procedure described in figure 74b is used when the MS/SGSN initiates Bearer Deactivation procedure.

In case of RNC Failure, SGSN may based on operator policy either preserve all bearers or initiate the Dedicated Bearer Deactivation procedure, as shown in Figure 74b below. In deactivating the GBR bearers, SGSN may take the EPS bearer QoS into account.

Figure 74b: MS- and SGSN Initiated Bearer Deactivation Procedure using S4

NOTE 1: Steps A), D) and E) are common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure steps (A1) and (A2) are defined in TS 23.402 [90]. Steps B, C and F concern GTP based S5/S8.

A) The SGSN sends the Delete Bearer Command (EPS Bearer Identity) message to the Serving GW to deactivate the selected EPS bearer.

NOTE 2: The SGSN does not modify the ISR status.

B) The Serving GW sends the Delete Bearer Command (EPS Bearer Identity) message to the PDN GW.

C) The PDN GW sends a Delete Bearer Request (TEID, EPS Bearer Identity) message to the Serving GW. The PDN GW may have interacted with PCRF beforehand (refer to TS 23.203 [88]).

If the bearer deleted is the default bearer (i.e. the UE is not supporting the default bearer concept) it is implementation specific whether the PDN GW keeps the rest of the EPS bearer(s) for the PDN connection or whether the PDN GW initiates a deactivation of the PDN connection.

D) The Serving GW sends the Delete Bearer Request (TEID, EPS Bearer Identity) message to the SGSN.

E) The SGSN deletes the bearer contexts related to the deactivated EPS bearer and acknowledges the bearer deactivation to the Serving GW by sending a Delete Bearer Response (TEID, EPS Bearer Identity, User Location Information) message.

F) The Serving GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer deactivation to the PDN GW by sending a Delete Bearer Response (TEID,EPS Bearer Identity, User Location Information, User CSG Information) message. The PDN GW may interact with the PCRF (refer to TS 23.203 [88]), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.

9.2.4.2 SGSN-initiated PDP Context Deactivation Procedure

The PDP Context Deactivation Initiated by SGSN procedure is illustrated in Figure 76.

Figure 76: SGSN-initiated PDP Context Deactivation Procedure

NOTE 1: Steps 2‑4 are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure step (A) is defined in clause 9.2.4.1A.

This procedure is also used as part of the SIPTO using GW selection function when the SGSN determines that GW relocation is desirable. In this situation the SGSN deactivates the relevant PDN connection(s) using the "reactivation requested" cause value, and the UE should then re-establish those PDN connection(s) towards the same APN(s).

1) If the PDP Context was served by a GGSN, the SGSN sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind, CGI/SAI) message to the GGSN. If Teardown Ind is included by the SGSN, the GGSN deactivates all PDP contexts associated with this PDP address and the same APN. The GGSN removes the PDP context and returns a Delete PDP Context Response (TEID) message to the SGSN. If the MS was using a dynamic PDP address allocated by the GGSN, and if the context being deactivated is the last PDP context associated with this PDP address, the GGSN releases this PDP address and makes it available for subsequent activation by other MSs. The Delete PDP Context messages are sent over the backbone network. The SGSN may not wait for the response from the GGSN before sending the Deactivate PDP Context Request message. For PDP Context using a T6b connection to the SCEF the SGSN indicates to the SCEF that the connection for the MS is no longer available according to TS 23.682 [119].

NOTE 2: The CGI/SAI may be outdated as the interaction with MS and RAN happen after step 1.

The GGSN may interact with PCRF (refer to TS 23.203 [88]), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.

2) The SGSN sends a Deactivate PDP Context Request (TI, Teardown Ind, Cause, WLAN offloadability indication) message to the MS. If Teardown Ind is included, all PDP contexts associated with this PDP address and the same APN are deactivated. The MS removes the PDP context(s) and returns a Deactivate PDP Context Accept (TI) message to the SGSN. If this deactivates the last PDP context of the UE then an E-UTRAN capable MS not using CIoT GSM Optimization shall set its TIN to "P-TMSI". If PDP contexts remain for the MS, the SGSN recalculates the UE-AMBR and updates the RAN accordingly.

If the request is deactivation with reactivation from SGSN, the UE starts MS initiated PDP context Activation Procedure as specified in clauses 9.2.2.1 and 9.2.2.1A by using the same APN of the released PDN connection.

The SGSN may include an indication whether the traffic of this PDP context is allowed to be offloaded to WLAN as described in clause 5.3.21 if some PDP contexts associated with this PDP address and the same APN are not deactivated.

3) In Iu mode, radio access bearer release is done by the RAB Assignment procedure.

4) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause "BSS Context".

The SGSN determines the Maximum APN Restriction for the remaining PDP contexts and stores this new value for the Maximum APN Restriction.

The CAMEL procedure call shall be performed, see referenced procedure in TS 23.078 [8b]:

C1) CAMEL_GPRS_PDP_Context_Disconnection

The procedure returns as result "Continue".

9.2.4.3 GGSN-initiated PDP Context Deactivation Procedure

The PDP Context Deactivation Initiated by GGSN procedure is illustrated in Figure 77.

Figure 77: GGSN-initiated PDP Context Deactivation Procedure

NOTE: Steps 2, 4 and ‑5 are common for architecture variants using Gn/Gp based interaction with GGSN and using S4 based interaction with S‑GW and P‑GW. For an S4 based interaction with S‑GW and P‑GW, procedure step (A) is defined in clause 9.2.4.3A and step (B) is defined in clause 9.2.4.3B.

1) The GGSN sends a Delete PDP Context Request (TEID, NSAPI, Teardown Ind) message to the SGSN. Teardown Ind indicates whether or not all PDP contexts associated with this PDP address and the same APN shall be deactivated.

For an emergency call related PDP address, the GGSN initiates the deactivation of all PDP contexts related to that emergency PDP address when the PDP context is inactive (i.e. not transferring any packets) for a configured period of time or when triggered by dynamic PCC.

2) The SGSN sends a Deactivate PDP Context Request (TI, Teardown Ind, Cause, WLAN offloadability indication) message to the MS. If Teardown Ind was included by the SGSN, then all PDP contexts associated with this PDP address and the same APN are deactivated. The MS removes the PDP context(s) and returns a Deactivate PDP Context Accept (TI) message to the SGSN. If this deactivates the last PDP context of the UE then an E-UTRAN capable MS shall set its TIN to "P-TMSI".

3) The SGSN returns a Delete PDP Context Response (TEID, CGI/SAI) message to the GGSN. If the MS was using a dynamic PDP address allocated by the GGSN, and if the context being deactivated is the last PDP context associated with this PDP address, the GGSN releases this PDP address and makes it available for subsequent activation by other MSs. The Delete PDP Context messages are sent over the backbone network. The SGSN may not wait for the response from the MS before sending the Delete PDP Context Response message. If PDP contexts remain for the MS, the SGSN recalculates the UE-AMBR and updates the RAN accordingly. If there is no signalling with the MS, e.g. because the MS is in PMM_IDLE or STANDBY state, the SGSN provides the last known CGI/SAI.

If extended idle mode DRX is enabled, then the SGSN acknowledges the bearer deactivation to the GGSN and at the same time the SGSN initiates the deactivation towards the MS.

The GGSN may interact with PCRF (refer to TS 23.203 [88]), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.

4) In Iu mode, radio access bearer release is done by the RAB Assignment procedure.

5) In A/Gb mode, BSS packet flow context procedures may be executed. These procedures are defined in clause "BSS Context".

The SGSN determines the Maximum APN Restriction for the remaining PDP contexts and stores this new value for the Maximum APN Restriction.

The CAMEL procedure call shall be performed, see referenced procedure in TS 23.078 [8b]:

C1) CAMEL_GPRS_PDP_Context_Disconnection.

The procedure returns as result "Continue".

9.2.4.3A PDN GW initiated Bearer Deactivation Procedure using S4, part 1

The procedure described in figures 77 shows only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedure given by clause 9.2.4.3.

Figure 77a: PDN GW initiated Bearer Deactivation Procedure using S4, part 1

NOTE: Step B) is common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure step (A1) is defined in TS 23.402 [90]. Step A) concern GTP based S5/S8.

A) The PDN GW sends a Delete Bearer Request (TEID, EPS Bearer Identity, Cause) message to the Serving GW. This message may include an indication that all bearers belonging to that PDN connection shall be released. If the PDN GW deactivates the PDP context created by the PDP Context Activation Procedure, the Teardown Ind shall be sent. The PDN GW may have interacted with PCRF beforehand (refer to TS 23.203 [88]).

If the Delete Bearer Request message is sent due to "handover without optimization from 3GPP to non-3GPP" then the PDN GW includes the ‘Cause’ IE set to ‘ RAT changed from 3GPP to Non-3GPP’.

For an emergency PDN connection the PDN GW initiates the deactivation of all bearers of that emergency PDN connection when the PDN connection is inactive (i.e. not transferring any packets) for a configured period of time or when triggered by dynamic PCC.

B) The Serving GW sends the Delete Bearer Request (TEID, EPS Bearer Identity, Cause) message to the SGSN. This message can include an indication that all bearers belonging to that PDN connection shall be released.

If all the bearers belonging to a UE are released due to "handover without optimization from 3GPP to non-3GPP", the SGSN changes the MM state of the UE to IDLE (GERAN network) or PMM-DETACHED (UTRAN network).

9.2.4.3B PDN GW initiated Bearer Deactivation Procedure using S4, part 2

The procedure described in figures 77b shows only the steps, due to use of S4, that are different from the Gn/Gp variant of the procedure given by clause 9.2.4.3

Figure 77b: PDN GW initiated Bearer Deactivation Procedure using S4, part 2

NOTE 1: Step A) is common for architecture variants with GTP based S5/S8 and PMIP-based S5/S8. For a PMIP-based S5/S8, procedure step (B1) is defined in TS 23.402 [90]. Step B) concerns GTP-based S5/S8.

A) The SGSN deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer deactivation to the Serving GW by sending a Delete Bearer Response (TEID, EPS Bearer Identity, User Location Information) message. If there is no signalling with the MS, e.g. because the MS is in PMM_IDLE or STANDBY state, the SGSN provides the last known CGI/SAI.

The SGSN does not modify the ISR status unless the bearer deactivation occurs for the last PDN connection in which case the SGSN deactivates ISR.

If extended idle mode DRX is enabled, then the SGSN acknowledges the bearer deactivation to the Serving GW and at the same time the SGSN initiates the deactivation towards the MS.

B) The Serving GW deletes the bearer context related to the deactivated EPS bearer and acknowledges the bearer deactivation to the PDN GW by sending a Delete Bearer Response (TEID, EPS Bearer Identity, User Location Information) message. The PDN GW may interact with PCRF (refer to TS 23.203 [88]), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.