Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.060  Word version:  18.0.0

Top   Top   Up   Prev   Next
1…   5…   5.3.8…   5.4…   5.4.2…   5.4.9…   5.6…   5.6.2   5.6.3…   5.6.3.7…   5.7…   6…   6.3…   6.5…   6.6…   6.8…   6.9…   6.9.1.3   6.9.2…   6.9.2.2…   6.9.2.2.2   6.9.2.2.3…   6.9.2.2.5…   6.9.3…   6.10…   6.12…   6.13…   6.13.1.2…   6.13.2…   6.13.2.2   6.14…   8…   8.2   9…   9.2.2…   9.2.2.2   9.2.2.3…   9.2.3…   9.2.3.2…   9.2.3.3…   9.2.4…   9.2.4.2…   9.2.5…   12…   12.5…   12.6…   12.7…   12.8…   13…   14…   15…   15.3…   16…   16.2…   A…   B…

 

9.2.4.2  SGSN-initiated PDP Context Deactivation Procedurep. 276

The PDP Context Deactivation Initiated by SGSN procedure is illustrated in Figure 76.
Reproduction of 3GPP TS 23.060, Fig. 76: SGSN-initiated PDP Context Deactivation Procedure
Up
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).
Step 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.
The GGSN may interact with PCRF (refer to TS 23.203), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.
Step 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.
Step 3.
In Iu mode, radio access bearer release is done by the RAB Assignment procedure.
Step 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:
  • C1) CAMEL_GPRS_PDP_Context_Disconnection
The procedure returns as result "Continue".
Up

9.2.4.3  GGSN-initiated PDP Context Deactivation Procedurep. 277

The PDP Context Deactivation Initiated by GGSN procedure is illustrated in Figure 77.
Reproduction of 3GPP TS 23.060, Fig. 77: GGSN-initiated PDP Context Deactivation Procedure
Up
Step 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.
Step 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".
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.
Step 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), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.
Step 4.
In Iu mode, radio access bearer release is done by the RAB Assignment procedure.
Step 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:
  • C1) CAMEL_GPRS_PDP_Context_Disconnection.
The procedure returns as result "Continue".
Up

9.2.4.3A  PDN GW initiated Bearer Deactivation Procedure using S4, part 1 |R8|p. 278

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.
Reproduction of 3GPP TS 23.060, Fig. 77a: PDN-GW initiated Bearer Deactivation Procedure using S4, part 1
Up
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).
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).
Up

9.2.4.3B  PDN GW initiated Bearer Deactivation Procedure using S4, part 2 |R8|p. 279

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
Reproduction of 3GPP TS 23.060, Fig. 77b: PDN-GW initiated Bearer Deactivation Procedure using S4, part 2
Up
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), e.g. to deliver User Location Information and/or UE Time Zone Information if it was requested by the PRCF.
Up

Up   Top   ToC