03-Mobility Management Functions PDF

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network
Table of Contents
Table of Contents
Chapter 3 Mobility Management Functions................................................................................ 3-1 3.1 Definition of Mobility Management States ......................................................................... 3-1 3.1.1 Mobility Management States (GSM Only)............................................................... 3-1 3.1.2 Mobility Management States (UMTS Only)............................................................. 3-2 3.2 Mobility Management Timer Functions.............................................................................. 3-4 3.2.1 READY Timer Function (GSM Only)....................................................................... 3-4 3.2.2 Periodic RA Update Timer Function........................................................................ 3-4 3.2.3 Mobile Reachable Timer Function .......................................................................... 3-5 3.3 Interactions Between SGSN and MSC/VLR...................................................................... 3-5 3.3.1 Administration of the SGSN-MSC/VLR Association ............................................... 3-5 3.3.2 Combined RA/LA Updating ..................................................................................... 3-6 3.3.3 CS Paging (GSM Only) .......................................................................................... 3-6 3.3.4 CS Paging (UMTS Only) ......................................................................................... 3-7 3.3.5 Non-GPRS Alert ...................................................................................................... 3-7 3.3.6 MS Information Procedure ...................................................................................... 3-7 3.3.7 MM Information Procedure...................................................................................... 3-8 3.4 GPRS Attach Function....................................................................................................... 3-8 3.4.1 GSM GPRS Attach Procedure ................................................................................ 3-8 3.4.2 Combined GPRS/IMSI Attach Procedure ............................................................... 3-9 3.5 Detach Function............................................................................................................... 3-13 3.5.1 MS-Initiated Detach Procedure ............................................................................. 3-13 3.5.2 Network-Initiated Detach Procedure ..................................................................... 3-14 3.6 Purge Function................................................................................................................. 3-17 3.7 Security Function ............................................................................................................. 3-17 3.7.1 Authentication........................................................................................................ 3-18 3.7.2 User Identity Confidentiality .................................................................................. 3-19 3.7.3 User Data and GMM/SM Signalling Confidentiality .............................................. 3-20 3.7.4 Identity Check Procedures .................................................................................... 3-21 3.7.5 Data Integrity Procedure (UMTS Only) ................................................................. 3-21 3.8 Location Management Function ...................................................................................... 3-21 3.8.1 Location Management Procedures (GSM Only) ................................................... 3-22 3.8.2 Location Management Procedures (UMTS Only) ................................................ 3-30 3.8.3 Periodic RA/LA Update ......................................................................................... 3-46 3.9 Subscriber Management Function................................................................................... 3-47 3.9.1 Subscriber Management Procedures ................................................................... 3-47 3.10 Service Request Procedure s (UMTS Only).................................................................. 3-48 3.10.1 MS-Initiated Service Request Procedure............................................................ 3-48
Huawei Technologies Proprietary i
Table of Contents
3.10.2 Network-Initiated Service Request Procedure .................................................... 3-50 3.11 UMTS-GSM Intersystem Change .................................................................................. 3-52 3.11.1 Intra SGSN Intersystem Change......................................................................... 3-52 3.11.2 Inter SGSN Intersystem Change......................................................................... 3-58 3.12 Classmark Handling....................................................................................................... 3-67 3.12.1 Radio Access Classmark .................................................................................... 3-67 3.12.2 MS Network Capability........................................................................................ 3-67
Huawei Technologies Proprietary ii
Chapter 3 Mobility Management Functions

3.1 Definition of Mobility Management States
3.1.1 Mobility Management States (GSM Only)
In GSM, the Mobility Management (MM) states for a GPRS subscriber are IDLE, STANDBY and READY. In IDLE state, the MS is not attached to the GPRS network. The MS is seen as not reachable in this case. In STANDBY state, the MS has been attached to the GPRS network. The MS and SGSN have established the relatd MM contexts. Data reception and transmission are not possible for the MS in this state, but it is possible to receive pages for the PS services and CS services. After receiving a page successfully, the MS moves from the STANDBY state to the READY state. In STANDBY state, the MS informs the SGSN of the routeing area update (RAU), but it does not reports the cell update. Therefore, the SGSN does not contain the accurate cell information of the MS in this case. The MS may initiate the GPRS detach procedure to move to the IDLE state. In READY state, the MS can send and receive data units, and the SGSN contains the accurate cell information of the MS. When it does not perform data reception or transmission for so long time in this state that the READY Timer expires, the MS moves to the STANDBY state. The MS can perform GPRS cell selection and reselection.
Huawei Technologies Proprietary 3-1
IDLE
IDLE
GPRS Attach
GPRS Detach
GPRS Attach
GPRS Detach or Cancel Location
READY
Implicit Detach or Cancel Location
READY
READY timer expiry or Force to STANDBY
PDU transmission
READY timer expiry or Force to STANDBY or Abnormal RLC condition
PDU reception
STANDBY
STANDBY
MM State Model of MS
MM State Model of SGSN
Figure 3-1 GSM MM state model
3.1.2 Mobility Management States (UMTS Only)

In UMTS, the PMM states for a GPRS subscriber are PMM-DETACHED, PMM-IDLE and PMM-CONNECTED. The state information held at the MS and the SGSN performs MM context management through mobility management. As shown in Figure 3-2, the PMM states are irrelated to the session management SM states. In both the PMM-CONNECTED and the PMM-IDLE states, the session management may or may not have ativated a PDP context. State transitions are given below:
I. Moving from PMM-DETACHED to PMM-CONNECTED

GPRS Attach. The MM context shall move from the PMM-DETACHED state to the PMM-CONNECTED state when a PS signalling connection is established between the MS and the 3G-SGSN for performing a GPRS attach.
II. Moving from PMM-CONNECTED to PMM-IDLE

PS Signalling Connection Release. The MM context shall move from the PMM-CONNECTED state to the PMM-IDLE state when the PS signalling connection is released.
III. Moving from PMM-IDLE to PMM-CONNECTED

PS Signalling Connection Establishment. The MM context shall move from the PMM-IDLE state to the PMM-CONNECTED state when the PS signalling connection is established between the MS and the 3G-SGSN.
IV. Moving from PMM-CONNECTED to PMM-DETACHED

GPRS Detach. The MM context shall move from the PMM-CONNECTED state to the PMM-DETACHED state when the PS signalling connection is released between the MS and the 3G-SGSN after the MS has performed a GPRS detach or after the network-initiated GPRS detach is performed. RAU Reject. The MM context shall move from the PMM-CONNECTED state to the PMM-DETACHED state when the PS signalling connection is released between the MS and the 3G-SGSN after a RAU is rejected by the 3G-SGSN. GPRS Attach Reject. The MM context shall move from the PMM-CONNECTED state to the PMM-DETACHED state when the PS signalling connection is released between the MS and the 3G-SGSN after a GPRS attach is rejected by the 3G-SGSN.
V. Moving from PMM-IDLE to PMM-DETACHED

Implicit GPRS Detach. The MM context shall move from the PMM-IDLE state to the PMM-DETACHED state, e.g., in the case of removal of the battery, the USIM, or the GSIM from the TE.
VI. Moving from PMM-CONNECTED to PMM-CONNECTED

SRNS Relocation. The MM context keeps in the PMM-CONNECTED state when the PS signalling connection is kept after a SRNS relocation is performed.
PM M DETACHED
PM M DETACHED
PS Detach PS Attach PS Signalling Connection Release
Detach, PS Attach Reject, RAUReject
PS Detach
PS Attach PS Signalling Connection Release PM M -IDLE
Detach, PS Attach Reject, RAUReject
PM M -IDLE
PM M CO NNECTED
PM M CO NNECTED
SM -ACTIVE or INACTIVE
PS Signalling Connection Establish
SM -ACTIVE or INACTIVE
SM -ACTIVE or SM -ACTIVE or PS Signalling INACTIVE INACTIVE Connection Establish
Serving RNC relocation
M SM MStates
Figure 3-2 UMTS PMM state model
3G-SGSNM MStates
Note: In case of an error, the PMM state of the MS and the 3G-SGSN may lose synchronisation. This situation may be recovered by a successful RAU.
3.2 Mobility Management Timer Functions

3.2.1 READY Timer Function (GSM Only)
The READY Timer function maintains the READY timer in the MS and SGSN. The READY timer controls the time an MS reamains in READY state in the MS and the SGSN. The READY timer shall be reset and begin running in the MS when an LLC PDU is transmitted, and in the SGSN when an LLC PDU is correctly received. When the READY timer expires, the MS and SGSN MM contexts shall return to STANDBY state. The UMTS system does not contain the READY timer.
3.2.2 Periodic RA Update Timer Function

The Periodic RA Update Timer function monitors the periodic RA update procedure in the MS. The length of the periodic RA update timer is sent in the Routeing Area
Update Accept or Attach Accept message. Upon expiry of the periodic RA update timer, the MS shall start a periodic routeing area update procedure.
3.2.3 Mobile Reachable Timer Function

The Mobile Reachable Timer function monitors the periodic RA update procedure in the SGSN. The mobile reachable timer shall be slightly longer than the periodic RA update timer used by an MS. The mobile reachable timer shall stop when the READY state or PMM-CONNECTED state is entered. The mobile reachable timer is reset and started when the state returns to STANDBY or PMM-IDLE.
3.3 Interactions Between SGSN and MSC/VLR

3.3.1 Administration of the SGSN-MSC/VLR Association
The interactions between SGSN and MSC/VLR are performed across the optional Gs interface. If the Gs interface is present, the SGSN stores the MSC/VLR number and the MSC/VLR stores the SGSN number, and the association is created. The association is updated when an IMSI and GPRS-attached MS changes SGSN or MSC/VLR. Besides requiring the support of the network operation mode, the interactions between SGSN and MSC/VLR are also associated with the operation mode of the MS. The GSM GPRS MS operation modes are defined as follows: Class-A mode of operation: The MS is attached to both GPRS and other GSM services, and the MS supports simultaenous operation of GPRS and other GSM services. Class-B mode of operation: The MS is attached to both GPRS and other GSM services, but the MS can only operate one set of services at a time. Class-C mode of operation: The MS is exclusively attached to GPRS services. The UMTS MS operation modes are defined as follows: CS/PS mode of operation: The MS is attached to both the PS domain and CS domain, and the MS is capable of simultaneously operating PS services and CS services. PS mode of operation: The MS is attached to the PS domain only and may only operate services of the PS domain. CS mode of operation: The MS is attached to the CS domain only and may only operate services of the CS domain.
3.3.2 Combined RA/LA Updating

The combined RA/LA update procedure is started at the following occasions: Combined GPRS/IMSI attach GPRS attach when the MS is already IMSI-attached IMSI attach when the MS is already GPRS-attached For details, refer to Section 3.4 GPRS Attach Function and Section 3.8 Location Management Function.
3.3.3 CS Paging (GSM Only)

When an MS is both IMSI and GPRS-attached in a network that operates in mode I, then the MSC/VLR executes paging for circuit-switched services via the SGSN. If the MS is in STANDBY state, then it is paged in the routeing area and in the null routeing area (Cells that do not support packet-domain services within an LA are grouped into a null RA). If the MS is in READY state, then it is paged in the cell. The paging procedure is supervised in the MSC by a paging timer. The SGSN converts the MSC paging message into an SGSN paging message and sends it to the MS. Upon receipt of the paging message, the MS makes a paging response directly to the MSC. Three network operation modes are defined for GSM, and they are described in Table 3-1. Table 3-1 Network operation modes for GSM Mode Circuit paging channel Packet paging channel I CCCH paging channel Packet data channel GPRS paging channel Packet paging channel CCCH paging channel Paging co-ordination Yes, the SGSN coordinates with the MSC/VLR to execute paging. The Gs interface is present in this case. The MS needs only to monitor one paging channel. It receives CS paging messages on the packet data channel when it has been assigned a packet data channel. No, the SGSN does not coordinate with the MSC/VLR to execute paging. The MS needs only to monitor the CCCH paging channel in this case. CS paging continues on the CCCH paging channel even if the MS has been assigned a packet data channel. No, the SGSN does not coordinate with the MSC/VLR to execute paging. An MS that wants to receive pages for both circuit-switched and packet-switched services shall monitor both the CCCH paging channel and the packet paging channel if the packet paging channel is allocated in the cell.
II
CCCH paging channel
CCCH paging channel
CCCH paging channel III CCCH paging channel
Packet paging channel CCCH paging channel
3.3.4 CS Paging (UMTS Only)

When an MS is both IMSI and GPRS-attached in a network that operates in mode I, then the MSC/VLR executes paging for circuit-switched services via the SGSN. The paging procedure is supervised in the MSC by a paging timer. The network operation mode is used to indicate whether the Gs interface is installed or not. When the Gs interface is present, the MSC/VLR executes paging via the SGSN. Upon receipt of the paging message, the MS makes a paging response directly to the MSC/VLR. Network operation modes for UMTS are described in Table 3-2. Table 3-2 Network operation modes for UMTS Mode I II Network configuration Gs interface is present Gs interface is not present Combined procedure by MS Yes No
The network operation mode shall be indicated as system information to the MSs. For proper operation, the mode of operation should be the same in each cell of a routeing area. Based on the mode of operation provided by the network, the MS can then choose, according to its capabilities, whether it can attach to CS domain services, to PS domain services, or to both. Furthermore, based on the mode of operation, the MS can choose whether it can initiate combine update procedures or separate update procedures, according to its capabilities. Network operation modes I and II for UMTS correspond to modes I and II, respectively, for GSM. Mode III applies to GSM and not to UMTS.
3.3.5 Non-GPRS Alert

If the MSC/VLR requests an SGSN to report activity from a specific MS, the SGSN shall set Non-GPRS Alert Flag (NGAF) for the MS. When the next activity from that MS is detected, the SGSN shall inform the MSC/VLR and clear NGAF.
3.3.6 MS Information Procedure

If the MSC/VLR requests the identity information and location information of an MS that is known by the SGSN, the SGSN shall return this information across the Gs interface. If the information requested is not known by the SGSN but is known by the
MS, then the MSC/VLR sends an MS information request to the MS via the SGSN and then gets the information.
3.3.7 MM Information Procedure

The MSC/VLR may send MM information to the SGSN, and then the SGSN may forward the MM information to the MS.
3.4 GPRS Attach Function

An MS shall perform a GPRS Attach to the SGSN in order to obtain access to the GPRS services. If the MS is connected via a GSM radio access network, it shall perform a GSM GPRS Attach procedure. If the MS is connected via a UMTS radio access network, it shall perform a UMTS GPRS Attach procedure. In whatever GPRS Attach procedure, the MS shall provide its identity and an indication of which type of attach that is to be executed. The identity provided to the network shall be the MS's Packet TMSI (P-TMSI) or IMSI. P-TMSI and the RAI associated with the P-TMSI shall be provided if the MS has a valid P-TMSI. If the MS does not have a valid P-TMSI, then the MS shall provide its IMSI. The MS performs a GPRS Attach procedure with the P-TMSI when it provides the P-TMSI, and with the IMSI when it provides its IMSI.
3.4.1 GSM GPRS Attach Procedure

A GPRS-attached MS makes IMSI attach, i.e., attach to CS domain services, via the SGSN with the combined RA/LA update procedure if the network operation mode is I. In network operation modes II and III, or if the MS is not GPRS-attached, then the MS makes IMSI attach across the A interface. An IMSI-attached MS in class-A mode of operation engaged in a CS connection shall use the (non-combined) GPRS Attach procedure when it performs a GPRS attach. At the RLC/MAC layer, the MS shall identify itself with a Local or Foreign TLLI if the MS is already GPRS-attached and is performing an IMSI attach. Otherwise, the MS shall identify itself with a Foreign TLLI, or a Random TLLI if a valid P-TMSI is not available. The Foreign or Random TLLI is used as an identifier during the attach procedure until a new P-TMSI is allocated. An IMSI-attached MS that can only operate in class-C mode of operation shall follow the normal IMSI detach procedure before it makes a GPRS attach. A GPRS-attached MS in class-C mode of operation shall always perform a GPRS detach before it makes an IMSI attach.
If the network operates in mode I, then an MS that is both GPRS-attached and IMSI-attached shall perform the Combined RA/LA Update procedures. If the network operates in mode II or III, then a GPRS-attached MS that has the capability to be simultaneously GPRS-attached and IMSI-attached shall perform the (non-combined) Routeing Area Update procedures.
3.4.2 Combined GPRS/IMSI Attach Procedure

The Combined GPRS/IMSI Attach procedure is illustrated in Figure 3-3.
MS
UTRAN
new SGSN
old SGSN
GGSN
EIR
new MSC/VLR
HLR
old MSC/VLR
1. Attach Request 2. Identification Request 2. Identification Response 3. Identity Request 3. Identity Response 4. Authentication 5. IMEI Check 6a. Update Location 6b. Cancel Location 6c. Cancel Location Ack 6d. Insert Subscriber Data
6e. Insert Subscriber Data Ack 6f. Update Location Ack
7a. Location Update Request 7b. Update Location 7c. Cancel Location 7d. Cancel Location Ack 7e. Insert Subscriber Data 7f. Insert Subscriber Data Ack 7g. Update Location Ack 7h. Location Update Accept
C1
8. Attach Accept 9. Attach Complete

10. TMSI Reallocation Complete
Figure 3-3 Combined GPRS/IMSI attach procedure
Each step is explained in the following list: 1) The MS initiates the Attach procedure by the transmission of an Attach Request (IMSI or P-TMSI and old RAI, Core Network Classmark, KSI,Attach Type, old P-TMSI Signature, follow on request, DRX Parameters) message to the SGSN. IMSI shall be included if the MS does not have a valid P-TMSI available. If the
MS has a valid P-TMSI, then P-TMSI and the old RAI associated with P-TMSI shall be included. If the MS uses P-TMSI for identifying itself and if it has also stored its old P-TMSI Signature, then the MS shall include the old P-TMSI Signature in the Attach Request message. Attach Type indicates which type of attach that is to be performed, i.e., GPRS attach only, GPRS Attach while already IMSI attached, or combined GPRS/IMSI attach. DRX Parameters indicate whether the MS uses discontinuous reception or not. If the MS uses discontinuous reception, then DRX Parameters also indicate when the MS is in a non-sleep mode able to receive paging requests. Follow on request shall be set by the MS if there is pending uplink traffic (signalling or user data). The SGSN may use, as an implementation option, the follow on request indication to release or keep the Iu connection after the completion of the GPRS Attach procedure. 2) If the MS identifies itself with P-TMSI and the SGSN has changed since detach, the new SGSN sends an Identification Request (P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN to request the IMSI. The old SGSN responds with Identification Response (IMSI, Authentication Triplets (for GPRS) or Authentication Vectors (for UMTS)). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN also validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old SGSN. 3) If the MS is unknown in both the old and new SGSN, the SGSN sends an Identity Request (Identity Type = IMSI) to the MS. The MS responds with Identity Response (IMSI). 4) If no MM context for the MS exists anywhere in the network, then authentication is mandatory. If P-TMSI allocation is going to be done, and if ciphering is supported by the network, ciphering mode shall be set. 5) 6) The equipment checking functions are optional in Identity Check procedures. Equipment checking is not supported here. If the SGSN number has changed since the GPRS detach, or if it is the very first attach, then the SGSN informs the HLR: a) The SGSN sends an Update Location (SGSN Number, SGSN Address, IMSI) to the HLR. b) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to Update Procedrue. c) The old SGSN acknowledges with Cancel Location Ack (IMSI). If there are any ongoing procedures for that MS, the old SGSN shall wait until these procedures are finished before removing the MM and PDP contexts. d) The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN.
e) The new SGSN validates the MS's presence in the (new) RA. If due to regional subscription restrictions the MS is not allowed to attach in the RA, the SGSN rejects the Attach Request with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If subscription checking fails for other reasons, the SGSN rejects the Attach Request with an appropriate cause and returns an Insert Subscriber Data Ack (IMSI, Cause) message to the HLR. If all checks are successful then the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. f) The HLR acknowledges the Update Location message by sending an Update Location Ack to the SGSN after the cancelling of old MM context and insertion of new MM context are finished. If the Update Location is rejected by the HLR, the SGSN rejects the Attach Request from the MS with an appropriate cause. g) If Attach Type in step 1) indicated GPRS Attach while already IMSI attached, or combined GPRS/IMSI attach, then the VLR shall be updated if the Gs interface is installed. The VLR number is derived from the RA information. The SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the first Insert Subscriber Data message from the HLR in step 6d). This operation marks the MS as GPRS-attached in the VLR. h) The SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) message to the VLR. Location Update Type shall indicate IMSI attach if Attach Type indicated combined GPRS/IMSI attach. Otherwise, Location Update Type shall indicate normal location update. The VLR creates an association with the SGSN by storing SGSN Number. i) If the LA update is inter-MSC, the new VLR sends Update Location (IMSI, new VLR) to the HLR. j) If the LA update is inter-MSC, the HLR sends a Cancel Location (IMSI) to the old VLR. k) The old VLR acknowledges with Cancel Location Ack (IMSI). l) If the LA update is inter-MSC, the HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR. m) The VLR acknowledges with Insert Subscriber Data Ack (IMSI). n) After finishing the inter-MSC location update procedures, the HLR responds with Update Location Ack (IMSI) to the new VLR. o) The VLR responds with Location Update Accept (VLR TMSI) to the SGSN. p) The SGSN selects Radio Priority SMS, and sends an Attach Accept (P-TMSI, VLR TMSI, P-TMSI Signature, Radio Priority SMS) message to the MS. P-TMSI is included if the SGSN allocates a new P-TMSI.
7) 8)
If P-TMSI or VLR TMSI was changed, the MS acknowledges the received TMSI(s) by returning an Attach Complete message to the SGSN. If VLR TMSI was changed, the SGSN confirms the VLR TMSI re-allocation by sending a TMSI Reallocation Complete message to the VLR.
If the Attach Request cannot be accepted, the SGSN returns an Attach Reject (IMSI, Cause) message to the MS. C1) CAMEL-GPRS-Attach-Request
3.5 Detach Function

Different from the GPRS Attach procedure that can only be initiated by an MS, the Detach procedure can be initiated by an MS or by the network. In the network-initiated Detach procedure, Detach Type indicates if the MS is requested to make a new attach and PDP context activation for the previously activated PDP contexts. If so, the attach procedure shall be initiated when the detach procedure is completed. The three different types of Detach are GPRS Detach, IMSI Detach and GPRS/IMSI Detach. The network equipment able to initiate the Detach procedure can be an SGSN or an HLR. The Detach procedure is usually used for operator-determined purposes if it is initiated by an HLR.
3.5.1 MS-Initiated Detach Procedure

The MS-Initiated Detach Procedure when initiated by the MS is illustrated in Figure 3-4.
MS BSS/UTRAN SGSN GGSN MSC/VLR
1. Detach Request 2. Delete PDP Context Request 2. Delete PDP Context Response C1 3. IMSI Detach Indication 4. GPRS Detach Indication 5. Detach Accept C2
6. PS Signalling Connection Release
Figure 3-4 MS-initiated detach procedure
Each step is explained in the following list:

1)
The MS detaches by sending Detach Request (Detach Type, P-TMSI, P-TMSI Signature, Switch Off) to the SGSN. Detach Type indicates which type of detach that is to be performed, i.e., GPRS Detach only, IMSI Detach only or combined GPRS and IMSI Detach. Switch Off indicates whether the detach is due to a switch off situation or not. The Detach Request message includes P-TMSI and P-TMSI Signature. P-TMSI Signature is used to check the validity of the Detach Request message. If P-TMSI Signature is not valid or is not included, then authentication procedure should be performed.
2)
If GPRS detach, the active PDP contexts in the GGSNs regarding this particular MS are deactivated by the SGSN sending Delete PDP Context Request (TEID) to the GGSNs. The GGSNs acknowledge with Delete PDP Context Response (TEID).
3) 4)
If IMSI detach, the SGSN sends an IMSI Detach Indication (IMSI) message to the VLR. If the MS wants to remain IMSI-attached and is doing a GPRS detach, the SGSN sends a GPRS Detach Indication (IMSI) message to the VLR. The VLR removes the association with the SGSN and handles paging and location update without going via the SGSN.
5) 6)
If Switch Off indicates that the detach is not due to a switch off situation, the SGSN sends a Detach Accept to the MS. If the MS was GPRS detached, then the 3G-SGSN releases the PS signalling connection.
C1) CAMEL-Deactivate-PDP-Context. This procedure is performed every time when a PDP context is updated and shall be performed for many times. C2) CAMEL-GPRS-Detach.
3.5.2 Network-Initiated Detach Procedure

The network-initiated detach includes two types of detach: SGSN-initiated detach and HLR-initiated detach that are described as follows:
I. SGSN-initiated detach procedure

The SGSN-initiated detach procedure when initiated by the SGSN is illustrated in Figure 3-5.
MS
BSS/UTRAN
SGSN
GGSN
MSC/VLR
1. Detach Request
2. Delete PDP Context Request 2. Delete PDP Context Response C1 3. GPRS Detach Indication C2
4. Detach Accept
5. PS Signalling Connection Release
Figure 3-5 SGSN-initiated detach procedure
Each step is explained in the following list: 1) The SGSN informs the MS that it has been detached by sending Detach Request (Detach Type) to the MS. Detach Type indicates if the MS is requested to make a new attach and PDP context activation for the previously activated PDP contexts. If so, the attach procedure shall be initiated when the detach procedure is completed. 2) The active PDP contexts in the GGSNs regarding this particular MS are deactivated by the SGSN sending Delete PDP Context Request (TEID) messages to the GGSNs. The GGSNs acknowledge with Delete PDP Context Response (TEID) messages. 3) If the MS was both IMSI- and GPRS-attached, the SGSN sends a GPRS Detach Indication (IMSI) message to the VLR. The VLR removes the association with the SGSN and handles paging and location update without going via the SGSN. 4) 5) The MS sends a Detach Accept message to the SGSN any time after step 1). After receiving the Detach Accept message, if Detach Type did not request the MS to make a new attach, then the 3G-SGSN releases the PS signalling connection. C1) CAMEL-Deactivate-PDP-Context. This procedure is performed every time when a PDP context is updated and shall be performed for many times. C2) CAMEL-GPRS-Detach initiated by the SGSN.
II. HLR-initiated detach procedure

The HLR-initiated detach procedure when initiated by the HLR is illustrated in Figure 3-6.
MS
BSS/UTRAN
SGSN
GGSN
HLR
MSC/VLR
2. Detach Request
1. Cancel Location 3. Delete PDP Context Request 3. Delete PDP Context Response C1
5. Detach Accept
4. GPRS Detach Indication
C2 6. Cancel Location Ack 7. PS Signalling Connection Release
Figure 3-6 HLR-initiated detach procedure
Each step is explained in the following list: 1) If the HLR wants to request the immediate deletion of a subscriber's MM and PDP contexts from the SGSN, the HLR shall send a Cancel Location (IMSI, Cancellation Type) message to the SGSN with Cancellation Type set to Subscription Withdrawn. 2) The SGSN informs the MS that it has been detached by sending Detach Request (Detach Type) to the MS. Detach Type shall indicate that the MS is not requested to make a new attach and PDP context activation. 3) The active PDP contexts in the GGSNs regarding this particular MS are deleted by the SGSN sending Delete PDP Context Request (TEID) messages to the GGSNs. The GGSNs acknowledge with Delete PDP Context Response (TEID) messages. 4) If the MS was both IMSI- and GPRS-attached, the SGSN sends a GPRS Detach Indication (IMSI) message to the VLR. The VLR removes the association with the SGSN and handles paging and location update without going via the SGSN. 5) 6) 7) The MS sends a Detach Accept message to the SGSN any time after step 1). The SGSN shall confirm the deletion of the MM and PDP contexts with a Cancel Location Ack (IMSI) message. After receiving the Detach Accept message, if Detach Type did not request the MS to make a new attach, then the 3G-SGSN releases the PS signalling connection. C1) CAMEL-Deactivate-PDP-Context. This procedure is performed every time when a PDP context is updated and shall be performed for many times. C2) CAMEL-GPRS-Detach initiated by the HLR.
3.6 Purge Function

The Purge function allows an SGSN to inform the HLR that it has deleted the MM and PDP contexts of a detached MS. The SGSN may, as an implementation option, delete the MM and PDP contexts after the implicit or explicit detach of the MS. Alternatively, the SGSN may keep for some time the MM and PDP contexts and the authentication triplets of the detached MS, so that the contexts can be reused at a later GPRS attach without accessing the HLR. When the SGSN deletes the MM and PDP contexts, it shall initiate the Purge procedure as illustrated in Figure 3-7.
SGSN 1. Purge MS 2. Purge MS Ack
HLR
Figure 3-7 Purge procedure
Each step is explained in the following list: 1) 2) After deleting the MM and PDP contexts of a detached MS, the SGSN sends a Purge MS (IMSI) message to the HLR. The HLR sets the MS Purged for GPRS flag and acknowledges with a Purge MS Ack message.
3.7 Security Function

The Security function: Guards against unauthorised packet-domain service usage (authentication of the MS by the network and service request validation). Provides user identity confidentiality (temporary identification and ciphering). Provides user data and signalling confidentiality (ciphering). Provides, for UMTS radio access only, data integrity and origin authentication of signalling data (integrity protection). Provides, for UMTS subscriber (USIM) only, authentication of the network by the MS. Security-related network functions are described in GSM 03.20 and in 3G TS 33.102.
3.7.1 Authentication
"GSM authentication" is executed from the SGSN and implies authentication of the MS by the network and establishment of a new GSM ciphering key (Kc) agreement between the SGSN and the MS. "UMTS authentication" is executed from the SGSN and implies mutual authentication, i.e., authentication of the MS by the network and authentication of the network by the MS. It also implies establishment of a new UMTS ciphering key (CK) and integrity key (IK) agreement between the SGSN and the MS. Compared with the GSM authentication procedure, the UMTS authentication procedure provides two more functions, i.e., integrity check and authentication of the network by the MS. These functions further enhance the UMTS security. The Authentication procedure is illustrated in Figure 3-8.
MS
BSS/UTRAN
SGSN
HLR
1. Send Authentication Info 1. Send Authentication Info Ack 2. Authentication and Ciphering Request 2. Authentication and Ciphering Response
Figure 3-8 Authentication procedure
Each step is explained in the following list, with the Authentication of UMTS Subscriber procedure as an example: 1) If the SGSN does not have previously stored UMTS Authentication Vectors (quintuplets), a Send Authentication Info (IMSI) message is sent to the HLR. Upon receipt of this message for a UMTS user, the HLR/AuC responds with a Send Authentication Info Ack message including an ordered array of quintuplets to the SGSN. Each quintuplet contains RAND, XRES, AUTN, CK, and IK. The generation of quintuplets in HLR/AuC for a UMTS user is performed as specified in 3G TS 33.102. 2) At authentication of a UMTS subscriber, the SGSN selects the next in-order quintuplet and transmits the RAND and AUTN, that belong to this quintuplet, to the MS in the Authentication and Ciphering Request (RAND, AUTN, CKSN) message. The SGSN also selects a ciphering key sequence number (CKSN) and includes this in the message.
3)
At reception of this message, the USIM in the MS verifies AUTN and, if accepted, the USIM computes the signature of RAND, RES, in accordance with 3G TS 33.102. If the USIM considers the authentication being successful the MS returns an Authentication and Ciphering Response (RES) message to the SGSN.
If the USIM considers the authentication being unsuccessful, e.g., in case of an authentication synchronisation failure, the MS returns the Authentication and Ciphering Failure message to the SGSN. The typical causes of the authentication failure include two types: MAC Failure. If the MS detects MAC error in the AUTN in the Authentication and Ciphering Request message at authentication of the network, it returns an Authentication and Ciphering Failure message to the SGSN with cause "MAC Failure". The SGSN determines, according to the identity provided by the MS, if an Identification procedure is to be initiated. If the currently-provided identity is TMSI or P-TMSI, the Identification procedure is initiated and the MS is requested to provide its IMSI. Then the SGSN initiates another Authentication prcedure. Synch Failure. If the MS detects SQN error in the AUTN in the Authentication and Ciphering Request message at authentication of the network, it returns an Authentication and Ciphering Failure message to the SGSN with cause "Synch Failure". The SGSN deletes all Authentication Vectors (quintuplets) and initiates a Synchronsation procedure to the HLR, requesting the HLR to reinsert Authentication Vectors (quintuplets). Then the SGSN initiates another Authentication procedure. 4) Upon reception of the Authentication and Ciphering Response message, the SGSN compares the XRES in the message with the XRES in Authentication Vectors (quintuplets) that are stored in the SGSN database and judges whether the authentication is successful. If successful, the SGSN continues to execute the following procedures normally. If unsuccessful, the SGSN sends an Authentication and Ciphering Reject message, informing the MS of the authentication failure. Then the SGSN terminates the current procedure and releases the resource allocated to the MS. After successful authentication, the MS stores the Ciphering Key (CK) and the Integrity Key (IK) in the USIM.
3.7.2 User Identity Confidentiality

Usually the network does not directly use an IMSI but uses a P-TMSI allocated by the SGSN as a temparory MS identity between the MS and the SGSN. A Temporary Logical Link Identity (TLLI) identifies a GSM user. The relationship between TLLI and IMSI is known only in the MS and in the SGSN. TLLI is derived from the P-TMSI allocated by the SGSN or built by the MS.
A Radio Network Temporary Identity (RNTI) identifies a UMTS user between the MS and the UTRAN. The relationship between RNTI and IMSI is known only in the MS and in the UTRAN. A P-TMSI identifies a UMTS user between the MS and the SGSN. The relationship between P-TMSI and IMSI is known only in the MS and in the SGSN. The reallocation procedure guarantees the randomness of the temporary identity. This avoids the leakage of the user identity. The P-TMSI Reallocation procedure is illustrated in Figure 3-9.
MS BSS/UTRAN SGSN
1. P-TMSI Reallocation Command 2. P-TMSI Reallocation Complete
Figure 3-9 P-TMSI reallocation procedure
Each step is explained in the following list: 1) The SGSN sends a P-TMSI Reallocation Command (new P-TMSI, P-TMSI Signature, RAI) message to the MS. P-TMSI Signature is an optional parameter that the MS, if received, shall return to the SGSN in the next Attach and Routeing Area Update procedures. 2) The MS returns a P-TMSI Reallocation Complete message to the SGSN.
3.7.3 User Data and GMM/SM Signalling Confidentiality

The scope of ciphering is illustrated in Figure 3-10.
MS BSS/UTRAN SGSN Scope of GPRS ciphering Scope of UMTS ciphering
Figure 3-10 Scope of ciphering
As illustrated in Figure 3-10, the scope of UMTS ciphering is narrower than that the scope of GPRS ciphering, and it is only from the ciphering function in the UTRAN to the ciphering function in the MS.
3.7.4 Identity Check Procedures

The Identity Check procedure is illustrated in Figure 3-11.
MS BSS/UTRAN SGSN EIR
1. Identity Request 1. Identity Response 2. Check IMEI 2. Check IMEI Ack
Figure 3-11 Identity check procedure
Each step is explained in the following list: 1) The SGSN sends Identity Request (Identity Type) to the MS. The MS responds with Identity Response (Mobile Identity). In UMTS, the MS may choose to send its IMSI encrypted (FFS). 2) If the SGSN decides to check the IMEI against the EIR, it sends Check IMEI (IMEI) to EIR. The EIR responds with Check IMEI Ack (IMEI). This is an optional procedure.
3.7.5 Data Integrity Procedure (UMTS Only)

The Data Integrity procedure is performed between the MS and the UTRAN. It is applicable only to radio signalling. The UMTS integrity check is made with the UMTS Integrity Algorithm (UIA). The UMTS Integrity Key (IK) is an input to the algorithm. The start of the data integrity procedure is controlled by the security mode procedure.
3.8 Location Management Function

The Location Management function: provides mechanisms for cell and PLMN selection; provides a mechanism for the network to know the Routeing Area for MSs in STANDBY, PMM-IDLE, READY, and PMM-CONNECTED states; provides a mechanism for the 2G-SGSN to know the cell identity for MSs in READY state; provides a mechanism for the UTRAN to know the URA identity or cell identity for MSs in PMM-CONNECTED state; provides a mechanism for the UTRAN to indicate to an MS in RRC Connected mode when a Routeing Area Update procedure shall be performed by providing the RAI; and
provides a mechanism for the network to know the address of the serving RNC handling an MS in PMM-CONNECTED state. This mechanism is the serving RNC relocation procedure. The SGSN may not know the Routeing Area where the UMTS MS is physically located for an MS is in RRC Connected mode. An MS in PMM-CONNECTED state is necessarily in RRC Connected mode. An MS in PMM-IDLE state is in RRC Connected mode only if the MS is in CS MM-CONNECTED state. In UMTS, the tracking of the location of the MS is on three levels (cell, URA, or RA), see 3G TS 23.121. In GSM, the tracking of the location of the MS is on two levels (cell or RA). In GSM: Cell update Routeing area update In UMTS: Routeing area update SRNC relocation
3.8.1 Location Management Procedures (GSM Only)

The MS detects that a new cell has been entered by comparing the cell's identity with the cell identity stored in the MS's MM context. The MS detects that a new RA has been entered by periodically comparing the RAI stored in its MM context with that received from the new cell. The MS shall consider hysteresis in signal strength measurements. When the MS camps on a new cell, possibly in a new RA, this indicates one of three possible scenarios: a cell update is required; a routeing area update is required; or a combined routeing area and location area update is required. In all three scenarios the MS stores the cell identity in its MM context. If the MS enters a new PLMN, the MS shall either perform a routeing area update, or enter IDLE state. In network mode of operation II and III, whenever an MS determines that it shall perform both an LA update and an RA update, the MS shall perform the LA update first.
I. Cell update procedure

A cell update takes place when the MS enters a new cell inside the current RA and the MS is in READY state. If the RA has changed, a routeing area update is executed instead of a cell update. If the network and the MS support the Cell Notification then
the MS shall use the LLC NULL frame, containing the MS's identity, in order to perform a cell update. The support of Cell Notification is mandatory for MS and network but the network as well as the MS has to support the Cell Update Procedure, not using the LLC NULL frame, for backward compatibility reasons.
II. Routeing area update procedure

A routeing area update takes place when a GPRS-attached MS detects that it has entered a new RA, when the periodic RA update timer has expired, or, for GSM, when a suspended MS is not resumed by the BSS. If the new RA belongs to an SGSN different from the SGSN for the old RA, the RA update is an inter SGSN routeing area update. Otherwise, the RA update is an intra SGSN routeing area update. A periodic RA update is always an intra SGSN routeing area update.
III. Intra SGSN routeing area update

In an Intra SGSN Routeing Area Update procedure, the GGSN and the HLR are not included. The Intra SGSN Routeing Area Update procedure is illustrated in Figure 3-12.
MS BSS SGSN
1. Routeing Area Update Request 2. Security Functions 3. Routeing Area Update Accept C1 4. Routeing Area Update Complete
Figure 3-12 Intra SGSN routeing area update procedure
Each step is explained in the following list: 1) The MS sends a Routeing Area Update Request (P-TMSI, old RAI, old P-TMSI Signature, Update Type) to the SGSN. Update Type shall indicate RA update or periodic RA update. The BSS shall add the Cell Global Identity including the RAC and LAC of the cell where the message was received before passing the message to the SGSN. 2) 3) Security functions may be executed. If all checks are successful then the SGSN updates the MM context for the MS. A new P-TMSI may be allocated. A Routeing Area Update Accept (P-TMSI, P-TMSI Signature) is returned to the MS. 4) If P-TMSI was reallocated, the MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete message to the SGSN. If the routeing area
update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing Area Update Reject (Cause) message, the MS shall enter IDLE state. C1) CAMEL-GPRS-Routeing-Area-Update and CAMEL-Update-PDP-Context. This procedure is performed every time when a PDP context is updated and shall be performed for many times.
IV. Inter SGSN routeing area update

The Inter SGSN Routeing Area Update procedure is illustrated in Figure 3-13.
MS BSS new SGSN old SGSN GGSN HLR
1. Routeing Area Update Request 2. SGSN Context Request 2. SGSN Context Response C1 3. Security Functions 4. SGSN Context Acknowledge C2 5. Forward Packets 6. Update PDP Context Request 6. Update PDP Context Response 7. Update Location 8. Cancel Location 8. Cancel Location Ack 9. Insert Subscriber Data 9. Insert Subscriber Data Ack 10. Update Location Ack C3 11. Routeing Area Update Accept C4 12. Routeing Area Update Complete
Figure 3-13 Inter SGSN routeing area update procedure
Each step is explained in the following list: 1) 2) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type) to the new SGSN. The new SGSN sends SGSN Context Request (old RAI, TLLI, old P-TMSI Signature, New SGSN Address) to the old SGSN to get the MM and PDP contexts for the MS. The old SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message to the old SGSN. The second SGSN Context Request message includes "MS Validated" instead of "old P-TMSI Signature". If the old P-TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN stops assigning SNDCP N-PDU numbers to downlink N-PDUs received, and responds with SGSN Context Response (MM Context, PDP Contexts). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN stores New SGSN Address, to allow the old SGSN to forward data packets to the new SGSN after it receives an SGSN Context Acknowledge message from the new SGSN. Each PDP Context includes the SNDCP Send N-PDU Number for the next downlink N-PDU to be sent in acknowledged mode to the MS, the SNDCP Receive N-PDU Number for the next uplink N-PDU to be received in acknowledged mode from the MS, the GTP sequence number for the next downlink N-PDU to be sent to the MS and the GTP sequence number for the next uplink N-PDU to be tunnelled to the GGSN. The old SGSN starts a timer and stops the transmission of N-PDUs to the MS. The data to be transmitted includes the N-PDUs buffered in the old SGSN and the N-PDUs received from the GGSN before the timer expires. N-PDUs that were already sent to the MS in acknowledged mode and that are not yet acknowledged by the MS are tunnelled together with the SNDCP N-PDU number. 3) 4) Security functions may be executed. The new SGSN sends an SGSN Context Acknowledge message to the old SGSN. This informs the old SGSN that the new SGSN is ready to receive data packets belonging to the activated PDP contexts. 5) 6) 7) The old SGSN duplicates the buffered N-PDUs and starts tunnelling them to the new SGSN. The new SGSN sends Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated) to the GGSNs concerned. The new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI) to the HLR. If the SGSN is unable to update the PDP context in one or more GGSNs, then the SGSN shall
deactivate the corresponding PDP contexts. This shall not cause the SGSN to reject the routeing area update. 8) 9) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN. The HLR sends Insert Subscriber Data (IMSI, GPRS Subscription Data) to the new SGSN. The new SGSN returnes an Insert Subscriber Data Ack message to the SGSN. 10) A new P-TMSI may be allocated. The SGSN responds to the MS with a Routeing Area Update Accept (P-TMSI, P-TMSI Signature). 11) If P-TMSI was reallocated, the MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete message to the SGSN. If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing Area Update Reject (Cause) message, the MS shall enter IDLE state. Compared with the intra SGSN routeing area update procedure, the inter SGSN routeing area update procedure includes two more processes, i.e., the process of context request of the new SGSN from the old SGSN and the process of location update between the HLR and the two SGSNs. For an MS with GPRS-CSI defined, CAMEL interaction may be performed: C1) CAMEL-Disconnect-PDP-Context. This procedure is performed every time when a PDP context is updated and shall be performed for many times. C2) CAMEL-GPRS-Detach C3) CAMEL-GPRS-Routeing-Area-Update C4) CAMEL-Update-PDP-Context. This procedure is performed every time when a PDP context is updated and shall be performed for many times.
V. Combined RA/LA Update Procedure

A combined RA/LA update procedure involves the MSC/VLR. A combined RA/LA update procedure takes place in network operation mode I: when the MS enters a new RA; when a GPRS-attached MS performs IMSI attach; or when the MS actually enters a new LA. The Combined RA/LA Update (intra SGSN) procedure is illustrated in Figure 3-14.
MS
BSS
SGSN
new MSC/VLR
HLR
old MSC/VLR
1. Routeing Area Update Request 2. Security Functions 3. Location Update Request 4a. Update Location 4b. Cancel Location 4c. Cancel Location Ack 4d. Insert Subscriber Data 4e. Insert Subscriber Data Ack 4f. Update Location Ack 5. Location Update Accept 6. Routeing Area Update Accept C1 7. Routeing Area Update Complete 8. TMSI Reallocation Complete
Figure 3-14 Combined RA/LA update in the case of intra SGSN RA update procedure
Each step is explained in the following list: 1) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type) to the SGSN. Update Type shall indicate combined RA/LA update, or, if the MS wants to perform an IMSI attach, combined RA/LA update with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC and LAC of the cell where the message was received before passing the message to the SGSN. 2) 3) Security functions may be executed. When the MS enters a new RA, when a GPRS-attached MS performs IMSI attach, or when the MS actually enters a new LA, the SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. 4) The new VLR sends an Update Location (new VLR) to the HLR. The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR and sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR.
5)
The new VLR allocates a new VLR TMSI and responds with Location Update Accept (VLR TMSI) to the SGSN. VLR TMSI is optional if the VLR has not changed.
6) 7)
The SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI Signature). If a new P-TMSI or VLR TMSI was received, then the MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete message to the SGSN.
8)
The SGSN sends a TMSI Reallocation Complete message to the VLR if the VLR TMSI is confirmed by the MS.
If the routeing area update procedure fails a maximum allowable number of times, or if the SGSN returns a Routeing Area Update Reject (Cause) message, the MS shall enter IDLE state. If the Location Update Accept message indicates a reject, then this should be indicated to the MS, and the MS shall not access non-GPRS services until a successful Location Update is performed. For an MS with GPRS-CSI defined, CAMEL interaction may be performed: C1) CAMEL-GPRS-Routeing-Area-Update. The Combiend RA/LA Update (inter SGSN) procedure is illustrated in Figure 3-15. Compared with the combined RA/LA update (intra SGSN) procedure, the combined RA/LA update (inter SGSN) procedure includes two more processes, i.e., the process of context request of the new SGSN from the old SGSN and the process of location update between the HLR and the two SGSNs.

new MSC/VLR old MSC/VLR
MS
BSS
new SGSN
old SGSN
GGSN
HLR
1. Routeing Area Update Request 2. SGSN Context Request 2. SGSN Context Response C1 3. Security Functions 4. SGSN Context Acknowledge C2 5. Forward Packets 6. Update PDP Context Request 6. Update PDP Context Response 7. Update Location 8. Cancel Location 8. Cancel Location Ack 9. Insert Subscriber Data 9. Insert Subscriber Data Ack 10. Update Location Ack 11. Location Update Request 12a. Update Location 12b. Cancel Location 12c. Cancel Location Ack 12d. Insert Subscriber Data 12e. Insert Subscriber Data Ack 12f. Update Location Ack 13. Location Update Accept C3 14. Routeing Area Update Accept C4 15. Routeing Area Update Complete 16. TMSI Reallocation Complete
Figure 3-15 Combined RA/LA update in the case of inter SGSN RA update procedure
Whether in the intra SGSN routeing area update procedure, in the inter SGSN routeing area update procedure or in the combined RA/LA update procedure, a new P-TMSI may be allocated by the SGSN.
3.8.2 Location Management Procedures (UMTS Only)

I. Routeing area update procedure
The UMTS RA Update procedure is illustrated in Figure 3-16.

new MSC/VLR old MSC/VLR
MS
UTRAN
new 3G-SGSN
old 3G-SGSN
GGSN
HLR
1. Routeing Area Update Request
2. SGSN Context Request C1
2a. SRNS Context Request 2a. SRNS Context Response
2. SGSN Context Response 3. Security Functions 4. SGSN Context Ack C2 5. Update PDP Context Request 5. Update PDP Context Response 6. Update Location 7a. Iu Release Command 7a. Iu Release Complete 7. Cancel Location Ack 8. Insert Subscriber Data 8. Insert Subscriber Data Ack 9. Update Location Ack 10. Location Update Request 11a. Update Location 11b. Cancel Location 11c. Cancel Location Ack 11d. Insert Subscriber Data 11e. Insert Subscriber Data Ack 11f. Update Location Ack 12. Location Update Accept C2 13. Routeing Area Update Accept C3 14. Routeing Area Update Complete 15. TMSI Reallocation Complete 7. Cancel Location
Figure 3-16 UMTS RA update procedure

Each step is explained in the following list: 1) The RRC connection is established, if not already done. The MS sends a Routeing Area Update Request message (P-TMSI, old RAI, old P-TMSI Signature, Update Type, follow on request, Classmark, DRX parameters) to the new SGSN. Follow on request shall be set by MS if there is pending uplink traffic (signalling or user data). The SGSN may use, as an implementation option, the follow on request indication to release or keep the Iu connection after the completion of the RA update procedure. Update Type shall indicate: RA Update if the RA Update is triggered by a change of RA; Periodic RA Update if the RA update is triggered by the expiry of the Periodic RA Update timer; Combined RA/LA Update if the MS is also IMSI-attached and the LA update shall be performed in network operation mode I; or Combined RA/LA Update with IMSI attach requested if the MS wants to perform an IMSI attach in network operation mode I. The SRNC shall add the Routeing Area Identity including the RAC and LAC of the area where the MS is located before forwarding the message to the 3G-SGSN. This RA identity corresponds to the RAI in the MM system information sent by the SRNC to the MS. ClassMark is described in Section 3.12 Classmark Handling. DRX Parameters indicate whether the MS uses discontinuous reception or not. If the MS uses discontinuous reception, then DRX Parameters also indicate when the MS is in a non-sleep mode able to receive paging requests. 2) If the RA update is an Inter-SGSN Routeing Area update and if the MS was in PMM-IDLE state, the new SGSN sends SGSN Context Request message (old P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN to get the MM and PDP contexts for the MS. The old SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the security functions in the new SGSN. If the security functions authenticate the MS correctly, the new SGSN shall send an SGSN Context Request (IMSI, old RAI, MS Validated) message to the old SGSN. MS Validated indicates that the new SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if the new SGSN indicates that it has authenticated the MS, the old SGSN responds with SGSN Context Response (Cause, IMSI, MM Context, PDP contexts). If the MS is not known in the old SGSN, the old SGSN responds with an appropriate error cause. The old SGSN starts a timer. 3) Security functions may be executed. If the security functions do not authenticate the MS correctly, then the routeing area update shall be rejected, and the new SGSN shall send a reject indication to the old SGSN. The old SGSN shall continue as if the SGSN Context Request was never received. 4) If the RA update is an Inter-SGSN Routeing Area update, the new SGSN sends an SGSN Context Acknowledge message to the old SGSN. The old SGSN
marks in its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a routeing area update procedure back to the old SGSN before completing the ongoing routeing area update procedure. 5) If the RA update is an Inter-SGSN RA Update and if the MS was in PMM-IDLE state, the new SGSN sends Update PDP Context Request (new SGSN Address, QoS Negotiated, Tunnel Endpoint Identifier) to the GGSNs concerned. The GGSNs update their PDP context fields and return an Update PDP Context Response (Tunnel Endpoint Identifier). If the RA update is an Inter-SGSN routeing area update initiated by an MS in PMM-CONNECTED state, then the Update PDP Context Request message is sent as described in Section II. Serving RNS relocation procedures. 6) If the RA update is an Inter-SGSN RA Update, the new SGSN informs the HLR of the change of SGSN by sending Update Location (SGSN Number, SGSN Address, IMSI) to the HLR. 7) If the RA update is an Inter-SGSN RA Update, the HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN with Cancellation Type set to Update Procedure. If the timer described in step 2) is not running, then the old SGSN removes the MM context. Otherwise, the contexts are removed only when the timer expires. It also ensures that the MM context is kept in the old SGSN in case the MS initiates another inter SGSN routeing area update before completing the ongoing routeing area update to the new SGSN. The old SGSN acknowledges with Cancel Location Ack (IMSI). 8) If the RA update is an Inter-SGSN RA Update, the HLR sends Insert Subscriber Data (IMSI, subscription data) to the new SGSN. The new SGSN validates the MS's presence in the (new) RA. If due to regional subscription restrictions the MS is not allowed to be attached in the RA, the SGSN rejects the Routeing Area Update Request with an appropriate cause, and may return an Insert Subscriber Data Ack (IMSI, SGSN Area Restricted) message to the HLR. If all checks are successful then the SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 9) If the RA update is an Inter-SGSN RA Update, the HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new SGSN after the old MM context is removed and the new MM is inserted. 10) If Update Type indicates combined RA/LA update with IMSI attach requested, or if the LA changed with the routeing area update, then the association has to be established, and the new SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI attach if Update Type in step 1) indicated combined RA/LA update with ISI attach requested. Otherwise, Location Update Type shall indicate normal location update. The VLR number is translated from the RAI via a table in the SGSN. The SGSN starts the location update procedure towards the
new MSC/VLR upon receipt of the first Insert Subscriber Data message from the HLR in step 8). The VLR creates or updates the association with the SGSN by storing SGSN Number. 11) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The HLR cancels the old VLR and inserts subscriber data in the new VLR (this signalling is not modified from existing GSM signalling and is included here for illustrative purposes): a) The new VLR sends an Update Location (new VLR) to the HLR. b) The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. c) The old VLR acknowledges with Cancel Location Ack (IMSI). d) The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR. e) The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). f) The HLR responds with Update Location Ack (IMSI) to the new VLR. 12) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the SGSN. VLR TMSI is optional if the VLR has not changed. 13) The new SGSN validates the MS's presence in the new RA. If due to roaming restrictions the MS is not allowed to be attached in the SGSN, or if subscription checking fails, then the SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then the new SGSN establishes MM context for the MS. The new SGSN responds to the MS with Routeing Area Update Accept (P-TMSI, VLR TMSI, P-TMSI Signature). 14) The MS confirms the reallocation of the TMSIs by returning a Routeing Area Update Complete message to the SGSN. 15) The new SGSN sends a TMSI Reallocation Complete message to the new VLR if the VLR TMSI is confirmed by the MS. For an MS with GPRS-CSI defined, CAMEL interaction may be performed: C1) CAMEL-GPRS-Detach. C2) CAMEL-GPRS-Routeing-Area-Update-Session. C3) CAMEL-GPRS-Routeing-Area-Update-Context. This procedure is performed every time when a PDP context is updated and shall be performed for many times. Note: Steps 11), 12), and 15), are performed only if step 9) is performed.
II. Serving RNS relocation procedures

Soft handover The Inter SGSN Soft Handover procedure is illustrated in Figure 3-17.
MS Source RNC 1. Decision to perform SRNS relocation 2. Relocation Required 3. Forward Relocation Request 4. Relocation Request Establishment of Radio Access Bearers 4. Relocation Request Acknowledge 5. Forward Relocation Response C1 6. Relocation Command 7. Relocation Commit 8. Forwarding of data 9. Relocation Detect 10. RNTI Reallocation 12. RNTI Reallocation Complete 13. Relocation Complete 13. Forward Relocation Complete 13. Forward Relocation Complete Acknowledge 14. Iu Release Command 14. Iu Release Complete C2 11. Update PDP Context Request 11. Update PDP Context Response Target RNC Old SGSN New SGSN GGSN
15. Routing Area Update
C3
Figure 3-17 Inter SGSN soft handover procedure
Each step is illustrated in the following list: 1) 2) The source SRNC decides to perform/initiate an SRNS relocation. The source SRNC initiates the relocation preparation procedure by sending a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC to target RNC transparent container) to the old SGSN. The source SRNC shall set the Relocation Type to "UE not involved". The Source RNC to
target RNC transparent container includes the necessary information for Relocation, security functionality and RRC protocol context information (including UE Capabilities). 3) The old SGSN determines from the Target ID if the SRNS Relocation is intra SGSN SRNS relocation or inter SGSN SRNS relocation. In case of inter SGSN relocation the old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request message (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context, Target Identification, UTRAN transparent container, RANAP Cause) to the new SGSN. At the same time a timer is started on the MM and PDP contexts in the old SGSN. The Forward Relocation Request message is applicable only in case of inter SGSN SRNS relocation. 4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain Indicator, Source RNC to target RNC transparent container, RABs to be setup) to the target RNC. For each RAB requested to be established, the RABs to be setup information elements shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the Iu Transport Association corresponds to Tunnel Endpoint Identifier Data. After all necessary resources for accepted RABs including the Iu user plane are successfully allocated, the target RNC shall send the Relocation Request Acknowledge message (RABs setup, RABs failed to setup) to the new SGSN. 5) When resources for the transmission of user data between target RNC and new SGSN have been allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response message (Cause, RANAP Cause, and RAB Setup Information) is sent from new SGSN to old SGSN. This message indicates that the target RNC is ready to receive from source SRNC the downstream packets not yet acknowledged by the MS, i.e. the relocation resource allocation procedure is terminated successfully. RANAP Cause is information from the target RNC to be forwarded to the source RNC. The RAB Setup Information, one information element for each RAB, contains the RNC Tunnel Endpoint Identifier and RNC IP address for data forwarding from source SRNC to target RNC. If the target RNC or the new SGSN failed to allocate resources the RAB Setup Information element contains only NSAPI indicating that the source RNC shall release the resources associated with the NSAPI. The Forward Relocation Response message is applicable only in case of inter SGSN SRNS relocation. 6) The old SGSN continues the relocation of SRNS by sending a Relocation Command message (RABs to be released, and RABs subject to data forwarding) to the source SRNC. The old SGSN decides the RABs to be subject to data forwarding based on QoS, and those RABs shall be contained in RABs subject to
data forwarding. For each RAB subject to data forwarding, the information element shall contain RAB ID, Transport Layer Address, and Iu Transport Association. The Transport Layer Address and Iu Transport Association are used for forwarding of DL N-PDU from source RNC to target RNC. 7) Upon reception of the Relocation Command message from the PS domain, the source RNC shall start the data-forwarding timer. When the relocation preparation procedure is terminated successfully and when the source SRNC is ready, the source SRNC shall trigger the execution of relocation of SRNS by sending a Relocation Commit message (SRNS Contexts) to the target RNC. The purpose of this procedure is to transfer SRNS contexts from the source RNC to the target RNC. 8) After having sent the Relocation Commit message, source SRNC begins the forwarding of data for the RABs to be subject for data forwarding. The data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the data exchanged between source SRNC and target RNC are duplicated in the source SRNC and routed at IP layer towards the target RNC. 9) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger is received. For SRNS relocation type "UE not involved", the relocation execution trigger is the reception of the Relocation Commit message from the Iur interface. When the Relocation Detect message is sent, the target RNC shall start SRNC operation. 10) After having sent the Relocation Detect message, target SRNC responds to the MS by sending a RNTI Reallocation message. Both messages contain UE information elements and CN information elements. The UE information elements include among others new SRNC identity. The CN information elements contain among others Location Area Identification and Routeing Area Identification. 11) Upon reception of the Relocation Detect message, the CN may switch the user plane from source RNC to target SRNC. If the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated) to the GGSNs concerned. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier). 12) When the MS has reconfigured itself, it sends the RNTI Reallocation Complete message to the target SRNC. From now on the exchange of packets with the MS can start. 13) When the target SRNC receives the RNTI Reallocation Complete message, the target SRNC shall initiate the Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. If the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN shall signal to the old SGSN the completion of the SRNS relocation procedure by sending a Forward Relocation
Complete message. Upon reception of the message, the old SGSN returns a response to the new SGSN. 14) After having received the Forward Relocation Complete message from the new SGSN and returned a response to the new SGSN, the old SGSN sends an Iu Release Command message to the source RNC. When the RNC data-forwarding timer has expired the source RNC responds with an Iu Release CMP message. 15) If the new Routeing Area Identification is different from the old one, the MS initiates the Routeing Area Update procedure. The relocation procedure is only a subset of the RA update procedure. For an MS with GPRS-CSI defined, CAMEL interaction may be performed: C1) CAMEL-GPRS-Deactivate-PDP-Context and
CAMEL-GPRS-Detach-PDP-Context. C2) CAMEL-GPRS-Routeing-Area-Update. Hard handover The Inter SGSN Hard Handover procedure is illustrated in Figure 3-18.

MS Source RNC Target RNC Old SGSN

New SGSN GGSN
1. Decision to perform SRNS Relocation MS Involved 2. Relocation Required 3. Forward Relocation Request 4. Relocation Request Establishment of Radio Access Bearers 4. Relocation Request Acknowledge 5. Forward Relocation Response C1 6. Relocation Command 7. Physical Channel Reconfiguration 8. Forward SRNS Context 8. Forward SRNS Context 8. Forward SRNS Context Acknowledge 8. Forward SRNS Context 9. Forwarding of data
MS detected by target RNC 10. Relocation Detect 11. Update PDP Context Request 12. Physical Channel Reconfiguration Complete 11. Update PDP Context Response 13. Relocation Complete 13. Forward Relocation Complete 13. Forward Relocation Complete Acknowledge 14. Iu Release Command 14. Iu Release Complete
C2 C3
Figure 3-18 Inter SGSN hard handover procedure
1)
Based on measurement results and knowledge of the UTRAN topology, the source SRNC decides to initiate a combined hard handover and SRNS relocation.
2)
The source SRNC initiates the relocation preparation procedure by sending a Relocation Required (Relocation Type, Cause, Source ID, Target ID, Source RNC to target RNC transparent container) message to the old SGSN. The source SRNC shall set Relocation Type to "UE Involved". Source RNC to target RNC transparent container includes the necessary information for relocation, security functionality and RRC protocol context information (including UE Capabilities).
3)
The old SGSN determines from the Target ID if the SRNS relocation is intra SGSN SRNS relocation or inter SGSN SRNS relocation. In case of inter SGSN SRNS relocation the old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context, Target Identification, UTRAN Transparent Container, RANAP Cause) message to the new SGSN. At the same time a timer is started on the MM and PDP contexts in the old SGSN. The Forward Relocation Request message is applicable only in case of inter SGSN SRNS relocation.
4)
The new SGSN sends a Relocation Request (Permanent NAS UE Identity, Cause, CN Domain Indicator, Source RNC to target RNC transparent container, RABs to be setup) message to the target RNC. For each RAB requested to be established, RABs to be setup shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the Iu Transport Association corresponds to Tunnel Endpoint Identifier Data. After all the necessary resources for accepted RABs including the Iu user plane are successfully allocated, the target RNC shall send the Relocation Request Acknowledge (RABs setup, RABs failed to setup) message to the new SGSN. The target RNC will for each RAB to be setup (defined by an IP Address and a Tunnel Endpoint Identifier) receive both forwarded downstream PDUs from the source SRNC as well as downstream PDUs from the new SGSN.
5)
When resources for the transmission of user data between target RNC and new SGSN have been allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response (Cause, RANAP Cause, RAB Setup Information) message is sent from the new SGSN to the old SGSN. This message indicates that the target RNC is ready to receive from source SRNC the downstream packets not yet acknowledged by the MS, i.e., the relocation resource allocation procedure is terminated successfully. RANAP Cause is information from the target RNC to be forwarded to the source RNC. RAB Setup
Information contains the RNC Tunnel Endpoint Identifier and RNC IP address for data forwarding from source SRNC to target RNC. If the target RNC or the new SGSN failed to allocate resources the RAB Setup Information element contains only NSAPI indicating that the source RNC shall release the resources associated with the NSAPI. The Forward Relocation Response message is applicable only in case of inter-SGSN SRNS relocation. 6) The old SGSN continues the relocation of SRNS by sending a Relocation Command (RABs to be released, RABs subject to data forwarding) message to the source SRNC. The old SGSN decides the RABs to be subject for data forwarding based on QoS, and those RABs shall be contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the information element shall contain RAB ID, Transport Layer Address, and Iu Transport Association. Transport Layer Address and Iu Transport Association are used for forwarding of DL N-PDU from source RNC to target RNC. 7) Upon reception of the Relocation Command message from the PS domain, the source RNC shall start the data-forwarding timer. The source SRNC triggers the execution of relocation of SRNS by sending to the MS a Physical Channel Reconfiguration (UE Information Elements, CN Information Elements) message. 8) The source SRNC continues the execution of relocation of SRNS by sending a Forward SRNS Context (RAB Contexts) message to the target RNC via the old and the new SGSNs, which is acknowledged by a Forward SRNS Context Acknowledge message. 9) After having sent the Forward SRNS Context message, source SRNC begins the forwarding of data for the RABs to be subject for data forwarding. The data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the data exchanged between source SRNC and target RNC are duplicated in the source SRNC and routed at IP layer towards the target RNC. 10) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger is received. For SRNS relocation type "UE Involved", the relocation execution trigger may be received from the Uu interface. When the Relocation Detect message is sent, the target RNC shall start SRNC operation. 11) Upon reception of the Relocation Detect message, the CN may switch the user plane from source RNC to target SRNC. If the SRNS relocation is an inter SGSN SRNS relocation, the new SGSN sends Update PDP Context Request (New SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated) message to the GGSNs concerned. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier) message. 12) When the MS has reconfigured itself, it sends an RNTI Reallocation Complete message to the target SRNC. From now on the exchange of packets with the MS can start.
13) When the target SRNC receives the RNTI Reallocation Complete message, the target SRNC shall initiate Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. If the SRNS Relocation is an inter SGSN SRNS relocation, then the new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward Relocation Complete message. Upon reception of the message, the old SGSN returns a response to the new SGSN. 14) After having received the Forward Relocation Complete message from the new SGSN and returned a response to the new SGSN, the old SGSN sends an Iu Release CMD message to the source RNC. When the RNC data-forwarding timer has expired the source RNC responds with an Iu Release CMP message. 15) If the new Routeing Area Identification is different from the old one, the MS initiates the Routeing Area Update procedure. The relocation procedure is only a subset of the RA update procedure. For an MS with GPRS-CSI defined, CAMEL interaction may be performed: C1) CAMEL-GPRS-Deactivate-PDP-Context and
CAMEL-GPRS-Detach-PDP-Context. C2) CAMEL-GPRS-Routeing-Area-Update Combined cell/URA update and SRNS relocation procedure

MS Source RNC Target RNC Old SGSN

New SGSN GGSN
1. Decision to perform SRNS Relocation MS Involved 2. Relocation Required 3. Forward Relocation Request 4. Relocation Request Establishment of Radio Access Bearers 4. Relocation Request Acknowledge 5. Forward Relocation Response C1 6. Relocation Command 7. Physical Channel Reconfiguration 8. Forward SRNS Context 8. Forward SRNS Context 8. Forward SRNS Context Acknowledge 8. Forward SRNS Context 9. Forwarding of data
MS detected by target RNC 10. Relocation Detect 11. Update PDP Context Request 12. Physical Channel Reconfiguration Complete 11. Update PDP Context Response 13. Relocation Complete 13. Forward Relocation Complete 13. Forward Relocation Complete Acknowledge 14. Iu Release Command 14. Iu Release Complete
C2 C3
Figure 3-19 Combined cell/URA update and SRNS relocation procedure
Each step is explained in the following list: 1) The MS sends a Cell Update/URA Update message to the UTRAN, after having made cell re-selection. Upon reception of the message, the source SRNC
decides to perform a combined cell/URA update and SRNS relocation towards the target RNC. 2) The source SRNC initiates the relocation preparation procedure by sending a Relocation Required message (Relocation Type, Cause, Source ID, Target ID, Source RNC to target RNC transparent container) to the old SGSN. The source SRNC shall set Relocation Type to "UE not involved". Source RNC to target RNC transparent container includes the necessary information for Relocation, security functionality, and RRC protocol context information (including UE Capabilities). 3) The old SGSN determines from the Target ID if the SRNS Relocation is intra SGSN SRNS relocation or inter SGSN SRNS relocation. In case of inter SGSN SRNS relocation the old SGSN initiates the relocation resource allocation procedure by sending a Forward Relocation Request (IMSI, Tunnel Endpoint Identifier Signalling, MM Context, PDP Context, Target Identification, UTRAN transparent container, RANAP Cause) message to the new SGSN. At the same time a timer is started on the MM and PDP contexts in the old SGSN. The Forward Relocation Request message is applicable only in case of inter SGSN SRNS relocation. 4) The new SGSN sends a Relocation Request message (Permanent NAS UE Identity, Cause, CN Domain Indicator, Source RNC to target RNC transparent container, RABs to be setup) to the target RNC. For each RAB requested to be established, RABs to be setup shall contain information such as RAB ID, RAB parameters, Transport Layer Address, and Iu Transport Association. The RAB ID information element contains the NSAPI value, and the RAB parameters information element gives the QoS profile. The Transport Layer Address is the SGSN Address for user data, and the Iu Transport Association corresponds to Tunnel Endpoint Identifier Data. After all necessary resources for accepted RABs including the Iu user plane are successfully allocated, the target RNC shall send the Relocation Request Acknowledge (RABs setup, RABs failed to setup) message to the new SGSN. The target RNC will for each RAB to be setup (defined by an IP Address and a Tunnel Endpoint Identifier) receive both forwarded downstream PDUs from the source SRNC as well as downstream PDUs from the new SGSN. 5) When resources for the transmission of user data between target RNC and new SGSN have been allocated and the new SGSN is ready for relocation of SRNS, the Forward Relocation Response message (Cause, RANAP Cause, and RAB Setup Information) is sent from new SGSN to old SGSN. This message indicates that the target RNC is ready to receive from source SRNC the downstream packets not yet acknowledged by MS, i.e., the relocation resource allocation procedure is terminated successfully. RANAP Cause is information from the target RNC to be forwarded to the source RNC. The RAB Setup Information contains the RNC Tunnel Endpoint Identifier and RNC IP address for data forwarding from source SRNC to target RNC. If the target RNC or the new SGSN
failed to allocate resources the RAB Setup Information element contains only NSAPI indicating that the source RNC shall release the resources associated with the NSAPI. The Forward Relocation Response message is applicable only in case of inter SGSN SRNS relocation. 6) The old SGSN continues the relocation of SRNS by sending a Relocation Command (RABs to be released, and RABs subject to data forwarding) message to the source SRNC. The old SGSN decides the RABs subject to data forwarding based on QoS, and those RABs shall be contained in RABs subject to data forwarding. For each RAB subject to data forwarding, the information element shall contain RAB ID, Transport Layer Address, and Iu Transport Association. The Transport Layer Address and Iu Transport Association are used for forwarding of DL N-PDU from source RNC to target RNC. 7) Upon reception of the Relocation Command message from the PS domain, the source RNC shall start the data-forwarding timer. When the relocation preparation procedure is terminated successfully and when the source SRNC is ready, the source SRNC shall trigger the execution of relocation of SRNS by sending a Relocation Commit (SRNS Contexts) message to the target RNC. The purpose of this procedure is to transfer SRNS contexts from the source RNC to the target RNC. 8) After having sent the Relocation Commit message, source SRNC begins the forwarding of data for the RABs subject to data forwarding. The data forwarding at SRNS relocation shall be carried out through the Iu interface, meaning that the data exchanged between source SRNC and target RNC are duplicated in the source SRNC and routed at IP layer towards the target RNC. 9) The target RNC shall send a Relocation Detect message to the new SGSN when the relocation execution trigger is received. For SRNS relocation type "UE not involved", the relocation execution trigger is the reception of the Relocation Commit message from the Iur interface. When the Relocation Detect message is sent, the target RNC shall start SRNC operation. 10) After having sent the Relocation Detect message, target SRNC responds to the MS by sending a Cell Update Confirm/URA Update Confirm message. Both messages contain UE information elements and CN information elements. The UE information elements include among others new SRNC identity and S-RNTI. The CN information elements contain among others Location Area Identification and Routeing Area Identification. 11) Upon reception of the Relocation Detect message, the CN may switch the user plane from source RNC to target SRNC. If the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN sends Update PDP Context Request messages (new SGSN Address, SGSN Tunnel Endpoint Identifier, QoS Negotiated) to the GGSNs concerned. The GGSNs update their PDP context fields and return an Update PDP Context Response (GGSN Tunnel Endpoint Identifier) message.
12) When the MS has reconfigured itself, it sends the RNTI Reallocation Complete message to the target SRNC. From now on the exchange of packets with the MS can start. 13) When the target SRNC receives the RNTI Reallocation Complete message, i.e. the new SRNC-ID+S-RNTI are successfully exchanged with the UE by the radio protocols, the target SRNC shall initiate the Relocation Complete procedure by sending the Relocation Complete message to the new SGSN. If the SRNS Relocation is an inter SGSN SRNS relocation, the new SGSN signals to the old SGSN the completion of the SRNS relocation procedure by sending a Forward Relocation Complete message. Upon reception of the message, the old SGSN returns a response to the new SGSN. 14) The old SGSN sends an Iu Release Command message to the source RNC. When the RNC data-forwarding timer has expired the source RNC responds with an Iu Release Complete. 15) After the MS has finished the Cell/URA update and RNTI reallocation procedure and if the new Routeing Area Identification is different from the old one, the MS initiates the Routeing Area Update procedure. The Relocation procedure is only a subset of the RA update procedure that is performed, since the MS is in PMM-CONNECTED state. For an MS with GPRS-CSI defined, CAMEL interaction may be performed: C1) CAMEL-GPRS-Deactivate-PDP-Context and
CAMEL-GPRS-Detach-PDP-Context. C2) CAMEL-GPRS-Routeing-Area-Update.
3.8.3 Periodic RA/LA Update

All GPRS-attached MSs, except GSM MSs in class-B mode of operation engaged in CS communication, shall perform periodic RA updates. MSs that are IMSI-attached and not GPRS-attached shall perform periodic LA updates. Periodic RA updates are equivalent to intra SGSN routeing area updates, with Update Type indicating periodic RA update. For MSs that are both IMSI-attached and GPRS-attached, the periodic updates depend on the mode of operation of the network: If the network operates in mode I, periodic RA updates shall be performed, and periodic LA updates shall not be performed. In this case, the MSC/VLR shall disable implicit detach for GPRS-attached MSs and instead rely on the SGSN to receive periodic RA updates. If periodic RA updates are not received in the SGSN and the SGSN detaches the MS, the SGSN shall notify the MSC/VLR by sending an IMSI Detach Indication message. If the network operates in mode II or mode III, both periodic RA updates and periodic LA updates shall be performed independently. RA updates are
performed towards the SGSN, and LA updates are performed towards the MSC/VLR. In the mode involving A/Gb interface, the periodic RA update timer in the MS is stopped when the MM context state enters to READY. The periodic RA update timer is reset and started when the state returns to STANDBY. In the mode involving Iu interfce, the periodic RA update timer in the MS is stopped when the MM context state enters to the PMM-CONNECTED state. The periodic RA update timer is reset and started when the state returns to the PMM-IDLE state.
3.9 Subscriber Management Function

The Subscriber Management function provides a mechanism to inform the nodes about changes of the PS subscription data for a specific PS subscriber.
3.9.1 Subscriber Management Procedures

The HLR performs management over the subscriber data stored in the SGSN by means of the following procedures: Insert Subscriber Data procedure
SGSN 1. Insert Subscriber Data 2. Insert Subscriber Data Ack HLR
Figure 3-20 Insert subscriber data procedure Delete Subscriber Data procedure
SGSN 1. Delete Subscriber Data 2. Delete Subscriber Data Ack HLR
Figure 3-21 Delete subscriber data procedure
3.10 Service Request Procedure s (UMTS Only)

3.10.1 MS-Initiated Service Request Procedure
MS SGSN HLR GGSN
RNC
1. RRC Connection Request 1. RRC Connection Setup 2. Service Request 3. Security Functions
4. Service Accept
4. Radio Access Bearer Assignment Request 5. Radio Bearer Setup 6. Radio Bearer Setup Complete 6. Radio Access Bearer Assignment Response 7. SGSN-Initiated PDP Context Modification 8. Uplink PDU
Figure 3-22 MS-initiated service request procedure
Each step is explained in the following list: 1) 2) The MS establishes an RRC connection, if none exists for CS traffic. The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type specifies the requested service. Service Type shall indicate Data or Signalling. At this time, the SGSN may perform the authentication procedure. If Service Type indicates Data then a signalling connection is established between the MS and the SGSN, and resources for active PDP context(s) are allocated. If Service Type indicates Signalling then the signalling connection is established between the MS and the SGSN for sending upper-layer signalling messages 3) 4) The SGSN shall perform the security functions if the service request was initiated by an MS in PMM-IDLE state. When the network is in the PMM-CONNECTED state and when Service Type indicates Data, the SGSN responds with a Service Accept message to the MS if it accepts the service request. In case Service Type indicates Data, the SGSN sends a Radio Access Bearer Assignment Request (NSAPIRAB ID(s), TEID(s),
QoS Profile(s), SGSN IP Address(es)) message to re-establish radio access bearer for every activated PDP context. 5) 6) The RNC indicates to the MS the new Radio Bearer Identity established and the corresponding RAB ID with the RRC radio bearer setup procedure. SRNC responds with the Radio Access Bearer Assignment Response (RAB ID(s), TEID(s), QoS Profile(s), RNC IP Address(es)) message. The GTP tunnel(s) are established on the Iu interface. If the RNC returns a Radio Access Bearer Assignment Response message with a cause indicating "Requested Maximum Bit Rate not Available", then the SGSN may send a new Radio Access Bearer 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. 7) For each RAB re-established with a modified QoS profile, the SGSN initiates a PDP Context Modification procedure to inform the MS and the GGSN of the new negotiated QoS profile for the corresponding PDP context. 8) The MS sends the uplink packet.
For Service Type=Signalling, the MS knows that the Service Request message was successfully received in the SGSN when the MS receives the RRC Security Mode Control Command message. For Service Type=Data, if it is in the PMM-IDLE state, the MS knows that the Service Request was successfully received when the MS receives the RRC Security Mode Control Command message. If it is in the PMM-IDLE state, the MS knows that the Service Request was successfully received when the MS receives the Service Accept message. The Service Accept message does not mean successful re-establishment of RAB(s) For any Service Type, in case the service request cannot be accepted, the network returns a Service Reject message to the MS with an appropriate cause value. For Service Type=Data, in case the SGSN fails to re-establish RAB(s) for the PDP context(s), the SGSN determines if an SGSN-Initiated PDP Context Modification or PDP Context Deactivation procedure should be initiated. The appropriate action depends on the QoS profile of the PDP context.
3.10.2 Network-Initiated Service Request Procedure

MS RNC SGSN
1. Downlink PDU 2. Paging 2. Paging 3. RRC Connection Request 3. RRC Connection Setup
HLR
GGSN
4. Service Request 5. Security Functions 6. Radio Access Bearer Assignment Request
6. Radio Bearer Setup
6. Radio Bearer Setup Complete
6. Radio Access Bearer Assignment Response
7. SGSN-Initiated PDP Context Modification Procedure 8. Downlink PDU
Figure 3-23 Network-initiated service request procedure
Each step is explained in the following list: 1) 2) 3) 4) The SGSN receives a downlink PDP PDU for an MS in PMM-IDLE state. The SGSN sends a Paging message to the RNC. The RNC pages the MS by sending a Paging message to the MS. The MS establishes an RRC connection if none exists for CS traffic. The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type specifies Paging Response. At this time, the SGSN may perform the authentication procedure. The SGSN knows whether the downlink packet requires RAB establishment or not. 5) 6) The SGSN shall perform the security mode procedure. If resources for the PDP contexts are re-established, the SGSN sends a Radio Access Bearer Assignment Request (RAB ID(s), TEID(s), QoS Profile(s), SGSN IP Address(es)) message to the RNC. The RNC sends a Radio Bearer Setup (RAB ID(s)) to the MS. The MS responds by returning a Radio Bearer Setup Complete message to the RNC. The RNC sends a Radio Access Bearer Assignment Response (RAB ID(s), TEID(s), RNC IP Address(es)) message to
the SGSN in order to indicate that GTP tunnels are established on the Iu interface and radio access bearers are established between the RNC and the MS. If the RNC returns a Radio Access Bearer Assignment Response message with a cause indicating that the requested QoS profile(s) cannot be provided, e.g., "Requested Maximum Bit Rate not Available", then the SGSN may send a new Radio Access Bearer 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. 7) For each RAB re-established with a modified QoS profile, the SGSN initiates a PDP Context Modification procedure to inform the MS and the GGSN of the new negotiated QoS profile for the corresponding PDP context. 8) The SGSN sends the downlink packet.
For Service Type=Page Response, the MS knows that the Service Request message was successfully received in the SGSN when the MS receives the RRC Security Mode Control Command message. In the case the SGSN fails to re-establish RAB(s) for the PDP context(s), the SGSN shall initiates a Modification procedure.
3.11 UMTS-GSM Intersystem Change

3.11.1 Intra SGSN Intersystem Change
I. UMTS-to-GSM intra SGSN change
MS BSS SRNS 2G+3G-SGSN new MSC/VLR HLR old MSC/VLR
1. Intersystem change decision
2. Routeing Area Update Request 3. SRNS Context Request 4. SRNS Context Response 5. Security Functions 6. SRNS Data Forward Command 7. Forward Packets 8. Iu Release Command 8. Iu Release Complete 9. Location Update Request 10a. Update Location 10b. Cancel Location 10c. Cancel Location Ac 10d. Insert Subscriber Data 10e. Insert Subscriber Data Ack 10f. Update Location 11. Location Update Accept 12. Routeing Area Update Accept C1 13. Routeing Area Update Complete 14. TMSI Reallocation Complete 15. BSS Packet Flow Context Procedure
Figure 3-24 UMTS-to-GSM intra SGSN change
1)
When the MS roams to a new cell that supports GSM radio technology, the MS or BSS or UTRAN decides to perform an intersystem change and stops transmission to the network.
2)
The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type) message to the 2G+3G-SGSN. Update Type shall indicate RA update or combined RA/LA update or, if the MS wants to perform an IMSI attach, combined RA/LA update with IMSI attached requested. The BSS shall add the Cell Global Identity (CGI) including the RAC and LAC of the cell where the message was received before passing the message to the 2G+3G-SGSN.
3) 4)
The 2G+3G-SGSN sends an SRNS Context Request (IMSI) message to the SRNS. Upon receiving the SRNS Context Request message, the SRNS stops transmission of downlink PDUs to the MS, buffers the downlink PDUs and responds with an SRNS Context Response (GTP-SND, GTP-SNU, PDCP-SND, PDCP-SNU) message to the 2G+3G-SGSN. The GTP sequence numbers are included for each PDP context indicating the next in-sequence downlink PDU to be sent to the MS and the next in-sequence GTP PDU to be tunnelled to the GGSN. For each active PDP context using acknowledged mode, the SRNS also includes the uplink PDCP sequence number (PDCP-SNU). PDCP-SNU is the PDCP sequence number for the next expected in-sequence uplink packet to be received in acknowledged mode from the MS for each radio bearer, which requires lossless relocation, thus converting them to SNDCP N-PDU numbers of the respective 2G GPRS PDP contexts.
5) 6)
Security functions may be executed. The 2G+3G-SGSN sends an SRNS Data Forward Command (RAB ID, Transport Layer Address, Iu Transport Association) message to the SRNS. This informs the SRNS that the 2G+3G-SGSN is ready to receive data packets. Upon reception of SRNS Data Forward Command message from the 2G+3G-SGSN the SRNS shall start the data-forwarding timer.
7)
The transmitted but not acknowledged PDCP-PDUs together with the downlink PDCP sequence number and the buffered downlink GTP PDUs are tunnelled back to the 2G+3G-SGSN. The 2G+3G-SGSN shall strip off the eight most significant bits of the PDCP sequence numbers accompanying the received N-PDUs before sending them to the MS.
8)
When the RNC data forwarding timer has expired, the 2G+3G-SGSN sends an Iu Release Command message to the SRNS and the SRNS responds with an Iu Release Complete message.
9)
If the association has to be established i.e., if Update Type indicates combined RA/LA update with IMSI attach requested, or if the LA changed with the routeing area update, then the 2G+3G-SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate normal location update. The VLR number is translated from the
RAI by the 2G+3G-SGSN. The VLR creates or updates the association with the 2G+3G-SGSN by storing SGSN Number. 10) If the subscriber data in the VLR is marked as not confirmed by the HLR, then the new VLR informs the HLR. The HLR cancels the data in the old VLR and inserts subscriber data in the new VLR: The new VLR sends an Update Location (new VLR) to the HLR. The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. The old VLR acknowledges with Cancel Location Ack (IMSI). The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR. The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). The HLR responds with Update Location Ack (IMSI) to the new VLR. 11) The new VLR allocates a new VLR TMSI and responds with Location Update Accept (VLR TMSI) to the 2G+3G-SGSN. VLR TMSI is optional if the VLR has not changed. 12) The 2G+3G-SGSN validates the MS's presence in the new RA. If due to roaming restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, then the 2G+3G-SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then the 2G+3G-SGSN updates MM and PDP contexts for the MS. A new P-TMSI may be allocated. A logical link is established between the new 2G+3G-SGSN and the MS. The establishment procedure is initiated by 2G+3G-SGSN. A Routeing Area Update Accept (P-TMSI, P-TMSI Signature, Receive N-PDU Number (=converted PDCP-SNU)) message is returned to the MS. Receive N-PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-originated N-PDUs successfully transferred before the start of the update procedure. 13) The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete (Receive N-PDU Number) message to the SGSN. Receive N-PDU Number (=converted PDCP-SND) contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-terminated N-PDUs successfully transferred before the start of the update procedure. The MS deducts Receive N-PDU Number from PDCP-SND by stripping off the eight most significant bits. 14) The 2G+3G-SGSN sends a TMSI Reallocation Complete message to the VLR if the VLR TMSI is confirmed by the MS. 15) The 2G+3G-SGSN and the BSS may execute the BSS Packet Flow Context procedure. C1) If CAMEL is supported, CAMEL-GPRS-Routeing-Area-Update shall be performed at C1.
II. GSM-to-UMTS intra SGSN change
MS
BSS
SRNS
2G+3G-SGSN
new MSC/VLR
HLR
old MSC/VLR
2. Routing Area Update Request 3. Security Functions 4. Location Update Request 5a. Update Location 5b. Cancel Location 5c. Cancel Location Ac 5d. Insert Subscriber Data 5e. Insert Subscriber Data 5f. Update Location 6. Location Update Accept 7. Routing Area Update Accept C1 8. Routing Area Update Complete 10. Service Request 9. TMSI Reallocation Complete
Set up Radio Resources
11. RAB Assignment Request 11. RAB Assignment 12. Packet Transfer Resume
13. Packet Transfer Resume
Figure 3-25 GSM-to-UMTS intra SGSN change
Each step is explained in the following list: 1) The MS or BSS or UTRAN decides to perform an intersystem change which makes the MS switch to a new cell that supports UMTS radio technology, and stops transmission to the network. 2) The MS initiates an RRC connection establishment and sends Routeing Area Update Request (P-TMSI, Old RA, Old P-TMSI Signature, Update Type, CM) message to the combined 2G+3G-SGSN. Update Type shall indicate RA update or combined RA/LA update or, if the MS wants to perform an IMSI attach,
combined RA/LA update with IMSI attach requested. The message may also contain the follow on request indication i.e., if there is pending uplink traffic (signalling or user data), the SGSN may use, as an implementation option, the follow on request indication to release or keep the Iu connection after the completion of the RAU procedure. The SRNS shall add an identifier of the area where the message was received before passing the message to the 2G+3G-SGSN. The 2G+3G-SGSN stops transmission of N-PDUs to the MS. 3) 4) Security functions may be executed. If the association has to be established i.e., if Update Type indicates combined RA/LA update with IMSI attach requested, or if the LA changed with the routeing area update, then the 2G+3G-SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI attach if Update Type in step 1) indicated combined RA/LA update with IMSI attach requested. Otherwise, Location Update Type shall indicate normal location update. The VLR number is translated from the RAI by the 2G+3G-SGSN. The VLR creates or updates the association with the 2G+3G-SGSN by storing SGSN Number. 5) If the subscriber data in the VLR is marked as not confirmed by the HLR, then the new VLR informs the HLR. The HLR cancels the data in the old VLR and inserts subscriber data in the new VLR: The new VLR sends an Update Location (new VLR) to the HLR. The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. The old VLR acknowledges with Cancel Location Ack (IMSI). The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR. The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). The HLR responds with Update Location Ack (IMSI) to the new VLR. 6) 7) The new VLR allocates a new VLR TMSI and responds with Location Update Accept (VLR TMSI) to the 2G+3G-SGSN. The 2G+3G-SGSN validates the MS's presence in the new RA. If due to roaming restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, then the 2G+3G-SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then the 2G+3G-SGSN updates MM and PDP contexts for the MS. A new P-TMSI may be allocated. A Routeing Area Update Accept (P-TMSI, P-TMSI Signature) message is returned to the MS. 8) 9) The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete message to the SGSN. The 2G+3G-SGSN sends a TMSI Reallocation Complete message to the VLR if the VLR TMSI is confirmed by the MS.
10) The MS sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type specifies the requested service (data or signalling). 11) The 2G+3G-SGSN requests the SRNS to establish a radio access bearer by sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP-SNDs, GTP-SNUs, PDCP-SNUs) message to the SRNS. The PDCP-SNU shall be derived from the N-PDU sequence numbers stored in the PDP contexts. The SRNS sends a Radio Bearer Setup Request (PDCP-SNUs) message to the MS. The MS responds with a Radio Bearer Setup Complete (PDCP-SNDs) message. The SRNS responds with a RAB Assignment Response message. 12) Traffic flow is resumed between the 2G+3G-SGSN and the SRNS. The SRNS shall discard all N-PDUs with N-PDU sequence numbers older than the downlink N-PDU sequence number received from the MS. Other N-PDUs shall be transmitted to the MS. The MS shall discard all N-PDUs with sequence numbers older than the GTP-SNU received from the SRNS. If this is not the case the N-PDU shall be transmitted to the SRNS. 13) The traffic flow is resumed between the SRNS and the MS.
3.11.2 Inter SGSN Intersystem Change

I. UMTS-to-GSM inter SGSN change
MS
BSS SRNS
new 2G-SGSN
old 3G-SGSN
GGSN
new MSC/VLR
HLR
old MSC/VLR
2. Routing Area Update Request

3. SGSN Context Request
4. SRNS Context Request
4. SRNS Context Response
5. SGSN Context Response

6. Security Functions
7. SGSN Context Acknowledge
C1
8. SRNS Data Forward Command
8a. Forward Packets 9. Forward Packets
10. Update PDP Context Request

10. Update PDP Context Response
11. Update GPRS Location
12. Cancel Location
13. Iu Release Command 13. Iu Release Complete
12. Cancel Location Ack

14. Insert Subscriber Data
14. Insert Subscriber Data Ack
15. Update GPRS Location Ack

16. Location Update Request 17a. Update Location 17b. Cancel Location 17c. Cancel Location Ack 17d. Insert Subscriber Data 17e. Insert Subscriber Data Ack 18. Location Update Accept
C2
17f. Update Location Ack
19. Routing Area Update Accept

C3
20. Routing Area Update Complete
21. TMSI Reallocation Complete
22. BSS Packet Flow Context Procedure
Figure 3-26 UMTS-to-GSM inter SGSN change

Each step is explained in the following list: 1) The MS or BSS or UTRAN decides to perform an intersystem change, which makes the MS switch to a new cell that supports GSM radio technology, and stops transmission to the network. 2) The MS sends a Routeing Area Update Request (old RAI, old P-TMSI Signature, Update Type) message to the new 2G-SGSN. Update Type shall indicate RA update or combined RA/LA update, or, if the MS wants to perform an IMSI attach, combined RA/LA update with IMSI attach requested. The BSS shall add the Cell Global Identity including the RAC and LAC of the cell where the message was received before passing the message to the new 2G-SGSN. 3) The new 2G-SGSN sends an SGSN Context Request (old RAI, TLLI, old P-TMSI Signature, New SGSN Address) message to the old 3G-SGSN to get the MM and PDP contexts for the MS. The old SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old 3G-SGSN. The old 3G-SGSN starts a timer. If the MS is not known in the old 3G-SGSN, the old 3G-SGSN responds with an appropriate error cause. 4) If the MS is PMM-CONNECTED the old 3G-SGSN sends an SRNS Context Request (IMSI) message to the SRNS. Upon reception of this message the SRNS buffers and stops sending downlink PDUs to the MS and returns an SRNS Context Response (IMSI, GTP-SNDs, GTP-SNUs, PDCP-SNUs) message. The SRNS shall include for each PDP context the next in-sequence GTP sequence number to be sent to the MS and the GTP sequence number of the next uplink PDU to be tunnelled to the GGSN. For each active PDP context using acknowledged mode, the SRNS also includes the uplink PDCP sequence number (PDCP-SNU). PDCP-SNU shall be the next in-sequence PDCP sequence number expected from the MS per active radio bearer. The 3G-SGSN shall strip off the eight most significant bits of the passed PDCP sequence numbers, thus converting them to SNDCP N-PDU numbers. 5) The old 3G-SGSN responds with an SGSN Context Response (MM Context, PDP Contexts) message. For each PDP context the old 3G-SGSN shall include the GTP sequence number for the next uplink GTP PDU to be tunnelled to the GGSN and the next donwlink GTP sequence number for the next in-sequence N-PDU to be sent to the MS. Each PDP Context also includes the SNDCP Send N-PDU Number (the value is 0) for the next in-sequence downlink N-PDU to be sent in acknowledged mode to the MS and the SNDCP Receive N-PDU Number (=converted PDCP-SNU) for the next in-sequence uplink N-PDU to be received in acknowledged mode from the MS. The new 3G-SGSN shall neglect the MS network capability that is included in the MM context in the SGSN Context Response message received during the previous routeing area update procedure. 6) Security functions may be executed.
7)
The new 2G-SGSN sends an SGSN Context Acknowledge message to the old 3G-SGSN. This informs the old 3G-SGSN that the new 2G-SGSN is ready to receive data packets belonging to the activated PDP contexts. The old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a RA update procedure back to the old SGSN before completing the ongoing RA update procedure.
8)
If the MS is PMM-CONNECTED the old 3G-SGSN sends an SRNS Data Forward Command (RAB ID, Transport Layer Address, Iu Transport Association) message to the SRNS. The SRNS shall start tunnelling the partly transmitted and the transmitted but not acknowledged PDCP-PDUs together with the PDCP downlink sequence number (the eight most significant bits shall be stripped off), and start duplicating and tunnelling the buffered GTP PDUs to the old 3G-SGSN. Upon reception of SRNS Data Forward Command message from the 3G-SGSN the SRNS shall start the data-forwarding timer.
9)
The old 3G-SGSN tunnels the GTP PDUs to the new 2G-SGSN. The sequence numbers (=converted PDCP sequence numbers) shall not be modified in the GTP header of the tunnelled PDUs.
10) The new 2G-SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated) message to each GGSN concerned. Each GGSN updates its PDP context fields and returns an Update PDP Context Response (TEID) message. 11) The new 2G-SGSN informs the HLR of the change of SGSN by sending an Update GPRS Location (SGSN Number, SGSN Address, IMSI) message to the HLR. 12) The HLR sends a Cancel Location (IMSI) message to the old 3G-SGSN. The old 3G-SGSN acknowledges with a Cancel Location Ack (IMSI) message. The old 3G-SGSN removes the MM and PDP contexts when the timer described in step 3) expires. 13) When the MS is PMM-CONNECTED the old 3G-SGSN sends an Iu Release Command message to the SRNS. When the RNC data-forwarding timer has expired the SRNS responds with an Iu Release Complete message. 14) The HLR sends an Insert Subscriber Data (IMSI, GPRS Subscription Data) message to the new 2G-SGSN. The 2G-SGSN inserts subscriber data in the MM and PDP contexts for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 15) The HLR acknowledges the Update GPRS Location by returning an Update GPRS Location Ack (IMSI) message to the new 2G-SGSN if the modification is confirmed to be completed. 16) If the association has to be established i.e., if Update Type indicates combined RA/LA update with IMSI attach requested, or if the LA changed with the routeing area update, then the new 2G-SGSN sends a Location Update Request (new
LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI attach if Update Type in step 1) indicated combined RA/LA update with IMSI attach requested. Otherwise, Location Update Type shall indicate normal location update. The VLR number is translated from the RAI by the 2G-SGSN. The 2G-SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the Insert Subscriber Data message from the HLR. The VLR creates or updates the association with the 2G-SGSN by storing SGSN Number. 17) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The HLR cancels the old VLR and inserts subscriber data in the new VLR: The new VLR sends an Update Location (new VLR) to the HLR. The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. The old VLR acknowledges with Cancel Location Ack (IMSI). The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR. The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). The HLR responds with Update Location Ack (IMSI) to the new VLR. 18) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the 2G-SGSN. VLR TMSI is optional if the VLR has not changed. 19) The new 2G-SGSN validates the MS's presence in the new RA. If due to roaming restrictions the MS is not allowed to be attached in the 2G-SGSN, or if subscription checking fails, then the new 2G-SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then the new 2G-SGSN constructs MM and PDP contexts for the MS. A logical link is established between the new 2G-SGSN and the MS. The establishment procedure is initiated by 2G-SGSN. The new 2G-SGSN responds to the MS with a Routeing Area Update Accept (P-TMSI, P-TMSI Signature, Receive N-PDU Number (=converted PDCP-SNU)) message. Receive N-PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-originated N-PDUs successfully transferred before the start of the update procedure. 20) The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete (Receive N-PDU Number (=converted PDCP-SND)) message to the SGSN. Receive N-PDU Number contains the acknowledgements for each acknowledged-mode NSAPI used by the MS, thereby confirming all mobile-terminated N-PDUs successfully transferred before the start of the update procedure. The MS deducts Receive N-PDU number from PDCP-SND by stripping off the eight most significant bits. PDCP-SND is the PDCP sequence number for the next expected in-sequence downlink packet to be received in acknowledged mode in the MS per radio bearer.
21) The new 2G-SGSN sends TMSI Reallocation Complete message to the new VLR if the VLR TMSI is confirmed by the MS. 22) The 2G-SGSN and the BSS may execute the BSS Packet Flow Context procedure. For an MS with GPRS-CSI defined, CAMEL interaction may be performed: C1) CAMEL-GPRS-SGSN-Context-Acknowledge C2) CAMEL-GPRS-Routeing-Area-Update-Session C3) CAMEL-GPRS-Routeing-Area-Update-Context
II. GSM-to-UMTS inter SGSN change
MS
BSS
SRNS
new 3G-SGSN
old 2G-SGSN
GGSN
new MSC/VLR
HLR
old MSC/VLR

2. Routeing Area Update Request
3. SGSN Context Request

4. SGSN Context Response
5. Security Functions
6. SGSN Context Acknowledge
C1
7. Forward Packets
8. Update PDP Context Request
8. Update PDP Context Response
9. Update GPRS Location
10. Cancel Location
10. Cancel Location Ack 11. Insert Subscriber Data 11. Insert Subscriber Data Ack
12. Update GPRS Location Ack
13. Location Update Request 14a. Update Location 14b. Cancel Location 14b. Cancel Location Ack 14c. Insert Subscriber Data 14d. Insert Subscriber Data Ack 14e. Update Location Ack 15. Location Update Accept
C2
16. Routeing Area Update Accept
C3
17. Routeing Area Update Complete 18. TMSI Reallocation Complete
19. Service Request Set up Radio Resources
20. RAB Assignment Request

20. RAB Assignment Response
Figure 3-27 GSM-to-UMTS inter SGSN change
Each step is explained in the following list: 1) The MS or BSS or UTRAN decides to perform an intersystem change, which makes the MS switch to a new cell that supports UMTS radio technology, and stops transmission to the network. 2) The MS sends a Routeing Area Update Request (P-TMSI, old RAI, old P-TMSI Signature, Update Type, CM, MS Network Capability) message to the new 3G-SGSN. Update Type shall indicate RA update or combined RA/LA update, or, if the MS wants to perform an IMSI attach, combined RA/LA update with IMSI attach requested. The message may also contain the follow on request indication i.e., if there is pending uplink traffic (signalling or user data), the SGSN may use, as an implementation option, the follow on request indication to release or keep the Iu connection after the completion of the RAU procedure. The SRNC shall add the Routeing Area Identity including the RAC and LAC of the area where the MS is located before forwarding the message to the 3G-SGSN. This RA identity corresponds to the RAI in the MM system information sent by the SRNC to the MS. 3) The new 3G-SGSN uses the old RAI received from the MS to derive the old 2G-SGSN address, and sends an SGSN Context Request (old RAI, old P-TMSI, New SGSN Address) message to the 2G-SGSN to get the MM and PDP contexts for the MS. The old 2G-SGSN validates the old P-TMSI Signature and responds with an appropriate error cause if it does not match the value stored in the old 2G-SGSN. If the unmatch error is received the 3G-SGSN shall initiate an Authenticate procedure. If the MS is authenticated correctly, the new 3G-SGSN shall send an SGSN Context Request (old RAI, TLLI, MS Validated, New SGSN Address) message to the old 2G-SGSN. MS Validated indicates that the new 3G-SGSN has authenticated the MS. If the old P-TMSI Signature was valid or if the new 3G-SGSN indicates that it has authenticated the MS, the old 2G-SGSN starts a timer and stops the transmission of N-PDUs to the MS. 4) The old 2G-SGSN responds with an SGSN Context Response (MM Context, PDP Contexts) message. Each PDP Context includes the GTP sequence number for the next downlink N-PDU to be sent to the MS and the GTP sequence number for the next uplink N-PDU to be tunnelled to the GGSN. Each PDP Context also includes the SNDCP Send N-PDU Number for the next downlink N-PDU to be sent in acknowledged mode to the MS and the SNDCP Receive N-PDU Number for the next uplink N-PDU to be received in acknowledged mode from the MS. The new 3G-SGSN shall use the GTP sequence numbers for in-sequence delivery over the Iu interface. The new 3G-SGSN shall neglect the MS network capability included in the MM context that is obtained through the routeing area update procedure. 5) 6) Security functions may be executed. The new 3G-SGSN sends an SGSN Context Acknowledge message to the old 2G-SGSN. This informs the old 2G-SGSN that the new 3G-SGSN is ready to
receive data packets belonging to the activated PDP contexts. The old SGSN marks in its context that the MSC/VLR association and the information in the GGSNs and the HLR are invalid. This triggers the MSC/VLR, the GGSNs, and the HLR to be updated if the MS initiates a routeing area update procedure back to the old SGSN before completing the ongoing routeing area update procedure. 7) The old 2G-SGSN duplicates the buffered N-PDUs and starts tunnelling them to the new 3G-SGSN. Additional N-PDUs received from the GGSN before the timer described in step 3) expires are also duplicated and tunnelled to the new 3G-SGSN. No N-PDUs shall be forwarded to the new 3G-SGSN after expiry of the timer described in step 3). 8) The new 3G-SGSN sends an Update PDP Context Request (new SGSN Address, TEID, QoS Negotiated) message to each GGSN concerned. Each GGSN updates its PDP context fields and return an Update PDP Context Response (TEID) message. 9) The new 3G-SGSN informs the HLR of the change of SGSN by sending an Update GPRS Location (SGSN Number, SGSN Address, IMSI) message to the HLR. 10) The HLR sends a Cancel Location (IMSI, Cancellation Type) message to the old 2G-SGSN. The old 2G-SGSN removes the MM and PDP contexts when the timer described in step 3) expires. The old 2G-SGSN acknowledges with a Cancel Location Ack (IMSI) message. 11) The HLR sends an Insert Subscriber Data (IMSI, GPRS Subscription Data) message to the new 3G-SGSN. The 3G-SGSN constructs an MM context for the MS and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 12) The HLR acknowledges the Update GPRS Location by returning an Update GPRS Location Ack (IMSI) message to the new 3G-SGSN. 13) If the association has to be established, if Update Type indicates combined RA/LA update with IMSI attach requested, or if the LA changed with the routeing area update, then the new SGSN sends a Location Update Request (new LAI, IMSI, SGSN Number, Location Update Type) to the VLR. Location Update Type shall indicate IMSI attach if Update Type in step 1) indicated combined RA/LA update with IMSI attach requested. Otherwise, Location Update Type shall indicate normal location update. The VLR number is translated from the RAI by the 3G-SGSN. The 3G-SGSN starts the location update procedure towards the new MSC/VLR upon receipt of the Insert Subscriber Data message from the HLR. The VLR creates or updates the association with the 3G-SGSN by storing SGSN Number. 14) If the subscriber data in the VLR is marked as not confirmed by the HLR, the new VLR informs the HLR. The HLR cancels the old VLR and inserts subscriber data in the new VLR: The new VLR sends an Update Location (new VLR) to the HLR.
The HLR cancels the data in the old VLR by sending Cancel Location (IMSI) to the old VLR. The old VLR acknowledges with Cancel Location Ack (IMSI). The HLR sends Insert Subscriber Data (IMSI, GSM subscriber data) to the new VLR. The new VLR acknowledges with Insert Subscriber Data Ack (IMSI). The HLR responds with Update Location Ack (IMSI) to the new VLR. 15) The new VLR allocates a new TMSI and responds with Location Update Accept (VLR TMSI) to the 3G-SGSN. VLR TMSI is optional if the VLR has not changed. 16) The new 3G-SGSN validates the MS's presence in the new RA. If due to roaming restrictions the MS is not allowed to be attached in the 3G-SGSN, or if subscription checking fails, then the new 3G-SGSN rejects the routeing area update with an appropriate cause. If all checks are successful then the new 3G-SGSN constructs MM and PDP contexts for the MS. The new 3G-SGSN responds to the MS with a Routeing Area Update Accept (P-TMSI, P-TMSI signature ) message. 17) The MS acknowledges the new P-TMSI by returning a Routeing Area Update Complete message to the SGSN. 18) The new 3G-SGSN sends TMSI Reallocation Complete message to the new VLR if the VLR TMSI is confirmed by the MS. 19) If the MS is to send any uplink data or signalling it sends a Service Request (P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type specifies the requested service Service Type shall indicate Data or Signalling. 20) If the MS has sent the Service Request the new 3G-SGSN requests the SRNS to establish a radio access bearer by sending a RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP-SNDs, GTP-SNUs, PDCP-SNUs) message to the SRNS. The PDCP sequence numbers shall be derived from the N-PDU sequence numbers stored in the PDP contexts. The SRNS sends a Radio Bearer Setup Request (PDCP-SNUs) message to the MS. The MS responds with a Radio Bearer Setup Complete (PDCP-SNDs) message. The SRNS responds with a RAB Assignment Response message. The SRNS shall discard all N-PDUs tunnelled from the SGSN with N-PDU sequence numbers older than the PDCP-SNDs received from the MS. Other N-PDUs shall be transmitted to the MS. The MS shall discard all N-PDUs with sequence numbers older than the PDCP-SNUs received from the SRNS. For an MS with GPRS-CSI defined, CAMEL interaction may be performed: C1) CAMEL-GPRS-SGSN-Context-Acknowledge C2) CAMEL-GPRS-Routeing-Area-Update-Session C3) CAMEL-GPRS-Routeing-Area-Update-Context
3.12 Classmark Handling

3.12.1 Radio Access Classmark
I. MS radio access capability (GSM only)
The MS radio access capability information element contains all the GSM radio capabilities of the MS, e.g., multislot capability, power class.
II. UE capability (UMTS only)

The UE capability information element contains all the UMTS radio capabilities of the MS, e.g., power control, code resource, UE mode, ciphering, PDCP capabilities, etc.
3.12.2 MS Network Capability

The MS network capability contains non radio-related capabilities, e.g., the GSM GPRS ciphering, UMTS authentication, and TI extension capabilities.

03-Mobility Management Functions PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

03-Mobility Management Functions PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Huawei Technologies Proprietary i

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Huawei Technologies Proprietary ii

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Chapter 3 Mobility Management Functions

Chapter 3 Mobility Management Functions

Huawei Technologies Proprietary 3-1

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Chapter 3 Mobility Management Functions

GPRS Detach or Cancel Location

Implicit Detach or Cancel Location

READY timer expiry or Force to STANDBY

READY timer expiry or Force to STANDBY or Abnormal RLC condition

MM State Model of SGSN

Figure 3-1 GSM MM state model

3.1.2 Mobility Management States (UMTS Only)

I. Moving from PMM-DETACHED to PMM-CONNECTED

Huawei Technologies Proprietary 3-2

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Chapter 3 Mobility Management Functions

II. Moving from PMM-CONNECTED to PMM-IDLE

III. Moving from PMM-IDLE to PMM-CONNECTED

IV. Moving from PMM-CONNECTED to PMM-DETACHED

V. Moving from PMM-IDLE to PMM-DETACHED

VI. Moving from PMM-CONNECTED to PMM-CONNECTED

Huawei Technologies Proprietary 3-3

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Chapter 3 Mobility Management Functions

PS Detach PS Attach PS Signalling Connection Release

Detach, PS Attach Reject, RAUReject

PS Attach PS Signalling Connection Release PM M -IDLE

Detach, PS Attach Reject, RAUReject

PS Signalling Connection Establish

SM -ACTIVE or SM -ACTIVE or PS Signalling INACTIVE INACTIVE Connection Establish

Serving RNC relocation

3.2 Mobility Management Timer Functions

3.2.2 Periodic RA Update Timer Function

Huawei Technologies Proprietary 3-4

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Chapter 3 Mobility Management Functions

3.2.3 Mobile Reachable Timer Function

3.3 Interactions Between SGSN and MSC/VLR

Huawei Technologies Proprietary 3-5

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Chapter 3 Mobility Management Functions

3.3.2 Combined RA/LA Updating

3.3.3 CS Paging (GSM Only)

CCCH paging channel

CCCH paging channel

CCCH paging channel III CCCH paging channel

Packet paging channel CCCH paging channel

Huawei Technologies Proprietary 3-6

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Chapter 3 Mobility Management Functions

3.3.4 CS Paging (UMTS Only)

3.3.5 Non-GPRS Alert

3.3.6 MS Information Procedure

Huawei Technologies Proprietary 3-7

Protocols and Signaling Analysis HUAWEI UMTS Packet-Switched Core Network

Chapter 3 Mobility Management Functions

3.3.7 MM Information Procedure

3.4 GPRS Attach Function