mobility management - from gprs to umts

WIRELESS COMMUNICATIONS AND MOBILE COMPUTINGWirel. Commun. Mob. Comput. 2001; 1:339–359 (DOI: 10.1002/wcm.27)

Mobility management: from GPRS to UMTS

Yi-Bing Lin*,†Department of Computer Science &Information EngineeringNational Chiao Tung UniversityHsinchu, TaiwanRepublic of China

Yieh-Ran HaungComputer & Communications ResearchLab.Industrial Technology Research InstituteHsinchu, TaiwanRepublic of China

Yuan-Kai Chen‡Department of Computer Science &Information EngineeringNational Chiao Tung UniversityHsinchu, TaiwanRepublic of China

Imrich ChlamtacCenter of Advanced TelecommunicationsSystem and ServicesThe University of Texas at DallasP.O. Box 830688RichardsonTX 75083-0688, U.S.A.

Summary

This paper describes mobility management for thethird-generation mobile networks. We focus on theevolution from General Packet Radio Service(GPRS) to Universal Mobile TelecommunicationSystem (UMTS). In this evolution, the radio accessnetwork UTRAN has been introduced, andradio-related management is moved from the corenetwork to UTRAN. We elaborate on how thisarchitecture change affects the mobility managementfunctionality, including the attach and detachprocedures, location update, serving radio networkcontroller relocation and intersystem changebetween GPRS and UMTS. Copyright 2001 JohnWiley & Sons, Ltd.

KEY WORDSGSMGPRSMobility ManagementUMTSUTRAN

Published online: 9 August 2001

ŁCorrespondence to: Yi-Bing Lin, Department of Computer Science & Information Engineering, National Chiao TungUniversity, Hsinchu, Taiwan, Republic of China.†E-mail: [email protected]

‡Now with Wireless Communication Technology Lab., Telecommunication Laboratories, Chunghwa Telecom Co. Ltd,Taiwan, Republic of China.

Copyright 2001 John Wiley & Sons, Ltd.

340 YI-BING LIN ET AL.

1. Introduction

Universal Mobile Telecommunication System (UMTS)is a third generation mobile network evolved from thesecond generation systems such as GSM and Gen-eral Packet Radio Service (GPRS). In this paper,we consider an evolution path GSM ! GPRS !UMTS. We assume that the readers are familiarwith the GSM and the GPRS systems, and theterms such as International Mobile Subscriber Iden-tity (IMSI), Temporary Mobile Subscriber Identity(TMSI), Packet TMSI (P-TMSI), Subscriber IdentityModule (SIM), Short Message Service (SMS), Visi-tor Location Register (VLR), Home Location Register(HLR), and Mobile Switching Center (MSC). Thereader is referred to References [1] and [2] and thereferences cited therein for the details of GSM andGPRS.

The network architecture of the GSM/GPRS/UMTS systems are shown in Figure 1. In this figure,the dashed lines represent signaling links, and thesolid lines represent data and signaling links. TheCore Network (CN) consists of two service domains,a circuit-switched (CS) service domain (i.e., PSTN/ISDN) and a packet-switched (PS) service domain(i.e., IP). In the CS domain, a Mobile Station (MS)is identified by IMSI and TMSI. In the PS domain,an MS is identified by IMSI and P-TMSI. This paperwill emphasize on the PS-related topics. In simplifica-tion (but maybe misleading), GPRS is evolved fromGSM by introducing two new core network nodesServing GPRS Support Node (SGSN) and Gateway

GPRS Support Node (GGSN). Existing GSM nodes(BSS, MSC/VLR, and HLR) are upgraded. GPRSBSS consists of Base Transceiver Station (BTS) andBase Station Controller (BSC) where the BSC is con-nected to the SGSN through frame relay link. TheBTS communicates with the MS through the radiointerface Um based on the TDMA technology. Threeoperation modes are defined for GPRS MS:

Class A MS allows simultaneous CS and PS con-nections.Class B MS provides automatic choice of CS or PSconnection, but only one at a time.Class C MS only supports PS connection.

UMTS is evolved from GPRS by replacing theradio access network. The UMTS Terrestrial RadioAccess Network (UTRAN) consists of Node Bs (the3G term for BTS) and Radio Network Controllers(RNCs) connected by an ATM network. The RNCand the Node B serving an MS are called the ServingRadio Network System (SRNS). The User Equipment(UE; the 3G term for MS) connects with Node Bsthrough the radio interface Uu based on the WCDMA(Wideband CDMA) technology [3]. Three operationmodes are defined for UMTS UE:

PS/CS mode UE is equivalent to GPRS Class A MS.PS mode UE is equivalent to GPRS Class C MS.CS mode UE can only attach to the CS domain.

For description purposes, the remainder of thispaper will use the term MS to represent UE. In

BSC

SGSN GGSN

MSC/VLR HLR

PSTN

RNC

RNC

BSS

Gs

Core Network

GcGr

A

Gb

IuCS

IuPS

IuCS

IuPS

GPRS/GSM MS

UE

UTRAN

Iub

Iur

Abis

DataNetworkNode B

BTS

IubUu

Um

Gn

Fig. 1. GSM/GPRS/UMTS network architectures. BSS: base station subsystem; BTS: base transceiver station; HLR: homelocation register; GGSN: gateway GPRS support node; MS: mobile station; MSC: mobile switching center; Node B: basestation; PSTN: public switched telephone network; RNC: radio network controller; SGSN: serving GPRS support node;

UE: user equipment; UTRAN: UMTS terrestrial radio access network; VLR: visitor location register.

Copyright 2001 John Wiley & Sons, Ltd. Wirel. Commun. Mob. Comput. 2001; 1:339–359

MOBILITY MANAGEMENT: FROM GPRS TO UMTS 341

UMTS, every Node B is connected to an RNCthrough the Iub interface. Every RNC is connected toan SGSN through the IuPS interface, and to an MSCthrough the IuCS interface. An RNC may connect toseveral RNCs through the Iur interface. Unlike RNCsin UMTS, the BSCs in GPRS/GSM do not connectto each other. The IuCS, IuPS, Iub, and Iur interfacesare implemented on the ATM network.

In terms of the core network evolution from GPRSto UMTS, both SGSN and MSC need to be modi-fied. Other core network nodes such as HLR (specif-ically, HLR packet domain subscription data), VLR(specifically, VLR and SGSN association), and GGSN(specifically, PDP contexts) are basically the same.The SGSN and the MS are modified (specifically MMand PDP contexts and the related procedures), whichwill be elaborated in Section 4. Figure 2 (a) and (b)illustrates the control planes (specifically for mobil-ity management) between the MS and the SGSN forUMTS and GPRS, respectively. Note that in the earlyGPRS version, the control plane was called the sig-naling plane. In Figure 2, details of GPRS protocolstacks such as Logic Link Control (LLC), Radio LinkControl (RLC), and BSS GPRS Protocol (BSSGP) aregiven in Reference [1]. We focus on the differencesbetween the GPRS and UMTS control planes. Forexample, unlike GPRS, the LLC layer is not supportedin UMTS. In GPRS, reliable communication betweenMS and SGSN is guaranteed by LLC. In UMTS, RadioResource Control (RRC) protocol is responsible forreliable connection between MS and UTRAN, and Sig-naling Connection Control Part (SCCP) is responsible

lowerlayer

protocols

lowerlayer

protocols

lowerlayer

protocols

lowerlayer

protocols

Relay

BSSGPRLC

lowerlayer

protocols

lowerlayer

protocols

lowerlayer

protocols

lowerlayer

protocols

MSUu

SGSNRNSIuPS

GMM GMM

LLC LLC

SGSNMS

BSSGP

Relay

RANAP

RLC SCCP

GMM

RLC

GMM

SCCP

RRC RRC RANAP

RLC

Um Gb

(a)

(b)

BSS

Fig. 2. Control planes for UMTS and GPRS. (a) Controlplane for UMTS mobility management; (b) control plane

for GPRS mobility management.

for reliable connection between UTRAN and SGSN.Specifically, radio resources are managed by RRCexercised between the MS and the UTRAN. On topof SCCP, the Radio Access Network Application Part(RANAP) protocol supports transparent mobility man-agement signaling transfer between the MS and the CNwhich are not interpreted by the UTRAN. RANAPis also responsible for serving RNC relocation (seeSection 7), radio access bearer (RAB) management,and so on. In both GPRS and UMTS the GPRS MobilityManagement (GMM) protocol supports mobility man-agement functionality, which is the focus of this paper.In Reference [2], GMM for UMTS is also referred toas UMTS MM (UMM). The GMM procedures will beelaborated in the subsequent sections.

The mobility management (MM) messages areexchanged among GPRS/UMTS nodes through vari-ous interfaces described as follows:

MS and SGSN. In GPRS, the mobility management(MM) messages are delivered through the Gb andthe Um interfaces. In UMTS, the MM messagetransmission is performed through the Iu and theUu interfaces. Specifically, an LLC link providesthe signaling connection between the MS and theSGSN in GPRS. In UMTS, the signaling connectionconsists of an RRC connection between the MSand UTRAN, and an Iu connection (‘one RANAPinstance’) between the UTRAN and the SGSN.

SGSN and other CN nodes. In both GPRS and UMTS,GSM Mobile Application Part (MAP) is used tointerface SGSN and the GSM nodes. For example,Gr for HLR and Gs (the BSSAPC protocol or BSSApplication ProtocolC) for MSC/VLR. SGSNs andGGSNs communicate by using the GPRS TunnelingProtocol (GTP) through the Gn interface. Specif-ically, a GTP tunnel is established between twoGPRS nodes to deliver the packets. This tunnel isidentified by a tunnel endpoint identifier (TEID),an IP address and a UDP port number. Details ofthe MAP protocols and GTP can be found in Refer-ences [1, 4] and the references cited therein.

The Gs interface merits further discussion. InGPRS and UMTS (R’99 release [2]), procedures suchas attach, paging and location update are defined sep-arately for CS and PS. For example, LA update isperformed for CS and RA update is performed for PS.To save radio resources, execution of similar proce-dures for both CS and PS can be combined. Examplesare combined PS/CS attach (see Section 5) and com-bined RA/LA update (see Section 6). Furthermore,



activities such as CS paging can be performed byusing the PS mechanism, so that the MS only needsto monitor the single paging channel. These optimiza-tions are achieved only if the Gs interface exists sothat SGSN and MSC/VLR can communicate to com-bine the PS and CS activities. The GPRS (UMTS)network is in Network Mode I if the Gs interfaceexists. Otherwise, it is in Network Mode II. Notethat an extra network mode (Mode III) is defined forGPRS when the Gs is not present. This network modehas been removed from UMTS.

Initiated by SGSN, a Gs association can be createdbetween SGSN and MSC/VLR by storing the SGSNnumber in the VLR and storing the VLR number inthe SGSN. With this association, messages regardingCS activities can be passed between the VLR andthe SGSN. We will elaborate more on these activitieslater.

Protocols for user data transmission are defined inthe user plane. In the early GPRS version, the userplane was called the transmission plane. In GPRS,the Sub-Network Dependent Convergence Protocol(SNDCP) carries out transmission of N-PDUs (Net-work Packet Data Units) on top of the LLC linkbetween the MS and the SGSN. In UMTS, the PacketData Convergence Protocol (PDCP) carries out N-PDU transmission on top of the RLC connectionbetween the MS and the UTRAN, and the GTP-U(GTP for the user plane) protocol carries out trans-mission of N-PDUs on top of the UDP/IP link (Iulink). Packets of user data transmission may be lost

when some MM signaling procedures are executed.These procedures include attach, routing area update,and authentication.

A brief summary for GPRS and UMTS architec-tures are given as follows. In both GPRS and UMTS,IMSI is used as the common user identity, and com-mon MAP signaling is applied to both systems aswell as GSM. Unlike GPRS, the UMTS radio net-work parameters and radio resources are managed inthe UTRAN. Like GPRS BSS, the UTRAN does notcoordinate mobility management procedures that arelogically between the MS and the CN. These proce-dures include location management, authentication,temporary identity management and equipment iden-tity check.

2. Concepts of Mobility Management

In order to track the MSs, the cells (i.e., BTSs/NodeBs) in GPRS/UMTS service area are partitioned intoseveral groups. To deliver services to an MS, thecells in the group covering the MS will page theMS to establish the radio link. The location changeof an MS is detected as follows. The cells broadcasttheir cell identities. The MS periodically listens to thebroadcast cell identity, and compares it with the cellidentity stored in the MS’s buffer. If the comparisonindicates that the location has been changed, then theMS sends the location update message to the network.

In the CS domain, cells are partitioned into locationareas (LAs). The LA of an MS is tracked by the

MSCVLR1

SGSN1

MSCVLR2

B1 B2 B3 B4 B6 B7 B8 B10 B11 B13 B14 B21B19B18B17B5

URA1 URA2 URA3

B15

URA5 URA6 URA7 URA8URA4

B23B22

URA9 URA10 URA11UMTS

only

B9 B12 B16 B20 B24

RA2RA1 RA3 RA4 RA5

LA1 LA2

SGSN2

LA3

BSC2/RNC2 BSC3/RNC3 BSC4/RNC4

BTS/Node B

BSC1/RNC1

Fig. 3. LAs, RAs, and URAs.



VLR. In the PS domain, the cells are partitioned intorouting areas (RAs). An RA is typically a subset ofan LA. The RA of an MS is tracked by the SGSN.In GPRS, the SGSN also tracks the cell of an MSin PS connection (i.e., when packets are deliveredbetween the MS and the SGSN). In UMTS, the cellsin an RA are further partitioned into UTRAN RAs(URAs). The URA and the cell of an MS are trackedby the UTRAN. Figure 3 illustrates an example ofLA, RA, and URA layout. The areas controlled byVLR, SGSN, and UTRAN are listed in Table 1.

In UMTS, the UTRAN tracking is triggered by theestablishment of the RRC connection. In the MS andthe UTRAN, an RRC state machine is executed [5, 6].Its state diagram is shown in Figure 4. In the RRCIdle mode, no RRC connection is established, andthe MS is tracked by the SGSN at the RA level.When the RRC connection is established, the statemoves from RRC Idle to RRC Cell Connected, andthe MS is tracked by the UTRAN at the cell level.If, for example, no PDUs are transmitted before aninactivity timer expires, the state moves from RRCCell Connected to RRC URA Connected, and the MSis tracked by UTRAN at the URA level [5].

The mobility management functions emphasizingPS-based services are listed below.

ž PS attach procedure allows an MS to be ‘known’by the PS service domain of the network. Forexample, after the MS is powered on, the PS attachprocedure must be executed before the MS can

obtain access to the PS services. Note that the term‘PS attach’ is used in UMTS and the term ‘GPRSattach’ is used in GPRS. Similarly, we have theterm ‘CS attach’ for UMTS and ‘IMSI attach’ forGPRS. For the discussion purpose, we will use theterms PS attach and CS attach in this paper.

ž PS detach procedure allows the MS or the networkto inform each other that the MS will not access theSGSN-based services. PS attach and detach will bedescribed in Section 5.

ž Security procedures include authentication, useridentity confidentiality (e.g., P-TMSI reallocationand P-TMSI signature) and ciphering. Detailsof security procedures can be found inReferences [7, 8]. Here, we elaborate more onP-TMSI signature. When the SGSN allocates theP-TMSI to an MS, it may also send the P-TMSIsignature to the MS. Then when the next MS iden-tity checking is performed, e.g., in the attach pro-cedure (see Step 2 in Figure 5), the MS sends theP-TMSI signature to the SGSN for comparison. Ifthe comparison fails, the authentication proceduremust be used by the SGSN to authenticate the MS.

GPRS ciphering is performed between the MS andthe SGSN. On the other hand, UMTS ciphering isperformed between the UTRAN and the MS.

ž Location management procedures track the loca-tion of an MS. These procedures are elaborated inSection 6.

Table 1. Areas tracked by the network nodes.

MSC/VLR SGSN UTRAN

GSM GPRS UMTS GPRS UMTS UMTS

Cell no no no yes no yesURA — — no — no yesRA — no no yes yes noLA yes yes yes no no no

Idle Mode

RRC ConnectionRelease

URA ConnectedCell Connected

Connected Mode

Enter the CellConnected State (PDU transmission)

EstablishmentRRC Connection (e.g., inactivity timer expires)

Enter the URA Connected State

Fig. 4. RRC state diagram.



VLROld HLRVLR

New GGSNSGSN

OldSGSNNew

UTRAN

BSS

UE

MS

1. Attach Request

2. Identification Request & Response

4. Security Functions

3. Identity Request & Response

5. RA Update Procedure

6. LA Update Procedure

7. Attach Accept

8. Attach Complete

9. TMSI Reallocation Complete

Fig. 5. Combined PS/CS (GPRS/IMSI) attach procedure.

ž Tunneling of non-GSM signaling message proce-dures support communication between GPRS/UMTS and non-GSM systems such as EIA/TIA IS-136. The SGSN forwards the signaling messages tothe non-GSM MSC/VLR using the BSSAPC pro-tocol in the Gs interface.

ž Subscriber management procedures are used by theHLR to inform the SGSN about changes of thePS subscription data. This procedure is needed, forexample, at Step 8 of the location update procedurein Section 6.

ž Service request procedure (UMTS only) is usedby the MS to establish a secure connection to theSGSN, so that the MS can send uplink signalingmessages or user data. This procedure is used,for example, when the MS replies a page fromthe UMTS network or when the MS attempts torequest resource reservation. In GPRS, LLC linkis always established between the MS and SGSNafter the attach procedure. Therefore, the servicerequest procedure is not needed and is not definedin GPRS.

ž UMTS-GPRS intersystem change procedures allowa dual mode MS to move between GPRS andUMTS systems. The details will be given inSection 8.

3. Mobility Management States

In GPRS and UMTS, an MM finite state machine isexercised in both SGSN and MS to characterize themobility management activities for the MS. In GPRS,the states in the machine are IDLE, STANDBY andREADY. For UMTS PS service domain, these statesare renamed as PMM-DETACHED, PMM-IDLE andPMM-CONNECTED, respectively. The MM statesare stored in the MM contexts maintained by the MSand the SGSN. Details of the MM context will begiven in Section 4. In this section, we describe theMM states and the transitions among these states.Figure 6 illustrates the MM state diagrams. The figureindicates that the MM state machines for both GPRSand UMTS are basically the same. The MM statesare described as follows.

IDLE or PMM-DETACHED. The MS is not known(i.e., not attached) to GPRS (UMTS/PS). That is,the MS is not reachable by the network. In thisstate, the MS may perform attach procedure.

STANDBY or PMM-IDLE. The MS is attached toGPRS (UMTS/PS); that is, both the MS and SGSNhave established MM contexts. In this state, the MSmay perform the detach and location update proce-dures. The SGSN may perform paging procedure.



IDLE READY STANDBY

GPRS Attach

GPRS Detach

Force to STANDBYREADY timer expiry or

PDU transmission

STANDBYIDLE READY

PMMIDLE

PMMCONNECTEDPMM

DETACHED

PMMDETACHED

PMMIDLE

PMMCONNECTED

PDU reception

Force to STANDBY, orREADY timer expiry,

Abnormal RLC ConditionGPRS Attach

GPRS Detach, Implicit Detach, or Cancel Location

Connection ReleasePS Signaling

PS Signaling

PS Attach

PS Detach,RAU RejectPS Attach Reject

PS Attach

PS Signaling

PS Signaling

PS Detach

Serving RNCRelocation

RAU RejectGPRS Attach Reject

Implicit PS Detach

Connection Establish

Connection Release

Connection Establish

GPRS Detach, RAU Reject,GPRS Attach Reject or

Cancel Location

PS Detach, RAU RejectPS Attach Reject or

Cancel Location

(c)

(b)

(a)

(d)

Fig. 6. MM state diagrams: (a) MS MM states for GPRS; (b) MS MM states for UMTS; (c) SGSN MM states for GPRS;(d) SGSN MM states for UMTS.

The MS is tracked by the SGSN at the RA level(see Table 1).

READY or PMM-CONNECTED. PDUs can only bedelivered in this state. In GPRS, the SGSN tracksthe MS at the cell level. In UMTS, a PS signalingconnection is established between the MS and theSGSN (that is, the MS is in RRC Connected mode).The SGSN tracks the MS with accuracy of the RAlevel, and the serving RNC is responsible for cell-level tracking. In UMTS, serving RNC relocation(see Section 7) is executed in this state.

The transitions among the MM states (see Figure 6)are described as follows.

IDLE!READY (PMM-DETACHED!PMM-CO-NNECTED). This transition is triggered by an MSwhen the MS performs GPRS/PS attach.

STANDBY ! IDLE (PMM-IDLE ! PMM-DETA-CHED). This transition can be triggered by MSor SGSN.

ž This transition is triggered by the SGSN whentracking of MS is lost. In this case, SGSNperforms an implicit GPRS/PS detach. A mobilereachable timer is maintained in the SGSN tomonitor the periodic RA update procedure (seeSection 6). If the SGSN does not receive RAupdate request message from the MS after thetimer expires, the MS is considered detached.This timer is used only when the MM state isSTANDBY/PMM-IDLE.

ž This transition may also be triggered by SGSNwhen the SGSN receives a Cancel Locationmessage from the HLR. In this case, the MMand the PDP contexts are already moved to thenew SGSN that serves the MS, and the contextsin the old SGSN can be deleted. Note that the



MS will be associated with the new SGSN inthis case.

ž This transition is triggered by the MS when theMS performs implicit detach due to removal ofthe SIM card or the battery. This case is definedfor UMTS, but not for GPRS.

STANDBY ! READY (PMM-IDLE ! PMM-CO-NNECTED). This transition is triggered by theMS. In GPRS, this transition occurs when theMS sends an LLC PDU to the SGSN, possiblyin response to a page from the SGSN. In UMTS,this transition occurs when the service requestprocedure is executed (possibly in response of apage from the SGSN) to establish the PS signalingconnection between the MS and the SGSN.

READY ! STANDBY (PMM-CONNECTED !PMM-IDLE). This transition is triggered by eitherSGSN or MS. In GPRS, a READY timer is main-tained in the MS and the SGSN. If no LLC PDUis transmitted before the timer expires, then thisMM transition occurs. The length of the READYtimer can only be changed by the SGSN. The MSis informed of the READY timer value changethrough messages such as Attach Accept and Rout-ing Area Update Accept. This MM transition mayalso occur when the SGSN forces to do so, or whenabnormal RLC condition is detected during radiotransmission.In UMTS, this MM transition occurs when the PSsignaling connection is released or broken (e.g.,RRC connection failure), or when the URA updatetimer at the RNC expires.

READY ! IDLE (PMM-CONNECTED ! PMM-DETACHED). This transition can be triggered byMS or SGSN.

ž This transition is triggered by MS or SGSNwhen the MS or the network-initiated GPRS/PSdetach is performed.

ž This transition is triggered by SGSN when theSGSN receives a Cancel Location message fromthe HLR, or when the SGSN rejects a RA updateor an attach request from the MS.

In UMTS, the PS signaling connection is releasedafter this transition. Specifically, both RRC andSCCP connections are released. In GPRS, LLC linkis removed after this transition.In UMTS, SRNC relocation occurs at the PMM-

CONNECTED state.

4. MM and PDP Contexts

Mobility Management (MM) context provides mobil-ity information of an MS, while Packet Data Pro-tocol (PDP) context provides information to sup-port packet delivery between an MS and the net-work. While an MS may be associated with sev-eral PDP contexts, it only has one MM context.The MM context is maintained in MS and SGSN.The PDP contexts are maintained in MS, SGSN, andGGSN. This section describes the MM and PDP con-texts, specifically the differences between GPRS andUMTS.

4.1. Contexts in SGSN

The following fields in the MM context are main-tained in both GPRS SGSN and UMTS SGSN:IMSI, MM state, P-TMSI, P-TMSI signature, Inter-national Mobile Equipment Identity (IMEI), MobileStation ISDN Number (MSISDN), routing area, VLRnumber, MS network access capability, new SGSNaddress, authentication triplets, Kc (currently usedciphering key), selected ciphering algorithm, sub-scribed charging characteristics, and several flags.Details of these fields can be found in Refer-ences [1, 9]. The following MM context fields aredifferent in GPRS SGSN and UMTS SGSN:

Location Information. GPRS SGSN maintains cellidentity (current cell in READY state, or the lastknown cell in STANDBY or IDLE state) and cellidentity age (time elapsed since the last LLC PDUwas received from the MS at the SGSN). These twofields are not maintained in UMTS SGSN becausecell tracking is performed by the serving RNC.UMTS SGSN maintains the last known servicearea code (SAC) when initial MS message wasreceived or when location reporting procedurewas executed, and the elapsed time since the lastSAC was received at the SGSN. The SAC isused to uniquely identify an area consisting ofone or more cells belonging to the same loca-tion area. SAC and the location reporting proce-dure are used in UMTS for location service (LCS)and other services such as emergency calls [10].These fields are not maintained in GPRS SGSNbecause the concept of SAC does not exist inGPRS.

Security Information. UMTS provides enhanced secu-rity functions over GPRS, and thus extra securityparameters are maintained in the UMTS SGSN



MM contexts. Specifically, UMTS SGSN main-tains authentication vectors, CK (currently usedciphering key), IK (currently used integrity key),and KSI (key set identifier). On the other hand,GPRS SGSN maintains CKSN (ciphering keysequence number of Kc). KSI in UMTS corre-sponds to CKSN in GSM, and they have the sameformat. The CK parameter in UMTS is equivalentto Kc in GPRS. The reader is referred to Refer-ence [8] for more information.

Radio Resource Information. GPRS SGSN main-tains radio access capability (MS’s GPRS multislotcapabilities and so on) and discontinuous recep-tion (DRX) parameters, radio priority SMS (theRLC/MAC radio priority level for uplink SMStransmission). DRX allows discontinuous radiotransmission to save the power consumption of theMS. In UMTS, the radio resources are controlledby UTRAN and are not known to the SGSN. Thus,the above fields are not kept in the UMTS SGSNMM context.In GPRS if DRX mode is selected, the MS mayspecify the DRX parameters that indicate the delayfor the network to send a page request or a channelassignment to the MS. DRX usage is independentof the MM states. However, during the GPRSattach and RA update, the GPRS MS shall notapply DRX in READY state. In UMTS, DRXparameter was not shown in the SGSN MM contextin 3G TS 23.060 Version 3.2.1. In Version 3.6.0,this parameter is added in UMTS SGSN MMcontext [5].

The following fields in a PDP context are main-tained in both GPRS SGSN and UMTS SGSN.

PDP route information includes PDP context identi-fier, PDP state, PDP type, and PDP address.

Access Point Name (APN) information includes APNsubscribed and APN in use. An APN represents anexternal network that can be accessed by the MS(i.e., WAPPIE.COM).

QoS information includes QoS profile subscribed,QoS profile requested and QoS profile negotiated.

N-PDU information includes GTP-SND and GTP-SNU. The GTP-SND (GTP-SNU) parameter is theGTP sequence number of the N-PDU to be sentfrom the SGSN to the MS (GGSN).

Charging information includes charging id.Other routing information includes NSAPI, TI, TEID

for Gn/Gp, GGSN address in use, and VPLMNaddress allowed. Network layer Service Access

Point Identifier (NSAPI) is used by LLC (in GPRS)or RLC (in UMTS) to route the N-PDUs to appro-priate higher layer protocols such as signaling,SMS, or packet data protocols. Transaction iden-tifier (TI) is used to represent NSAPI for somesession management signaling messages. VPLMNspecifies the GPRS/UMTS networks visited bythe MS.

Subscribed Charging Characteristics can be normal,prepaid, flat-rate, and/or hot billing. In the earlyGPRS/UMTS version, charging characteristics forPDP contexts are maintained in the SGSN. In thelatest version, charging characteristics are includedin SGSN MM context.

The following PDP context fields are different inGPRS SGSN and UMTS SGSN:

Core Network to Radio Access Network Connection.The UMTS maintains the TEID for the Iu interfaceand the IP address of the RNC currently used.These two fields are not maintained in the GPRSSGSN.

Radio Resource Information. The GPRS SGSN main-tains radio priority (the RLC/MAC radio prior-ity level for uplink user data transmission). Thesefields are not kept in UMTS SGSN.

PDU Information. GPRS SGSN maintains SendN-PDU number (SNDCP sequence number of thenext downlink N-PDU to be sent to the MS),Receive N-PDU number (SNDCP sequence num-ber of the next uplink N-PDU to be received fromthe MS), packet flow identifier and aggregate BSSQoS profile negotiated.On the other hand, UMTS SGSN maintains PDCP-SND (the next PDCP sequence number to besent to the MS) and PDCP-SNU (the next PDCPsequence number expected from the MS).

We note that in both GPRS and UMTS, the radioresource information for SMS is kept in the MMcontext, while the radio resource information for userdata is maintained in the PDP context. The reasonis the following. The PDP context is defined for datatransfer in the user plane. On the other hand, the MMcontext is defined for mobility management signalingin the control plane. SMS is delivered through thecontrol plane by using common channel, which ismore efficient than delivery through the user plane.Furthermore, through the control plane, the sameSMS transfer procedure is used for both CS and PSdomains [2]. Thus, the radio resource information forSMS is kept in the MM context.



4.2. The contexts in the MS

The following fields in the MM context are main-tained in both GPRS MS and UMTS MS: IMSI,MM state, P-TMSI, P-TMSI signature, routing area,MS network access capability, CKSN/KSI, cipheringalgorithm, and DRX parameters. Some of these fieldswere described in Section 4.1. Details of other fieldscan be found in References [1, 9]. The following MMcontext fields are different in GPRS MS and UMTSMS:

Location Information. GPRS MS maintains cell iden-tity. In UMTS, cell tracking is not conducted at themobility management layer between the MS andthe SGSN. Thus, cell identity is not maintained inthe MM context of the MS. Instead, it is maintainedbetween the MS and the UTRAN.

Security Information. UMTS MS maintains extrasecurity parameter CK next.

Radio Resource Information. GPRS MS maintainsradio priority SMS. In UMTS, the SMS as well assignaling are delivered through dedicated controlchannels. Thus the radio priority is not maintainedin the UMTS MS [11]. The GPRS MS maintainsthe MS radio access capability, (e.g., multislotcapability and power class) while the UMTS MSmaintains UE capability (e.g., power control, coderesource, UE mode, and PDCP capability).

The following fields in a PDP context are main-tained in both GPRS MS and UMTS MS: PDP type,PDP address, PDP state, dynamic address allowed,APN requested, NSAPI, TI, QoS profile requested,QoS profile negotiated, and a flag. The followingPDP context fields are different in GPRS MS andUMTS MS:

Radio Resource Information. The GPRS MS main-tains radio priority. In UMTS, the radio priorityfor data delivery is determined by QoS profile, andthe radio priority is not kept separately in the MS.

PDU Delivery Information. GPRS MS maintainsBSS packet flow identifier, Send N-PDU number

and Receive N-PDU number. On the other hand,UMTS MS maintains PDCP-SND and PDCP-SNU.

4.3. Relationship between MM states and thecontexts

The status of an MM/PDP context is affected bythe MM states. Relationship between the MM statesand the contexts is summarized in Table 2 and isdescribed as follows.

ž In the IDLE/PMM-DETACHED state, the PDPcontext in the GGSN is deleted. The MM andPDP contexts in MS and SGSN may or maynot be deleted. If the MM state moves fromSTANDBY/PMM-IDLE to IDLE/MM-DETA-CHED because the mobile reachable timer expires(e.g., the MS is temporarily out of the GPRS/UMTScoverage), then these two contexts shall not bedeleted. In this case, the location and routing infor-mation is stale.

ž In the STANDBY/PMM-IDLE state, valid MMcontexts are maintained in the MS and the SGSN.In this state, the PDP context can be activatedand deactivated. In UMTS, when the PDP con-text is activated in this state, no Iu/radio con-nection is established between the MS and thenetwork because PDU delivery is not allowedin this state. In GPRS the LLC link is con-nected.

ž In the READY/PMM-CONNECTED state, validMM contexts are maintained in the MS and theSGSN. As in the STANDBY/PMM-IDLE state,the MS may initiate PDP context activation anddeactivation. In this state, the signaling connectionis established in UMTS.

5. Attach and Detach

With the attach procedure, the MS informs the net-work of its presence. Figure 5 illustrates the messageflow of the combined PS/CS (GPRS/IMSI) attach

Table 2. Relationship between the MM states and the contexts. �: The context is kept but is stale; ð: the context is removed;— : the context does not exist; °: the current context is maintained.

IDLE/DETACHED STANDBY/IDLE READY/CONNECTED

Context MS SGSN GGSN MS SGSN GGSN MS SGSN GGSNMM ð/� ð/� — ° ° — ° ° —PDP ð/� ð/� ð ð/° ð/° ð/° ð/° ð/° ð/°



procedure. In each step, we point out the differencesbetween GPRS and UMTS.

Step 1. The MS initiates the attach procedure by send-ing the Attach Request message to the SGSN. InGPRS, besides the MS network access capabil-ity, the message includes parameters such as MSradio access capability. These radio related param-eters are not included in UMTS Attach Requestmessage. On the other hand, the UMTS mes-sage includes the ‘follow on request’ field to indi-cate if there is pending uplink traffic that needsIu connection after the attach procedure is com-pleted. This field is not needed in GPRS becausethe Iu interface does not exist. Furthermore, thesecurity parameters for UMTS and for GPRS aredifferent.

When the SGSN receives the attach request at the endof Step 1, there are several possibilities:

ž If the MS has changed SGSN since last detach,then Step 2 is executed so that the new SGSNcan obtain the MS identity (i.e., IMSI) from theold SGSN.

ž If the MS has not changed SGSN, then thereceived P-TMSI is used by the SGSN to iden-tify the MM context of the MS. If the MMcontext has not been deleted since last detach(i.e., the MS is known by the new SGSN), thenSteps 2–6 are skipped, and Step 7 is executed.Otherwise (the MS is not known by the old andthe new SGSNs), Step 2 is skipped, and Step 3is executed.

Step 2 (the MS is known by the old SGSN). The newSGSN sends the Identification Request message tothe old SGSN. The P-TMSI is used to obtain theIMSI and authentication information from the oldSGSN. If the old SGSN cannot find the MM con-text for the MS, then Step 3 is executed. Otherwisethe IMSI is returned to the new SGSN, and Step 4is executed.

Step 3 (the MS is unknown in both the old andthe new SGSNs). The new SGSN asks the MSto supply IMSI through the Identity Request andResponse messages exchange.

Step 4. Authentication is mandatory if the MM con-text of the MS has been deleted since last detach.The equipment (IMEI) may be optionally checked.

Step 5. If the MS has moved from the old SGSNto the new SGSN since last detach or if the MSis performing the first attach, then the RA update

procedure is executed so that the new SGSN canobtain the current MM context of the MS. Thedetails are given in Steps 6–9 (Figure 7).

Step 6. If the Gs interface does not exist, then thisstep is skipped. Otherwise (Gs exists), the attachtype in Step 1 is checked. If attach type indi-cates (1) combined PS/CS attach or (2) PS attachand the MS is already CS attach, then LA updateis performed. The LA update is required so thatthe SGSN-VLR association is established and theVLR can maintain current LA information ofthe MS. The details are given in Steps 10–12,Figure 7.

Step 7. For GPRS, if attach is successful, thenthe SGSN selects radio priority SMS and sendsthe Attach Accept message to the MS. P-TMSIis included in the message if the SGSN allo-cates a new P-TMSI. In UMTS, radio prior-ity SMS is not maintained in mobility manage-ment. However, this parameter is still reservedin the UMTS Attach Accept message in order tosupport handoff between UMTS and GSM net-works [11].

Step 8. If P-TMSI or TMSI have been changed, theMS sends the Attach Complete message to theSGSN to acknowledge receipt of the TMSIs.

Step 9. If TMSI has been changed, the SGSN sendsthe TMSI Reallocation Complete message to theVLR.

After PS attach, the MS is in the READY (forGPRS) or the PMM-CONNECTED (for UMTS) stateand MM contexts are established in the MS and theSGSN.

When PS detach is executed, the MS will notreceive the SGSN-based service. The network orthe MS may request detach explicitly. On the otherhand, implicit PS detach is executed by the network(without notifying the MS) if the mobile reachabletimer expires or when radio path is disconnected dueto errors. After implicit PS detach is performed, theMS’s MM context is deleted after an implementationdependent timeout period. The PS detach procedurealso inactivates the PDP contexts. The PS detachprocedures are basically the same for both GPRSand UMTS, and the details can be found in Refe-rences [1, 9].

6. Location Update

In location management, the MS informs the networkof its location through RA and LA update procedures.



VLROld HLRVLR

New GGSNSGSN

OldSGSNNew

UTRAN

BSS

UE

MS

1. Routing Area Update Request

2. SGSN Context Request & Response

4. SGSN Context Ack

4a. Forward Packets (GPRS only)

7. Cancel Location & Ack

6. Update Location

8. Insert Subscriber Data & Ack

5. Update PDP Context Request & Response

9. Update Location Ack

15. TMSI Reallocation Complete14. Routing Area Update Complete

13. Routing Area Update Accept

10. Location Update Request

11. GSM Location Update Proc.12. Location Update Accept


LA Update

RA Updateinter-SGSN

Fig. 7. Combined RA/LA update.

The update procedures are executed in two situa-tions.

Normal location update is performed when the MSdetects that the location has been changed.

Periodic location update is exercised even if the MSdoes not move. That is, the MS periodically reportsits ‘presence’ to the network.Periodic RA update allows the network to detect ifan MS is still attached to the network. A periodicRA update timer is maintained in both the MS andthe SGSN. Every time this timer expires, the MSperforms periodic RA update. The periodic RAupdate timer value is set/changed by the SGSN,and is sent to the MS through the RA UpdateAccept or the Attach Accept messages when theMS visits an RA. This value cannot be changedbefore the MS leaves the RA.

Table 3. RA/LA update (the MS is not engaged in the CS connec-tion).

Network mode Mode I Mode II

PS Attached RA update RA updateCS Attached LA update LA updatePS/CS Attached RA update

(periodic)Separate LA and

RA updatescombined RA

update (normal)

RA update is periodically performed for a PS-attached MS that is not CS-attached (see Table 3).On the other hand, LA update is periodically per-formed for a CS-attached MS that is not PS-attached. For a PS/CS attached MS, two cases areconsidered:The MS is not engaged in a CS connection (seeTable 3). For a PS/CS attached MS in Network



Mode I, periodic RA update is performed, andLA update must not be performed. In this case,the VLR relies on SGSN to receive periodic RAupdates. If the SGSN detects that the MS is lost,the SGSN detaches the MS, and notifies the VLRof this detach by the IMSI Detach Indicationmessage. For normal location update, combinedRA/LA update is performed when the MS changeslocations.

In Network Mode II, the RA update (to the SGSN)and LA update (to the VLR) are performed sepa-rately. In this case, the LA update is always per-formed before RA update.

The MS is engaged in a CS connection. During aCS connection, the network knows that the MSis attached, and no periodic location update isperformed. In terms of normal location update, twocases are considered (see Table 4):

Class A MS (GPRS) or PS/CS MS (UMTS). DuringCS connection, RA update is exercised whenthe MS changes RAs. LA update is not per-formed when the MS changes LAs. Supposethat only inter-RA crossings occur during CSconnection, then at the end of the CS con-nection, no action is required. For NetworkMode I, if there are inter-SGSN or inter-LAcrossings during CS connection, then at theend of the CS connection, combined RA/LAupdate is executed to modify the SGSN-VLRassociation. For Network Mode II, if there areinter-LA crossings during CS connection, thenat the end of the CS connection, LA update isperformed.

Class B MS (GPRS only). During CS connection,the MS does not execute any RA/LA updates.For Network Mode I, at the end of the CS

connection, RA update is performed if inter-RA crossings occur in CS connection, andcombined RA/LA update is performed if inter-SGSN or inter-LA crossings occur in CS con-nection.For Network Mode II, at the end of the CSconnection, RA update is performed if inter-RA or inter-SGSN crossings occur in CSconnection. LA update is performed if inter-LA crossings occur in CS connection.

Figure 7 illustrates the message flow of the com-bined RA/LA update. In each step, we point out thedifferences between GPRS and UMTS.

Step 1. The MS sends the Routing Area UpdateRequest message to the new SGSN. This messageis not ciphered so that the new SGSN can pro-cess the message. For both GPRS and UMTS, theupdate type can be RA update, periodic RA update,combined RA/LA update, or combined RA/LAupdate with IMSI attach. The ‘follow on request’parameter is used in UMTS to indicate if the Iuconnection should be kept for pending uplink traf-fic. This parameter does not exist in GPRS. InGPRS, before the BSS passes the message to theSGSN, it adds the cell global identity information(including cell, RA and LA identities). In UMTS,the RNC adds the routing area identity information(including RA and LA identities).For inter-SGSN update, Steps 2–9 are executed.Otherwise (intra-SGSN update), these steps areskipped.

Step 2. To obtain the MM and PDP contexts ofthe MS, the new SGSN sends the SGSN ContextRequest message to the old SGSN. Basically, theold SGSN validates the old P-TMSI signature, and

Table 4. RA/LA update (the MS is engaged in CS connection).

MS Mode Class A (PS/CS)

Movement Type Inter-RA Inter-SGSN Inter-LADuring CS Connection RA update RA update no actionConnection Terminates (Mode I) no action Combined Combined

RA/LA update RA/LA updateConnection Terminates (Mode II) no action no action LA update

MS Mode Class B (GPRS only)

Movement Type Inter-RA Inter-SGSN Inter-LADuring CS Connection no action no action no actionConnection Terminates (Mode I) RA update Combined Combined

RA/LA update RA/LA updateConnection Terminates (Mode II) RA update RA update LA update



returns the MM and the PDP contexts of the MSusing the SGSN Context Response message. Theold SGSN starts a timer. The MM context in theold SGSN is deleted when both of the followingconditions are satisfied:

ž the timer expires, andž the old SGSN receives the Cancel Location mes-

sage from the HLR.

This timer mechanism ensures that if the MSinitiates another inter-SGSN routing area updatebefore the current update procedure is completed,the old SGSN still keeps the MM context. InGPRS, the old SGSN stops assigning SNDCP N-PDU numbers to downlink N-PDUs received. Theold SGSN will forward buffered packets to the newSGSN at Step 4a. In UMTS, packet forwardingis not performed between the SGSNs. Also, thetemporary logical link identity (TLLI) included inthe GPRS SGSN Context Request message is notfound in the UMTS message.

Step 3. If the old P-TMSI signature checking atStep 2 fails, security function involving MS, BSS/UTRAN, new SGSN, and the HLR is performed.If this security procedure also fails, then the oldSGSN continues as if the SGSN Context Requestmessage is never received and this procedure exits.Otherwise (security check successes), Step 4 isexecuted.

Step 4. The new SGSN sends the SGSN ContextAcknowledge message to the old SGSN, whichinvalids the SGSN-VLR association in the oldMM context. In GPRS, this message includes theaddress of the new SGSN, which is used to informthe old SGSN that new SGSN is ready to receivethe buffered packets to be forwarded from the oldSGSN. The new SGSN address is not included inthe UMTS SGSN Context Acknowledge message.

Step 4a (GPRS only). The old SGSN then tunnels thebuffered N-PDUs to the new SGSN. Note that nopackets are forwarded from the old SGSN to thenew SGSN in UMTS.

Step 5. The new SGSN sends the Update PDP Con-text Request message to the corresponding GGSNs.With this message, the GGSN PDP contexts aremodified. The GGSNs return the Update PDP Con-text Response messages.

Step 6. The SGSN issues the Update Location mes-sage to inform the HLR that the SGSN for the MShas been changed.

Step 7. The HLR and the old SGSN exchange theCancel Location message pair. The MM and the

PDP contexts in the old SGSN is not deleted untilthe timer described in Step 2 expires.

Steps 8 and 9. The HLR inserts the subscriber datato the new SGSN. For each PDP context, the newSGSN checks if the context is new, active, orinactive. If the PDP context is active, then extratasks are performed by the SGSN. For example, theSGSN compares if the received ‘QoS subscribed’value is the same as the value of the QoS negotiatedparameter. If not, the SGSN should initiate the PDPcontext modification procedure to adjust the QoSparameters of the context.Steps 10–12 are executed if the new SGSN detectsthat the LA has been changed or the update typein Step 1 indicates combined RA/LA update withIMSI (CS) attach.

Step 10 (LA Update). Through a table lookup tech-nique, the SGSN translated RA identity (RAI) intothe VLR number and sends the Location UpdateRequest message to the VLR (after Step 8 is exe-cuted). The VLR creates or updates the SGSN-VLR association by storing the SGSN number.

Step 11. The standard GSM location update proce-dure is performed. The details can be found inReferences [1, 9].

Step 12. The new VLR allocates a new TMSI andresponds with Location Update Accept to theSGSN. Allocation of TMSI is optional if the VLRis not changed.

Step 13. The new SGSN sends the Routing AreaUpdate Accept message to the MS. In GPRS, thenew SGSN also confirms all mobile-originated N-PDUs successfully transferred before the start ofthe update procedure.

Step 14. The MS sends the Routing Area UpdateComplete message to the new SGSN to confirmthe reallocation of the TMSI. In GPRS, the MSalso confirms all received mobile-terminated N-PDUs before the RA update procedure started. Thisinformation is used by the new SGSN to check ifthe packets forwarded from the old SGSN havebeen received by the MS. If so, these redundantpackets are discarded.

Step 15. If a new TMSI has been received by the MS,then the TMSI Reallocation Complete message issent to the VLR.In terms of RA update, the major differences

between UMTS and GPRS are the following:

ž In GPRS, packet forwarding is performed bet-ween old and new SGSN during RA update. InUMTS, packet forwarding is handled at the RNClevel, and the SGSN is not involved.



ž In the RA update, the UMTS MS may determineif the Iu connection should be maintained (cf.,Step 1 in Figure 7), which is not needed inGPRS.

Note that for a pure intra-SGSN RA update,Steps 2–12, 14 and 15 in Figure 7 are not executed.For a pure inter-SGSN RA update, Steps 10–12, and15 are not executed.

7. SRNC, DRNC, and SRNC Relocation

In UMTS, packets are routed between the MS and theGGSN. An example of the routing path is illustratedin Figure 8(a). In this figure, the MS communicateswith two Node Bs (B1 and B2). In WCDMA [3, 12],

an MS is allowed to transmit signal through multi-ple radio paths connected to different Node Bs, andthe signals are merged in a network node (RNC1 inFigure 8(a)). In a packet routing path between thecore network and the MS, the RNC that directly con-nects to the SGSN is called the serving RNC (SRNC).In Figure 8(a), RNC1 is the serving RNC. If the MSmoves during packet transmission, the packet rout-ing path may be changed. In the above example,when the MS moves toward Node B3, the radio linkbetween the MS and B1 is removed due to radiopath loss, and the radio link between B3 and theMS is added [Figure 8(b)]. In this case, B3 is con-nected to RNC2, and an Iur link between RNC1and RNC2 is established so that the signal receivedby B3 can be forwarded to RNC1 through RNC2.

RNC2

SGSN1 SGSN2

GGSN

B2B1 B3

RNC1 RNC2

SGSN1 SGSN2

GGSN

B2B1 B3

RNC1

RNC2

SGSN1 SGSN2

GGSN

B2B1 B3

RNC1 RNC2

SGSN1 SGSN2

GGSN

B2B1 B3

RNC1

(a) (b)

(c)(d)

Fig. 8. PS SRNC relocation.



RNC1 then combines the signals from B2 and B3,and forwards it to SGSN1. In this case, RNC1 is theSRNC, and RNC2 is called the drift RNC (DRNC).DRNC transparently routes the data through the Iuband the Iur interfaces. It only performs Layer 1 andpartial Layer 2 functionality (e.g., MAC for commonand shared channels). Thus, in Figure 8(b), the RLCconnections are defined between the SRNC and theMS, and the DRNC is bypassed. Suppose that the MSmoves away from B2, and the radio link between theMS and B2 is disconnected. In this case, the MSdoes not communicate with any Node Bs connectedto RNC1. The routing path is now MS $ B3 $RNC2 $ RNC1 $ SGSN1 $ GGSN as shown in[Figure 8(c)]. In this case, it does not make sense toroute packets between the MS and the core networkthrough RNC1. SRNC relocation may be performedto remove RNC1 from the routing path. Suppose thatRNC2 connects to SGSN2. Then after RNC reloca-tion, the packets are routed to the GGSN throughRNC2 and SGSN2 [Figure 8(d)]. At this point, RNC2becomes the serving RNC. SRNC relocation may alsobe executed when hard handoff [1] occurs (and theMS is in the PMM-CONNECTED state). As shownin Figure 9(a), before the relocation, the communi-cation path is GGSN $ SGSN1 $ RNC1 $ B2 $MS, and the MS is not connected to any Node Bsof RNC2. During hard handoff and SRNC relocation,the radio link connected to the MS is switched fromB2 to B3. After the relocation, the communicationpath is GGSN $ SGSN2 $ RNC2 $ B3 $ MS.

The SRNC relocation procedures for PS andCS services are different. Figure 10 illustrates theCS connection before and after SRNC relocation.

Before relocation, the call path is MSC1 $ RNC1 $RNC2 $ MS. After the relocation, the call pathis MSC1 $ MSC2 $ RNC2 $ MS, and MSC1becomes the anchor MSC.

The SRNC relocation procedure for PS is illus-trated in Figure 11. This procedure is only performedfor an MS in PMM-CONNECTED state. The detailsare given next.

Step 1. RNC1 determines that RNC2 is the targetfor relocation, and informs SGSN1 of this decisionthrough the Relocation Required message.

Step 2. If both RNC2 and RNC1 are connected toSGSN1 (intra SGSN relocation), Steps 2–4 areskipped, and the relocation procedure proceeds toStep 5. Otherwise, it is an inter-SGSN SRNC relo-cation. In this case, suppose that RNC2 connectsto SGSN2. Then SGSN1 sends the MM and thePDP contexts of the MS to SGSN2 by using theForward Relocation Request message.

Step 3. SGSN2 and RNC2 exchange the RelocationRequest and Response message pair to establish theIu user plane transport bearers between SGSN2 andRNC2, and exchange routing information requiredfor packet delivery.

Step 4. SGSN2 sends the Forward Relocation Res-ponse message to SGSN1. The message indicatesthat SGSN2 and RNC2 are ready to receive thedownstream packets buffered in RNC1 (i.e., thepackets that have not been acknowledged by theMS).

Step 5. SGSN1 sends the Relocation Command mes-sage to RNC1. This message instructs RNC1 toforward the buffered downstream packets to RNC2.

RNC2

SGSN1 SGSN2

GGSN

B2B1 B3

RNC1RNC2

SGSN1 SGSN2

GGSN

(a) (b)

B2B1 B3

RNC1

Fig. 9. Combined hard handoff with SRNS relocation. (a) Before SRNC relocation; (b) after SRNC relocation.



(a) (b)

B1 B2 B3

RNC1 RNC2

Another call party

MSC2MSC1PSTN

B1 B2 B3

RNC1 RNC2

PSTN

Another call party

MSC2MSC1

Fig. 10. CS SRNC relocation. (a) Before SRNC relocation; (b) after SRNC relocation.

MS GGSNSGSN2SGSN1RNC2RNC1

Preparation phaseat the core network

Resource release ofthe old connection

1. Relocation Required2. Forward Relocation Request

3. Relocation Request & Ack

4. Forward Relocation Response

5. Relocation Command

6. Relocation Commit

8. RNTI Reallocation & Complete

Downstream Packet forwarding7. Relocation Detect

13. RA Update Procedure

11. Forward Relocation Complete & Ack

9. Update PDP Context Request & Response

10. Relocation Complete

12. Iu Release Command & Complete

Fig. 11. SRNC relocation message flow for PS.

Steps 1–5 reserve the core network resources forthe new path. Before Step 6 is executed, the packetsare routed through the old path.Step 6. When RNC1 receives the Relocation

Command message, it starts the data-forwardingtimer. Expiration of this timer will be checkedat Step 12. RNC1 sends the Relocation Commitmessage to RNC2, which provides informationabout the buffered packets (e.g., sequence

numbers) to be tunneled to RNC2. RNC1 stopsexchanging packets with the MS, and forwards thebuffered packets (which are sent from GGSN) toRNC2. RNC2 switches all bearers from the RNC1to the SGSN.

Step 7. Immediately after RNC2 is successfulswitched at Step 6, RNC2 sends Relocation Detectmessage to SGSN2 [13]. The purpose of thismessage is to inform the SGSN2 that RNC2 is



starting the SRNC operation, and the CN shouldswitch the packet routing path from RNC1 toRNC2.

Step 8. RNC2 restarts the RLC connections. RNC2and the MS exchange information to identify thelast upstream packets received by RNC2 and thelast downstream packets received by the MS. Thisis achieved by exchanging the RNTI Reallocationand Complete message pair. In the RNTI Real-location message, RNC2 provides RA, LA, andpossibly RRC information. Since the RA has beenchanged, the MS also triggers the RA update pro-cedure shown at Step 13. After the MS has recon-figured itself, it sends the RNTI Reallocation Com-plete message to the RNC2. The packet exchangewith the MS can start. Note that the messageRNTI Reallocation is not found in 3GPP specifi-cations (specifically, 3GPP 25.331 [5]) by the timewhen this article was written. Instead, we foundthat two messages, UTRAN Mobility Informationand UTRAN Mobility Information Confirm, canbe used by UTRAN to allocate a new RNTI and toconvey other UTRAN mobility related informationto an MS.In Steps 6–8, the UTRAN connection point is

moved from RNC1 to RNC2. In this period, packetexchange between the MS and network is stopped forloss-less relocation.Step 9. After Step 7, the SGSN2 switches the user

plane from RNC1 to RNC2. For inter SGSNSRNS relocation, SGSN2 and every correspondingGGSN exchange the Update PDP Context Requestand Response message pair to modify the GGSNaddress, SGSN TEID, and QoS profile negotiatedstored in the GGSN PDP context. This operationswitches the GGSN connection from SGSN1 toSGSN2.

Step 10. After Step 8, RNC2 sends the RelocationComplete message to SGSN2. This message trig-gers resource release of the old Iu connection.For intra-SGSN SRNC relocation (i.e., SGSN2is SGSN1), the procedure proceeds to Step 12to release the old Iu connection. For inter-SGSNSRNS relocation, Steps 11 and 12 are executed torelease old Iu connection.

Step 11. SGSN2 instructs SGSN1 to release the old Iuconnection by exchanging the Forward RelocationComplete and Acknowledge message pair.

Step 12. SGSN1 sends the Iu Release Command mes-sage to RNC1. When the data-forwarding timer setin Step 6 expires, RNC1 returns the Iu Release

Complete message to SGSN1, and the old Iu con-nection is released.

Step 13. The RA update procedure described inSection 6 is triggered by the MS at Step 8.

For combined hard handoff with SRNC relocation,the message flow is similar to the one in Figure 11with the following differences. The SRNC reloca-tion procedure (without hard handoff) is initiatedby RNC1 without involving the MS. For combinedhard handoff with SRNC relocation, at the begin-ning, RNC1 decides that the MS is involved, andthe MS reconfigures physical channel immediatelyafter Step 5. Thus, RNTI relocation at Step 8 is notneeded. Also, in the combined procedure, the SRNCcontext (of RNC1) must be forwarded through thepath SGSN1 ! SGSN2 ! RNC2.

8. UMTS-GPRS Intersystem Change

When a GPRS/UMTS dual mode MS moves from acell supporting GSM/GPRS radio technology to a cellsupporting WCDMA radio technology (or vice versa),a UMTS-GPRS intersystem change may take place.To provide this feature, mechanisms should exist toderive the area identities (for LA, RA, and cell) andthe routing-related information from one system toanother.

In this section, we describe UMTS-GPRS inter-system change using simple examples where theGSM/GPRS cells and the UMTS cells are connectedto the same SGSN. In this case, the SGSN supportsboth the Gb and Iu-PS interfaces.

For SGSN change from UMTS to GPRS, if the MSis in the PMM-IDLE state, then the normal GPRS RAupdate procedure is executed. If the MS makes theintersystem change decision when it is in the PMM-CONNECTED state, then it stops the transmission tothe network, and the following steps are executed forintra SGSN change (see Figure 12):

Step 1. An LLC link is established between theMS and the SGSN. The MS sends the Rout-ing Area Update Request message to the SGSNthrough the new BSS. This step is exactly thesame as Step 1 of Figure 7 initiated by a GPRSMS.

Step 2. The SGSN exchanges the SRNS ContextRequest and Response messages with the oldSRNS to obtain the following information: GTP-SND and GTP-SNU are used to resume transmis-sion to the GGSN. PDCP-SNU is used to resume



MS SGSN

LA update involving SGSN, newVLR, old VLR, and the HLR

new BSS old SRNS


2. SRNS Context Request & Response3. Security Functions

4. SRNS Data Forward Command

5. Forward Packets

6. Iu Release Command & Complete

7. Routing Area Update Acept

8. Routing Area Update Complete

9. BSS Packet Flow Context Procedure

Fig. 12. Intra SGSN change from UMTS to GPRS.

transmission to the MS for loss-less relocation.The SGSN converts the PDCP sequence numberinto the SNDCP sequence number and saved it inthe GPRS PDP context. The SRNS stops sendingpackets to the MS, and starts buffering the packetsreceived from the GGSN.

Step 3. Security functions may be executed as inStep 3 of Figure 7. If the MS is not allowed toattach in the RA, or if subscription checking fails,then the SGSN rejects this RA update.

Step 4. At this point, the SGSN is ready to receivepackets. The SGSN sends the SRNS Data For-ward Command message to the old SRNS, whichinstructs the SRNS to forward the buffered packetsto the SGSN. The SRNS starts a data-forwardingtimer. Before this timer expires, the Iu connectionbetween the SRNS and the SGSN will be main-tained (see Step 6).

Step 5. For the packets received by the old SRNSfrom the SGSN, but have not been sent to the MS,the packets are tunneled back from the SRNS tothe SGSN.

Step 6. When the SGSN timer set at Step 4 expires,the Iu Release Command and Complete mes-sages are exchanged to release the Iu connec-tion. If the type parameter in the Routing AreaUpdate Request message at Step 1 is combinedRA/LA update (for Network Mode I), or if the

LA has been changed, then the SGSN triggersLA update (see Steps 10–12 in Figure 7) thatinvolves the SGSN, new VLR, old VLR andthe HLR.

Step 7. The SGSN updates the MM and PDP con-texts. New P-TMSI and new TMSI may be allo-cated. The SGSN sends the Routing Area UpdateAccept message to the MS.

Step 8. The MS returns the Routing Area UpdateComplete message to the SGSN if a new P-TMSIis allocated or if the MS needs to acknowledgethe packets received from the network. If a newTMSI is allocated to the MS, then the SGSNsends a TMSI Reallocation Complete messageto the new VLR (this message is not shown inFigure 12).

Step 9. The SGSN and the BSS execute the BSSpacket flow context procedure if no BSS packetflow context exists in the BSS. In this context, theSGSN provides the BSS with information relatedto ongoing user data transmission.

For SGSN change from GPRS to UMTS, if theMS is in the STANDBY state, then the normalUMTS RA update procedure is executed. If the MSmakes the intersystem change decision when it isin the READY state, then it stops the transmissionto the network by disconnecting the LLC link. The



SGSNMS old BSSnew SRNS


LA update involving SGSN, newVLR, old VLR, and the HLR


3. Routing Area Update Accept & Complete

4. Service Request

5. RAB Assignment Request

5. Radio Path Setup

5. RAB Assignment Response

6. Packet Transfer Resumed

Fig. 13. Intra SGSN change from GPRS to UMTS.

following steps are executed for intra SGSN change(see Figure 13):

Step 1. The MS establishes an RRC connection to thenew SRNS, and sends the Routing Area UpdateRequest to the SGSN through the SRNS.

Step 2. The SGSN stops the transmission to theold BSS. The security functions may be executedamong SGSN, SRNS, and MS. If the type param-eter in the Routing Area Update Request messageat Step 1 is combined RA/LA update (for Net-work Mode I), or if the LA has been changed, thenthe SGSN triggers LA update (see Steps 10–12 inFigure 7) that involves the SGSN, new VLR, oldVLR and the HLR.

Step 3. The SGSN updates the MM and PDP con-texts for the MS. A new P-TMSI may be allo-cated. The SGSN sends the Routing Area UpdateAccept message to the MS. Reception of the newP-TMSI is acknowledged by the MS through theRouting Area Update Complete message. If a newTMSI is allocated to the MS, then the SGSNsends a TMSI Reallocation Complete messageto the new VLR (this message is not shown inFigure 13).

Step 4. If the MS has pending uplink data or signal-ing, it sends the Service Request message to theSGSN.

Step 5. The SGSN requests the SRNS to set up theradio bearer between the SRNS and the MS. TheN-PDU sequence numbers in GPRS PDP contextof the SGSN is used to derive PDCP sequencenumbers for the next packets to be delivered inthe UTRAN radio bearer.

Step 6. Packet transmission is resumed betweenSGSN, SRNS, and MS.

A major difference between the message flowsin Figs 12 and 13 is that packet forwarding is notrequired in intra SGSN change from GPRS to UMTS.The reason is that in GPRS, the packets are bufferedin SGSN. Note that for inter SGSN change fromGPRS to UMTS, packet forwarding will occur fromthe old SGSN to the new SGSN. The details can befound in Reference [9].

9. Summary

Based on 3GPP 23.060 [9], this paper describesmobility management evolution from GPRS toUMTS. In the UMTS architecture, the radio accessnetwork UTRAN is introduced. Most radio manage-ment functions handled in GPRS core network havebeen moved to UTRAN in UMTS. This architecturechange results in a clean design that allows the radio



technology and the core network technology to bedeveloped independently. The GPRS mobility man-agement functionality has been significantly modifiedto accommodate UMTS. This paper pronounced thedifferences between the GPRS and the UMTS proce-dures.

For further reading, the readers are encouraged tounderstand the UMTS radio technology; i.e.,WCDMA [3]. For UMTS core network architecture,the reader is referred to [2]. The UMTS protocolstacks are introduced in Reference [9]. Details for theGPRS mobility management can be found in Refer-ence [1]. The complete 3GPP specifications can befound in www.3gpp.org.

Acknowledgment

Lin’s work was sponsored in part by MOE Programof Excellence Research, Tahoe Network, Ericsson,InterVideo, FarEastone, National Science Council,and the Lee and MTI Center for Networking Re-search, NCTU.

References

1. Lin Y-B, Chlamtac I. wireless and Mobile Network Architec-tures. John Wiley & Sons, 2000.

2. 3GPP. 3rd Generation Partnership Project; Technical Speci-fication Group Services and Systems Aspects; ArchitecturalRequirements for Release 1999. Technical Specification 3GTS 23.121 version 3.4.0 (2000-10), 3GPP, 2000.

3. Holma H, Toskala A (eds). WCDMA for UMTS. John Wiley& Sons, 2000.

4. 3GPP. 3rd Generation Partnership Project; Technical Speci-fication Group Core Network; General Packet Radio Service(GPRS); GPRS Tunneling Protocol (GTP) across the Gn andGp Interface (Release 99), 3G Ts 29.060 version 3.7.0 (2000-12). Technical Specification, 3GPP, 2000.

5. 3GPP. 3rd Generation Partnership Project; Technical Specifi-cation Group Radio Access Network; RRC Protocol Specifica-tion for Release 1999. Technical Specification 3G TS 25.331version 3.5.0 (2000–12), 3GPP, 2000.

6. 3GPP. 3rd Generation Partnership Project; Technical Specifi-cation Group Services and Systems Aspects; Network Archi-tecture. Technical Specification 3G TS 23.002 version 4.0.0(2000-10), 3GPP, 2000.

7. ETSI/TC. Mobile Radio Interface Layer 3 Specification. Tech-nical Specification Recommendation GSM 04.08, ETSI, 1993.

8. 3GPP. 3rd Generation Partnership Project; Technical Speci-fication Group Services and Systems Aspects; 3G Security;Security Architecture. Technical Specification 3G TS 33.102V3.7.0 (2000-12), 2000.

9. 3GPP. 3rd Generation Partnership Project; Technical Specifi-cation Group Services and Systems Aspects; General PacketRadio Service (GPRS); Service Description; Stage 2. Techni-cal Specification 3G TS 23.060 version 3.6.0 (2001-01), 2000.

10. 3GPP. 3rd Generation Partnership Project; Technical Specifica-tion Group Services and Systems Aspects; Functional Stage 2Description of Location Services in UMTS for Release 1999.Technical Specification 3G TS 23.171 version 3.2.0 (2000-12),3GPP, 2000.

11. 3GPP. 3rd Generation Partnership Project; Technical Specifi-cation Group Core Network; Mobile Radio Interface Layer 3Specification; Core Network Protocols—Stage 3 for Release1999. 3G TS 24.008 version 3.6.0 (2000-12), 2000.

12. 3GPP. 3rd Generation Partnership Project; Technical Specifica-tion Group Radio Access Network; UTRAN Overall Descrip-tion. Technical Specification 3G TS 25.401 version 3.5.0(2000-12), 2000.

13. 3GPP. 3rd Generation Partnership Project; Technical Speci-fication Group Radio Access Network; UTRAN Iu InterfaceRANAP signaling for Release 1999. Technical Specification3G TS 25.413 version 3.4.0 (2000-12), 3GPP, 2000.


mobility management - from gprs to umts

Documents