Content for &nbsp; TS 23.060 &nbsp; Word version:&nbsp; 18.0.0

UTRAN initiates the procedure by sending a RAB Release Request (For each RAB to be released: RAB ID, Cause) message to the SGSN.

Step 1a.

If PDP Contexts associated with the released RABs are using streaming or conversational traffic class and to be preserved, or Direct Tunnel was established the SGSN sends Update PDP Context Request to the GGSN(s) concerned to establish the GTP tunnel between SGSN and GGSN. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an Update PDP Context Response. The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN shall not negotiate the QoS attributes. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. See clause12.7.2.2 when S4 interface is used.

The SGSN sends a RAB Assignment Request (For each RAB to be released: RAB ID, Cause) to the UTRAN.

The Radio Bearer(s) are released if still existing.

Figure 88b: RAB Release Procedure Using S4

UTRAN sends a RAB Assignment Response (For each released RAB: RAB ID, GTP SND, GTP SNU) to the SGSN. GTP SND and GTP SNU enable the SGSN to restore the values in case the PDP context is maintained and the RAB is re-established at a later stage.

If the RAB for the LIPA PDP Context is released, the HNB informs the collocated L-GW by internal signalling to release the direct user plane path between the L-GW and HNB of the LIPA PDP context.

12.7.2.2 RAB Release Procedure using S4 |R8| p. 296

12722The following illustrates the procedure between SGSN and S-GW when RAB Release Procedures takes place over S4. The procedure between MS and SGSN is same as specified in clause 12.7.2.1.

Reproduction of 3GPP TS 23.060, Fig. 88b: RAB Release Procedure Using S4

The SGSN deactivates affected PDP context using streaming or conversational traffic class as specified in clause 9.2.4.2. For all other traffic classes, the SGSN preserves the affected PDP context.

If PDP Contexts associated with the released RAB is to be preserved and Direct Tunnel is established the SGSN sends Release Access Bearers Request to the S-GW concerned to remove RNC address and TEID.

S-GW sends Release Access Bearers Response to SGSN. The SGSN update the Address for User Plane and TEID for downlink data.

12.7.3 Iu Release Procedure p. 297

12.7.3.1 Iu Release Procedure Using Gn/Gp |R8| p. 297

This procedure is used to release the Iu interface. This procedure also triggers the release of all the Iu connections and changes the 3G SGSN PMM state to PMM IDLE. Both RAN-initiated and SGSN-initiated Iu release procedures are shown in Figure 89a.

Reproduction of 3GPP TS 23.060, Fig. 89a: Iu Release Procedure Using Gn/Gp

Figure 89a: Iu Release Procedure Using Gn/Gp

The RAN notices that the RRC connection has been released or detects a need to release the radio resources. It sends an Iu Release Request (Cause) message to the SGSN. Cause indicates the reason for the release (e.g. O&M Intervention, Unspecified Failure, User Inactivity, Repeated Integrity Checking Failure, or Release due to UE generated signalling connection release). User Inactivity means that the RAN decided to release an MS that shows no more activity, in the case where the MS has only non real-time RABs established, in order to optimise the radio usage after the RRC-Connection-Release timer expired.

Step 1a.

If PDP Contexts associated with the released RABs are using streaming or conversational traffic class and to be preserved, or Direct Tunnel was established the SGSN sends Update PDP Context Request to the GGSN(s) concerned to establish the GTP tunnel between SGSN and GGSN. The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN(s) shall not negotiate the QoS attributes. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an Update PDP Context Response. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. See clause 12.7.3.2 when S4 interface is used.

The SGSN releases the Iu by sending the Iu Release Command (Cause) message to the RAN. This message may be triggered either by an Iu Release Request message, or by another SGSN event (e.g. authentication failure, detach or the subscription to the CSG ID expires). The SGSN shall take the responsibility to release the Iu interface when the UE has no active PDP context, either immediately or after some timeout. It is optional for the SGSN to send the Iu Release Command message after an Iu Release Request message with Cause set to User Inactivity is received from the RAN.

If the RRC connection is not already released (Cause = User Inactivity), the RAN sends a Release RRC Connection message to the MS.

Figure 89b: Iu Release Procedure Using S4

The MS returns a Release RRC Connection Acknowledge message to the RAN.

Step 5.

The RAN confirms the Iu release by returning an Iu Release Completion (for each released RAB: RAB ID, GTP SND, GTP SNU) message to the SGSN. GTP SND and GTP SNU enable the SGSN to restore the values in case the PDP context is maintained and the RAB is re-established at a later stage.

If the RNC does not receive the Release RRC Connection Acknowledge message and if Cause is different from Authentication Failure or Detach, it should send a failure message to the SGSN, and the SGSN should stay in the MM CONNECTED state.

If LIPA is active for a PDN connection, the HNB informs the collocated L-GW by internal signalling to release the direct user plane path between the L-GW and the HNB.

After Iu release, the MS and the SGSN shall modify PDP context(s) that use streaming or conversational traffic class according to the rules in clause "RNC-Initiated PDP Context Modification Procedure".

12.7.3.2 Iu Release Procedure Using S4 |R8| p. 298

The following illustrates the procedure between SGSN and S-GW when Iu Release Procedures takes place over S4. The procedure between MS and SGSN is same as specified in clause 12.7.3.1.

Reproduction of 3GPP TS 23.060, Fig. 89b: Iu Release Procedure Using S4

The SGSN deactivates the PDP contexts using streaming or conversational traffic class as specified in clause 9.2.4.2. For all other cases, the SGSN preserves the PDP contexts.

In case of RNC Failure, SGSN may based on operator policy either preserve all bearers or initiate the Dedicated Bearer Deactivation procedure. See clause 9.2.4.1A.2.

If PDP Contexts associated with the released RABs are to be preserved and:

if ISR is activated or Direct tunnel is established, the SGSN shall send Release Access Bearers Request to the S-GW. For Direct Tunnel, the S-GW removes RNC address for user plane and downlink S12 GTP-U TEID. Otherwise the S-GW removes the SGSN addresses for user plane and downlink S4 GTP-U TEIDs.
in other cases the SGSN can optionally send a Release Access Bearers Request to the SGW to remove the downlink user plane on S4.

The S-GW returns a Release Access Bearers Response to SGSN.

12.7.4 RAB Assignment Procedure p. 299

12.7.4.1 RAB Assignment Procedure Using Gn/Gp |R8| p. 299

The purpose of the RAB Assignment procedure is to enable establishment of new RABs for a given MS and/or modification and/or release of already established RABs. When this procedure is executed and if there is any PDP context without radio access bearer assigned, the SGSN will decide which RABs to re-establish. The same messages are used for the three mentioned actions and it is only the content carried by the messages that is different. The RAB Assignment procedure, which is shown below, is specified in TS 25.413. The RRC protocol is specified in TS 25.331.

Reproduction of 3GPP TS 23.060, Fig. 90a: RAB Assignment Procedure Using Gn/Gp

Figure 90a: RAB Assignment Procedure Using Gn/Gp

For LIPA or SIPTO at the local network with L-GW function collocated with the HNB PDN connection, when the L-GW receives the downlink data for an MS after the direct user plane path between the HNB and L-GW is released for that PDP context as defined in clause 12.7.2, the L GW sends the first downlink user packet to the SGSN and buffers all other downlink user packets.

The SGSN sends a RAB Assignment Request (MSISDN, APN, Charging characteristics) message to the RAN to establish, modify, or release one or several RABs. For each requested RAB or modified, if the RAB is allowed for queuing and the resource situation requires it, the RAN may place the RAB in the establishment queue. If Direct Tunnel is used the SGSN provides to the RNC the GGSN's Address(es) for User Plane and TEID(s) for Uplink data. If any Release 7 new QoS IEs i.e. extended maximum bitrate and/or extended guaranteed bitrate are requested, QoS negotiation should be allowed. For RABs belonging to a PDP context/PDN connection for local IP access or SIPTO at the Local Network with L-GW function collocated with the HNB, the RAB Assignment Request message includes a Correlation ID for enabling the direct user plane path between the HNB and the L GW. For RABs belonging to a PDP context/PDN connection for SIPTO at the Local Network with L GW function collocated with the HNB, the RAB Assignment Request message includes a SIPTO Correlation ID for enabling the direct user plane path between the HNB and the L GW.

The SGSN may add, modify or remove the UE-AMBR in parallel to any requested RAB procedures. If the Access Restriction is present in the MM context, the Service Handover related information shall be included by S4-SGSN for the RAB Assignment Request message in order for RNC to restrict the UE in connected mode to handover to the RAT prohibited by the Access Restriction. MSISDN, APN and Charging characteristics are optional parameters and only transferred if SGSN supports SIPTO at Iu-ps.

The RAN establishes, modifies, or releases the appropriate radio bearers.

The RAN returns a RAB Assignment Response message to the SGSN. If the request to establish or modify one or several RABs has been queued, the RAN will report the outcome of the establishment or modification in subsequent RAB Assignment Response messages. The RAN returned MBR and/or GBR shall not exceed the maximum value corresponding to the 3GPP release the UE supports. If the SGSN receives a RAB Assignment Response message with a cause indicating that the requested QoS profile(s) can not be provided (e.g. "Requested Maximum Bit Rate not Available"), then the SGSN may send a new RAB Assignment Request message with different QoS profile(s). The number of re-attempts, if any, as well as how the new QoS profile(s) values are determined is implementation dependent. If the LIPA or SIPTO at the Local Network with L-GW function collocated with the HNB PDP context is requested in the RAB Assignment, the internal direct user plane path is established between the HNB and L-GW. The downlink packet in the SGSN is forwarded to the HNB and the packets buffered in the L-GW are forwarded to the HNB on the direct user plane path.

Figure 90b: RAB Assignment Procedure Using S4

If the SGSN established Direct Tunnel it shall send Update PDP Context Request to the GGSN(s) concerned and include the RNC's Address for User Plane, downlink TEID for data, No QoS negotiation indication and the DTI. DTI is used to instruct the GGSN to apply Direct Tunnel specific error handling as described in clause 13.8, The No QoS negotiation indication is set in Update PDP Context Request to indicate to the GGSN that the SGSN does not upgrade the previously negotiated QoS attributes and that the GGSN(s) shall not negotiate the QoS attributes. The GGSN(s) update the Address for User Plane and TEID for downlink data and return an Update PDP Context Response. The GGSN(s) shall not include a PCO in the Update PDP Context Response if the No QoS negotiation indication is set. See clause 12.7.4.2 when S4 interface is used.

12.7.4.2 RAB Assignment Procedure Using S4 |R8| p. 300

The following illustrates the procedure between SGSN and S-GW when RAB Assignment Procedures takes place over S4. The procedure between MS and SGSN is same as specified in clause 12.7.4.1.

For LIPA PDN connection, the downlink data handling in the L-GW as described in clause 12.7.4.1 is applied with one difference: If the SGSN established direct tunnel, the L-GW sends the first downlink user packet to the Serving GW. Otherwise, if the SGSN did not establish the direct tunnel, the L-GW sends the first downlink user packet to the SGSN.

If the SGSN receives a RAB Assignment Response message with a cause indicating that the requested QoS profile(s) can not be provided, the SGSN shall not re-attempt to send a new RAB Assignment Request message with different QoS profile(s) and also the step A and B below shall not be performed for the non-established RABs.

Reproduction of 3GPP TS 23.060, Fig. 90b: RAB Assignment Procedure Using S4

If the SGSN established Direct Tunnel it shall send Modify Bearer Request to the S-GW concerned and include the RNC's Address for User Plane, downlink TEID for data, No QoS negotiation indication and the DTI. DTI is used to instruct th12742e S-GW to apply Direct Tunnel specific error handling as described in clause 13.8.

The S-GW update the Address for User Plane and TEID for downlink data and return a Modify Bearer Response to S-GW.

12.7.5 Location Reporting Procedure p. 300

This procedure is used by an SGSN to request the RAN to report where the MS is currently located, or to report when the MS moves into or out of a given service area. This procedure is defined for Iu mode and may be used for services that require location information (e.g. CAMEL and emergency calls).

Reproduction of 3GPP TS 23.060, Fig. 91: Location Reporting Procedure

Figure 91: Location Reporting Procedure

The SGSN detects from the subscriber data the need to monitor in which service area an MS in the PMM CONNECTED state with an Iu interface connection is located. The SGSN sends a Location Reporting Control (Service Area Code(s), Reporting Type) message to the RAN. The RAN stores the Service Area Code(s) as reporting area(s) for this MS. For example, a service area may be a location area with restricted access. Reporting Type indicates whether the message is intended to start a reporting period or trigger a stand-alone report about the current location of the MS.

The RAN detects that the MS moves into or out of a reporting area. Alternatively, the RAN derives the current location of the MS if this was requested by the SGSN.

The RAN sends a Location Report message informing the SGSN about where the MS is located. When the SGSN has requested the current location of the MS, the RAN shall include the requested location information , i.e. the Service Area Indication, in the Location Report message, if the RAN cannot determine current Service Area of the mobile, it indicates that the request could not be fulfilled, and may report Last Known Service Area with an indication of how long has past since the mobile was known to be in the indicated Service Area. The SGSN may then perform specific actions.