You are on page 1of 168

TECHCOM Consulting

UE-CN Protocols
Content: 1 GENERAL ABOUT UE-CN PROTOCOLS ......................................................... 3 1.1. 1.2. 1.3. 1.4. 2 2.1. 2.2. 2.3. 2.4. 2.5. 3 3.1. 3.2. 3.3. 3.4. 4 4.1. 4.2. 4.3. 4.4. 4.5. 5 5.1. PROTOCOLS BETWEEN UE AND CN............................................................................. 4 UE OPERATION MODES ................................................................................................ 6 NETWORK OPERATION MODES ..................................................................................... 8 NAS PROTOCOLS IN THE UE AND MESSAGE DISCRIMINATION................................... 10 TASKS OF MM AND CC PROTOCOL ........................................................................... 16 MM CONNECTIONS ................................................................................................... 20 MM PROCEDURES ..................................................................................................... 22 CC PROCEDURES ....................................................................................................... 58 COMPLETE CALL CONTROL SEQUENCES ................................................................... 70 TASKS OF GMM AND SM PROTOCOL........................................................................ 84 MM SUB-LAYER STATES FOR PS CN DOMAIN........................................................... 88 GMM PROCEDURES .................................................................................................. 90 SM PROCEDURES .................................................................................................... 132 UE-CN SIGNALING MESSAGE TRANSPORT............................................................... 152 PROTOCOL DISCRIMINATOR AND TRANSACTION IDENTIFIER .................................... 154 MESSAGE TYPE ....................................................................................................... 156 PARAMETER FORMATS ............................................................................................ 158 SPECIFICATION EXAMPLE ........................................................................................ 160 ETSI / 3GPP RECOMMENDATIONS .......................................................................... 168

MM AND CC PROTOCOL ................................................................................ 15

GMM AND SM PROTOCOL ............................................................................. 83

LAYER 3 MESSAGE FORMATTING.............................................................. 151

REFERENCES................................................................................................ 167

TECHCOM Consulting - Training and Course Material

TC 1160-4

UE-CN Protocols

-2-

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

1 General about UE-CN protocols

TECHCOM Consulting

-3-

TC 1160-4

UE-CN Protocols

1.1.

Protocols between UE and CN

As discussed in the very first part of this course, there are two basic types of signaling in a communication network access and non access related messages. The previously discussed RANAP mainly provides access related signaling. To manage the communication services offered by the core network (e.g. calls, sessions, mobility management and messaging) there must be communication directly between UE and CN the non access related signaling. The following protocols belong to this: MM : The Mobility Management protocol is responsible for signaling procedures that enable the mobility handling for the CS core network domain. GMM : The GPRS Mobility Management protocol has the same task but for the PS core network domain. CC : The call control protocol handles circuit switched user connections (e.g. CS call or circuit switched data CSD). SS : The supplementary service protocol enables the subscriber to trigger non-call related supplementary services like USSD. SM : The Session Management protocol handles packet data session via the GPRS feature of UMTS. SMS : The Short Message Service is a whole series of protocols that enable a store-and-forward service for user text messages or binary data.

These protocols form the Non Access Stratum NAS between UE and CN. For the transport of their messages they use the signaling transport services offered by RRC and RANAP. The serving RNC is responsible to relay NAS messages between these two protocols. The end result is a direct transfer of NAS messages between UE and CN.

-4-

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

UTRAN
MSC | SGSN RNC

SS, CC, SMS, SM MM,GMM

Relay RRC RANAP RLC MAC


SCCP MTP3B SAAL AAL5

SS, CC, SMS, SM MM, GMM

RRC RLC MAC PHY


NAS protocols.

RANAP
SCCP MTP3B SAAL AAL5

PHY ATM

ATM
core network

figure 1 Non Access Stratum protocols between UE and CN.

TECHCOM Consulting

-5-

TC 1160-4

UE-CN Protocols

1.2.

UE operation modes

In GPRS/GSM (2G) there was a barrier for the integration of CS and PS services the air interface. The second generation of mobile communication networks had to implement for GPRS and CS services separated radio protocol stacks. Therefore mobile phones that should work simultaneously for GPRS and CS services had to have multiple protocol stacks running in parallel. Even worse they had to have two independent transceivers. In UMTS there is no differentiation of circuit and packet oriented services on radio level. Additionally the existing radio protocols are not only prepared but also required to support multiple radio bearers. So simultaneously running service for PS and CS are no problem from the point of the radio interface. But also in UMTS it is possible to built user equipments that work only for CS services or only for PS services. But this is no longer a restriction from the radio side, more it is a question whether the UE has the corresponding core network capabilities. All in all in UMTS one can distinguish three different operation modes of the UE. These modes are transient states, which means the mode of a UE can change as long as the core network capabilities allow the new operation mode. The following modes are defined : PS/CS mode : In the PS/CS mode the UE is registered in the CS and PS core network domain, hence it can use both services. All combinations of simultaneous service usage are possible as long as the UE processing power is sufficient. PS mode : In the PS mode the UE is registered to the PS core network domain only. Thus only PS services are possible. CS mode : In the CS mode the UE is attached to the CS network only, this means it cannot have PS services, but can use the CS services. If a UE supports the PS/CS mode it is also said to be of class A. If a UE supports only either PS mode or CS mode it is said of class C. (Note that the class B from 2G does not exist in UMTS, because the class B results from the radio protocol restriction of 2G. A class B mobile phone of 2G can be attached to PS and CS domain, but cannot use both service types simultaneously because of the restricted radio capability.)

-6-

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

Simultaneously Attached UE mode PS PS/CS mode (class A) PS mode (class C) CS mode (class C) CS

Simultaneous Service Usage PS CS

x x x x -

x x x x

x x x -

x x x

TECHCOM Consulting

UE operation modes.

figure 2 UE operation modes in UMTS.

-7-

TC 1160-4

UE-CN Protocols

1.3.

Network operation modes

When a UE is in PS/CS mode there would be a mobility management for the PS core network domain and for the CS core network domain. This means two times usage of UTRAN and air interface for the same story. This is reason why the Gs interface has been introduced. The interface is used to combine the mobility management procedures (location/routing area update, paging) of both core network domains. This is simply done in the following way. First the UE triggers a combined mobility management procedure request (which is a GMM message) to the SGSN. Then the SGSN will perform its own GMM procedure and shall after this trigger the MSC/VLR to perform the CS mobility management procedure. Of course the UE has to know when to trigger combined procedures and when to use two independent procedures. This is told to the UE via the broadcasted system information which carries the network operation mode : Network Operation Mode I: This indicates, that the Gs interface is present and the UE shall try combined MM/GMM procedures if possible. Network Operation Mode II: This mode means that there is no Gs interface provided and the UE must use individual procedures for MM and GMM.

(Note that these network operation modes are essentially different from the definitions in 2G GPRS/GSM networks. The reason is, that the RNC in UMTS performs paging co-ordination all the time. In contrast to that there is a much more complicated paging behavior in 2G.)

-8-

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

MSC/VLR

Iu-CS U T R A N Iu-PS
SGSN CS core network domain

Gs
PS core network domain

UE

Network Operation Mode I : Gs interface is present. Network Operation Mode II : Gs interface is not present.

figure 3 UMTS network operation modes.

TECHCOM Consulting

-9-

TC 1160-4

UE-CN Protocols

1.4.

NAS protocols in the UE and message discrimination

For a detailed understanding of the NAS protocols a look to the protocol stack in the UE is necessary. The basis of all NAS protocols is the Access Stratum AS. The AS consists of the radio protocols RRC, RLC, MAC, PHY. The AS protocols provide the transport service for the NAS protocols. The NAS protocols are contained in so called sub-layers. Two sub-layers exist : MM sub-layer : The MM sub-layer contains both mobility management protocols GMM and MM. The MM sub-layer controls the registration status of the UE and controls also the status of the signaling connections to the CN. The MM sub-layer can block higher layer activities when necessary (e.g. location area update before call set up). CM sub-layer : The CM (Connection Management) sub-layer is responsible for all core network services that are not related to mobility management handling. So the protocols CC (call control), SM (session management), SMS (short message service), SS (non-call related supplementary service) are contained in here.

All protocols GMM, MM, CC, SS, SMS, SM are transmitted directly in RRC messages (Initial Direct Transfer, UL Direct Transfer, DL Direct Transfer). To distinguish between the NAS protocols a Protocol Discriminator PD is used. This PD is transmitted always ahead of the message itself, so it is easy to see from which protocol the message is. The protocols in the CM sub-layer handle calls, sessions, messaging service, etc. Each of these services is called a transaction. The specification allows that several transactions of the same type of protocols (e.g. several calls, several sessions, etc.) are running simultaneously. Therefore each of the CM sub-layer protocols can occur in several instances. Now with that there is the problem to assign a message to a certain transaction. Well from the PD it is known which protocol it is. But for the transactions of this protocol a Transaction Identifier TI is needed. Like the PD the TI is transmitted ahead of the CM sub-layer message. In the protocol stack of the UE a RAB manager can be seen. The RAB manager is responsible for PDP contexts (sessions) only. When no RAB is assigned to a session but uplink data has to be sent, the RAB manager triggers the re-establishment of the RAB.

- 10 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

application and user control


CM sublayer RAB manager
RAB 1 RAB 2

SM SM
...

SM SMS
... ...

SM CC
...

SM SS
...

RAB N

RAB control

TI

TI

TI

TI

TI

GMM
Protocol Architecture in the UE for class A and B.

PD

MM

PD

MM sublayer

Access Stratum Protocols (RRC, RLC, MAC, PHY) Access Stratum Protocols (RRC, RLC, MAC, PHY)

figure 4 Protocol stacks and sub-layers in the UE.

TECHCOM Consulting

- 11 -

TC 1160-4

UE-CN Protocols

Each of the NAS message follows a defined format for transmission. This format starts with a common header that consists of Protocol Discriminator (4), Transaction Identifier (4 or 8).

The protocol discriminator PD is always 4 bit in length and indicates from which protocol (GMM, MM, CC, SS, SM, SMS, ) the message comes from. The transaction identifier consists of two or three parts: TI flag : The TI flag always in bit 8 of octet number 1 and is set to b0 if the message is sent from the side that originally allocated the TI. It is set to b0 if the message is sent to the side that originally allocated the TI. TIO : The TI octet is the value of the TI if it is between b000 and b110. In case the TIO is b111 the TI value is contained in the next octet. TIE : The TI extension is sent only when the TIO before is set to b111. In this case the TIE is the TI value.

After the Transaction Identifier follows the message type indicator.

- 12 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

8
TI flag

6
TIO ( 1 1 1)

1
PD 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 1 1 1 0 0 0 0 1 0 0 1 1 0 0 1 0 0 1 1 0 0 1 0 1 0 1 0 0 1 0 1 0 Protocol Message Group Call Control Broadcast Call Control PDSS1 Call Control (CC) GPRS Transparent Transport Protocol Mobility Management (MM) Radio Resource Management (RR) GPRS Mobility Mgt. (GMM) SMS GPRS Session Mgt. (SM) Non-call related Suppl. Services LCS

Protocol Discriminator

Message Type Message Parameters


standard TI

8
TI flag

6
TIO (=1 1 1)

Protocol Discriminator

TI flag 0 1

Description Message sent from TI originator Message sent to TI originator

1
Layer 3 header for NAS messages.

TIE ( 0000111 ... 1111111)

Message Type Message Parameters


extended TI

figure 5 Standard layer 3 header for NAS messages.

TECHCOM Consulting

- 13 -

TC 1160-4

UE-CN Protocols

- 14 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

2 MM and CC protocol

TECHCOM Consulting

- 15 -

TC 1160-4

UE-CN Protocols

2.1.

Tasks of MM and CC protocol

The protocol MM (Mobility Management) is responsible for all mobility handling tasks related to the CS core network domain. The MM protocol is terminated in the UE and in the MSC/VLR. The MM protocol has to work together with the MAP (Mobile Application Part) protocol within the core network. The tasks of the MM protocol are : Location Area Update : When the UE enters a new location area it shall trigger the update of the location information in VLR and HLR. This can also happen on a periodical basis (periodic location update). IMSI Attach/Detach : The UE can indicate power switch on and off to the network to avoid unnecessary paging. TMSI Reallocation : The TMSI (Temporary Mobile Subscriber Identity) is used to keep the user identity (IMSI) secret. Therefore the TMSI should be reallocated from time to time. Authentication : The MM protocol provides a procedure to perform a subscriber authentication using a challenge/response mechanism. MM connection setup : When a circuit switched transaction is established (e.g. CS call, SMS over MSC, USSD) a signaling connection between UE and MSC must be created first. This is the MM connection.

- 16 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR

MSC/VLR, HLR, EIR

MM

MM

MAP

MAP

Location Area Update

MM connection set up

IMSI Attach/Detach

Authentication

TMSI (re-)allocation
MM tasks.

figure 6 MM protocol tasks and protocol termination.

TECHCOM Consulting

- 17 -

TC 1160-4

UE-CN Protocols

The CC (Call Control) protocol is used to establish, maintain and release circuit switched calls or circuit switched data connections. This protocol is like the MM protocol terminated in UE and MSC. It has to inter-work with ISUP and MAP that are used within the core network. The individual tasks and services of the CC protocol are : MOC (Mobile Originated Call) / MTC (Mobile Terminated Call), call related supplementary services : To this task belong things like CCBS (call completion to busy subscriber), CLIP (calling line identity presentation), call hold, call wait, etc. emergency call set up : The emergency call is handled differently because of its urgency. DTMF tone interaction : The DTMF (Dual Tone Multi- Frequency) feature is already known from ISDN. But a UMTS/GSM subscriber uses signaling messages to indicate the pressed key pad instead of sending a multifrequency signal corresponding to the key.

The CC protocol is based on the classical ISDN user-network protocol DSS.1 (Digital Subscriber System No.1), but modifies it for the purposes of a mobile communication system using radio access.

- 18 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR ISUP/ MAP

MSC/VLR, HLR, EIR ISUP/ MAP

CC

CC

MOC / MTC

Call related supplementary services

DTMF tone interaction

Emergency call set up

TECHCOM Consulting

CC tasks.

figure 7 Call control protocol tasks and termination.

- 19 -

TC 1160-4

UE-CN Protocols

2.2.

MM connections

When a circuit switched service related transaction is established a signaling connection for this transaction is needed. This signaling connection is running between UE and MSC directly. This signaling connection is provided by the MM protocol and is called MM connection. Note that there is no physical resource associated with this connection. The MM connection simply uses the signaling transport capabilities that are provided by RRC connection between UE and serving RNC and provided by the SCCP connection that exists for this UE between serving RNC and MSC. Thus the MM connection is based on RRC and Iu signaling (SCCP) connection, in other words no MM connection can exist without SCCP connection and already known is that no SCCP connection can exist without RRC connection. A direct consequence from this fact is, that as long as a circuit switched service is running, there must be a SCCP Iu signaling connection. This behavior is different for the PS core network domain. Each MM connection is uniquely assigned to one and only one transaction. So the identification of a MM connection is easy. Because each transaction is identified by the corresponding PD (Protocol Discriminator) and TI (Transaction Identifier), also the MM connection is identified by the pair (PD,TI).

- 20 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

RRC connection

Iu-CS signalling connection serving RNC MSC

RRC connection
Iu-CS signalling connection
PD = d3 : CC

PD

PD = d1 : SMS over CS

TI MM connection call 1
MM connections concept.

TI MM connection call 14 MM connection e.g. USSD 1


PD = d11 : non-call SS

...

MM connection SMS 1

...

MM connection SMS 14

TI

...

MM connection e.g. USSD 2

figure 8 MM connections and their relation to transactions, Iu signaling connection and RRC connection.

TECHCOM Consulting

- 21 -

TC 1160-4

UE-CN Protocols

2.3.

MM procedures

General overview about MM procedures The MM protocol differentiates between three categories of procedures : MM common procedures : Common procedures can be triggered whenever an Iu signaling connection for this UE exists. The procedures that belong this category are TMSI Reallocation, Authentication, Identification, MM Information, IMSI Detach and the Abort procedure. MM specific procedures : Specific procedures can be triggered when no MM common procedure is running and no MM connection exists. This category contains Normal and Periodic Location Update and the IMSI Attach. MM connection management : The MM connection management is used to set up and release MM connections. This can only happen when no MM specific procedure is running.

A direct consequence from the mentioned pre-requisites is that there can be no location update as long as a circuit switched service is running.

- 22 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

MM procedures

MM common procedures Pre-requisites :


RRC connection exists and Iu-CS signalling connection exists.

MM specific procedures Pre-requisites :


No MM common procedure running. No MM connection exists.

MM connection mgt. Pre-requisites :


No MM specific procedure running.

Procedures :

Procedures : Normal Location Update Periodic Location Update

Procedures : MM connection set up MM connection release

TMSI Reallocation Authentication Identification MM Information Abort


MM procedures.

IMSI Attach

IMSI Detach

figure 9 Categories of MM procedures.

TECHCOM Consulting

- 23 -

TC 1160-4

UE-CN Protocols

Authentication The authentication procedure of UMTS works like in the 2G network as a challenge/response authentication. Three goals are associated with the procedure: allow the network to verify the identity of the USIM (IMSI and secret key), allow the UE to calculate the new CK (Cipher Key) and the new IK (Integrity Key), allow the UE to authenticate the network (HPLMN, VPLMN) (note that this is operator specific).

The network triggers the authentication with the MM message Authentication Request. This message carries the RAND (random number) which proves to be the challenge for the UE. Additional parameters are the AUTN (Authentication Token) which is mandatory for the UMTS authentication, it contains the following parameters: MAC (Message Authentication Code) : The MAC is a electronic signature for the authentication data. With this the UE can check whether the authentication data comes from the correct HLR. AMF (Authentication key Management Field) : The AMF field usage is operator specific. It shall enable the operator to give several algorithm versions to calculate the keys to an individual subscriber. The AMF then tells the USIM which algorithm to choose. SQN (Sequence Number) : The sequence number is used to label the authentication vectors coming from HLR/AC.

A last important parameter of the Authentication Request message is the CKSN (Cipher Key Sequence Number) which is also called KSI (Key Set Identifier). This is used to label CK,IK on the USIM and enables the usage of these keys later on for encryption and integrity protection (RANAP message : Security Mode Command). The UE shall on reception of the Authentication Request message calculate IK,CK and RES (Response) and must return the RES value in the MM message Authentication Response. No the VLR should check the response and with this the procedure ends.

- 24 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR

Authentication Request
( CKSN=KSI, RAND, AUTN )

Authentication Response
( RES )

USIM EF (ID: H6F08) Keys


MM Authentication procedure.

KSI (1 byte) CK (16 byte) IK (16 byte)

figure 10 Authentication procedure of MM protocol.

TECHCOM Consulting

- 25 -

TC 1160-4

UE-CN Protocols

Identification procedure In some cases it might be necessary that the VLR request one of the following identities explicitly from the UE : IMSI : This happens typically when the VLR cannot translate the TMSI into the IMSI. IMEI, IMEISV, TMSI.

The procedure is triggered by the VLR with the MM message Identity Request. Inside of this message the type of requested identity is indicated. The UE shall answer with Identity Response and the requested identifier inside.

- 26 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR

Identity Request
( requested Identity Type )

Identity Response
( Mobile Identity =IMSI | IMEI | IMEISV | TMSI )

TECHCOM Consulting

MM Identification procedure.

figure 11 Identification procedure of MM protocol.

- 27 -

TC 1160-4

UE-CN Protocols

TMSI Reallocation The TMSI is used to hide the IMSI on the air interface. To reduce the probability that an intruder is able to assign TMSI to the IMSI, the TMSI should be changed from time to time. This is called TMSI reallocation. It is operator dependent when this is done. Typically the TMSI is always reallocated when the subscriber enters a new location area, but also with a MOC, MTC, etc. the TMSI can be reallocated. In case the TMSI shall be reallocated without an associated location update procedure the following messages are used. The VLR triggers the reallocation with the message TMSI Reallocation Command. This message contains the TMSI and the corresponding LAI. The UE has to store this information on the USIM and shall acknowledge with TMSI Reallocation Complete. It is possible that the VLR sends the IMSI to the subscriber within the TMSI Reallocation Command message. This means for the UE to delete the old TMSI and no new TMSI is allocated.

- 28 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR

TMSI Reallocation Command


( LAI, TMSI )

TMSI Reallocation Complete


()

USIM EF LOCI (ID: H6F7E)


MM TMIS Reallocation procedure.

TMSI (4 byte) LAI (5 byte) location update status (1 byte)

figure 12 TMSI Reallocation procedure when no location update is done.

TECHCOM Consulting

- 29 -

TC 1160-4

UE-CN Protocols

IMSI Detach Indication The purpose of the IMSI Detach Indication procedure is to inform the VLR that the UE is switched off. The VLR will set in its data base the IMSI Detach Flag. The effect is that the VLR can avoid paging to this UE when it is not listening to the network. It is important to note that all the other UE related information (e.g. subscriber record) is not touched by this procedure. Whether the UE shall perform the IMSI Detach procedure or not before it is switched off, is broadcasted in the system information to the UE. In the System Information Block 1 there is the ATT (Attach) flag. When ATT is set, the UE shall perform the IMSI Detach procedure otherwise the UE shall not trigger the procedure. The procedure itself consists of the MM message IMSI Detach Indication. This message contains an UE identifier (IMSI or TMSI) and the MS class-mark which describes the UE capabilities. The revision level of the MS class-mark parameter should be set to b10 for a release 1999 mobile. Note that if this IMSI Detach Indication message is packed in a CR ( Initial UE Message) then the MSC will return a CREF (Connection Refused) because it makes no sense to establish a SCCP connection for a UE that is switched off.

- 30 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR

RRC: System Info Block 1


( ..., ATT flag = TRUE )

IMSI Detach Indication


(TMSI or IMSI, MS classmark 1 )

TECHCOM Consulting

MM IMSI detach procedure.

Revision ES A5/1 Level IND

RF power capability

figure 13 IMSI Detach Indication procedure.

- 31 -

TC 1160-4

UE-CN Protocols

MM information The MM information procedure is used to give the UE additional information about the network. This information is needed for the access to the network, but can be displayed for the user. The MM message MM Information is used. The information can be : full name of the network operator, short name of the network operator, local time zone, universal time, localized service area (LSA) identity, network daylight saving time.

If the UE does not understand the information it shall send an abort message.

- 32 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR

MM Information
(Full name of network, short name of network, local time zone, universal time, LSA identity, network daylight saving time )

TECHCOM Consulting

MM Inforamtion procedure.

figure 14 MM information procedure.

- 33 -

TC 1160-4

UE-CN Protocols

Normal Location Update In UMTS networks all independent network domains (PS and CS) provide their individual mobility management. For the CS core network domain this mobility handling is controlled by the MM protocol. This protocol maintains three different states for the update status of the UE: U1 (Updated) : This state means, that the last location update was successful and the registration was accepted by the network. In this state a valid CK, IK, CKSN, LAI is stored on the USIM. Possibly the UE has a valid TMSI if it has been allocated by the network for this UE. U2 (Not Updated) : This means that the last location update was unsuccessful, hence the USIM has no location information stored. U3 (Roaming Not Allowed) : In this case the last location update was successful, but the network rejected the registration. Therefore the subscriber cannot use any services (except emergency calls) from the network. The USIM may have valid IK, CK, LAI, CKSN and TMSI.

Note that the IMSI Detach procedure that has been discussed before does not influence these states.

- 34 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

USIM EF LOCI (ID: H6F7E)


TMSI (4 byte) LAI (5 byte) location update status (1 byte)

EFKeys (ID: H6F08) KSI (1 byte) CK (16 byte) IK (16 byte)

U1: Updated
-last LAU successful and registration accepted by the network -USIM has valid LAI, CK, IK, CKSN and possibly a TMSI
MM Update states.

U2 : Not Updated
-last LAU unsuccessful, -USIM has no location information stored and keys are deleted

U3 : Roaming Not Allowed -last LAU successful, but registration was rejected by the network -USIM may have valid LAI, CK, IK, CKSN and possibly a TMSI

figure 15 CS mobility management states of the MM protocol in the UE.

TECHCOM Consulting

- 35 -

TC 1160-4

UE-CN Protocols

For the core network the location update procedure has the meaning of an update of location data bases. The effect of a location update is : the UE has valid network information stored on the USIM, the VLR that serves the current location area of the UE has a subscriber record for this UE (IMSI as reference key) and the corresponding LAI is stored in this record together with the subscription data from the HLR, the HLR stores the number (ISDN number) of the VLR that has the subscriber record.

With this it is possible to find the subscriber. When the IMSI or MSISDN is known one can find the HLR, but from the HLR one can get the VLR number. In the VLR the location area for this UE is found, with this paging of the UE in this location area can be triggered.

- 36 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

LA 1 LA 2

LA 3

LAI = MCC + MNC + LAC IMSI = MCC + MNC + MSIN MSISDN = CC + NDC + SN
IMSI / MSISDN

UE

Updated

Location Information distribution in case of MM update staet U1.

VLR
IMSI Subscriber record - Service data - LAI

HLR
IMSI Subscriber record - Service data - VLR - number

figure 16 Distribution of location information for CS core network domain.

TECHCOM Consulting

- 37 -

TC 1160-4

UE-CN Protocols

The normal location area update procedure has the task to keep the location information in HLR and VLR up to date. The procedure is triggered by the UE when it enters a new location area. Well this can happen in two different ways: UE has no RRC connection: When the UE has no RRC connection it will listen to the broadcasted system information that is available in each UMTS cell. From this system information the UE gets the LAI this cell belongs too. When the subscriber moves away from a cell, the UE will select a new cell from where the system information will be read. If the newly received LAI from the new is different to the LAI stored on the USIM the normal location update will be triggered. UE has a RRC connection: When the UE has a RRC connection it will not listen to the normal broadcasted system information, furthermore the UE will receive the system information about the network from its serving RNC directly. So it is the serving RNC that decides which LAI is to be sent to the UE. If the serving RNC sends a new LAI to the UE, that is different to the one stored on the USIM it will trigger the normal location update procedure as long as there is no MM connection active at the moment. On figure on the right side shown is the normal location update triggered by a UE that has currently no RRC connection. The difference between a UE with and without RRC connection is the trigger for the location update procedure. The procedure itself is the same and includes the following steps: trigger the location update in the VLR with a MM message, the VLR updates the location information in the HLR and gets back the CS subscription information from the HRL, the HLR deletes the subscriber record in the old VLR.

If old and new VLR are the same, the procedure part including the HLR are not performed. This means in this case the VLR will only store the new LAI of the UE and then finish the procedure.

- 38 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

old VLR
IMSI UE
Update of the location information within the CS core network domain location area update.

LA 1

Subscriber record - Service data - LAI 1

delete old VLR record

no location update UE location update UE no location update UE

HLR
IMSI
Subscriber record - Service data - VLR-no.

LA 1
update location area in VLR

LA 2
IMSI
Subscriber record - Service data - LAI 2

LA 2

update VLR address in HLR

new VLR

figure 17 Trigger of normal location update for a UE without RRC connection.

TECHCOM Consulting

- 39 -

TC 1160-4

UE-CN Protocols

The signaling procedure for a normal location update between a new and an old VLR is shown below. It has the following steps: 1. The UE gets the trigger for the location area update and sends the MM message Location Area Update Request to the new VLR through the cell of the new location area. The message contains a mobile subscriber identity (either IMSI or TMSI with old LAI). 2. The new VLR must first of all get the IMSI. Therefore it translates the old LAI of the subscriber into the ISDN number of the old VLR. Then the MAP operation Send Identification is triggered, which transports the TMSI. The old VLR should return the IMSI and the authentication data in the response message. 3. Now the new VLR has the IMSI and can perform authentication with the received authentication data. 4. When authentication is successful the new VLR shall trigger the MAP operation Update Location to the HLR of the subscriber. The HLR is addressed by the IMSI. The new VLR provides its own ISDN number and the MSC number to the HLR. 5. The HLR shall on reception of the Update Location operation request trigger two things concurrently: a. Delete the subscriber record in the old VLR with the MAP operation Cancel Location. b. Send the CS subscription of this subscriber to the new VLR. For this the MAP operation Insert Subscriber Data can be used several times if necessary. 6. When the new VLR has acknowledged the whole CS subscription record, the HLR shall acknowledge the Update Location operation. With this the update within the core network is completed. 7. The new VLR shall now inform the UE about the success of the normal location update with the MM message Location Update Accept. In this message the new LAI and possibly a new TMSI shall be included. 8. If a new TMSI was inside the Location Update Accept message the UE has to send the MM message TMSI Reallocation Complete to acknowledge the new TMSI. This ends the location update.

- 40 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE
new VLR old VLR HLR

Location Update Request


( old [LAI,TMSI] )

Send Identification
( TMSI )

Authentication

Send Identification Ack


( IMSI, authentication data )

Update Location
( IMSI, MSC-no., VLR-no.)

Cancel Location
( IMSI )

Cancel Location Ack


()
Generic Location Update procedure (general case).

Insert Subscriber Data


( IMSI, CS subscription information )

Insert Subscriber Data Ack Location Update Accept


( new TMSI )

Update Location Ack


( HLR number )

TMSI Reallocation Comp.


()

figure 18 Normal location update with change of the VLR.

TECHCOM Consulting

- 41 -

TC 1160-4

UE-CN Protocols

From the point of the MM protocol the normal location update consists of the message Location Update Request which triggers the procedure. This message contains the following elements : location updating type : For a normal location update this is always set to normal location updating. old LAI and old TMSI or the IMSI instead, CKSN/KSI of the stored key set on the USIM, MS class-mark 1 : indicates which core network release is supported by the UE (release 99), its power capability class. MS class-mark 2 : this class-mark indicates several parameters that are necessary for inter-working GSM/UMTS, also indicated are special capabilities like LCS (location services), PS capabilities, SMS capabilities, etc.

The network can respond to this request either with Location Update Accept or Location Update Reject. In the accept message typically the new LAI, a new TMSI are included. The followon-proceed parameter enables the MSC to tell the UE that is already a CS mobile terminating service waiting.

- 42 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR

Location Update Request


( location updating type = normal location updating, old [LAI,TMSI] or IMSI, CKSN/KSI, MS classmark 1, MS classmark 2 )

Location Update Accept


MM Location Update MM messages with detailed parameters.

( new LAI, new TMSI or IMSI, follow-on-proceed, equivalent PLMNs )

or
Location Update Reject
( reject cause )

figure 19 Detailed picture of the normal location update message of MM.

TECHCOM Consulting

- 43 -

TC 1160-4

UE-CN Protocols

IMSI Attach The IMSI Attach procedure is the counterpart to the IMSI Detach procedure. In other words the aim of the IMSI Attach procedure is to inform the VLR that the UE is now switched on and reachable, so the VLR should reset the IMSI Detach flag that has been set before as result of the IMSI Detach. Therefore the trigger for a IMSI Attach requires several conditions to be fulfilled. In detail these conditions are : the UE is switched on, the ATT parameter in the system information that is broadcasted in the current cell is set, the location area identity of the current cell is the same LAI that is stored on the USIM.

In case the UE is switched on in a new location area a normal location update is performed. The IMSI Attach procedure looks similar to the normal location update procedure. The only difference is, that the location updating type in the Location Update Request message is set to IMSI attach. Of course there is no procedure part between VLR and HLR because the VLR is not changed.

- 44 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

System Information

(ATT = TRUE, LAI = LA Z) USIM EF LOCI (ID: H6F7E)


TMSI (4 byte) (old, stored) LAI = LA Z update status = updated

LA Z

UE

MSC/VLR

Location Update Request


( location updating type = IMSI Attach, ...)

Location Update Accept


MM IMSI Attach.

( ... )

figure 20 IMSI Attach procedure.

TECHCOM Consulting

- 45 -

TC 1160-4

UE-CN Protocols

Periodic location update The periodic location update is used in the following way. When the Iu signaling connection between MSC and serving RNC for a UE is terminated, the UE is informed about that (RRC message: Signaling Connection Release). The UE now starts timer T3212 with an initial value received from the system information that is broadcasted in the cell. Now there are two possibilities: 1. The UE establishes a new Iu signaling connection to the MSC before timer T3212 expires. In this case the timer is stopped. 2. If the timer T3212 expires the UE will perform a periodic location area update which looks like a normal location update, but the location update type is set to periodic update. The handling in the VLR is so that it counts the not performed periodic updates. When the UE is too long missing its subscriber record in the VLR is purged. This means the record is deleted and the HLR is informed about that. Of course mobile terminated services are no longer available for this UE.

- 46 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

System Information 1
( T3212 ) T3212 last network contact

MSC/VLR

Location Update Request


( location updating type = periodic update, ...)

Location Update Accept


( ... )
MM Periodic Update.

figure 21 Periodic location update.

TECHCOM Consulting

- 47 -

TC 1160-4

UE-CN Protocols

MM connection establishment The MM connection establishment has to be done before a circuit switched transaction is set up. In case of a mobile originating circuit switched transaction it is the UE that has to set up the MM connection. The UE will therefore send the MM message CM Service Request. This message contains the following: CM Service Type : With this element the UE demands a MM connection for MOC, emergency call, short message service, non call related supplementary service, voice group call service, voice broadcast service or location (positioning) service. CKSN/KSI : This indicates to the network which keys are currently stored on the USIM. MS class-mark 2: In this parameter the UE indicates its network service capabilities. TMSI or IMSI. priority.

The MSC will evaluate the CM Service Request message and check the VLR subscriber record whether the user is allowed to have the indicated category of service or not. If the network wants to acknowledge the MM connection it has two possibilities: 1. The MSC sends the MM message CM Service Accept. 2. The MSC activates the security features with the RANAP message Security Mode Command. In case the MSC wants to reject the MM connection request it shall send the MM message CM Service Reject.

- 48 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

RNC

MSC/VLR

CM Service Request
( CM service type, CKSN/KSI, MS classmark 2, TMSI or IMSI, priority )

CM Service Accept
( )
MM Connection establishment UE initiated MM connection.

CM Service Request
( CM service type, CKSN/KSI, MS classmark 2, TMSI or IMSI, priority ) RRC: Security Mode CMD RRC: Security Mode COM RANAP: Security Mode CMD RANAP: Security Mode COM

figure 22 MM connection set up for a mobile originated transaction.

TECHCOM Consulting

- 49 -

TC 1160-4

UE-CN Protocols

For the CCBS (Call Completion to Busy Subscriber) feature a special treatment of the MM connection is necessary. A subscriber can invoke the CCBS service when he gets a busy indication for a MOC. This means there is already a MM connection established for this MOC. But because the B-party is busy the connection is deactivated. The CCBS feature informs the MSC when the B-party is reachable again. Then the MSC re-establishes the MM connection from the MOC. This is done with the message CM Service Prompt. This message is sent to the UE and contains the protocol discriminator for the protocol that used the CCBS feature. On reception of the CM Service Prompt the UE immediately begins with higher layer signaling (e.g. call control) using the re-established MM connection.

- 50 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR

CM Service Prompt
( Protocol Discriminator = service to be re-started )
MM Connection establishment Network requested UE initiated MM connection.

CM message

figure 23 Mobile originated MM connection re-establishment.

TECHCOM Consulting

- 51 -

TC 1160-4

UE-CN Protocols

For mobile terminating circuit switched transactions the MM connection is set up implicitly by the MSC. This is simply done by sending a new downlink message from one of the protocols CC, SMS or SS with a new pair (PD,TI) inside.

- 52 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR

Any CM message (CC, SMS, SS)

TECHCOM Consulting

MM Connection establishment network initiated MM connection.

figure 24 Mobile terminating MM connection set up.

- 53 -

TC 1160-4

UE-CN Protocols

MM connection re-establishment after failures When a UE loses the radio link it can happen that the previously activated MM connections fail (e.g. timeouts). The MM protocol allows that these MM connections are re-established even in a new cell or location area. For this the UE simply has to send the MM message CM Reestablishment Request. The network should acknowledge the re-activated MM connection with CM Service Accepts or ciphering activation. If this is not possible the MSC should send CM Service Reject. Whether the re-activation of a MM connection makes sense or not usually depends on the higher layer. Typically there are only a very view possibilities to re-activate a call.

- 54 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

RNC

MSC/VLR

radio link failure

CM Re-establishment Request
( CKSN/KSI, MS classmark 2, [IMSI,LAI] or TMSI, )

CM Service Accept or ciphering activation


MM connection re-establishment..

figure 25 Re-activation of MM connection after radio link failure.

TECHCOM Consulting

- 55 -

TC 1160-4

UE-CN Protocols

Paging The paging procedure is used to find a UE. Therefore the information from the location updates is used. Therefore the paging procedure is considered to be part of the MM protocol. But the signaling messages typically come from RANAP and other protocols. Paging is triggered by the MSC because of the following two conditions: there is no Iu signaling connection (SCCP connection) for this UE and there is an incoming service request for this UE.

The paging from the core network is considered as a request for the missing SCCP connection on the Iu interface. Therefore the UE will receive this paging as RRC message from the RNC (paging co-ordination) and should set up the Iu signaling connection with the NAS message Paging Response. Well this message comes historically from the GSM RR (Radio Resource) protocol. For compatibility reasons it is also in UMTS used as answer to the paging. Note that currently many manufactures work on a feature called pre-paging. Prepaging means, that the core network sends a paging message without an incoming service. Mainly this will be used either to test whether the UE is reachable or not or to get the exact position of the UE.

- 56 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

RNC

MSC/VLR

RRC : Paging Type 1 or 2

RANAP : Paging

RR : Paging Response
( CKSN, MS classmark 2, TMSI or IMSI )

TECHCOM Consulting

Paging.

figure 26 Paging procedure for circuit switched services.

- 57 -

TC 1160-4

UE-CN Protocols

2.4.

CC procedures

Mobile Originated CS Call The mobile originated call is done in the following way: 1. The UE has to request a new MM connection before any CC signaling can begin. Therefore the UE sends the MM message CM Service Request to the MSC, inside of this message the UE has to indicate the type of service that is requested. 2. Optionally the network can now perform an authentication. The response to the CM Service Request Message is the activation of ciphering (or the MM message CM Service Accept). 3. When the MM connection exists the UE can begin with the service related signaling of CC protocol. To trigger the call set up the UE shall send the CC message Setup to the MSC. The Setup message contains all information about the requested call, like called party number, requested bearer capability. 4. The MSC checks now the data whether the service is allowed for the subscriber and whether the network has the requested capabilities. If this is o.k. the network will acknowledge the Setup message with the CC message Call Proceeding. Together with this the MSC begins call routing through the CS core network. 5. If the B-party is reachable, the MSC will send the CC message Alerting to the UE. 6. If the B-party accepts the call the initial UE will be informed by the CC message Connect, which has to be acknowledged with Connect Acknowledge. Now the call is active.

- 58 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR CM Sevice Request


( CM Service Type = MOC establ. or Emergency Call establ. )

authentication/ciphering activation (Emergency) Setup


( bearer capability, called party BCD number )

Call Proceeding
( bearer capability )

Alerting Connect Connect Acknowledge


MOC set up.

figure 27 MOC message flow.

TECHCOM Consulting

- 59 -

TC 1160-4

UE-CN Protocols

Mobile Terminated CS Call The mobile terminated call begins with an incoming call for the UE. Possibly paging has to be performed to get an Iu signaling connection for this UE. The higher layer signaling looks like the following: 1. When Iu signaling connection exists, the network can perform authentication and ciphering activation. 2. The MSC then begins immediately with the CC signaling by sending the CC message Setup to the UE. This Setup message contains a new (PD,TI) pair and implicitly establishes a new MM connection. Additionally the Setup message contains parameters like the requested bearer capability. It is also possible to indicate special signals (e.g. dial tone, ring back tone, answer tone) to the UE. 3. The UE shall now check the received data and decide whether this call service can be provided or not. If yes the UE shall acknowledge the Setup message with the CC message Call Confirmed. 4. After the confirmation the UE shall begin to alert the called subscriber (e.g. alerting tone or vibration alert) and shall send the CC message Alerting to the MSC. This alerting means the UE is reachable. 5. When the called subscriber accepts the call (by pressing OK) the UE must send the CC message Connect and the MSC will answer with Connect Acknowledge. The call is now active. If the UE is busy in the moment, but the call set up is allowed (set calls on wait or hold), the UE shall include a busy indication into the Call Confirmed message. If the UE is busy and because of this the call cannot be accepted the UE shall send the CC message Release Complete instead of the Call Confirmed message.

- 60 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR authentication/ciphering activation Setup


( bearer capability, signals )

Call Confirmed
( bearer capability, user busy indication )

Alerting Connect Connect Acknowledge

TECHCOM Consulting

MTC set up.

figure 28 MTC set up.

- 61 -

TC 1160-4

UE-CN Protocols

Network initiated MOC (CCBS) When a subscriber activates a MOC and the called party is busy, the network might offer the CCBS feature (Call Completion to Busy Subscriber). This feature automatically re-activates the call (MOC) when the B-party is reachable again. This feature is optional to be supported in UE and network. The CC protocol supports this in the following way. 1. After the failed MOC the UE is waiting. When the network gets the information that the B-party is reachable again it will re-activate the MM connection of the failed MOC. Therefore the MSC sends the MM message CM Service Prompt. This message contains the PD for the CC protocol (d3) and the TI for the failed MOC. 2. The MM connection is now re-activated. The UE will first have to indicate that it restarts the corresponding CC entity that handled the initial MOC. This is done by the CC message Start CC. This message is a request from UE to MSC for the call data that have been used for the failed MOC. 3. The MSC will respond to the Start CC message with the CC message CC Establishment. In this message all parameters for the Setup message of the call-back are included. The UE has to acknowledge this with the CC message CC Establishment Confirm. 4. Now the UE has re-activated and re-configured the CC entity that handles the MOC. The MSC gives now the trigger to begin with the MOC call set up again, this is done by sending the CC message Recall. 5. On reception of the Recall message the UE begins again with a call set up starting with CC message Setup.

- 62 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR CM Service Prompt


( Protocol Discriminator = d3, TI )

Start CC
( CC capabilities )

CC Establishment
( Setup parameter container )

CC Establishment Confirm Recall Setup


Network initiated MOC.

...

MOC

figure 29 Re-establishment of a failed MOC with CCBS (network initiated MOC).

TECHCOM Consulting

- 63 -

TC 1160-4

UE-CN Protocols

Call Release The call release is also controlled by CC protocol and is the same for MOC and MTC. One has to distinguish between: local (forward) release : The release is triggered from the selected call party. remote (backward) release : The release is triggered from the other party.

The release works always in two steps : 1. Disconnect : The Disconnect message of the CC protocol terminates the call connection, but does not release the call itself. This behavior is important for IN (Intelligent Network) controlled calls, because with IN it is possible that a call is connected several times to different destinations (e.g. announcements). 2. Release : The Release message of CC protocol terminates the transaction and with this the associated MM connection. The release is therefore the absolute end of a call. It is possible to send the Release message without Disconnect, because every call user connection is of course terminated together with the MM connection. The Release message must be acknowledged with Release Complete.

- 64 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR
local release

Disconnect Release Release Complete

remote release

Disconnect Release Release Complete

figure 30 Call clear down.

TECHCOM Consulting

Call release.

- 65 -

TC 1160-4

UE-CN Protocols

In-call modification It is possible to modify a call during it is running. The modification concerns bearer capabilities, lower and higher layer compatibilities. So it is possible to change from speech to facsimile and back. It is not possible to modify the called party characteristics (e.g. called party number, etc.). The modification can be triggered by the originating party only, this is because it is usually the calling party that pays for the call. The modification is performed by two messages from CC protocols: Modify and Modify Complete. The originating party sends Modify to the MSC and the MSC checks whether the modification is possible and allowed. The B-party gets the same Modify message and can also check. If the modification can be performed the called UE sends back Modify Complete and this is forwarded to the calling party.

- 66 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR local modification (only MOC) Modify


( bearer capability, low and higher layer compatibility )

Modify Complete
( bearer capability, low and higher layer compatibility )

remote modification Modify


( bearer capability, low and higher layer compatibility )

Call Modification.

Modify Complete
( bearer capability, low and higher layer compatibility )

figure 31 In-call modification.

TECHCOM Consulting

- 67 -

TC 1160-4

UE-CN Protocols

DTMF tone interaction The basic implementation of user interaction in UMTS and GSM is the DTMF (Dual Tone Multi-Frequency) feature. In ISDN network this is done such that when the user presses a keypad on the keyboard during the call is running a signal consisting of two frequencies is sent to the network. The MSC can analyze the signal and then trigger some operator or subscriber specific actions. In GSM/UMTS the usage of the radio channel in this way is too expensive and difficult because of the speech codecs. Hence the pressing of a keypad during the call is running is here indicated with CC protocol signaling messages. When the user presses a keypad the CC message Start DTMF is sent to the network, the message contains the digit of the keypad. The network will acknowledge this with Start DTMF Acknowledge. When the user releases the keypad the CC message Stop DTMF is sent. The MSC again has to acknowledge with Stop DTMF Acknowledge. With this mechanism even the duration of the tone can be indicated.

- 68 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

MSC/VLR successful call set up call active keypad pressed Start DTMF
( digit )

Start DTMF Ack


( digit )

call active keypad released


DTMF interaction within a CS call.

Stop DTMF Stop DTMF Ack

figure 32 DTMF tone interaction with CC protocol.

TECHCOM Consulting

- 69 -

TC 1160-4

UE-CN Protocols

2.5.

Complete Call Control Sequences

MOC (no Off Air Call Setup) The complete sequence for a MOC establishment can be decomposed in the following three big steps: 1. Access Request and Call Request 2. RAB establishment and Call Completion 3. Call Disconnection and clear down In the message sequence charts shown are the UE, the RNC, MSC, VLR and next switch. The interface between MSC and VLR is of course internal, but is shown here to explain the functionality. Note that real implementation of MSC-VLR interface are usually completely different due to scalability issues. The first part of the MOC is the access request and call request. This is done with the following steps: a. The first thing the UE has to do is to request the MM connection. Therefore it sends CM Service Request to the MSC. The MSC will now request the VLR to return all needed data to process this access request. This data covers whether the subscriber is allowed to use MOC, whether authentication must be performed and whether security features shall be activated or not. Of course the VLR also delivers the authentication data to the MSC. When the MSC has done all tasks the MM connection is established by activation of the security features. b. The UE can now request the call itself. This is of course done using the Setup message. On reception of this Setup message the MSC has to check again whether the user can have this service or not. Therefore the MSC need information for the outgoing (SIFOC: Send Information For Outgoing Call). For example the call barring settings must be checked here. The VLR sends the information for the outgoing call as Complete Call command to the MSC, which therefore acknowledges the Setup message with Call Proceeding.

- 70 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

RNC
UE
radio access and RRC connection set up

MSC

VLR

next switch

CM Service Request Authentication Request Authentication Response

Process Access Request Authenticate Authenticate Ack Start Security

MOC complete procedure 1(3) call and access request.

Security Mode Command Security Mode Complete

Security Mode Command Security Mode Complete

Process Access Request Ack

Setup Call Proceeding

SIFOC Complete Call

figure 33 MOC 1(3): Access request and call request.

TECHCOM Consulting

- 71 -

TC 1160-4

UE-CN Protocols

The MSC can now begin with call processing. This means two things are done concurrently: c. Radio Access Bearer establishment: The MSC uses RANAP to allocate the needed transport resources from UE to MSC. The well known RANAP message RAB Assignment Request is used for that. This procedure triggers the set up of link transport bearer services on Iu (AAL 2 virtual circuit), on Iub (AAL 2 virtual circuit for the transport frames of MAC) and on Uu (radio bearer with a dedicated channel). If all bearers are allocated the RAB Assignment Response message will come. d. Call Processing: The call processing begins in the MSC immediately with the Call Proceeding message. First digit analysis is performed using the information from the Setup message (called party number). If the next destination is found, the MSC sends the ISUP message IAM (Initial Address Message) to the next switch. Then the MSC waits. First it will be indicated that the B-party is reachable with the ISUP message ACM (Address Complete Message). This triggers the CC message Alerting to the calling UE. Then the MSC waits for the B-party to accept the call. This is indicated with the ISUP message ANM (Answer Message). The answer message triggers the CC message Connect to the UE which acknowledges with Connect Acknowledge. Now the call is active.

- 72 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

RNC
UE

MSC

VLR

next switch

Radio Bearer Setup


MOC complete procedure 2(3) bearer allocation, ISUP procedure and call establishment completion.

RAB Assignment Request

Radio Link Setup


Radio Bearer Setup Complete

Iu Bearer Setup
RAB Assignment Response ISUP: IAM

Alerting

ISUP: ACM

Connect Connect Acknowledge

ISUP: ANM

Call active

figure 34 MOC 2(3): Radio access bearer setup and call completion.

TECHCOM Consulting

- 73 -

TC 1160-4

UE-CN Protocols

The last step in the live cycle of a call is the clear down. e. The calling party in this case releases the call with the CC message Disconnect. This message triggers two things in the MSC. First the CC message Release will be sent to the UE and the message Release Complete is expected as response. Second the MSC releases the speech call in the forward direction to the next switch with the ISUP message REL (Release). The switch has to acknowledge with RLC (Release Complete). f. After the call has been released the radio access bearer and the associated SCCP connection can be released (if this is the last CS transaction). Instead of making individual procedures for both things it is possible simply to use the RANAP message Iu Release Command which clears down the Iu signaling connection and all associated Radio Access Bearers.

- 74 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

RNC
UE

MSC

VLR

next switch

Disconnect

Release Release Complete

ISUP: REL

ISUP: RLC

MOC complete procedure 3(3) call disconnection from A party.

Radio Bearer Release

Iu Release Command

Radio Link Release


Radio Bearer Release Complete Signalling Connection Release

Iu Bearer Release

Iu Release Complete

figure 35 MOC 3(3): Call clear down and resource release.

TECHCOM Consulting

- 75 -

TC 1160-4

UE-CN Protocols

MTC (no Off Air Call Setup, no pre-paging) MTC complete message sequence can be divided into the following three big steps: 1. Interrogation and access request, 2. Call request and call completion, 3. call clear down. The first step is in detail : a. A GMSC (Gateway MSC) receives the incoming call request via ISUP message IAM. The IAM message contains as called party number a MSISDN. It is up to the GMSC to detect that this called party address is really a MSISDN and not a normal ISDN. The effect of this detection is that the GMSC starts interrogation. It uses the MSISDN as routing address to find the HLR of the called subscriber. The MAP operation Send Routing Info is sent to the HLR. The HLR will look into the subscriber record and send the MAP message Provide Roaming Number to the current serving VLR. The VLR shall now allocate a MSRN (Mobile Station Roaming Number). This MSRN is returned back to HLR and from here sent to the GMSC. b. The GMSC now uses the MSRN to route the call to the visited MSC of the called party using IAM message from ISUP. When the MSC receives this IAM it detects its own MSRN and asks the VLR for further instructions with SIFIC (Send Information For Incoming Call). c. The VLR will advise the MSC to page the UE. Hence there will be the RANAP message Paging to be seen. The UE when it receives the paging shall establish radio access and send the Paging Response message back to the MSC. d. Now the MSC must check which tasks have to be performed to process the access request of the UE. Therefore the VLR is requested to send all access relevant data to the MSC (e.g. authentication data which is not needed here, CK, IK). In the example only the security features are activated.

- 76 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

GMSC

HLR

MSC

VLR

RNC
UE

IAM

Send Routing Info Send Routing Info Ack IAM

Provide Roaming Number Provide Roaming Number Ack SIFIC Page MS Paging Paging Type 1or 2 radio access Paging Response Process Access Request Start Security Process Access Request Security Mode Command Security Mode Command Security Mode Complete

MTC complete procedure 1(3) interrogation, call routing and paging.

Security Mode Complete

figure 36 MTC 1(3): Interrogation and access request.

TECHCOM Consulting

- 77 -

TC 1160-4

UE-CN Protocols

Step 2 of the MTC is divided into the following steps: e. Call request: Now that the access is successfully processed the VLR will tell the MSC to complete the call. Therefore the MSC sends the CC message Setup to the UE which checks the data for not supported features. If everything is o.k. the UE shall send the CC message CC Confirmed. f. Now the MSC will set up the radio access bearer using RANAP message RAB Assignment Request. Again this triggers transport bearer setup procedures on Iu, Iub and Uu. g. When everything is provided the UE can send the CC message Alerting to indicate that it is ready for the call. This Alerting message triggers in the MSC the ISUP message ACM (Address Complete) which is sent to the GMSC and so on. h. When the B-party accepts the call by pressing the OK button, the called UE will send CC message Connect and the MSC acknowledges with Connect Acknowledge. But the Connect message also triggers the ISUP message ANM (Answer Message) which is sent back up to the originating switch. The call is active. This is also reported to the VLR, because the MSRN that had been used for this MTC can used now for new MTCs.

- 78 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

GMSC

HLR

MSC

VLR

RNC
UE

Complete Call Setup Call Confirmed RAB Assignment Request Radio Bearer Setup

Iu Bearer Setup
RAB Assignment Response

Radio Link Setup


Radio Bearer Setup Complete

ACM
MTC complete procedure 2(3) call set up.

ACM

Alerting

ANM

ANM

Connect Connect Acknowledge Complete Call Ack

Call active

figure 37 MTC 2(3): Call request and call completion.

TECHCOM Consulting

- 79 -

TC 1160-4

UE-CN Protocols

Again the last step of the call is the clear down. i. In the example the calling party releases the call. This is indicated by the ISUP message REL (Release) which is received by the GMSC and is forwarded to the MSC that serves the called party. The REL message triggers two things. First the ISUP message RLC (Release Complete) is sent back as acknowledgement of the REL. Second the MSC sends the CC message Disconnect to the UE. In this Disconnect message the MSC could indicate that the call itself shall not be released (Progress Indication), but this is here not the case (usually used with IN calls). j. In the example the UE immediately sends the CC message Release and the MSC answers with Release Complete. With this the speech channel and the call control instance for this call can be terminated. k. In the example this call is the only CS transaction for this UE, so the Iu signaling connection and all associated radio access bearers can be released. Again this is done with the RANAP message Iu Release Command.

- 80 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

GMSC

HLR

MSC

VLR

RNC
UE

REL RLC

REL Disconnect Release Release Complete Iu Release Command Radio Bearer Release

RLC

MTC complete procedure 3(3) call disconnection from B party.

Iu Bearer Release

Radio Link Release


Radio Bearer Release Complete

Iu Release Complete

Signalling Connection Release

figure 38 MTC 3(3): Call clear down.

TECHCOM Consulting

- 81 -

TC 1160-4

UE-CN Protocols

- 82 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

3 GMM and SM protocol

TECHCOM Consulting

- 83 -

TC 1160-4

UE-CN Protocols

3.1.

Tasks of GMM and SM protocol

The protocols GMM (GPRS Mobility Management) and SM (Session Management) are used between the UE and packet switched core network domain. So they are terminated in UE and SGSN. The GMM protocol provides the mobility management related to the packet switched core network domain. It has the following tasks: Routing Area Update: The routing area update keeps the information in VLR and HLR with respect to the current location up to date. This effects also the routing of packet switched user data to new locations. GPRS Attach and Detach: These procedures register and deregister the UE for PS services. P-TMSI Reallocation: The P-TMSI has the same functionality as the TMSI but is used in the SGSN instead of VLR. Therefore like the TMSI the P-TMSI must be reallocated from time to time. Service Request: The service request message triggers the access request in the SGSN. This means before the UE can establish a new PDP context or can request a new RAB, the UE has to request the service on GMM level. This can be compared to the CM Service Request message from the MM protocol, but note that there is no such thing like a GMM connection. Authentication: Because of the independence of CS and PS core network domain also the GMM protocol provides an authentication procedure. The mechanism is the same as the MM protocol authentication. combined MM/GMM procedure: When the Gs interface is present, the UE can trigger a GMM procedure and within this procedure the UE can also request a MM procedure. This will be further explained in the section about BSSAP+ and the Gs interface.

The GMM protocol is terminated in UE and SGSN. Within the core network the protocols GTP-C, BSSAP+ and TCAP/MAP will be used for inter-working with GMM.

- 84 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

HLR, EIR

MAP
UE

GMM
SGSN

GTP-C
BSSAP+

SGSN, GGSN VLR

Routing Area Update

Service Request

GPRS Attach/Detach

Authentication
Combined MM/GMM procedures

PTMSI (re-)allocation
GMM tasks.

figure 39 GMM protocol tasks.

TECHCOM Consulting

- 85 -

TC 1160-4

UE-CN Protocols

The SM (Session Management) protocol controls the PDP contexts. There is an essential difference between CS calls and the PDP contexts. A call is a complete telecommunication service, whereas a PDP context is only a transport bearer service that enables the transfer of packet oriented user data between UE and GGSN. The packet user data is simply tunneled through the PDP context. The tasks of the SM protocol are: Activation of PDP contexts: A PDP context is established as packet transport bearer between the UE and an external service provider identified by an Access Point Name APN. A PDP context is used to tunnel exactly one protocol for the external data network, this protocol is called the Packet Data Protocol (PDP). Because all relevant packet data protocols (specified are IP and PPP) need addresses for data transfer the UE gets for an activated PDP context a so called PDP address. This address identifies the UE in the external network. Activation of secondary PDP contexts: If several data streams with different quality of service requirements are needed it is possible to set up additional PDP contexts for the same APN and PDP address. Deactivation of PDP contexts, PDP context modification.

The SM protocol is terminated in UE and SGSN. Between SGSN and GGSN the GTP-C protocol takes over the SM tasks.

- 86 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SM
SGSN

GTP-C

GGSN

Activation of PDP contexts

Activation of secondary PDP contexts

Deactivation of PDP contexts

PDP context modification

TECHCOM Consulting

SM tasks.

figure 40 SM tasks and protocol termination.

- 87 -

TC 1160-4

UE-CN Protocols

3.2.

MM sub-layer states for PS CN domain

The MM sub-layer defines three different states for the PS core network domain GMM protocol: PMM Detached: In this state the UE is not registered for PS services. This means in detail The UE has no valid network information, because it is not listening to the broadcasted system information. No SGSN possesses a valid subscriber record for this UE. The HLR has no valid SGSN number stored for this UE (note that there might be a not updated SGSN number stored). PMM Connected: In this state there is an Iu signaling connection for the UE and the following distribution of information is applicable: The UE listens to the system information coming from the serving RNC and thus has valid network information stored on the USIM. The SGSN that terminates the Iu signaling connection has a valid subscriber record for this UE. The HLR has stored the number of the SGSN that possesses the valid subscriber record. PMM Idle: The PMM Idle state is characterized by the fact that there is no Iu signaling connection for this UE, but the distribution of location information is the same as for the PMM Connected state: The UE listens to the system information broadcast and thus has valid network information stored on the USIM. The SGSN that serves the routing area of the UE has a valid subscriber record and knows the routing area identity for the UE. The HLR has stored the number of the SGSN that possesses the valid subscriber record.

In PMM Idle state the UE is known by the SGSN on the level of routing areas, to reach the UE the SGSN must perform paging. In PMM Connected state the SGSN knows the UE on the level of the serving RNC (the cell is not known by the SGSN). Hence paging in PMM Connected state will never come from the SGSN. In contrast to the CS core network domain where a service can be active only when an Iu signaling connection exists, a PDP context can be active in PMM Connected and PMM Idle. The only thing that is not possible is to have a radio access bearer in PMM Idle state.

- 88 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

PMM_Detached Detach, PS Attach Reject, RAU Reject PS Attach

implicit Detach

PS Signalling Connection Release


MM sub-layer states for PS core network domain.

PMM_Idle PS Signalling Connection Setup

PMM_Connected

S-RNC relocation

figure 41 MM sub-layer states.

TECHCOM Consulting

- 89 -

TC 1160-4

UE-CN Protocols

3.3.

GMM procedures

General overview about GMM procedures The GMM protocol divides its procedures into two groups: GMM common procedures: GMM common procedures can be invoked only when an Iu-PS signaling connection exists. GMM specific procedures: GMM specific procedures can be invoked at any time. They may be the trigger to establish an Iu-PS signaling connection if there was none.

As long as a GMM procedure is running any signaling procedures of SM and SMS protocol are suspended.

- 90 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

GMM procedures

GMM common procedures Pre-requisites :


Iu-PS signalling connection exists. (PMM Connected)

GMM specific procedures Pre-requisites :

Procedures :

Procedures : GPRS Attach GPRS Detach Routing Area Update Periodic Area Update Service Request

P-TMSI Reallocation Authentication Identification Information


GMM procedures.

SM and SMS procedures are suspended during any GMM procedure.

figure 42 GMM procedures.

TECHCOM Consulting

- 91 -

TC 1160-4

UE-CN Protocols

Authentication The authentication of the GMM protocol works in the same as the authentication for the MM protocol. The GMM authentication is triggered by the SGSN with the GMM message Authentication And Ciphering Request. The message name has historical reasons, because in 2G the message not only performed authentication but also triggered ciphering. This is not the case for UMTS. In UMTS the GMM authentication is used for subscriber identity verification only. The GMM message Authentication And Ciphering Request contains the RAND (random number = challenge) and the AUTN ( Authentication Token). These parameters have the same meaning as in the CS core network domain. Additionally the message contains the KSI (Key Set Identifier) that is used to label the keys IK and CK calculated out of the RAND and AUTN. When the UE receives the message it will check the validity of the authentication data and calculate RES (Response), IK and CK. The RES value shall be sent back to the SGSN using the GMM message Authentication And Ciphering Response. In request and response message an A&C reference is contained. This element is used to assign request message and response message to each other.

- 92 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN

Authentication And Ciphering Request


( CKSN=KSI, RAND, AUTN, A&C reference )

Authentication And Ciphering Response


( RES, A&C reference )

Packet Switched Authentication and keys.

USIM EF KeysPS (ID: H6F09)


KSI (1 byte) CK (16 byte) IK (16 byte)

figure 43 GMM authentication.

TECHCOM Consulting

- 93 -

TC 1160-4

UE-CN Protocols

P-TMSI Reallocation The P-TMSI reallocation can be part of routing area update or attach procedure, but also an explicit procedure is available. In this case the SGSN sends the GMM message P-TMSI Reallocation Command to the UE. In the message the SGSN shall indicate the new P-TMSI, the associated routing area identity RAI and a P-TMSI signature. The P-TMSI signature is some kind of an electronic signature of the SGSN for the P-TMSI. At attach or routing area update procedures the SGSN can request the UE not only to send the P-TMSI but the P-TMSI signature too. This shall provide a higher security against network attacks with a P-TMSI intercepted from the radio interface. The UE shall store the P-TMSI together with the RAI and the P-TMSI signature on the USIM. Then the UE shall acknowledge with P-TMSI Reallocation Complete.

- 94 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN

P-TMSI Reallocation Command


( P-TMSI, RAI, P-TMSI signature )

P-TMSI Reallocation Complete


()

USIM EF PSLOCI (ID: H6F73)


P-TMSI (4 byte) P-TMSI Signature (3 byte)
PTMSI reallocation.

RAI (6 byte)
routing area update status (1 byte)

figure 44 P-TMSI reallocation.

TECHCOM Consulting

- 95 -

TC 1160-4

UE-CN Protocols

Identity Request If the SGSN explicitly needs one of the following identifiers: IMSI, IMEI, IMEISV, TMSI

from the UE it can send the GMM message Identity Request. Inside of the message the type of requested identity must be indicated. The UE shall respond with Identity Response with the identifier inside.

- 96 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN

Identity Request
( requested identity type )

Identity Response
( IMSI | IMEI | IMEISV | TMSI )

TECHCOM Consulting

Identification procedure.

figure 45 Identity request procedure.

- 97 -

TC 1160-4

UE-CN Protocols

GMM Information The GMM information procedure can be used by the SGSN to provide the UE with additional information about the network. This information is not relevant for the protocol behavior of the UE but can be displayed to the subscriber. The implementation of the GMM information message is optional in network and UE. The GMM Information message can contain full name of network operator, short name of network operator, local time zone, universal time, network daylight saving time, localized service area (LSA) identity.

- 98 -

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN

GMM Information
( full name for network, short name for network, local time zone, universal time, network daylight saving time, LSA identity )

TECHCOM Consulting

GMM Information procedure.

figure 46 GMM information procedure.

- 99 -

TC 1160-4

UE-CN Protocols

GPRS Attach The GPRS attach procedure is used to register the UE for packet switched services in the network. (It is important to see the difference between IMSI Attach which only indicates power on and GPRS Attach.) Therefore the GPRS attach establishes that is called the GMM Context. The GMM context describes the synchronization of information elements in the following data bases: USIM: The USIM stores information about the network. So it keeps the current RAI with the corresponding P-TMSI. SGSN: The SGSN keeps a subscriber record where a the current RAI of the UE is stored together with the PS subscription data. HLR: The HLR stores the address (IP) and number (ISDN) of the SGSN that currently serves the subscriber in the permanent subscriber record.

If one compares this with the definition of the MM sub-layer states for the PS core network domain, it becomes clear that the GMM context exists for the state PMM_Connected and PMM_Idle only. To establish a GMM context when there is none means therefore to go from PMM_Detached to PMM_Connected and PMM_Idle. The associated signaling procedure is triggered by the GMM protocol and is called the GPRS Attach procedure.

- 100

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

RA 1 RA 2

RA 3

RAI = MCC + MNC + LAC+RAC IMSI = MCC + MNC + MSIN MSISDN = CC + NDC + SN
IMSI / MSISDN

UE

PMM connected or PMM idle

SGSN
IMSI Subscriber record - PS Service data - RAI

HLR
IMSI Subscriber record - Service data - SGSN no. (E.164) - SGSN IP Address

TECHCOM Consulting

MM Context for GMM.

figure 47 GMM context.

- 101

TC 1160-4

UE-CN Protocols

The complete sequence of a GPRS Attach can be seen on the next figure. On request of the subscriber or some application software on the UE the UE will perform the procedure in the following steps: 1. The UE sends the GMM message Attach Request to the SGSN. In the message the UE should indicate its own identity which can be IMSI or the pair (P-TMSI,RAI) from the last network contact. 2. The new SGSN has now the task to translate the P-TMSI into the IMSI. But this can be done in the old SGSN that allocated the P-TMSI only. Hence the new SGSN first gets the old SGSN IP-address from the old RAI using a DNS (Domain Name System) and then sends the GTP-C message Identification Request with the P-TMSI inside. The old SGSN returns the IMSI and the authentication data with the GTP-C message Identification Response. 3. Now the new SGSN has IMSI and can perform authentication with the received authentication data. If authentication is successful the new SGSN will trigger the update of the HLR data base using the MAP operation Update GPRS Location. Inside of this message the IMSI and SGSN number and SGSN address are indicated. Two things will happen now concurrently: a. The HLR will delete the subscriber record in the old SGSN using the MAP operation Cancel Location. b. The HLR will fill the subscriber record in the new SGSN with the PS subscription data using the MAP operation Insert Subscriber Data. This operation can be used several times, each time the new SGSN will acknowledge the received data. When this is completed the HLR will indicate the end of the update with the acknowledgement for the Update GPRS Location operation. 4. Now the new SGSN can accept the attach to the UE using the GMM message Attach Accept. This message usually contains a new P-TMSI and the current routing area identity RAI. 5. If a new P-TMSI was assigned to the UE it has to acknowledge this P-TMSI with the GMM message Attach Complete. With this the UE is registered to the network for PS services. At the beginning of this procedure the UE was in state PMM_Detached. At the end the UE is in state PMM_Connected (an Iu signaling connection was used for the signaling procedure) and will go now to state PMM_Idle when the Iu signaling connection will be released. If the UE wants to immediately make another procedure after the attach (e.g. PDP context activation) then the UE can also stay in state PMM_Connected.

- 102

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

(Note that the HLR update occurs also when old and new SGSN are the same.)

UE
new SGSN old SGSN HLR

Attach Request
( old [LAI,PTMSI] )

Identification Request
( PTMSI )

Authentication

Identification Response
( IMSI, authentication data )

Update GPRS Location


( IMSI, SGSN-no., SGSN-IP-address)

Cancel Location
( IMSI, type=update )
GPRS Attach (case with two SGSN, without combined attach).

Cancel Location Ack


()

Insert Subscriber Data


( IMSI, PS subscription information )

Insert Subscriber Data Ack

Attach Accept
( new PTMSI, new RAI )

Update GPRS Location Ack


( HLR number )

Attach Complete
()

figure 48 GPRS attach procedure.

TECHCOM Consulting

- 103

TC 1160-4

UE-CN Protocols

The GMM part of the procedure consists of three messages only: Attach Request: The Attach Request message is the trigger of the whole procedure. It must contain a user identity (IMSI or P-TMSI with RAI). If the UE has stored a P-TMSI signature it shall include it too. The attach type parameter can be used to indicate a combined MM/GMM procedure and will be explained later. The UE also will indicates its network and radio access capabilities. Attach Accept: This message is sent from the SGSN to the UE and indicates a successful update to the HLR. It usually contains a new P-TMSI with the new RAI. The P-TMSI signature is an optional element to be included by the SGSN. In the same way like in the CS domain there are periodic updates to be performed by the UE. The periodic update timer value for the PS core network domain is part of the Attach Accept message. (Note that the CS periodic update timer value was part of the system information.) The parameters new TMSI and attach result will be explained in the section about combined GMM/MM procedures. Attach Complete: The Attach Complete message is used to acknowledge new P-TMSI (and possibly new TMSI) from the Attach Accept message.

- 104

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN

Attach Request
( MS network capability, attach type, CKSN, P-TMSI signature, old RAI, P-TMSI or IMSI, MS radio access capability )

Authentication

Attach Accept
( new P-TMSI, new RAI, P-TMSI signature, periodic update timer, attach result, equivalent PLMNs, new TMSI )

GPRS Attach GMM messages.

Attach Complete

figure 49 GMM message details for attach procedure.

TECHCOM Consulting

- 105

TC 1160-4

UE-CN Protocols

UE initiated detach If the UE wants to de-register from the PS core network domain it can use the GPRS Detach procedure. This procedure destroys the GMM context, deletes all activated PDP contexts and brings the UE to state PMM_Detached. The procedure has the following steps: 1. On request of the subscriber or some software application on the UE the UE will send the GMM message Detach Request to the SGSN. Inside of the message the UE shall identify the subscriber with IMSI or P-TMSI. Also the UE has to indicate whether it will be switched off or not after the Detach Request message. 2. The SGSN can optionally perform authentication now. 3. Then the SGSN should delete all active PDP Contexts. This will be done with the GTP-C message Delete PDP Context Request which will be sent to the GGSN that terminates the PDP Context. This message contains a TEID (Tunnel Endpoint Identifier) that is used by the GGSN to identify the PDP Context. The GGSN responds with Delete PDP Context Response. This message pair deletes one and only one PDP Context. If several PDP Contexts have been activated this procedure must be repeated several times. 4. If the UE is not switched off, the SGSN sends the GMM message Detach Accept to the UE. This ends the procedure and the UE is now in state PMM_Detached, no PS services are available any more.

- 106

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE
SGSN GGSN

Detach Request
( P-TMSI, P-TMSI signature, switch off indicator)

Authentication Delete PDP Context Request


( TEID )

Delete PDP Context Response


( TEID )

Detach Accept
GPRS Detach (UE initiaated detach)

figure 50 UE initiated detach.

TECHCOM Consulting

- 107

TC 1160-4

UE-CN Protocols

Network initiated detach Also the network can trigger the detach of the packet switched attached subscriber. The figure on the next side shows the case that the operator deletes the PS subscription in the HLR. 1. The HLR now sends the MAP operation Cancel Location with the cancellation type se to subscription withdrawn. 2. This special type triggers the SGSN to detach the subscriber with the GMM message Detach Request. This message contains a parameter that indicates whether the UE shall try an automatic re-attach or not (re-attach required parameter). 3. Then the SGSN shall delete all activated PDP contexts with the GTP-C message Delete PDP Context Request which is sent to the corresponding GGSN of the PDP context. The GGSN will acknowledge with Delete PDP Context Response. Again this pair of messages must be repeated for each active PDP Context. 4. The UE will acknowledge the Detach Request message with a Detach Accept message. 5. Now the SGSN can acknowledge the invoked Cancel Location operation of MAP to the HLR.

- 108

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE
SGSN HLR GGSN

Cancel Location
( IMSI, type = subscription withdrawn )

Detach Request
( Cause, re-attach required? )

Delete PDP Context Request


( TEID )

Delete PDP Context Response


( TEID )
Network initiated detach (here from HLR)..

Detach Accept
()

Cancel Location Ack


()

figure 51 Network initiated detach triggered by HLR because of subscription deletion.

TECHCOM Consulting

- 109

TC 1160-4

UE-CN Protocols

Routing Area Update for UE in PMM_Idle state When a UE is in PMM_Idle state there is no SCCP connection on Iu-PS. This UE gets the network system information either from the system information broadcast (UE has no RRC connection) or it gets the information directly from its serving RNC (US has a RRC connection). Important is that there is no radio access bearer allocated for the PS core network domain with respect to this UE because there is no SCCP connection. In case the UE has no RRC connection it performs cell re-selections based on radio quality measurements and gets new system information all the time the cell is changed. If the UE has a RRC connection it is the serving RNC that decides which system information the UE will get. In the received system information the routing area identity for the UE to be used is encoded. 1. When the UE detects that the RAI of the new cell is different from the RAI stored on the USIM it will trigger a routing area update. This signaling procedure of GMM is done between UE and the SGSN of the new cell. 2. The new SGSN will now create a new subscriber record for this UE and will store the RAI for this UE. Additionally the SGSN will get all the PS subscription data from the HLR of the UE. 3. The HLR will update its own permanent record for the UE, in other words the new SGSN number and address will be stored. 4. The HLR will trigger the old SGSN to delete the useless subscriber record. This is the main use of the routing area update procedure. It keeps the GMM context for an attached UE up to date.

- 110

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

old SGSN
IMSI UE
Update of the location information within the PS core network domain routing area update.

RA 1

Subscriber record - Service data - RAI 1

delete old SGSN record

no routing area update UE routing area update UE no routing area update UE

HLR
IMSI
Subscriber record - Service data - SGSN-no. - SGSN IP #

RA 1
update routing area in SGSN

RA 2
IMSI
Subscriber record - Service data - RAI 2

RA 2

update VLR address in HLR

new SGSN

figure 52 Update of the GMM context during routing area update procedure.

TECHCOM Consulting

- 111

TC 1160-4

UE-CN Protocols

When PDP contexts are activated during a routing area update is performed there is more to do. Still remember that the UE was in PMM_Idle mode. This means that there is no radio access bearer allocated for the UE. But an activated PDP context means, that there is a tunnel defined between GGSN and old SGSN. When the UE now changes to the new SGSN this tunnel must be modified such that a new tunnel between GGSN and new SGSN is created. Second it can happen that during the routing area update is running packet user data is flowing from GGSN to old SGSN. This data would be buffered within the old SGSN, but there is no way to send it to the UE, because the UE is already connected to the new SGSN. There is now the optional feature that this buffered data can be forwarded from old to new SGSN. In this way the packets are not lost, otherwise if this forwarding feature is not supported the packets in the old SGSN are simply discarded.

- 112

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

Routing Area Update to a new SGSN with an activated PDP context PDP context handling tasks.

GGSN

old tunnel

new tunnel

old SGSN

...
buffered packets

forwarding of buffered packets

new SGSN

figure 53 PDP context management during a routing area update for a UE that was in PMM_Idle state before the update.

TECHCOM Consulting

- 113

TC 1160-4

UE-CN Protocols

The signaling procedure for the routing area update for a UE in PMM_Idle state is shown below for the case that one PDP context is active. It is divided into two steps: 1. Routing area update request and PDP context modification.. 2. GMM context update of HLR and SGSN. The procedure begins when the UE in PMM_Idle state detects a new RAI that is different to the one stored on the USIM. a. The UE will send the GMM message Routing Area Update Request. This message is sent to the SGSN of the new routing area, thus the UE has to identify itself either by IMSI or by (P-TMSI, old RAI). b. It is now up to the new SGSN to get the IMSI for this UE. Therefore the new SGSN translates the old RAI from the UE into the old SGSN IP address using a DNS. Then the new SGSN sends the GTP-C message SGSN Context Request to the old SGSN. This SGSN Context Request message contains the P-TMSI. The old SGSN transfers all GMM context and all data about active PDP contexts back to the new SGSN using the GTP-C message SGSN Context Response. c. The new SGSN has now IMSI and authentication data from the GMM context and all information about all PDP contexts. Hence the new SGSN can perform authentication. d. When authentication is successful the new SGSN will send the GTP-C message SGSN Context Acknowledge to the old SGSN which triggers the old SGSN to forward buffered user packet data to the new SGSN. e. Concurrently with the last step the new SGSN contacts the GGSN for the active PDP context. It will send the GTP-C message Update PDP Context Request to the GGSN. This message gives the GGSN two IP addresses of the new SGSN one for user data and one for signaling. Additionally the new SGSN can set a new quality of service for the PDP context. The new QoS can be lower or higher than the QoS before the update. But the QoS will never exceed the QoS requested by the user. The GGSN will acknowledge with the GTP-C message Update PDP Context Response which can provide the new SGSN with the corresponding two GGSN IP addresses for signaling and data.

- 114

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

Routing Area Update (inter SGSN, one active PDP context, PMM idle mode 1(2) Update request and PDP context modification.

UE
new SGSN Routing Area Update Request
( old [LAI,PTMSI] )

old SGSN

GGSN

HLR

SGSN Context Request


( PTMSI )

SGSN Context Response Authentication


( MM context, PDP contexts )

SGSN Context Ack


( SGSN address for user traffic )

Update PDP Context Request


( new SGSN address for GTP-U and GTP-C, QoS )

Update PDP Context Response


( GGSN address for GTP-U and GTP-C, QoS )

figure 54 Routing area update for a UE in PMM_Idle state 1(2): Update request and PDP context modification.

TECHCOM Consulting

- 115

TC 1160-4

UE-CN Protocols

Now the PDP context is modified and the GMM context update can be performed. Whether the GMM context waits for the end of the PDP context update or is started together with it is not specified. f. The new SGSN invokes the MAP operation Update GPRS Location in the HLR. The message contains the IMSI and SGSN number and SGSN IP address. g. The HLR will start two things concurrently. First it will delete the old subscriber record in the old SGSN using the MAP operation Cancel Location. Second the HLR fills the subscriber record in the new SGSN with the PS subscription data. This is done by the MAP operation Insert Subscriber Data. The Insert Subscriber Data operation can be repeated several times. h. When the record in the new SGSN is completed the HLR will acknowledge the Update GPRS Location operation. i. Now the SGSN can indicate the successful end of the routing area update to the UE with the GMM message Routing Area Update Accept. In this message a new P-TMIS together with the new RAI can be assigned. j. If a new P-TMSI is assigned the UE has to acknowledge it with the GMM message Routing Area Update Complete.

- 116

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE
new SGSN old SGSN GGSN HLR

Routing Area Update (inter SGSN, one active PDP context, PMM idle mode 2(2) HLR update.

Update GPRS Location


( IMSI, SGSN-no., SGSN-IP-address)

Cancel Location
( IMSI, type=update )

Cancel Location Ack Insert Subscriber Data


( IMSI, PS subscription information )

Insert Subscriber Data Ack


Routing Area Update Accept
( P-TMSI , RAI )

Update GPRS Location Ack


( HLR number)

Routing Area Update Complete

figure 55 Routing area update for a UE in PMM_Idle state 2(2): GMM context update.

TECHCOM Consulting

- 117

TC 1160-4

UE-CN Protocols

The GMM protocol supports the routing area update with three messages: Routing Area Update Request: This message is sent by the UE to trigger the update. It contains a subscriber identity (IMSI or P-TMSI with P-TMSI signature if available) and includes the network and radio access capabilities. The PDP context status parameter indicates for all 11 possible PDP contexts whether they are active or not. The parameter update type is used for combined MM/GMM procedures and will be explained later. Routing Area Update Accept: The routing area update accept message indicates the successful outcome of the routing area update. A new P-TMSI with the new RAI can be assigned. Optional is the assignment of a P-TMSI signature. In case of combined MM/GMM procedure also a new TMSI can be allocated and the outcome of the CS procedure can be indicate with the update result element. Routing Area Update Complete: This message is used by the UE to acknowledge a received new P-TMSI and/or new TMSI.

- 118

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN

Routing Area Update Request


( update type, CKSN, old RAI, old P-TMSI, old P-TMSI signature, MS radio access capability, MS network capability, PDP context status ) Authentication

Routing Area Update Accept


Routing Area Update GMM messages.

( update result, new P-TMSI, new RAI, P-TMSI signature, periodic update timer, equivalent PLMNs, new TMSI )

Routing Area Update Complete

figure 56 GMM message details for routing area updates.

TECHCOM Consulting

- 119

TC 1160-4

UE-CN Protocols

Routing Area Update for a UE in PMM_Connected state In the last part the routing area update for a UE in PMM_Idle state has been discussed. Now the comes the story for the UE in PMM_Connected state. When the UE is in PMM_Connected state there is an Iu-PS signaling connection associated with a serving RNC. The key point is, that the UE gets the RAI directly from its serving RNC. The general system information broadcast is not considered by such a UE. The behavior in this case is that first a S-RNC relocation must be performed and then the UE gets told a new RAI and with this the routing area update takes place. The following tasks have to be performed: 1. The resources and signaling connection on the old Iu interface have to released and a signaling connection and radio access bearers on the new Iu interface are needed. (S-RNC relocation) 2. The buffered packets in the source RNC can optionally be forwarded to the new target RNC (this requires the Iur interface). (S-RNC relocation) 3. When the radio access bearers are moved from the old to the new Iu interface during S-RNC relocation it makes no sense to keep the old tunnel between GGSN and old SGSN. Hence already during S-RNC relocation the backbone tunnel will be modified such that it is between GGSN and new SGSNS. (SRNC relocation) 4. The GMM context between SGSN and HLR must be updated. (routing area update) 5. When the relocation is done it may still happen that downlink user data packets are flowing from GGSN to the old SGSN. Therefore it is an optional feature that the old SGSN forwards some still buffered packets that could not have been forwarded to the source RNC to the new SGSN. (routing area update) So it can be seen that most of the tasks that are related to the PDP context resources (e.g. radio access bearer and tunnel) are handled during S-RNC relocation. Only the update of the HLR is done during the routing area update procedure that comes as result of the relocation. Packets that are buffered in the old SGSN will be forwarded as long as possible to the source RNC, which can forward it to the target RNC when Iur is present. When this is not possible for all downlink user data packets, there is still the option to forward them directly from old to new SGSN.

- 120

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

old tunnel

GGSN

new tunnel

Routing Area Update with S-RNC relocation overvieew about the principle tasks.

old SGSN

...
buffered packets

forwarding of buffered packets

new SGSN

old Iu interface

new Iu interface

source RNC

...
buffered packets

forwarding of buffered packets

target RNC

figure 57 Transport bearer related tasks during S-RNC relocation with routing area update.

TECHCOM Consulting

- 121

TC 1160-4

UE-CN Protocols

The complete message sequence chart for the serving RNC relocation with routing area update is divided into three figures: 1. Relocation preparation and execution. 2. Relocation completion and routing area update request. 3. Routing area update (GMM context update). As already mentioned the whole procedure begins with a S-RNC relocation. a. The source RNC decides that a relocation is needed, hence it send RANAP: Relocation Required to the old SGSN to which it is connected to. The old SGSN evaluates the new target RNC ID and forwards the required indication with GTP-C message Forward Relocation Request to the new SGSN that serves the target RNC. This message Forward Relocation Request transfers already all GMM and PDP context data to the new SGSN. b. The new SGSN triggers now the target RNC to allocate all needed resources (relocation preparation) with RANAP: Relocation Request. The target RNC shall now allocate all radio access bearers and set up the new Iu signaling connection. When this is done the RANAP message Relocation Request Acknowledge will come. The new SGSN will forward this message as GTP-C message Forward Relocation Response to the old SGSN. c. The old SGSN knows now that all resources are allocated and triggers the execution of the relocation with RANAP: Relocation Command to the source RNC. In the example the relocation is a soft-handover completion and thus the execution is done with the RNSAP message Relocation Commit on Iur. Together with this the source RNC begins with the forwarding of downlink packet user data to the target RNC. d. The target RNC will on reception of the RNSAP message Relocation Commit trigger the RANAP message Relocation Detect. This message is of course running to the new SGSN where the target RNC is connected to.

- 122

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE
source RNC target RNC Relocation Required old SGSN new SGSN GGSN HLR

Forward Relocation Request (MM context, PDP context )

Routing Area Update with S-RNC relocation 1(3) Relecotion preparation and execution.

Relocation Request

RAB establishment
Relocation Request Acknowledge
Forward Relocation Response

Relocation Command
Relocation Commit

data forwarding Relocation Detect

figure 58 S-RNC relocation with routing area update 1(3): Relocation preparation and execution.

TECHCOM Consulting

- 123

TC 1160-4

UE-CN Protocols

e. When the relocation has been detected two things happen in parallel. First the target RNC will provide the UE with new RNTI (Radio Network Temporary Identity) and with new system information. This is done with a RRC message, the example shows the message RRC:UTRAN Mobility Information. This message also gives a new RAI. Second the new SGSN will now update the tunnel with GTP-C Update PDP Context Request. The GGSN will respond to this with Update PDP Context Response, now the tunnel is between GGSN and new SGSN. f. When the UE has confirmed the new RNTI the RRC connection is between UE and target RNC. At this point the target RNC can indicated RANAP: Relocation Complete. This will be forwarded by the new SGSN to the old SGSN using GTP-C Forward Relocation Complete. g. Now the old SGSN can release the old Iu interface using RANAP: Iu Release Command. This message releases the old SCCP connection and the radio access bearers on the old Iu interface. The source RNC will acknowledge with RANAP: Iu Release Complete. From now on there is no forwarding of downlink user packet data from old SGSN to source RNC possible. The old SGSN acknowledges to the new SGSN with Forward Relocation Complete Acknowledgement. h. In the meantime the UE has analyzed the newly received network information from the target RNC and detects the new RAI. Hence the UE triggers the routing area update with GMM message Routing Area Update Request. Because the target RNC is already the new serving RNC the message is forwarded to the new SGSN which is also responsible for the new RAI. i. The new SGSN knows already the UE from the relocation and expects the UE. Also the IMSI is already known from the GMM context that was received from the old SGSN. Therefore there is no translation of PTMSI into IMSI necessary. Instead the new SGSN immediately sends the GTP-C message SGSN Context Acknowledgement to the old SGSN. This allows the forwarding of buffered user data packets from old to new SGSN. In parallel with that the new SGSN triggers the GMM context update to the HLR with the invocation of the MAP operation Update GPRS Location.

- 124

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE
Routing Area Update with S-RNC relocation 2(3) Relocation completion and trigger of Routing area update.

source RNC

target RNC

old SGSN

new SGSN

GGSN

HLR

UTRAN Mobility Information


(new RNTI, new RAI)

Update PDP Context Request Update PDP Context Response

UTRAN Mobility Information Confirm

Relocation Complete
Forward Relocation Complete

Iu Release Command Iu Release Complete

Forward Relocation Complete Ack

Routing Area Update Request


SGSN Context Acknowledge

Update GPRS Location

figure 59 S-RNC relocation with routing area update 2(3): Relocation completion and routing area update request.

TECHCOM Consulting

- 125

TC 1160-4

UE-CN Protocols

j. The HLR starts again two procedures in parallel. First the old subscriber record in the old SGSN will be deleted using the MAP operation Cancel Location. Second the new subscriber record in the new SGSN will be filled with the PS subscription data. This is done with MAP Insert Subscriber Data. k. When the subscriber record is filled and the SGSN has acknowledged all data the HLR terminates the process with the acknowledgement for the Update GPRS Location operation. l. The new SGSN has now all data for the UE and the Iu signaling connection with the UE. Therefore the successful end of the routing area update will be indicated. The GMM message Routing Area Update Accept is used for this. This message will usually assign a new P-TMSI to the UE. m. The new P-TMSI must be acknowledged by the UE with GMM Routing Area Update Complete.

- 126

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE
source RNC target RNC old SGSN new SGSN GGSN HLR

Cancel Location Cancel Location Ack


Routing Area Update with S-RNC relocation 3(3) Routing area update completion.

Insert Subscriber Data Insert Subscriber Data Ack Routing Area Update Accept Routing Area Update Complete Update GPRS Location Ack

figure 60 S-RNC relocation with routing area update 3(3): Routing area update completion.

TECHCOM Consulting

- 127

TC 1160-4

UE-CN Protocols

Service Request procedure The PS core network domain does not know something like a GMM connection. But like in case of the circuit switched transactions the request of some PS service runs in two steps: first the UE must request the access to the PS core network domain for the service, then the UE can start with the service.

The access request is performed by the GMM protocol with the message Service Request. This message contains a parameter why this access request has been sent: paging : This means the UE sends the Service Request message because of a received paging from the SGSN. signaling : This indicates that the UE wants to start a signaling procedure either for session management SM or short message service SMS. data : With this the UE indicates that it wants to send uplink data within an activated PDP context that currently has no radio access bearer assigned.

The service request message can be sent by the UE in PMM_Idle mode. In this case the Service Request message triggers the set up of a Iu signaling connection on Iu PS. The network acknowledges the service request with the activation of the security features.

- 128

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

RNC

SGSN RANAP: Paging

RRC: Paging Type 1 or 2

Service Request
( CKSN, P-TMSI, PDP context status, service type= paging response | data | signalling )

Service Request from PMM idle mode.

RRC: Security Mode CMD RRC: Security Mode COM

RANAP: Security Mode CMD RANAP: Security Mode COM

figure 61 GMM message Service Request to establish an Iu-PS signaling connection.

TECHCOM Consulting

- 129

TC 1160-4

UE-CN Protocols

When the UE sends the Service Request message in PMM_Idle mode the Iu signaling connection already exists. There is only one case when this happens. This is when the UE has an Iu-PS signaling connection but no radio access bearer for the sending of uplink packet user data. The network will accept the service request with the GMM message Service Accepts. After this the SGSN will activate the radio access bearer for the uplink data.

- 130

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

RNC

SGSN

Service Request
( CKSN, P-TMSI, PDP context status, service type= data )

Service Accept
() RANAP: RAB Assignment Request RANAP: RAB Assignment Response

RRC: Radio Bearer Setup


Service Request from PMM connected mode.

RRC: Radio Bearer Setup Complete

UL user data

figure 62 Service request in PMM_Connected mode.

TECHCOM Consulting

- 131

TC 1160-4

UE-CN Protocols

3.4.

SM procedures

General about PDP contexts The PDP context is the service of the PS core network domain, is must be considered to be completely different to the classical circuit switched services. In principle the following service types can be distinguished: integrated services: Integrated services are built into the communication network. Examples for integrated services are circuit switched calls and short message services. open services: Open services are services that are implemented outside of the communication network. The open service implementations use simple transport services offered by the communication network.

The classical telecommunication networks PSTN, ISDN, GSM are typical integrated service networks. Their advantage is the high degree of inter-operability between networks of different operators and between equipment of different manufactures. On the other hand integrated service networks are not very flexible with respect to the introduction of new services. A long way is to be gone from service design, implementation to service testing. Especially because the network operators are deeply involved in every step of this process the service creation is very expensive. This is the reason for the introduction of the open service networks. Open service networks do not specify subscriber services. Instead such networks provide pure transport bearer services. The data that is transported may be structured or unstructured. The best example for an open service network is the IPbased internet. With PARLAY and OSA (Open Service Access) it is tried to make the classical integrated service networks to open service networks too. The PS core network domain is an open service domain. The service offered by this domain is the PDP context. The PDP context must be seen as a packet oriented transport bearer service that is used to transfer the packet network control protocol datagrams (PDP Packet Data Protocol) through the UMTS PS core network domain. For which type of application this transport bearer is used is not of interest for UMTS. The states of PDP contexts are simple. A context can be active or inactive. Active PDP contexts are possible for a UE in PMM_Connected and PMM_Idle state.

- 132

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

Inactive
PDP context deactivation or GPRS detach

PDP context activation

Active
States of a PDP context and its rleation to packet sessions.

UE

ISP ISP
SGSN GGSN

Packet Session (using PDP) PDP context

PDP bearer

figure 63 PDP context.

TECHCOM Consulting

- 133

TC 1160-4

UE-CN Protocols

A PDP context is associated with a set of parameters that are stored in UE, SGSN and GGSN. The following are important: NSAPI (Network Service Access Point Identifier): The NSAPI is used as a global identifier for a PDP context. Especially it is used from outside of the UMTS network to access a PDP context. So if the PDP context is used for the tunneling of IP datagrams, the associated IP layer in the UE (or equipment connected to the UE) will use the NSAPI as interface identifier. In fixed line IP networks this is mainly used to distinguish between several interface cards (e.g. ethernet cards, modems, etc.). PDP Type: The PDP type indicates which protocol is tunneled through the PDP context (e.g. IP or PPP). PDP Address : The PDP address is a routing address of the tunneled protocol (PDP). The UE uses the PDP address to be connected to the external data network. For the UMTS network this address has no meaning, which means that it will not be used for routing within the UMTS network. APN (Access Point Name): The APN is the name of the external data network. Hence it indicates the internet service provider (ISP). Within the UMTS network the APN is used by the SGSN to find a suitable GGSN using a domain name service. The GGSN uses the APN to find the correct port to the specified ISP. TI (Transaction Identifier): The SM protocol that handles the PDP contexts between UE and SGSN uses the TI to differentiate between different PDP contexts. This is the same as for circuit switched calls. GSN Addresses: The PDP context consist of three parts. The link between UE and RNC, a tunnel between RNC and SGSN and a tunnel between SGSN and GGSN. The tunnel within the core network works exactly the same way like the Iu-PS tunnel. Hence the base of all routing are the (internal) IP addresses of SGSN and GGSN and RNC. TEID (Tunnel Endpoint Identifier): The GTP-U protocol is used to transport packet traffic over Iu-PS and between SGSN and GGSN. Hence the tunnel between SGSN and GGSN is identified by TEIDs like it was the case on IuPS. But now there are four TEIDs. Two TEID values are allocated by the SGSN one for signaling and one for data. The same holds for the SGSN. This differentiation has been done, because the control signaling for the GTPU tunnels is done by the GTP-C protocol which allocates its own TEIDs.

- 134

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

ISP ISP
SGSN GGSN NSAPI
PDP type PDP address APN SGSN address PDP address

NSAPI
PDP type PDP address APN

NSAPI
PDP type PDP address APN GGSN address

PDP context parameters excerpt.

TEIDSGSN TEIDGGSN

TEIDGGSN TEIDSGSN

figure 64 PDP context and associated parameters.

TECHCOM Consulting

- 135

TC 1160-4

UE-CN Protocols

PDP context activation A PDP context is always established by the UE and will never be activated directly by the network. The procedure is as follows: 1. The UE uses the SM message Activate PDP Context Request which is sent to the SGSN. The message contains the new TI and the NSAPI to identify the PDP context. The subscriber will indicate the requested quality of service and the access point name APN within the message. APN and QoS will especially be used for charging. If the UE has a statically allocated PDP address it can indicate it too. 2. When the SGSN receives the Activate PDP Context Request message it will check whether the transmitted parameters are allowed by the subscriber record received from the HLR during routing area update. If the PDP context is permitted, the SGSN sends the GTP-C frame Create PDP Context Request to the GGSN. In the message the SGSN will indicate its TEIDs, the NSAPI, the APN, QoS and the SGSN IP addresses. If the UE has a statically allocated PDP address the SGSN sends it to the GGSN too, otherwise an empty PDP address is sent. For identification purposes the MSISDN will be sent to the GGSN. 3. The GGSN will now check the data and will possibly perform PDP address allocation. If everything is ok the GGSN sends to the SGSN the GTP-C message Create PDP Context Response, which contains the GGSN data. 4. When the SGSN receives this, it will acknowledge the PDP context activation to the UE with the SM message Activate PDP Context Accept. With this the PDP context as PDP transport bearer is established. Therefore the SGSN will also trigger the radio access bearer setup now.

- 136

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN Activate PDP Context Request


( TI, NSAPI, requested QoS, requested PDP address, APN )

GGSN

Create PDP Context Request Authentication


( TEIDSGSN for data, TEIDSGSN control, NSAPI, APN, PDP address, QoS, SGSN address signalling/data, MSISDN )

Create PDP Context Response Activate PDP Context Accept


PDP context activavtion.

( TEIDGGSN for data, TEIDGGSN control, NSAPI, APN, PDP address, QoS GGSN address signalling/data )

( TI, granted QoS, radio priority allocated PDP address )

figure 65 PDP context activation first PDP context.

TECHCOM Consulting

- 137

TC 1160-4

UE-CN Protocols

Secondary PDP contexts A PDP context represents one transport bearer service for the tunneling of a protocol. Hence it is described by a set of quality of service parameters. How the UE uses this transport bearer is not a matter of the UMTS network. So it is possible that several applications (e.g. http, ftp, email, VoIP) share one PDP context. This might result in problems with the quality of service. Therefore UMTS allows that several PDP contexts are activated with the same PDP address and APN this is the secondary PDP context. But now a problem arises for the GGSN. The GGSN receives packets from the external data network and assigns the packets to PDP contexts using the destination address which is the PDP address of the UE. When several PDP contexts with the same address and the same external network (APN) exists a conflict occurs which packet belongs to which PDP context. This conflict is solved by a so called packet filter. A packet filter screens the received packets for additional information and then decides which way the packet will take. For all secondary PDP contexts the packet filter possesses a so called TFT (Traffic Flow Template). The TFT contains a list of parameters and their values, if the packet header information (e.g. IP/TCP or IP/UDP header) matches the packet will go to the associated secondary PDP context. If no suitable secondary PDP context is found, the packet will be transmitted in the first PDP context. This is the reason why there is no TFT for the first PDP context. Of course the TFT parameters of different secondary PDP context must be disjoint, this means a packet will be transmitted in one and only one PDP context. The parameters of the TFT cover the following: IPv4 / IPv6 source address, destination/source port number, destination/source port number range, protocol identifier (IP v4) / next header (IP v6), flow label (IP v6), IPsec parameters.

- 138

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

PDP context 1 (PDP address: A, APN: a)


UE

PDP context 1a (PDP address: A, APN: a) PDP context 1b PDP context 2 (PDP address: A, APN: a)

Packet Filter TFT 1 TFT 2 TFT 3

Dest.Address: A

ISP ISP
Dest.Address: A

GGSN
Secondary PDP context general principles.

Traffic Flow Template (TFT)


IPv4 source address IPv6 source address Protocol ID / Next Header Source Port Number Source Port Number Range Dest. Port Number Dest. Port Number Range Type of Service/Traffic Class Flow Label IPsec security parameter

figure 66 Secondary PDP contexts general principle.

TECHCOM Consulting

- 139

TC 1160-4

UE-CN Protocols

The activation of a secondary PDP context looks exactly like the first PDP context set up. Some parameters are new: linked TI : The linked TI will be indicated by the UE to the SGSN and tells the SGSN which PDP context was the first one for this PDP address and APN. TFT : The traffic flow template is sent to the GGSN via SGSN and describes which part of the packet flow has to be sent in this PDP context.

- 140

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN Activate Secondary PDP Context Request


( TI, NSAPI, requested QoS, linked TI, TFT )

GGSN

Authentication

Create PDP Context Request


( TEIDSGSN for data, TEIDSGSN control, NSAPI, APN, PDP address, QoS, SGSN address signalling/data, MSISDN, TFT )

Create PDP Context Response


Secondary PDP context activation.

Activate Secondary PDP Context Accept


( TI, granted QoS, radio priority )

( TEIDGGSN for data, TEIDGGSN control, NSAPI, APN, PDP address, QoS GGSN address signalling/data )

figure 67 Secondary PDP context activation.

TECHCOM Consulting

- 141

TC 1160-4

UE-CN Protocols

PDP context modification A PDP context can be modified during it is active. The modification mainly covers the following three cases: the QoS of the PDP context is modified either on request of the user or due to certain network decisions, the tunnel path will be modified from old SGSN to new SGSN during routing area update or serving RNC relocation, a PDP context was established without a valid PDP address (PDP address for IP is 0.0.0.0), then later on a PDP address allocation will be done which triggers the modification of the PDP context's PDP address (This will be used when the address is dynamically negotiated by the UE using DHCP).

The modification is supported by the SM protocol with the messages Modify PDP Context Request and Modify PDP Context Accept. These two messages are used between UE and SGSN and can be used for UE and network initiated PDP context modification. The GTP-C protocol provides the messages Update PDP Context Request and Update PDP Context Response. These two messages organize the PDP context modification between SGSN and GGSN.

(Note that the change of a PDP address is allowed only once. If there should occur a second change of the PDP address triggered by the DHCP server, the GGSN can release the PDP context.)

- 142

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN Modify PDP Context Request


( new QoS, new TFT )

GGSN

Authentication

Update PDP Context Request


( TEIDSGSN for data, TEIDSGSN control, requested QoS, SGSN address signalling/data, TFT )

UE initiated PDP context modification.

Update PDP Context Response Modify PDP Context Accept


( granted QoS, new radio priority )
( TEIDGGSN for data, TEIDGGSN control, negotiated QoS, GGSN address signalling/data )

figure 68 UE initiated PDP context modification.

TECHCOM Consulting

- 143

TC 1160-4

UE-CN Protocols

UE

SGSN Update PDP Context Request

GGSN

( TEIDSGSN for data, TEIDSGSN control, requested QoS, SGSN address signalling/data, TFT )

Update PDP Context Response Modify PDP Context Request


SGSN initiated PDP context modification.

( TEIDGGSN for data, TEIDGGSN control, negotiated QoS, GGSN address signalling/data )

( new QoS )

Modify PDP Context Accept


()

figure 69 Network initiated PDP context modification QoS update.

- 144

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN Update PDP Context Request


( QoS, PDP address )

GGSN

Modify PDP Context Request


( new QoS, new PDP address )

Update PDP Context Response


( QoS )

Modify PDP Context Accept


()
GGSN initiated PDP address modification.

figure 70 GGSN initiated PDP context modification PDP address update.

TECHCOM Consulting

- 145

TC 1160-4

UE-CN Protocols

PDP context deactivation The deactivation of PDP contexts comes in three different versions: UE initiated deactivation, network initiated deactivation, implicit deactivation during detach.

The first two cases use explicit signaling between UE and SGSN. The corresponding SM protocol messages are Deactivate PDP Context Request and Deactivate PDP Context Accept. The Deactivate PDP Context Request message contains a Tear Down Indicator which specifies whether only the PDP context with the indicated TI shall be released or all PDP context with the same PDP address and APN shall be released together. Between SGSN and GGSN the GTP-C protocol allows the deactivation with the messages Delete PDP Context Request and Delete PDP Context Response.

- 146

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN Deactivate PDP Context Request


( TI, SM cause, Tear Down Indicator )

GGSN

Delete PDP Context Request


( NSAPI )

Deactivate PDP Context Accept


()

Delete PDP Context Response


()

TECHCOM Consulting

UE initiated PDP context deactivation.

figure 71 UE initiated PDP context deactivation.

- 147

TC 1160-4

UE-CN Protocols

- 148

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN

GGSN

Deactivate PDP Context Request


( TI, SM cause, Tear Down Indicator )

Delete PDP Context Request


( NSAPI )

Delete PDP Context Response


()
SGSN initiated PDP context deactivation.

Deactivate PDP Context Accept


()

figure 72 Network initiated PDP context deactivation.

TECHCOM Consulting

- 149

TC 1160-4

UE-CN Protocols

- 150

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

4 Layer 3 message formatting

TECHCOM Consulting

- 151

TC 1160-4

UE-CN Protocols

4.1.

UE-CN signaling message transport

The messages that run between UE and CN directly are usually called NAS (Non Access Stratum) messages. These messages must be transported over the radio interface Uu and over the interface Iu between RNC and CN. On the radio interface Uu the NAS messages will be transported within messages of the RRC protocol that is terminated in UE and serving RNC. The serving RNC relays the NAS messages from RRC protocol to RANAP protocol on Iu and vice versa. The messages that are transported have a common header structure. This structure contains the following: PD (Protocol Discriminator): The PD distinguishes between the different higher layer protocols like MM, CC, GMM, SM, SS, SMS, etc. This field is used by UE and MSC or SGSN to route the message to the correct internal protocol module. Note that the RNC does not evaluate this parameter. TI (Transaction Identifier): The TI is used to label transactions/session of the same type. So it is used to handle several calls simultaneously or handle several PDP contexts simultaneously. Message Type: The message type indicates which message is transmitted with respect to the indicated protocol PD.

These three elements form the so called layer 3 standard header.

- 152

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

UE

SGSN RRC: UL|DL Direct Transfer

SGSN / MSC RANAP: Direct Transfer

(..., NAS-PDU, ... )

(..., NAS-PDU, ... )

Formatting of Layer 3 messages on Uu/Iu.

TI PD TI extension (optional) Message Type Message Parameters (Information Elements)

figure 73 Layer 3 message transport and layer 3 standard header.

TECHCOM Consulting

- 153

TC 1160-4

UE-CN Protocols

4.2.

Protocol discriminator and transaction identifier

The protocol discriminator PD distinguishes the various protocols between UE and CN. The most important are: MM (Mobility Management) : H5, GMM (GPRS Mobility Mgt.) : H8, CC (Call Control) : H3, SM (Session Mgt.) : HA.

The transaction identifier is used by protocols that support transaction (calls, sessions, messaging services) only. Hence for the protocols MM and GMM the TI is set to 0 and is called a skip indicator. For all other protocols the TI consists of two things: TI Flag: The TI flag is 0 when the message is sent by the side that allocated the TI. It is 1 when the message will be received by the side that allocated the TI. TI Value: The TI value labels the transactions.

The TI Value comes in two types: short TI: In this case the TI value is 3 bits and can have the values 000 to 110. The TI value 111 can not be used for the short TI. extended TI: In case the three bits are not enough the TI value can be extended to 7 bits. Therefore the short TI (TIO) is set to 111 (the forbidden value) and the real TI is indicated in the lower 7 bits of the next octet.

- 154

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

8
TI flag

6
TIO ( 1 1 1)

1
PD 0 0 0 0 0 0 0 1 1 1 1 1 0 0 0 0 1 1 1 0 0 0 0 1 0 0 1 1 0 0 1 0 0 1 1 0 0 1 0 1 0 1 0 0 1 0 1 0 Protocol Message Group Call Control Broadcast Call Control PDSS1 Call Control (CC) GPRS Transparent Transport Protocol Mobility Management (MM) Radio Resource Management (RR) GPRS Mobility Mgt. (GMM) SMS GPRS Session Mgt. (SM) Non-call related Suppl. Services LCS

Protocol Discriminator

Message Type Message Parameters


standard TI

8
Formatting of Layer 3 messages on Uu/Iu header details.

6
TIO (=1 1 1)

TI flag

Protocol Discriminator

TI flag 0 1

Description Message sent from TI originator Message sent to TI originator

TIE ( 0000111 ... 1111111)

Message Type Message Parameters


extended TI

figure 74 PD and TI of the layer 3 standard header.

TECHCOM Consulting

- 155

TC 1160-4

UE-CN Protocols

4.3.

Message Type

The message type will be indicated within one octet that follows the TI. The message type itself is specified in the lowest six bits of the octet, the exact assignment message type to value depends on the protocol that is indicated by the PD. The highest two bits of the message type octet have different meaning dependent on the protocol: GMM : In GMM messages the highest two bits are always b00. SM : In SM messages the highest two bits are always b01. MM, CC, SS : For these protocols the highest two bits form the so called send sequence number N(SD). The N(SD) is always b00 in the downlink. In the uplink the N(SD) is a strictly increasing sequence number,

- 156

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

0 0

0 GMM message type code 1 SM message type code

N(SD) MM message type code N(SD)


Message type octet for Iu/Uu layer 3 messages.

CC message type code SS message type code

N(SD)

figure 75 Message type octets.

TECHCOM Consulting

- 157

TC 1160-4

UE-CN Protocols

4.4.

Parameter formats

The formatting of parameters for the messages follows a standardized picture. A parameter in general will be transmitted with three different elements: IEI (Information Element Identifier): The IEI indicates which parameter is it. Length indicator: The length indicator specifies the length of the content. Value.

It depends upon the concrete message type which of these three elements are necessary for a parameter. In other words the message type also determines in which format the parameter is encoded. The following formats are defined: V (Value): The V-format is used for parameters that have a fixed length and are mandatory. Hence no length indicator and no IEI are needed, only the content of the parameter itself is transmitted. TV (Type Value): The TV format means that first the IEI and then the value of the parameter must be transmitted. LV (Length Value): The LV format transmits the parameter with length indicator first and then the content. TLV (Type Length Value): In this format all parts of the parameter are present, first the type (IEI) is indicated, then come length indicator and content. T (Type): This format is used for optional parameters that take the values yes and no only. Only the IEI is indicated, but no length and no content can be seen. When this type field occurs in the message the parameter value is yes, otherwise it is no.

The formats V and TV can also be used for parameters where the length is only 4 bits. In case several 4 bit parameters shall be sent in V format they are packed such that the lower four bits of an octet carry the first parameter and the higher four bits carry the next parameter. If there is no next four bit parameter, the higher four bits must be padded with 0000.

- 158

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

full octet values V


Value

half octet values


Value 2 0 0 0 0 1 IEI Value 1 Value 3 Value

TV

IEI Value 1 IEI

T LV TLV
Parameter formats.

LI Value 0 IEI LI Value

figure 76 Parameter formats.

TECHCOM Consulting

- 159

TC 1160-4

UE-CN Protocols

4.5.

Specification example

The message format definitions for CC, SM, GMM, MM protocols can be found in ETSI/3GPP TS 24.008. The messages are specified in tabular format. The tables contain the following information: The first row shows the IEI value for all parameters that are transmitted in formats TV, TLV or T. Then comes the name of the information element. The next row gives the type of the parameter and the reference to the section where this type is defined. The last three rows indicate the presence (M=mandatory, O=Optional, C=Conditional), the format and the total length of the element in bytes.

- 160

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

Table 9.4.1/3GPP TS 24.008: ATTACH REQUEST message content


IEI Information Element Protocol discriminator Skip indicator Attach request message identity MS network capability Attach type GPRS ciphering key sequence number
Example of a GMM message specification Attach Request.

Type/Reference Protocol discriminator 10.2 Skip indicator 10.3.1 Message type 10.4 MS network capability 10.5.5.12 Attach type 10.5.5.2 Ciphering key sequence number 10.5.1.2 DRX parameter 10.5.5.6 Mobile identity 10.5.1.4 Routing area identification 10.5.5.15 MS Radio Access capability 10.5.5.12a P-TMSI signature 10.5.5.8 GPRS Timer 10.5.7.3 TMSI status 10.5.5.4

Presence M M M M M M M M M M O O O

Format V V V LV V V V LV V LV TV TV TV

Length 1/2 1 3-9 2 6-9 6 6 - 52 4 2 1

DRX parameter P-TMSI or IMSI Old routing area identification MS Radio Access capability 19 17 9Old P-TMSI signature Requested READY timer value TMSI status

figure 77 Format specification of message Attach Request (GMM), excerpt from ETSI/3GPP TS 24.008.

TECHCOM Consulting

- 161

TC 1160-4

UE-CN Protocols

If we would look to Attach Type of the Attach Request message, the section 10.5.5.2 must be found. In this section the attach type parameter is defined. Also the parameters are specified in tabular format. The parameter layout is shown as a table of octets and for the meaning of the bits additional tables can be found.

- 162

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

Figure 10.5.118b/3GPP TS 24.008: Attach type information element Table 10.5.135b/3GPP TS 24.008: Attach type information element

4 FO R

1 octet 1

Attach type IEI

Type of attach

Example of a GMM message specification Attach Request.

Type of attach (octet 1, bit 1 to 3) Bits 3 2 1 0 0 1 GPRS attach 0 1 0 GPRS attach while IMSI attached 0 1 1 Combined GPRS/IMSI attach All other values are interpreted as GPRS attach in this version of the protocol. Follow-on request (octet 1, bit 4) Bits 4 0 No follow-on request pending 1 Follow-on request pending Follow-on request pending is applicable only in UMTS.

figure 78 Definition of the Attach Type parameter, excerpt from ETSI/3GPP TS 24.008.

TECHCOM Consulting

- 163

TC 1160-4

UE-CN Protocols

The principle layout of the Attach Request message can be found below.

0 0 0

0 0 0

0 0 0

0 0 0

1 0 0

0 0 0

0 0 1

0 1 0

Skip Indicator; PD=H8 (GMM) GMM message type H01 (Attach Request) MS network capability : Length 2

MS network capability
0 1 0 1 0 0 1 1
CKSN (d5); no follow on request; attach type=d3 (combined attach)

DRX parameter
Example of a GMM message layout Attach Request 1(2).

0 1 1

0 1 1

0 1

0 1

0 0

1 1

0 0

1 0

Mobile Identity : Length 5 Filler (HF); even number of digits; Identity type H4 (PTMSI/TMSI)

PTMSI

figure 79 Attach Request message formatting example 1(2).

- 164

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

MCC #2 MNC #3 (filler) MNC #2

MCC #1 MCC #3 MNC #1

old RAI

LAC RAC
0 0 0 0 0 1 0 1
MS radio access capability: Length 5

Example of a GMM message layout Attach Request 2(2).

MS radio access capability


0 0 0 1 1 1 0 1
IEI H19 (PTMSI signature)

PTMSI signature
1 0 0 0 0 0 0 1
IEI H9- (TMSI status); spare; valid TMSI available

figure 80 Attach Request message formatting example 2(2).

TECHCOM Consulting

- 165

TC 1160-4

UE-CN Protocols

- 166

TECHCOM Consulting

UE-CN Protocols

TC 1160-4

5 References

TECHCOM Consulting

- 167

TC 1160-4

UE-CN Protocols

5.1.

ETSI / 3GPP recommendations

[1] [2] [3] [4] [5] [6] [7] [8]

TS 23.008 TS 23.016 TS 23.018 TS 23.060 TS 24.007 TS 24.008 TS 29.002 TS 29.060

V 3.5.0 V 3.7.0 V 3.7.0 V 3.7.0 V 3.8.0 V 3.11.0 V 3.7.0 V 3.11.0

Organization of subscriber data Subscriber data management Basic call handling General Packet Radio Service Signaling Layer 3 general aspects Signaling Layer 3 CN protocols Mobile Application Part protocol GPRS Tunneling Protocol

(general) (general) (Ch 2) (Ch 1,3) (Ch 1,4) (Ch 2,3,4) (Ch 2,3) (Ch 2,3)

- 168

TECHCOM Consulting