4.3.14 Signalling procedures

23.1213GPPArchitectural requirements for Release 1999Release 1999TS

4.3.14.1 Idle mode procedures

The signalling procedures shown in the following subclauses do not represent the complete set of possibilities, nor do they mandate this kind of operation. The standard will specify a set of elementary procedures for each interface, which may be combined in different ways in an implementation. Therefore these sequences are merely examples of a typical implementation. By default the combined procedures as defined in GSM 03.60 are also applicable when using Gs.

Furthermore the list of parameters may not be complete, but should only be seen as examples of possible information carried by the messages.

4.3.14.1.1 Location Area update

This example shows location registration when changing Location Area including change of 3G-MSC/VLR and when the UE is in MM idle state towards the 3G_MSC/VLR.

The illustrated transfer of MM signalling to/from the UE uses an established RRC connection. This RRC connection can have been established beforehand due to ongoing interwork between UE and 3G-SGSN or be established only for this location registration procedure towards the 3G_MSC/VLR.

For each indicated MM message sent in this case to/from UE, the CN discriminator indicates 3G_MSC/VLR.

Figure 4.17: Interface information transfer for location update when changing VLR area

– The RRC connection is established, if not already done. The UE sends the initial message Location Area Update Request (old TMSI, old LAI, etc.) to the new 3G_MSC/VLR. The old TMSI and the old LAI are assigned data in UMTS. The SRNS transfers the message to the 3G_MSC/VLR. The sending of this message to 3G_MSC/VLR will also imply establishment of a signalling connection between SRNS and 3G_MSC/VLR for the concerned UE. The UTRAN shall add the RAC and the LAC of the cell where the message was received before passing the message to the MSC.

– The new 3G_MSC/VLR sends an Send Identification Request (old TMSI) to the old 3G_MSC/VLR to get the IMSI for the UE. (The old LAI received from UE is used to derive the old 3G_MSC/VLR identity/address.) The old 3G_MSC/VLR responds with Send Identification Ack. (IMSI and Authentication triplets).

– Security functions may be executed.

– The new 3G_MSC/VLR inform the HLR of the change of 3G_MSC/VLR by sending Update Location (IMSI, MSC address, VLR number) to the HLR.

– The HLR cancels the context in the old 3G_MSC/VLR by sending Cancel Location (IMSI). The old 3G_MSC/VLR removes the context and acknowledges with Cancel Location Ack.

– The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3G_MSC/VLR. The new 3G_MSC/VLR acknowledges with Insert Subscriber Data Ack.

– The HLR acknowledges the Update Location by sending Update Location Ack. To the new 3G_MSC/VLR.

– The new 3G_MSC/VLR validates the UE presence in the new LA. If due to regional, national or international restrictions the UE is not allowed to attach in the LA or subscription checking fails, then the new 3G_MSC/VLR rejects the location area update with an appropriate cause. If all checks are successful, then the new 3G_MSC/VLR responds to the UE with Location Area Update Accept (new TMSI, new LAI).

– The UE acknowledges the new TMSI with a TMSI reallocation Complete. (TMSI can optionally be reallocated with the TMSI reallocation procedure).

– When the location registration procedure is finished, the 3G_MSC/VLR may release the signalling connection towards the SRNS for the concerned UE. The SRNS will then release the RRC connection if there is no signalling connection between 3G_SGSN and SRNS for the UE.

4.3.14.1.2 Routing Area update

This example shows location registration when changing Routing Area including change of 3G_SGSN when the UE is in MM idle state towards the 3G_SGSN.

The illustrated transfer of MM signalling to/from the UE uses an established RRC connection. This RRC connection can have been established beforehand due to ongoing interwork between UE and 3G_MSC/VLR or be established only for this location registration procedure towards the 3G_SGSN.

For each indicated MM message sent in this case to/from UE, the CN discriminator indicates 3G_SGSN.

Figure 4.18: Interface information transfer for Routing Area update
when changing SGSN area (successful case)

– The RRC connection is established, if not already done. The UE sends the initial message Routing Area Update Request (old P-TMSI, old RAI, etc.) to the new 3G_SGSN. The old P-TMSI and the old RAI are assigned data in UMTS. The SRNS transfers the message to the 3G_SGSN. The sending of this message to 3G_SGSN will also imply establishment of a signalling connection between SRNS and 3G_SGSN for the concerned UE. The UTRAN shall add the RAC and the LAC of the cell where the message was received before passing the message to the SGSN.

– The new 3G_SGSN send an SGSN Context Request (old P-TMSI, old RAI) to the old 3G_SGSN to get the IMSI for the UE. (The old RAI received from UE is used to derive the old 3G_SGSN identity/address.) The old 3G_SGSN responds with SGSN Context Response (e.g. IMSI, PDP context information and Authentication triplets).

– Security functions may be executed.

– The new 3G_SGSN informs the HLR of the change of 3G_SGSN by sending Update GPRS Location (IMSI, SGSN number, SGSN address) to the HLR.

– The HLR cancels the context in the old 3G_SGSN by sending Cancel Location (IMSI). The old 3G_SGSN removes the context and acknowledges with Cancel Location Ack.

– The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3G_SGSN. The new 3G_SGSN acknowledges with Insert Subscriber Data Ack.

– The HLR acknowledges the Update GPRS Location by sending Update GPRS Location Ack. To the new 3G_SGSN.

– The new 3G_SGSN validate the Ues presence in the new RA. If due to regional, national or international restrictions the UE is not allowed to attach in the RA or subscription checking fails, then the new 3G_SGSN rejects the Routing Area Update Request with an appropriate cause. If all checks are successful, then the new 3G_SGSN responds to the UE with Routing Area Update Accept (new P-TMSI, new RAI, etc.).

– The UE acknowledges the new P-TMSI with Routing Area Update Complete.

– When the location registration procedure is finished, the 3G_SGSN may release the signalling connection towards the SRNS for the concerned UE. The SRNS will then release the RRC connection if there is no signalling connection between 3G_MSC/VLR and SRNS for the UE.

4.3.14.1.3 Periodic Registration towards both CN nodes without use of Gs

This example shows Periodic Registration to both the 3G_MSC/VLR and the 3G-SGSN (i.e. no change of registration areas) when the UE is in MM idle state and registered in both the 3G_SGSN and the 3G_MSC/VLR.

The illustrated transfer of MM signalling to/from the UE uses an established RRC connection. This RRC connection will be established, is in this case, only for the two registration procedures towards the 3G_SGSN and 3G_MSC/VLR.

For each indicated MM message sent to/from UE, the CN discriminator indicates either 3G_ SGSN or 3G_MSC/VLR.

Figure 4.19: Interface information transfer for periodic registration to 3G_SGSN
and 3G_MSC/VLR (successful case)

– The RRC connection is established. The UE sends the initial messages Routing Area Update Request (old P‑TMSI, old RAI, etc.) to the 3G_SGSN and Location Area Update Request (old TMSI, old LAI, etc.) to the 3G_MSC/VLR. In both cases, the UE will indicate the cause periodic registration. The sending of the respective message to SGSN respective to MSC/VLR will also imply establishment of a signalling connection between SRNS and SGSN and a signalling connection between SRNS and MSC/VLR for the concerned UE.

– Security functions may be executed.

– The 3G_SGSN respective the 3G_MSC/VLR validates the Ues presence. If all checks are successful, then the 3G_SGSN responds to the UE with Routing Area Update Accept and 3G_MSC/VLR responds to the UE with Location Area Update Accept.

– When the periodic registration procedure is finished, the 3G_SGSN respective the 3G_MSC/VLR may release the signalling connection towards the SRNS for the concerned UE. If both CN nodes release the signalling connection towards the SRNS for the concerned UE, then the SRNS will release the RRC connection towards the UE.

4.3.14.1.4 Periodic Registration with use of Gs/UMSC

Figure 4.20: Periodic update procedure when the MS is attached for both CS and PS services

An RRC connection is established for the periodic registration.

NOTE: This procedure is invoked only when the UE is in MM-idle state. The UE sends a Routing Area Update to the UMSC. The UMSC authenticates the P-TMSI signature. If the update is successful it sends a Routing Area Accept message. The RRC connection is then released.

4.3.14.1.5 UE initiated Combined Detach Procedure when using Gs/UMSC

The UE-Initiated Detach procedure when initiated by the UE is illustrated in figure 4.21. Each step is explained in the following list.

Figure 4.21: UE-Initiated Combined Detach Procedure
(the procedure for combined detach when using Gs is as defined in GSM 03.60)

– The UE detaches by sending Detach Request (Detach Type, Switch Off) to the UMSC. Detach Type indicates which type of detach that is to be performed, i.e., PS Detach only, CS Detach only or combined Detach. Switch Off indicates whether the detach is due to a switch off situation or not.

– If PS detach, any active PDP contexts in the GGSNs regarding this particular UE may be deactivated.

– If Switch Off indicates that the detach is not due to a switch off situation, the UMSC sends a Detach Accept to the UE.

4.3.14.2 SRNS Relocation

4.3.14.2.1 SRNS relocation principles

To carry out SRNS relocation, the source SRNC must launch the SRNS relocation procedure, since it is not the target SRNC but the source SRNC that knows the current services of an user. This is done only when this procedure has the least adverse effect on user traffic.

The SRNC relocation procedures shall ensure that there is only one Serving RNC for an user even if this user has services through more than one (IP or ISDN) domain.

The SRNS relocation procedure is split in 2 phases. In the first one resources are reserved on the new Iu interfaces and (if needed) inside the CN. Only when this first phase has been successfully carried out for all domains on which the user has currently some services, the source SRNC can launch the second phase i.e. hand-over the role of SRNC to the target SRNC.

The signalling procedures shown in the following subclauses do not represent the complete set of possibilities, nor do they mandate this kind of operation. The standard will specify a set of elementary procedures for each interface, which may be combined in different ways in an implementation. Therefore these sequences are merely examples of a typical implementation. In these examples MSC stands for 3G_MSC/VLR and SGSN stands for 3G_SGSN.

Furthermore the list of parameters may not be complete, but should only be seen as examples of possible information carried by the messages.

4.3.14.2.2 SRNS relocation (UE connected to a single CN node, 3G_MSC/VLR) followed by Location Registration in new Routing Area

This example shows SRNS relocation when source RNC and target RNC are connected to different 3G_MSC/VLR. This is then followed by a Routing Area update procedure towards a new SGSN. Figure 4.22 and figure 4.23 illustrate the situation before respective after the SRNS relocation and location registration. Figure 4.24 illustrates the signalling sequence where each step is explained in the following list.

Figure 4.22: Before the SRNS relocation and location registration

Before the SRNS relocation and location registration the UE is registered in SGSN1 and in MSC1. The UE is in state MM idle towards the SGSN1 and in state MM connected towards the MSC1. The RNC1 is acting as SRNC and the RNC2 is acting as DRNC.

Figure 4.23: After the SRNS relocation and location registration

After the SRNS relocation and location registration the UE is still registered in MSC1 while the registration in the IP domain has changed from SGSN1 to SGSN2. The UE is in state MM idle towards the SGSN2 and in state MM connected towards the MSC1. The RNC2 is acting as SRNC.

Figure 4.24: Interface information transfer for SRNS relocation when UE connected
to 3G_MSC/VLR followed by location registration in new Routing Area.

– UTRAN makes the decision to perform the Serving RNC relocation procedure. This includes decision on into which RNC (Target RNC) the Serving RNC functionality is to be relocated. The source SRNC sends SRNC Relocation required messages to the MSC. This message includes parameters such as target RNC identifier and an information field that shall be passed transparently to the target RNC.

– Upon reception of SRNC Relocation required message the Anchor MSC (MSC1) prepares itself for the switch and determines from the received information that the SRNC relocation will (in this case) involve another MSC. The Anchor MSC will then send a Prepare SRNC Relocation Request to the applicable non-anchor MSC (MSC2) including the information received from the Source RNC.

– The non-anchor MSC will send a SRNC Relocation Request message to the target RNC. This message includes information for building up the SRNC context, transparently sent from Source RNC (UE id., no of connected CN nodes, UE capability information), and directives for setting up Iu user plane transport bearers. When Iu user plane transport bearers have been established, and target RNC has completed its preparation phase, SRNC Relocation Proceeding 1 message is sent to the non-anchor MSC.

– The Prepare SRNC Relocation Response that is sent from non-anchor MSC to Anchor MSC will contain the SRNC Relocation Proceeding 1 received from target RNC.

– When the SRNC Relocation Proceeding 1 has been received in the Anchor MSC, the user plane transport bearers has been allocated the whole path between target RNC and Anchor MSC and the Anchor MSC is ready for the SRNC move, then the Anchor MSC indicates the completion of preparation phase at the CN side for the SRNC relocation by sending the SRNC relocation proceeding 2 message to the Source RNC.

– When the source RNC has received the SRNC Relocation Proceeding 2 message, the source RNC sends a SRNC Relocation Commit message to the target RNC. The target RNC executes switch for all bearers at the earliest suitable time instance.

– Immediately after a successful switch at RNC, target RNC (=SRNC) sends SRNC Relocation Complete message to the non-anchor MSC. This message is included by the non-anchor MSC in the Complete SRNC relocation message that is sent to the anchor MSC. Upon reception of this message, the Anchor-MSC switches from the old Iu transport bearers to the new ones.

– After a successful switch at the Anchor MSC, a release indication is sent towards the Source RNC. This will imply release of all UTRAN resources that were related to this UE.

– When the target RNC is acting as SRNC, it will send New MM System Information to the UE indicating e.g. relevant Routing Area and Location Area. Additional RRC information may then also be sent to the UE, e.g. new RNTI identity.

– When receiving new MM system information indicating a new Routing Area, the UE will in this case initiate a Routing Area update procedure towards the SGSN.

– Before point (a), in figure 4.24, the connection is established between UE and Anchor MSC via Source RNC.

– After point (b), in figure 4.24, the connection is established between UE and Anchor MSC via Target RNC and Non-anchor MSC.

4.3.14.2.3 SRNS relocation (UE connected to a single CN node, 3G_SGSN) followed by Location Registration in new Location Area

This is described in TS 23.060.

Figures 4.25, 4.26, 4.27, 4.28, 4.29 and 4.30: (void).

4.3.14.3 Comparison between UMTS and GSM

For the PSTN/ISDN domain, the proposed UMTS MM concept is in principle identical to the GSM MM.

For the IP domain, the differences between the proposed UMTS MM concept and the GSM GMM are more extensive, such as:

– GSM GMM-Ready state where "Cell update" is replaced in UMTS by UMTS PS-CONNECTED state where SGSN is 39ignalling39 a connection toward UTRAN and the UE location is tracked by UTRAN (i.e. not on MM level);

– GSM GMM-standby state corresponds to UMTS PS-IDLE state. In both case, "Routing area update" is performed and SGSN is paging in the routing area;

– a UMTS PS-CONNECTED state is introduced and in this state the UE mobility towards the CN will be handled by UTRAN-CN procedures, i.e. not on MM level.

Figure 4.31 provides illustration of the above bullets.

Figure 4.31: The states written in italics correspond to those defined in GSM with GPRS

4.3.14.3.1 PS –idle state

The RA update procedure is utilised to update the whereabouts of the UE into SGSN. The updating into SGSN takes place irrespectively of the CS MM state in MSC.

4.3.14.3.2 PS –connected state

The URA and cell updating and handover procedures presented in figure 4.31 are based on UMTS YY.03 [2]. In brief, the aim in [2] is to introduce functionality that caters for the same functionality as standby/ready in GPRS. The RRC shall be designed in such a fashion, which allows the state of the RRC connection to define the level of activity associated to a packet data connection. The key parameters of each state are the required activity and resources within the state and the required signalling prior to the packet transmission. The operator configurable RRC_connection_release timer can be used to release RRC connections in case of very low level of activity and in case the QoS requirements e.g. delay requirement allow the release of the RRC connection.

The cell update and URA update between UE and RNC are used when the UE is in RRC common channel state, i.e. when the above mentioned parameters allow to scale down the resources reserved for the UE (for a more detailed description on this, see [2]). For example, the purpose of the cell update procedure is to allow the UE to inform its current location in the corresponding RRC state. According to [2] the cell update procedure replaces handover in the corresponding RRC substate.

A significant deviation from GPRS is the introduction of the handover procedures for connections supporting traffic into IP domain (in RRC cell connected state, see [2]).

The UE moves to PS-IDLE state in case of expiry of RRC_connection_release timer or an RRC connection failure.

4.3.14.4 Issues for further study

List of issues that are for further study related to this chapter and is the following:

– more details are required with regards to the differences with regards to the "IP-domain" MM compared to GPRS MM, especially considering roaming and handover to/from UMTS to GSM/GPRS;

– more details should be provided with regards to the logical relations between UE-CN and UTRAN-CN, and how these relate to the physical interconnection between UTRAN and the CN nodes(s), namely whether one logical/physical Iu can be used to interconnect the UTRAN with the CN.