Signaling Procedures for GSM Radio System

Signaling procedures of the GSM radio system

RA21584EN09GLS0 © 2008 Nokia Siemens Networks

1

Contents 1 GSM CS signaling procedures 3 1.1 Overview of the system interfaces and protocols 4 1.2 Air Interface 6 1.3 Call sequences on Air and A- interface 56 1.4 Call Connection analysis 62 2 GSM PS signaling procedure 135 2.1 Overview of the system interfaces and protocols 136 2.2 Message flow of basic packet switched BSS procedures 172



RA21584EN09GLS0© 2008 Nokia Siemens Networks

2



3

1 GSM CS signaling procedures



4

1.1 Overview of the system interfaces and protocols

BSCBTS

AC

HLR

EIR

MSC

MSCTRAU

FLMTLMT

Um Abis Asub A C

T T

O B

Not specified!

RC E

MS

VLR

VLR

G

D

Gateway to other networks

(Air Interface)

GSM (phase1/2)interfaces

Fig. 1 Overview of the system interfaces (circuit switched)



5

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CCS7

L1

LAPDm

RR

EIRAC VLR

othernetworks

Air interface

PLMN

HLR

MMCM

(CC)

MTP

SCCP

TCAP

MAP

BTS BSC MSC

MTP

SCCPISUP

signalling

RC SC

e.g. MFC-R2

CCS7

BSSAP

SCCP

MTP

BSSMAP

DTAP

ISDN

PSTN

LAPD

TMP(DTAP)(RSL)L2M

NMP(O&M)

L1

BSSAP Base Station System Application Part LAPD Link Access Protocol for D Channel BSSMAP Base Station System Management

Part MM Mobility Management

CM (CC) Connection Management (Call Control)

MTP Message Transfer Part

DTAP Direct Transfer Application Part NMP Network Management Procedures ISUP ISDN User Part RR Radio Resource Management L1 Layer 1 SCCP Signaling Connection Control Part LAPDm Link Access Protocol for Dm Channel TCAP Transaction Capability Part L2M L2 Management TMP Traffic Management Procedures Fig. 2 Overview of the protocols and user parts



6

1.2 Air Interface The Um Interface (air interface) connects the Mobile Station with the Base Transceiver Station. The following chapters will give you a short overview about protocols on the Um interface.

1.2.1 Layer 1 Layer 1 (physical Layer: GSM 04.04) is a physical directional point-to-point connection in multiframe mode. Layer 1 communicates with layer 3 directly according channel management and measurement control. The physical layer will offer layer 2 appropriate channels by usage of the following functions: Burst transmission Error correction and detection Supervision of RSS Link Control Furthermore the layer 1 protocol defines the mobile station's search for a suitable BCCH and the seizure of DCCH through the MS (after allocation by the base station).



7

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Radio Interface Signaling

Layer 1LogicalPhysical

Layer 2: LAPDm

Radio Resource managementRR

Mobility Management MM

Connection Management CMCall

Control CCSupplementary

Services SSShort MessageServices SMS

Support of “connection types”:Call Control CC support, e.g.• “Setup”, “Alert”, “Connect”, “Disconnect”Supplementary Services” support, e.g.• Call Forwarding, Call back when busy, Advice Of Charge,..SMS support

Support of mobility (Keep track of MS), e.g.:• “IMSI attach / detach”• “Location Update request / accept”• “Authentication request /response”• “TMSI reallocation command / complete”• “CM Service Request / accept” (activates: SS, MOC, SMS, Emergency Call)

Secure transfer ofsignaling data, e.g.:• Broadcast, Paging, Access Grant, dedicated signaling

Setup / Maintenance / Releaseof Dedicated Channels, e.g.:• “paging”• “channel request”• “immediate assignment”• “cipher mode command / complete”• “channel release”

Layer3

Fig. 3



8

1.2.1.1 Logical Channels on the Air-Interface for Circuit Switched Technology

Eight physical message channels are transmitted on one transceiver (TRX) by means of TDMA. So-called logical channels, which receive the signaling or useful data, are dedicated to these physical channels (mapping). The logical channels can be divided into two categories. There are two types of Traffic CHannels, TCH: full rate traffic channel (22.8 kbit/s) half rate traffic channel (11.4 kbit/s). There are three different types of Control CHannels, CCH: BCH (broadcast channels) CCCH (common control channels) DCCH (dedicated control channels). The entire signaling system is processed using the control channels. BCH (Broadcast Channels) These consist of the BCCH (broadcast control channel), which is used to transmit the basic data on the cell (CI, channel configuration, carrier frequencies, carrier frequencies of the neighboring cells etc.). The mobile station (MS) performs a frequency synchronization using the information from the FCCH (frequency correction channel). The SCH (synchronization channel) is used to synchronize the MS to the exact bit using the BTS. The system clock and the BSIC are also transmitted via the SCH. The CBCH (cell broadcast channel) is used to transmit the short message cell broadcast. All the broadcast channels are unidirectional (downlink).



9

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Logical channels

CCHControl Channel

TCHTraffic Channel

FCCHFrequency Correction CH

SCHSynchronization CH

BCCHBroadcast Control CHCBCHCell Broadcast CH

RACHRandom Access CH

AGCHAccess Grant CH

PCHPaging Channel

SDCCHStand Alone DCCHFACCHFast AssociatedControl ChannelSACCHSlow AssociatedControl Channel

NCHNotification Channel

Speech Channel

BCHBroadcast CH

DCCHDedicated CCH

CCCHCommon CCH

Data Channel

Fig. 4 Logical channels on the air-interface for circuit switched technology



10

DCCH (Dedicated Control Channels) Consist of the SDCCH (Stand Alone Dedicated Control Channel), which is used to process the call setup, location update and the IMSI attach/detach. The SDCCH prepares the connection on the traffic channel (TCH). Once the connection has been made, the SACCH and FACCH deal with the signaling traffic. The SACCH (Slow Associated Control Channel) is chiefly used for transmitting measurement values between MS and BTS. Due to its low transmission rate and the long delay time this channel is not suitable if the signaling has to be performed quickly. If signaling data has to be exchanged immediately (e.g. emergency handover), the FACCH (Fast Associated Control Channel) is used. By using the „ frame-stealing “ procedure it transmits its data via the TCH by transmitting a signaling block instead of a user data block (speech or data). The user data block intended for this position is lost. The DCCH is bi-directional; it is sent uplink and downlink. CCCH (Common Control Channels) The common control channels are used to set up a call between BTS and MS. The mobile station (MS) requests a dedicated channel, the SDCCH, on the RACH Random Access Channel). The BTS responds on the AGCH (Access Grant Channel) and assigns the SDCCH to the MS. If a mobile station is to be called, this is done on the PCH (Paging Channel). The common control channels are unidirectional. AGCH and PCH are downlink and the RACH is uplink. NCH (Notification Channel) is used for Voice Group Call Service (VGCS) and for Voice Broadcast Service (VBS).



11

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MOC / MTC

Radio Interface (Layer 1)

RACH: Channel Request

AGCH: Immediate Assign

SDCCH: CM Service Request

SDCCH: Authentication Request

SDCCH: Authentication Response

SDCCH: Cipher Mode Command

SDCCH: Cipher Mode Complete

SDCCH: Setup

SDCCH: Call Proceeding

SDCCH: Assign Command

•••

Fig. 5 An example for signaling on Air interface



12

1.2.2 Layer 2

Link Access Procedure on the Dm (LAPDm) The LAPDm (Link Access Procedure on the Dm, GSM 04.06) protocol is used for all channels on the air interface except SCH, FCCH and TCH. The purpose of LAPDm is to convey information between layer 3 entities across the GSM PLMN radio interface using the Dm channel. Especially the LAPDm will support:

• multiple layer 3 entities

• multiple physical layer entities

• BCCH, PCH, AGCH, DCCH signaling. The most important LAPDm functions are:

• channel de/multiplexing

• handling of the layer 2 connections

• error correction

• flow control. The address field of a LAPDm message consists of a Link Protocol discriminator (LPD, discriminator for GSM or other protocols), a Service access point identifier (SAPI, discriminator between SMS and layer 3 parts (RR, MM, CC) and a Command response field Bit (C/R, discriminator between commands and responses). The control field differentiates the following types:

• Information frames (I-frames)

• Supervisory frames (S-frames)

• Unnumbered frames (U-frames). The following table will show you the types of commands and messages:

Format I S S S U U U U U

Commands I RR RNR REJ SABM UI DISC

Responses RR RNR REJ DM UA Overview LAPDm frames

RR Receive Ready UI Unnumbered format RNR Receive not Ready DISC Disconnect REJ Reject UA Unnumbered Acknowledge DM Disconnect Mode SABM Set Asynchronous Balanced Mode



13

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LPD SAPI C / R1

2

Length M

Address Field

Control Field

Length Indicator

Layer 3

Fill bits

3

n

23

Fig. 6 Structure of the Layer 2 frame (acc. to GSM04.06)



14

1.2.3 Layer 3 The layer 3 for circuit switched traffic is composed of three sublayers comprising:

• the Radio Resource Management (RR) functions

• the Mobility Management (MM) functions

• the Connection Management (CM) functions. The Layer 3 messages can only contain maximal 249 Bytes. They are sent between the MS and the BTS or BSC. The following figure will give you an overview about the Layer 3 connections between the MS and the network.



15

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BSS SIEMENS D900SIEMENS D900

MSC

CM connection

MM connection

RR connection SCCP conn.

Fig. 7 Layer 3 connections between the MS and the network for circuit switched traffic



16

1.2.3.1 Radio Resource Management (RR) The Radio Resource management (GSM 04.08) messages will be sent between MS and BTS / BSC. Many RR messages will be transported over the Abis Interface within the RSL / DTAP to the BSC. Radio Resource management procedures include the functions related to the management of the common transmission resources, e.g. the physical channels and the data link connections on control channels. The general purpose of Radio Resource procedures is to establish, maintain and release RR connections that allow a point-to-point dialogue between the network and a Mobile Station. This includes the cell selection/reselection and the handover procedures. Moreover, Radio Resource management procedures include the reception of the uni-directional BCCH and CCCH when no RR connection is established. This permits automatic cell selection/reselection.



17

The elementary procedures for Radio Resource management are as follows:

Idle mode procedures: System information broadcasting Paging

RR connection establishment procedures: Entering the dedicated mode: immediate assignment procedure Entering the group transmit mode: uplink access procedure Paging procedure for RR connection establishment Notification procedure

Procedures in dedicated mode and in group transmit mode: SACCH procedures Channel assignment procedure Handover procedure Frequency redefinition procedure Channel mode modify procedure Ciphering mode setting procedure Additional channel assignment procedure Partial channel release procedure Classmark change procedure Classmark interrogation procedure RR connection release procedure Group receive mode procedures Configuration change procedure

The following table summarizes Radio Resource Management messages:



18

RADIO RESOURCE MANAGEMENT MESSAGES (GSM 04.18-850) Channel establishment messages: Reference ADDITIONAL ASSIGNMENT IMMEDIATE ASSIGNMENT IMMEDIATE ASSIGNMENT EXTENDED IMMEDIATE ASSIGNMENT REJECTED

9.1.1 9.1.18 9.1.19 9.1.20

DTM ASSIGMENT FAILURE DTM REJECT DTM REQUEST MAIN DCCH ASSIGNMENT PACKET ASSIGNMENT RR INITIALISATION REQUEST

9.1.12f 9.1.12g 9.1.12h 9.1.20a 9.1.21f 9.1.28a

Ciphering messages: Reference CIPHERING MODE COMMAND CIPHERING MODE COMPLETE

9.1.9 9.1.10

Handover messages: Reference ASSIGNMENT COMMAND ASSIGNMENT COMPLETE ASSIGNMENT FAILURE DTM ASSIGNMENT COMMAND INTER SYSTEM TO UTRAN HANDOVER COMMAND PDCH ASSIGNMENT COMMAND HANDOVER ACCESS HANDOVER COMMAND HANDOVER COMPLETE HANDOVER FAILURE RR-CELL CHANGE ORDER PHYSICAL INFORMATION INTER SYSTEM TO CDMA2000 HANDOVER COMMAND

9.1.2 9.1.3 9.1.4 9.1.12e 9.1.15a 9.1.13a 9.1.14 9.1.15 9.1.16 9.1.17 9.1.21e 9.1.28 9.1.15b



19

Channel release messages: Reference CHANNEL RELEASE PARTIAL RELEASE PARTIAL RELEASE COMPLETE

9.1.7 9.1.26 9.1.27

Paging messages: Reference PACKET NOTIFICATION PAGING REQUEST TYPE 1 PAGING REQUEST TYPE 2 PAGING REQUEST TYPE 3 PAGING RESPONSE

9.1.21g 9.1.22 9.1.23 9.1.24 9.1.25

System information messages: Reference SYSTEM INFORMATION TYPE1 SYSTEM INFORMATION TYPE2 SYSTEM INFORMATION TYPE2bis SYSTEM INFORMATION TYPE2ter SYSTEM INFORMATION TYPE2quater SYSTEM INFORMATION TYPE3 SYSTEM INFORMATION TYPE4 SYSTEM INFORMATION TYPE5 SYSTEM INFORMATION TYPE5bis SYSTEM INFORMATION TYPE5ter SYSTEM INFORMATION TYPE6 SYSTEM INFORMATION TYPE7 SYSTEM INFORMATION TYPE8 SYSTEM INFORMATION TYPE9 SYSTEM INFORMATION TYPE13 SYSTEM INFORMATION TYPE16 SYSTEM INFORMATION TYPE17 SYSTEM INFORMATION TYPE18 SYSTEM INFORMATION TYPE19 SYSTEM INFORMATION TYPE20

9.1.31 9.1.32 9.1.33 9.3.34 9.3.34a 9.1.35 9.1.36 9.1.37 9.1.38 9.1.39 9.1.40 9.1.41 9.1.42 9.1.43 9.1.43a 9.1.43d 9.1.43e 9.1.43g 9.1.43f 9.1.43h



20

Specific messages for VBS/VGCS: Reference NOTIFICATION/FACCH NOTIFICATION/NCH NOTIFICATION RESPONSE TALKER INDICATION UPLINK ACCESS

9.1.21a 9.1.21b 9.1.21d 9.1.44 9.1.45

Specific messages for VBS/VGCS: Reference UPLINK BUSY UPLINK FREE UPLINK RELEASE VGCS UPLINK GRANT

9.1.46 9.1.47 9.1.48 9.1.49

Measurement specific messages: Reference EXTENDED MEASUREMENT ORDER EXTENDED MEASUREMENT REPORT MEASUREMENT REPORT MEASUREMENT INFORMATION ENHANCED MEASUREMENT REPORT

9.1.51 9.1.52 9.1.21 9.1.54 9.1.55

Miscellaneous messages: Reference CHANNEL MODE MODIFY CHANNEL MODE MODIFY ACKNOWLEDGE CHANNEL REQUEST CLASSMARK CHANGE CLASSMARK ENQUIRY UTRAN CLASSMARK CHANGE cdma2000 CLASSMARK CHANGE UE RAB PRE-CONFIGURATION FREQUENCY REDEFINITION MEASUREMENT REPORT SYNCHRONIZATION CHANNELS INFORMATION RR STATUS GPRS SUSPENSION REQUEST

9.1.5 9.1.6 9.1.8 9.1.11 9.1.12 9.1.11a 9.1.11b 9.1.11c 9.1.13 9.1.21 9.1.30 9.1.29 9.1.13b



21

Configuration Change messages: Reference CONFIGURATION CHANGE COMMAND CONFIGURATION CHANGE ACKNOWLEDGE CONFIGURATION CHANGE REJECT

9.1.12b 9.1.12c 9.1.12d

Application messages: Reference

APPLICATION INFORMATION 9.1.53



22

1.2.3.2 Mobility Management (MM) The Mobility Management (GSM 04.08) messages will be sent between MS and MSC and have no influences to the BSS. The MM messages will be transported over the Abis and A-Interface within the RSL / DTAP and DTAP to the BSC. The main function of the Mobility Management sublayer (GSM 04.08) is to support the mobility of user terminals, such as informing the network of its present location and providing user identity confidentiality. A further function of the MM sublayer is to provide connection management services to the different entities of the upper Connection Management (CM) sublayer. The elementary procedures for Mobility Management are as follows:

• MM common procedures: TMSI reallocation procedure Authentication procedure Identification procedure IMSI detach procedure Abort procedure MM information procedure

• MM specific procedures: Location updating procedure Periodic updating IMSI attach procedure Generic Location Updating procedure

• Connection management sublayer service provision: MM connection establishment MM connection information transfer phase MM connection release

The following table summarizes Mobility Management messages.



23

MOBILITY MANAGEMENT MESSAGES (3GPP TS24.008-350) Registration messages: Remarks IMSI DETACH INDICATION 9.2.12

LOCATION UPDATING ACCEPT 9.2.13

LOCATION UPDATING REJECT 9.2.14

LOCATION UPDATING REQUEST 9.2.15

Security messages: AUTHENTICATION REJECT 9.2.1

AUTHENTICATION REQUEST 9.2.2

AUTHENTICATION RESPONSE 9.2.3

IDENTITY REQUEST 9.2.10

IDENTITY RESPONSE 9.2.11

TMSI REALLOCATION COMMAND 9.2.17

TMSI REALLOCATION COMPLETE 9.2.18

Connection management messages: CM SERVICE ACCEPT 9.2.5

CM SERVICE REJECT 9.2.6

CM SERVICE ABORT 9.2.7

CM SERVICE REQUEST 9.2.9

CM RE-ESTABLISHMENT REQUEST 9.2.4

ABORT 9.2.8

Miscellaneous messages: MM INFORMATION 9.2.15a

MM STATUS 9.2.16

MM NULL 9.2.19



24

1.2.3.3 Connection Management (CM) The Connection Management (CM) sublayer is composed of: Call Control (CC) Short Message Service Support (SMS) Supplementary Services Support (SS) The CC messages will be sent between the MS and the MSC and will therefore be considered mainly. Every mobile station must support the call control protocol. If a mobile station does not support any bearer capability at all then it shall respond to a SETUP message with a RELEASE COMPLETE message. In the call control protocol, more than one CC entity are defined. Each CC entity is independent from each other and shall communicate with the correspondent peer entity using its own MM connection. Different CC entities use different transaction identifiers. The elementary procedures for circuit switched Call Control are as follows:

Call establishment procedures: Mobile originating call establishment Mobile terminating call establishment

Signaling procedures during the "active" state User notification procedure Call rearrangements User initiated level up- and downgrading

Call clearing Clearing initiated by the mobile station Clearing initiated by the network Clear collision

Miscellaneous procedures In-band tones and announcements Call collisions Status procedures Call re-establishment, mobile station side Call re-establishment, network side DTMF protocol control procedure.



25

CALL CONTROL MESSAGES (3GPP TS24.008-350) Call establishment messages: Remarks ALERTING 9.3.1

CALL CONFIRMED 9.3.2

CALL PROCEEDING 9.3.3

CONNECT 9.3.5

CONNECT ACKNOWLEDGE 9.3.6

EMERGENCY SETUP 9.3.8

PROGRESS 9.3.17

SETUP 9.3.23

Call information phase messages: MODIFY 9.3.13

MODIFY COMPLETE 9.3.14

MODIFY REJECT 9.3.15

USER INFORMATION 9.3.31

Call clearing messages: DISCONNECT 9.3.7

RELEASE 9.3.18

RELEASE COMPLETE 9.3.19

Messages for supplementary service control:

FACILITY 9.3.9

HOLD 9.3.10

HOLD ACKNOWLEDGE 9.3.11

HOLD REJECT 9.3.12

RETRIEVE 9.3.20

RETRIEVE ACKNOWLEDGE 9.3.21

RETRIEVE REJECT 9.3.22



26

Miscellaneous messages: Remarks CONGESTION CONTROL 9.3.4

NOTIFY 9.3.16

START DTMF 9.3.24

START DTMF ACKNOWLEDGE 9.3.25

START DTMF REJECT 9.3.26

STATUS 9.3.27

STATUS ENQUIRY 9.3.28

STOP DTMF 9.3.29

STOP DTMF ACKNOWLEDGE 9.3.30



27

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Layer 3 Network Layer

CC

CallControl

SSS

SupplementaryServicesSupport

SMS

ShortMessageService

CM Connection Management

MM Mobility Management

RR Radio Resource Management

Layer 2 Data Link Layer

Layer 1 Physical Layer

Fig. 8 Layers to 3 at the Air interface; the sublayers of layer 3



28

1.2.4 Abis interface Abis interface is the three layer interface composed of:

• Layer 1, physical layer, realized as PCM system.

• Layer 2 realized as standard LAPD

• Layer 3, user part.

1.2.4.1 Layer 1 The A-bis interface is physical 2 Mbit PCM System with 16 Kbit/s subchannels. These 16 Kbit/s subchannels can be used for signaling and speech. The 16 Kbit/s speech information will be transformed in the TRAU to 64 Kbit/s.



29

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LAPD

RR

L 2 M

O& M

R S L

D T A P

LAPDm

BTS

Layer 1 Layer 1

LAPD

DTAP

L 2 M

O& M

RS L

DT A P

MTP

to UM

MSC A-bis

BSC

Layer 1

BSSMAP

SCCP

Layer 1

Fig. 9 Protocols on the A-bis interface



30

1.2.4.2 Layer 2- Link Access Protocol D-Channel (LAPD) The LAPD protocol is used for transferring all channels on the A-bis interface. The purpose of LAPD is to convey information between layer 3 entities across the A-bis Interface. LAPD is a connection procedure of the data link layer in packet-oriented networks and is specified in CCITT Q920 and Q921. The most important LAPD functions are:

• channel de-/multiplexing

• handling of layer 2 connections

• error correction

• flow control. The LAPD will use two transmission modes with and without acknowledge (e.g. Measurement reports). In the Service access point identifier (SAPI) there are three different possibilities for connection of a logical Link for a terminal endpoint:

• RSL, Radio Signaling link (per TRX) for traffic management SAPI = 0

• OML, O&M Link for network management SAPI = 62

• L2ML, Layer 2 management link SAPI = 63. The address field of a LAPD message contains extension address bit, terminal end point identifier (TEI), Service access point identifier (SAPI and a Command response field Bit (C/R, discriminator between commands and responses). The control field differentiates the following types:

• Information frames (I-frames)

• Supervisory frames (S-frames)

• Unnumbered frames (U-frames). The following table will show you the types of commands and messages:

Format I S S S U U U U U

Commands I RR RNR REJ SABM UI DISC

Responses RR RNR REJ DM UA Overview LAPD frames



31

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

LAPD Frame Types

Information Frames Supervisory Frames

RR (Receive Ready)

RNR (Receive Not Ready)

REJ (Reject)

Unnumbered Frames

SABME (Set AsynchronousBalanced Mode Extended)

DM (Disconnect Mode)

UI (Unnumbered Information)

DISC (Disconnect)

UA (Unnumb. Acknowledgm.

FRMR (Frame Reject)

Fig. 10 LAPD Frame types



32

1.2.4.3 Layer 3 Layer 3 is mainly responsible for activation, supervision and release of connections. Layer 3 consists of the following functions:

• Network Management Procedures (NMP)

• L2 Management (L2M)

• Traffic Management Procedures (TMP).

•

Network Management Procedures (NMP) The A-bis Interface supports the transmission of Network Management messages by usage of an O&M Link. The transport is done with LAPD. There are the following kinds of Layer 3 Network Management messages:

• formatted O&M messages

• MMI transfer messages

• TRAU O&M messages.

L2 Management (L2M) The Layer 2 Management Link is used for transmission of Layer 2 messages between BSC and TRX, for example for Alarms.



33

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7 6 5 4 3 2 1 0 Bit-No

0 1 1 1 1 1 1 0

SAPI C/R EA

TEI EA

N(S) 0

N(R) P

Opening flag

Address field

Control field of aninformation frame

Layer 3 data(max. 260 octets)

Frame check sequence

Closing flag

FCS

FCS

0 1 1 1 1 1 1 0

Channel number identifierMessage type

Channel numberLayer 3 Header

Message Identificator

Fig. 11 Layer 3 on Abis (RSL)



34

Traffic Management Procedures (TMP) The Traffic Management procedures are separated into transparent and non-transparent procedures. The transparent Layer 3 Traffic Management procedures of the Radio signaling link will be transmitted without any change through the BTS. The content of transparent messages belongs to:

• the Radio Resource Management (RR) functions

• the Mobility Management (MM) functions

• the Connection Management (CM) functions. The non-transparent Layer 3 Traffic Management procedures of the Radio signaling link can be divided into four groups:

• Radio Signaling Link Layer Management responsible for connection, support and release of L2 radio connections. All BTS transparent messages will be translated to the primitives of the radio interface.

• Dedicated Channel Management for usage of DCCHs and for channel activation, HOV detection, ciphering, power control, etc.

• Common Channel Management for usage of CCCH for Random access procedures, immediate assignment, Paging or Broadcast.

• TRX Management for information transfer between TRX and BTS Controller.

The following tables summarize Traffic Management Procedures messages.



35

RADIO LINK LAYER MANAGEMENT MESSAGES (GSM 08.58-860) Message name Reference sectionDATA REQuest 8.3.1

DATA INDication 8.3.2

ERROR INDication 8.3.3

ESTablish REQuest 8.3.4

ESTablish CONFirm 8.3.5

ESTablish INDication 8.3.6

RELease REQuest 8.3.7

RELease CONFirm 8.3.8

RELease INDication 8.3.9

UNIT DATA REQuest 8.3.10

UNIT DATA INDication 8.3.11



36

DEDICATED CHANNEL MANAGEMENT MESSAGES (GSM 08.58-860) Message name Reference section CHANnel ACTIVation 8.4.1

CHANnel ACTIVation ACKnowledge 8.4.2

CHANnel ACTIVation Negative ACK 8.4.3

CONNection FAILure INDication 8.4.4

DEACTIVATE SACCH 8.4.5

ENCRyption CoMmanD 8.4.6

HANDOver DETection 8.4.7

TALKER DETection 8.4.21

LISTENER DETection 8.4.22

MEASurement RESult 8.4.8

MODE MODIFY REQuest 8.4.9

MODE MODIFY ACKnowledge 8.4.10

MODE MODIFY Negative ACKnowledge 8.4.11

PHYsical CONTEXT REQuest 8.4.12

PHYsical CONTEXT CONFirm 8.4.13

RF CHANnel RELease 8.4.14

MS POWER CONTROL 8.4.15

BS POWER CONTROL 8.4.16

PREPROCecc CONFIGure 8.4.17

Pre-processed MEASurement RESult 8.4.18

RF CHANnel RELease ACKnowledge 8.4.19

SACCH INFO MODIFY 8.4.20



37

Message name Reference section REMOTE CODEC CONFiguration REPort 8.4.23

Round Trip Delay REPort 8.4.24

PRE-HANDOver NOTIFication 8.4.25

MultiRate CODEC MODification REQuest 8.4.26

MultiRate CODEC MOD ACKnowledge 8.4.27

MultiRate CODEC MOD Negative ACK 8.4.28

MultiRate CODEC MOD PERformed 8.4.29

TFO REPort 8.4.30

TFO MODification REQuest 8.4.31

COMMON CHANNEL MANAGEMENT MESSAGES (GSM 08.58-860)

Message name Reference sectionBCCH INFOrmation 8.5.1

CCCH LOAD INDication 8.5.2

CHANnel ReQuireD 8.5.3

DELETE INDication 8.5.4

PAGING CoMmanD 8.5.5

NOTification CoMmanD 8.5.10

IMMEDIATE ASSIGN COMMAND 8.5.6

SMS BroadCast REQuest 8.5.7

SMS Broadcast Command 8.5.8

CBCH LOAD INDICATION 8.5.9

TRX MANAGEMENT MESSAGES (GSM 8.58-860) Message name Reference sectionRF RESource INDication 8.6.1

SACCH FILLing 8.6.2

OVERLOAD 8.6.3

ERROR REPORT 8.6.4



38

1.2.5 A-interface The A-Interface was defined by GSM and is the Interface between BSC and MSC. The interface comprises both signaling and user channels. On the A-Interface the MTP, SCCP, BSSAP (BSSMAP, DTAP) and the BSSOMAP (BSS Operation & Maintenance Part) protocols are used and will be described below.



39

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SS #7Signaling System #7

Physical & electrical attributes

Signaling Data Link

Signaling Network functionsMTP

MessageTransfer

Part

ISUPISDN

User Part

Layer

TUPTelephoneUser Part

DUPData

User Part

MAPMobile

ApplicationPart

TCAP

SCCP

TCAP: Transaction Capability Application PartSCCP: Signaling Connection Control Part

7

4 - 6

3

2

1

3

2

1

Level

4

Fig. 12 A-Interface / Signaling System #7



40

1.2.5.1 Message Transfer Part (MTP) The Message Transfer Part (MTP, GSM 08.08, CCITT Q701 - Q709) is responsible for transport of SCCP messages and therefore for the transport of BSSMAP, DTAP and BSSOMAP messages. The MTP will guarantee that the message will reach the Destination without loss of information, bit errors, or sequence changes. The Message Transfer Part consists of 3 layers:

Layer 1: Physical Layer It defines the physical, electrical and functional characteristics of a signaling data link and the means to access it.

Layer 2: Data Link Layer Defines the functions and procedures for and relating to the transfer of signaling messages over one individual signaling data link. These functions include:

• delimitation of signal units by means of flags;

• error detection by means of check bits included in each signal unit;

• error correction control by means of explicit sequence number in each signal unit.

Layer 3: Network Layer This layer defines the following functions:

• discrimination: this is used at a signaling point to distinguish whether a message is destined for itself or not. If not the message is passed to the routing function;

• routing: determines the onward routing of messages to the correct destination;

• distribution: this directs messages for the signaling point to the correct function or user part;

• network management: controls and maintains the status of the signaling network to which the signaling point is connected.

The tables in the following pages summarize the Message Transfer Part messages.



41

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BSSAPBSS Application Part

BSSMAP ⏐ DTAP

MAPMobile Application

Part

SCCPSignaling Connection Control Part

SS #7 for GSM

TCAPTransmission Capabilities

Application Part

ISUPISDN User Part

Connection relatedsignaling(MSC - MSC / ISDN) e.g.: • “Initial Address Message IAM”• “Address Complete• Message ACM”, “Alert”• “Answer Message”

Procedures supporting mobility(MSC - Register/MSC) e.g.: • “Update Location” (VLR → HLR)• “Insert / Delete Subscriber Data” (HLR → VLR)• “Send IMSI”, “Authenticate”, “Start Ciphering”, “Forward new TMSI” (VLR → MSC (MS))

A-Interface protocolsubdivided into

DTAPBSC not involved, transparent: MS ↔ CN.compare MM & CMBSSMAPBSC involved• “Paging”• “HOV Request”• “HOV Complete”

Enables its UP’s:• to take access to data bases / exchanges (world-wide via SS7)• to invoke transactions• to identify messagesof same transaction

Layer 1: Physical Layer

Layer 2: Data Link Layer

Layer 3: Network Layer

Offers (L3 extension): • Global Routing Global Title Translation GTT• service classes (Connection -oriented / -less)

Fig. 13 CCSS7 protocol architecture in the D900



42

MTP Layer 2 types of signal units FISU Fill in signal unit

LSSU Link status signal unit

SIO: Status indication Out of alignment

SIN: Status indication Normal alignment

SIE: Status indication Emergency alignment

SIOS: Status indication Out of Service

SIPO: Status indication Processor Outage

MSU Message signal unit

SIO: Service Information Octet

SIF: Signaling Information field

MTP Layer 3 messages

CBA Changeback-acknowledgement signal

CBD Changeback-declaration signal

CHM Changeover and changeback messages

CNP Connection-not-possible signal

CNS Connection-not-successful signal

COA Changeover-acknowledgement signal

COO Changeover-order signal

CSS Connection-successful signal

DLC Signaling-data-link-connection-order signal

DLM Signaling-data-link-connection-order message

ECA Emergency-changeover-acknowledgement signal

ECM Emergency-changeover message

ECO Emergency-changeover-order signal

FCM Signaling-traffic-flow-control messages



43

MTP Layer 3 messages (continued)

LFU Link forced uninhibit signal

LIA Link inhibit acknowledgement signal

LID Link inhibit denied signal

LIN Link inhibit signal

LLT Link local inhibit test signal

LUA Link uninhibit acknowledgement signal

LUN Link uninhibit signal

LRT Link remote inhibit test signal

MIM Management inhibit messages

RCT Signaling-route-set-congestion-test signal.

RSM Signaling-route-set-test message

RSR Signaling-route-set-test signal for restricted destination (national option)

RST Signaling-route-set-test signal for prohibited destination

TFA Transfer-allowed signal

TFC Transfer-controlled signal

TFM Transfer-prohibited-transfer-allowed-transfer-restricted messages

TFP Transfer-prohibited signal

TFR Transfer-restricted signal (national option)

TRA Traffic-restart-allowed signal

TRM Traffic-restart-allowed message

UFC User part flow control messages

UPU User part unavailable signal



44

1.2.5.2 Signaling Connection Control Part (SCCP) The Signaling Connection Control Part (SCCP, GSM 08.08) is used to support transport of signaling messages between the MSC and the BSS. The SCCP is responsible for transport of BSSMAP, DTAP and BSSOMAP messages. Various forms of addresses as the Signaling Point Code (SPC) and a general address Global Title (GT) as e.g. the service 130 of the German Telekom are used. The SCCP provides functions, which are additional to those of the MTP:

• translation and routing functions

• connectionless and connection-oriented transfer of signaling information

• transfer of circuit-related and non-circuit related signaling information

• segmented transfer of signaling information management functions.

Connection-oriented Services The connection-oriented services of the SCCP are controlled of the connection-oriented control (COC) function. With the COC the connection of two SCCP users is possible. This function contains all procedures, which are necessary for setup and release of signaling connections. For D900 only protocol class 2 is used on the A-Interface.

Connectionless Services The Connectionless Control (CLC) function of the SCCP controls the connectionless transfer of 2 SCCP Users. These messages (e.g. PAGING, RESET) have no relation to a speech channel. For messages on the A-Interface only protocol class 0 is used for BSSAP Users. Protocol class 1 is not relevant for the A-Interface. The following table summarizes SCCP messages.



45

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ISDN-UP

TCAP-user

Message transfer part (MTP)

TCAP

CCS7 user

TUP other MTPusers

SCCP

MSC/HLR or VLR

Fig. 14 Example of user parts(UP)



46

SCCP Message type code Message type Protocol classes Code 0 1 2 3 CR Connection Request X X 0000 0001

CC Connection Confirm X X 0000 0010

CREF Connection Refused X X 0000 0011

RLSD Released X X 0000 0100

RLC Release Complete X X 0000 0101

DT1 Data Form 1 X 0000 0110

DT2 Data Form 2 X 0000 0111

AK Data Acknowledgement X 0000 1000

UDT Unitdata X X 0000 1001

UDTS Unitdata Service X X 0000 1010

ED Expedited Data X 0000 1011

EA Expedited Data Ack. X 0000 1100

RSR Reset Request X 0000 1101

RSC Reset Confirm X 0000 1110

ERR Protocol Data Unit Error X X 0000 1111

IT Inactivity Test X X 0001 0000



47

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

SCCP

ProtocolClass 0

ProtocolClass 1

ProtocolClass 3

single messagewith individual

routing

messagegroups

with commonrouting

(not relevant forBSSAP)

signalingconnectionswith uniform

routing

signalingconnectionswith uniformrouting and message

numbering(not relevant for

D900)

connectionlessorientedservices

connectionorientedservices

ProtocolClass 2

Fig. 15 The services and protocol classes of SCCP



48

1.2.5.3 Base Station System Application Part (BSSAP) The Base Station System Application Part (BSSAP, GSM 04.08/08.08), also called Radio Subsystem Application part, is subdivided into the Direct Transfer Application Part (DTAP) and the Base Station System Management Part (BSSMAP).

Base Station System Management Part (BSSMAP) The Base Station System Management Part (BSSMAP, GSM 08.06, 08.08) supports all of the procedures between the MSC and the BSS that require interpretation and processing of information related to single calls, and resource management. Some of the BSSMAP procedures result in, or are triggered by, Radio Resource (RR) management messages. The BSSMAP messages will be transferred within the SCCP as connectionless or connection-oriented messages. There are the following main BSSMAP procedures: Assignment Release Blocking Paging Resource indication Flow control Reset Classmark update Handover required indication Cipher mode control Handover resource allocation Trace invocation Handover execution Initial MS message Handover candidate inquiry Queuing indication Data link control Reset circuit The following table summarizes BSSMAP messages.



49

BSSMAP MESSAGES (GSM 08.08-850) Message name GSM Reference ASSignment REQuest 3.2.1.1.

ASSignment COMplete 3.2.1.2.

ASSignment FAILure 3.2.1.3.

BLOck 3.2.1.4.

BLocking Acknowledge 3.2.1.5.

circuit group block 3.2.1.41.

circuit Group blockING acknowledge 3.2.1.42.

circuit group unblock 3.2.1.43.

circuit group unblockING acknowledge 3.2.1.44.

CLear command 3.2.1.21.

CLeaR COMplete 3.2.1.22.

CLeaR REQuest 3.2.1.20.

UnBLOck 3.2.1.6.

UnBLocking Ack 3.2.1.7.

HaNDover CaNDidate ENQuirE 3.2.1.14.

HaNDover CaNDidate RESponse 3.2.1.15.

HaNDover REQuest 3.2.1.8.

HaNDover ReQuireD 3.2.1.9.

HaNDover ReQuireD Reject 3.2.1.37.

HaNDover ReQuest ACKnowledge 3.2.1.10.

HaNDover COMmand 3.2.1.11.

HaNDover CoMPlete 3.2.1.12.

HaNDover Succeeded 3.2.1.13.

HaNDover FaiLuRe 3.2.1.16.

HaNDover PerForMed 3.2.1.25.

HaNDover DETect 3.2.1.40.



50

BSSMAP MESSAGES(GSM 08.08-850) (cont.) Message name GSM Reference RESource REQuest 3.2.1.17.

ReSeT 3.2.1.23.

ReSeT ACK 3.2.1.24.

RESource indication 3.2.1.18.

Paging 3.2.1.19.

Overload 3.2.1.26.

MSC Invoke trace 3.2.1.27.

BSS Invoke trace 3.2.1.28.

Classmark update 3.2.1.29.

CLASSMARK REQUEST 3.2.1.46.

Cipher Mode Command 3.2.1.30.

Cipher Mode Complete 3.2.1.31.

Cipher mode Reject 3.2.1.48.

Complete layer 3 information 3.2.1.32.

Queuing indication 3.2.1.33.

SAPI „n“ reject 3.2.1.34.

Reset circuit 3.2.1.38.

Reset circuit acknowledge 3.2.1.39.

CONFUSION 3.2.1.45.

UNEQUIPPED CIRCUIT 3.2.1.47.

Load indication 3.2.1.49.

VGCS/VBS SETUP 3.2.1.50.

VGCS/VBS SETUP ACK 3.2.1.51.

VGCS/VBS SETUP REFUSE 3.2.1.52.

VGCS/VBS ASSIGNMENT REQUEST 3.2.1.53.

VGCS/VBS ASSIGNMENT RESULT 3.2.1.54.

VGCS/VBS ASSIGNMENT FAILURE 3.2.1.55.

VGCS/VBS QUEUING INDICATION 3.2.1.56.



51

BSSMAP MESSAGES (GSM 08.08-850) (cont.) Message name GSM Reference UPLINK REQUEST 3.2.1.57.

UPLINK REQUEST ACKNOWLEDGE 3.2.1.58.

UPLINK REQUEST CONFIRMATION 3.2.1.59.

UPLINK RELEASE INDICATION 3.2.1.60.

UPLINK REJECT COMMAND 3.2.1.61.

UPLINK RELEASE COMMAND 3.2.1.62.

UPLINK SEIZED COMMAND 3.2.1.63.

SUSPEND 3.2.1.64.

RESUME 3.2.1.65.

CHANGE CIRCUIT 3.2.1.66.

CHANGE CIRCUIT ACKNOWLEDGE 3.2.1.67.

LSA INFORMATION 3.2.1.69.

CONNECTION ORIENTED INFORMATION 3.2.1.70.

PERFORM LOCATION REQUEST 3.2.1.71.

PERFORM LOCATION RESPONSE 3.2.1.72.

PERFORM LOCATION ABORT 3.2.1.73.

CONNECTIONLESS INFORMATION 3.2.1.74.



52

Direct Transfer Application Part (DTAP) The Direct Transfer Application Part (DTAP) is used to transfer call control (CC) and mobility management messages (MM) between the MSC and the MS. The DTAP information in these messages is not interpreted by the BSS. GSM 08.06 contains more detail relating to the handling of DTAP messages at the BSS, the multiplexing of the messages onto the relevant signaling channels of the radio interface, and the use of the SCCP services. Messages received from the MS are identified as DTAP by the Protocol Discriminator Information Element as described in GSM 04.08, except for Initial Layer 3 messages. The majority of radio interface messages are transferred across the BSS MSC interface by the DTAP, the exceptions being messages belonging to the Radio Resource (RR) management protocol.



53

1.2.6 Example: setup message In the following example a Setup Message sent from the MS to the MSC is regarded.

MS BTS BSC

Setup (CC)

MSC

Layer 1

LAPDm (Info)

Setup (CC)

DTAP

LAPD (Info)

Datin (RSL)

Setup (CC)

DTAP

Layer 1

MSU (MTP)

DT1 (SCCP)

Setup (CC)

DTAP

Layer1 (MTP)

Fig. 16 Example: setup message sent from the MS to the MSC



54

Setup : A-bis Interface 08:13:35"0 3Rx< LAPD 0 0 0 0 0 101 INFO 1 SDCCH+ACCH RSL DATIN GSM 08.56 Rev 3.1.0 (LAPD) Info frame (INFO) -------0 Address field ext. ------0- Command/Response 0 000000-- SAPI 0 -------1 Address field ext. 0000000- TEI 0 -------0 Frame Type Information transfer format 0000000- N(S) 0 -------0 Poll Bit don't poll 1100101- N(R) 101 GSM 08.58 Rev 3.5.0 (RSL ) DATA INDication (DATIN) -------1 Transparency bit transparent to BTS 0000001- Message Group Radio Link Layer Management messages 00000010 Message Type 2 Channel Number 00000001 IE Name Channel Number -----001 time slot number 1 01010--- channel SDCCH/8 + ACCH subchannel 2 Link Identifier 00000010 IE Name Link Identifier -----000 SAPI SAPI 0 (standard signaling) ---00--- Spare --0----- NA Bit Link Identifier applicable 00------ Channel Type main signaling channel (FACCH or SDCCH) L3 Information 00001011 IE Name L3 Information 00000000 Spare 00001101 LLSDU Length 13 ******** DTAP LLSDU 03 45 04 01 A0 5E 06 81 60 51 10 57 92 DTAP 3 SETUP CC Message Call establishment message DTAP GSM 04.08 Rev 3.11.0 (DTAP) Setup (SETUP) ----0011 Protocol Discriminator Call/Connection control, CR SS -000---- Transaction Id value TI value 0 0------- Transaction Id flag message sent from orig TI --000101 Message Type 0x5 -1------ Send Sequence Number 1 0------- Extension bit Bearer Capability 00000100 IE Name Bearer capability 00000001 IE Length 1 -----000 Info transfer capability Speech ----0--- Transfer mode Circuit mode ---0---- Coding standard GSM standardized coding -01----- Radio channel requirement Full rate channel 1------- Extension bit No Extension CaLleD party BCD number 01011110 IE Name Called party BCD number 00000110 IE Length 6 ----0001 Number plan ISDN/telephony numbering plan -000---- Type of number Unknown 1------- Extension bit No Extension ******** Called party number 0615017529



55

Setup: A-Interface 08:15:31"3 4Tx> SCCP 86 1 61 1 28 83 05-7-06-1 05-7-07-1 9 DT1 Blue Book SCCP (SCCP) Data Form 1 (DT1) -1010110 Backward Sequence Number 86 1------- Backward Indicator Bit 1 -0111101 Forward Sequence Number 61 1------- Forward Indicator Bit 1 --011100 Length Indicator 28 00------ Spare ----0011 Service Indicator SCCP --00---- Sub-Service: Priority Spare/priority 0 (U.S.A. only) 10------ Sub-Service: Network Ind National message ******** Destination Point Code 05-7-06-1 ******** Originating Point Code 05-7-07-1 ******** Signaling Link Selection 9 00000110 SCCP Message Type 0x6 ******** Destination Local Ref. 0x3904CF -------0 Segment/reass M indicator No more data 0000000- Spare 00000001 Ptr to Data parameter 1 Data parameter 00010000 Parameter length 16 ******** Data 01 00 0D 03 45 04 01 A0 5E 06 81 60 51 10 57 92 DTAP 13 3 SETUP CC Message Call establishment message DTAP GSM 04.08 Rev 3.11.0 (DTAP) Setup (SETUP) -------1 Discrimination bit D DTAP 0000000- Filler -----000 SAPI Signaling --000--- Spare 00------ Radio channel id fACCH or sDCCH 00001101 Message Length 13 ----0011 Protocol Discriminator Call/Connection control, CR SS -000---- Transaction Id value TI value 0 0------- Transaction Id flag message sent from orig TI --000101 Message Type 0x5 -1------ Send Sequence Number 1 0------- Extension bit Bearer Capability 00000100 IE Name Bearer capability 00000001 IE Length 1 -----000 Info transfer capability Speech ----0--- Transfer mode Circuit mode ---0---- Coding standard GSM standardized coding -01----- Radio channel requirement Full rate channel 1------- Extension bit No Extension CaLleD party BCD number 01011110 IE Name Called party BCD number 00000110 IE Length 6 ----0001 Number plan ISDN/telephony numbering plan -000---- Type of number Unknown 1------- Extension bit No Extension ******** Called party number 0615017529



56

1.3 Call sequences on Air and A- interface

1.3.1 Location update

SDCCH

BSS MSC

RACH

AGCH

SDCCH

SDCCH

SDCCH

SDCCH

SDCCH

Authentication Response (SRES)

UI (Imm. Assign.)(SDCCH-No, TA)

SABM(Loc. Upd. Req.,)

Authentication Request (RAND)

Channel Req(Reason =Loc. Upd., Rand. Ref.)

UA

I (Ciph. Comm.)

SDCCH I (Ciph.Mode Compl.)

TMSI Reallocation Complete

Location Update Accept

I

I

I

I

I (Channel Rel.)

DISC

UA

CR (Complete L3 Info)(Cell-Id., Loc. Upd. Req.)

CC

DT1

DT1

DT1 (Clear Command)

DT1 (Clear Compl.)

DT1 (Cipher Command)

DT1 (Cipher Compl.)

DT1

DT1

RLSD

RLC

Fig. 17 Location update



57

1.3.2 Mobile Originating Call (MOC)

SDCCH

BSS MSC

RACH

AGCH

SDCCH

SDCCH

SDCCH

FACCH

FACCH

Authentication Response (SRES)

SABM(CM Request)

Authentication Request (RAND)

Channel Req(Reason = MOC, Rand. Ref.).

UA

I (Ciph. Comm.)

SDCCH I (Ciph. Compl.)

and so onSet up

I

I

I

I (Ass. Command)

SABM

UA

CR (Complete L3 Info)(Cell-Id., MOC.)

CC

DT1

DT1 (Assign Request)


DT1 (Cipher Compl.)

DT1

DT1

DT1 (Assign Complete)FACCH I (Ass. Complete)


Fig. 18 Mobile Originating Call (MOC)



58

1.3.3 Mobile Terminating Call (MTC)

SDCCH

BSS MSC

PCH

RACH

AGCH

SDCCH

SDCCH

UI (Paging Req.)

SABM(Paging Resp.)

UA

SDCCH

Authentication Request (RAND)I

I (Ciph. Comm.)

I (Ciph. Compl.)

CR (Complete L3 Info)(Cell-Id., MTC.)

CC

DT1


DT1 (Cipher Compl.)

UDT (Paging)

Authentication Response (SRES)I DT1

Set up

and so on

Channel assignment as with Mobile Originating Calls

I DT1


Channel Req(Reason = MTC, Rand. Ref.).

Fig. 19 Mobile Terminating Call (MTC)



59

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I (Handover Command)(data about new cell, new

TCH-No., handover reference)

FACCH old

FACCH old Receive Ready

FACCH new

FACCH new

FACCH new

FACCH newHandover Access

(Handover Reference)

FACCH new

FACCH newUA

FACCH new I (Handover Complete)

SABM

FACCH newReceive Ready

Handover Access


Handover Access


Handover Access


Fig. 20 Synchronous Handover on Abis interface



60

1.3.4 Call clear down

FACCH

BSS MSC

Disconnect

Release

UA

I

I

RLSD

DT1

DT1

Initiatedby the mobile station:

Release CompleteI DT1

FACCHI (Channel Rel.) DT1 (Clear Command)

FACCH DISC DT1 (Clear Complete)

RLC

FACCH

BSS MSC

Disconnect

Release

UA

I

I

RLSD

DT1

DT1

Initiatedby the partner side:

Release CompleteI DT1

FACCHI (Channel Rel.) DT1 (Clear Command)

FACCH DISC DT1 (Clear Complete)

RLC

FACCH RR

Fig. 21 Call clear down



61

1.3.5 Differences between important complete call sequences The following table will give you an overview in an abstract form about differences between mobile originated call (MOC), mobile terminated call (MOC) and Location Update (LOCUPD).

Differences between important complete call sequences: Message / Procedure MOC MTC LOCUPD Paging Message X

Immediate Assignment Procedure X X X

Security Procedures * (Authentication, Identity check, Ciphering)

X X X

Setup Message X X

Location update accept Message X

TMSI Reallocation Message* X X X

Assignment Procedure X X

Alert, Connect, Connect Acknowledge Messages X X

Disconnect, Release, Release Complete Messages X X

Clearing Procedure X X X

* These procedures are not always performed. It can be administered in the Siemens MSC how often the procedures to be executed.



62

1.4 Call Connection analysis

1.4.1 General Some KPIs will be defined in this chapter analyzing call and signaling transactions. As an example for the allocation of a TCH, the circuit switched call setup and its release will be shown. The complete Call Setup procedure is divided into three parts: 1. Immediate Assignment (assignment of a signaling channel, exception Direct

Assignment) 2. SSS Procedure (Authentication, Ciphering, Check IMEI) 3. Assignment Procedure (assignment of a TCH). The last part of the call connection is the release of the call. The analysis of Call Setup procedure and associated KPIs is derived from the analysis of the above mentioned procedures and their KPIs. Handover procedures that may occur during an ongoing connection are also the subject of analyses and have some KPI defined. In general, the analysis of different procedures is based on Performance Measurements Message Flows, e.g. flows of messages that are exchanged between the network elements (MS, BTS, BSC and MSC) during a certain procedure. These Message Flows contain in addition embedded PM counters that are associated to their triggering events. When certain event happens a message is issued that trigger associated PM counter in the SBS. The scanners gather data by adapting the counters assigned to them at certain events.



63

1.4.2 Message flows of basic circuit switched BSS procedures

1.4.2.1 Immediate assignment procedure The immediate assignment procedure is used to create a signaling connection between the MS and the network. It can be initiated only by the MS. The reason for this may be:

• response to a PAGING REQUEST message

• location update

• call setup

• etc. With a CHANNEL REQUEST message on the RACH the MS signals the BTS that it requires a signaling channel (SDCCH). This message contains the information field „establishment cause and random reference“. The „establishment cause“ gives the reason why the MS is requesting a SDCCH. Possible reasons are:

• emergency call

• call re-establishment

• answer to paging

• originating speech call

• originating data call

• location updating

• another procedures, which can be completed with an SDCCH.



64

The BTS forwards the request to the BSC with a CHANNEL REQUIRED message. The BSC selects a free SDCCH and instructs the BTS with a CHANNEL ACTIVATION message to activate it. If the SDCCH is successfully activated, the BTS responds with a CHANNEL ACTIVATION ACKNOWLEDGE message. If not, it sends a CHANNEL ACTIVATION NEGATIV ACKNOWLEDGE message. Channel activation may fail for the following reasons:

• O&M intervention (channel blocked)

• channel already occupied

• hardware fault. The BSC then sends to the BTS an IMMEDIATE ASSIGNMENT COMMAND message, which is forwarded to the MS, to instruct the MS to activate the channel. In case of a failure the BSC sends an IMMEDIATE ASSIGNMENT REJECT message to the BTS and further on to the MS. If the BTS is not able to send the IMMEDIATE ASSIGNMENT message due to the Access Grant Channel (AGCH) being overloaded, it notifies the BSC of this with a DELETE INDICATION message. When the MS receives the IMMEDIATE ASSIGNMENT message, it switches to the assigned channel and activates it. By sending an SABM frame containing a „Service Request Message“, it switches the SDCCH to the „Multiple Frame Acknowledge“ mode, there by activating it. The Service Request message helps the network to recognize the service being requested by the MS. This information is used to decide how to proceed. Service request messages are:

• CM SERVICE REQUEST

• LOCATION UPDATING REQUEST

• IMSI DETACH

• PAGING RESPONSE

• CM REESTABLISHMENT REQUEST The BTS sends confirmation to the MS, that it has received the service by means of a UA frame. The BTS also informs the BSC with an ESTABLISH INDICATION message, which also contains the service request message. Further coordination procedures (authentication, ciphering etc.) are now performed on the SDCCH.



65

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IMMEDIATE ASSIGNMENT PROCEDURE

MS BTS BSC

CHANNEL REQUEST

CHANNEL REQUIRED

(NATTSDPE, NACSUCPR, ATIMASCA,ASDCALTI, ATSDCMBS, NINVRACH)

CHANNEL ACTIV

CHANNEL ACTIV ACK

CHANNEL ACTIV NEG. ACK

IMMEDIATE ASS CMD

IMMEDIATE ASS REJECT

(TACCBPRO, SUIMASCA, NACSUCPR)

DELETE INDICATION

IMMEDIATE ASS CMD

IMMEDIATE ASS REJECT

SABM

UAESTABLISH INDICATION (*)

(NSUCCHPC, NASUSDPE)

(NACSUCPR)

*CM Service Request, Locupd Request,Paging Response

Fig. 22 Immediate Assignment procedure



66

1.4.2.2 Paging procedure The paging procedure is used to inform the mobile station (MS) that a connection setup is being requested. In case of a mobile terminated call the MSC/VLR, has to send a PAGING message to all BSC belonging to the location area, where the MS is located. The PAGING message, contains the temporary mobile station identity (TMSI) and the location area of the MS. This message can be repeated after a certain time (MSC Timer value, e.g. 8s ) containing now IMSI and TMSI, if there was no response. All involved BSC then generates a PAGING COMMAND message, which will be transmitted to all the BTSs in the location area. If a BTS gets a PAGING COMMAND message, it transmits a PAGING REQUEST message on the paging channel (PCH). The PAGING REQUEST message contains the TMSI (IMSI). A MS which receives a PAGING REQUEST message, checks whether the received TMSI / IMSI is identical with the TMSI (IMSI) on the SIM card. If this is the case, it initiates an „immediate assignment“ procedure to occupy an SDCCH. If the SDCCH was occupied, the BSC sends a CONNECTION REQUEST including the COMPLETE LAYER 3 INFORMATION message to the MSC. If the MSC/VLR has lost the LAC of a MS, then the Searching Procedure is used instead of the paging procedure. Then the PAGING message is sent to all cells of the MSC/VLR area. If the MS is attached in the network a Periodic Location Update is done periodically. The time can be administered in the BSC. The Detach Time, to detach the MS in the MSC/VLR, has however to be administered in the MSC. The following rule has to be valid, that a mobile terminating call is always possible. Detach Timer (MSC) > Periodic Location Update Timer (BSC).



67

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MS BTS BSC MSC

PAGING PROCEDURE

IMMEDIATEASSIGNMENT

PAGINGPAGING COMMAND

PAGING REQUEST

CHANNEL REQUIRED

(NATTSDPE, NACSUCPR,ATIMASCA, ASDCALTI,

ATSDCMBS)CHANNEL REQUEST

CHANNEL ACTIV

CHANNEL ACTIV ACK

IMMEDIATE ASS CMD

(TACCBPRO, SUIMASCA,NACSUCPR)

CR (COMP LAYER3INFO (PAG RES))

ESTABLISH INDICATION(NSUCCHPC)

(TACCBPRO)

IMMEDIATE ASS CMD

UA(PAGING RESPONSE)

SABM(PAGING RESPONSE)

Fig. 23 Paging and Immediate Assignment procedure



68

1.4.2.3 SSS Procedure The SSS procedure runs between the MS and the MSC while a SDCCH is allocated on the Um interface. There is a logical connection between the MS and the MSC used for some access control functions to be performed before assigning the channel for call setup. After receipt of the SABM message the BTS sends a confirmation to the MS, that it has received the service request by means of a UA frame and also informs the BSC with an ESTABLISH INDICATION message about the requested service. Further coordination procedures (authentication, ciphering, IMEI check etc.) are now performed on the SDCCH on Um interface and by using the SCCP/DTAP protocols on the A interface.



69

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MS BTS BSC MSC

TASSATT (1..3)TASSATT(2,3)

Fig. 24 SSS Procedure



70

1.4.2.4 Assignment procedure The assignment procedure is used to occupy a radio resource (e.g. speech channel/data channel), if it is required. The MSC is Initiator of this procedure (except in case of intracell Handover). The MSC sends an ASSIGNMENT REQUEST message to the BSC requesting the assignment of a radio resource (RR). The ASSIGNMENT REQUEST message contains information on the requested channel (channel type (speech/data), priority, interference band to be used etc.), which is to be evaluated by the BSC. Based on this data, the BSC selects a suitable RR and activates it, with the message CHANNEL ACTIVATION. If the SDCCH is successfully activated, the BTS responds with a CHANNEL ACTIVATION ACKNOWLEDGE message. If not, it sends a CHANNEL ACTIVATION NEGATIV ACKNOWLEDGE message and furthers on to the MSC an ASSIGNMENT FAILURE message. Channel activation may fail for the following reasons:

• O&M intervention (channel blocked)

• channel already occupied

• hardware fault. It then instructs the MS with an ASSIGNMENT COMMAND message to occupy the channels. When the MS receives the ASSIGNMENT COMMAND message, it switches to the assigned channels and activates them by sending an SABM frame. The BTS acknowledges receipt of the SABM frame with a UA frame to the MS and informs the BSC with an ESTABLISHMENT INDICATION message that the MS has occupied the channels. When the MS receives the UA frame, it sends an ASSIGNMENT COMPLETE message to the BSC. If the assignment procedure was initiated by the MSC (the BSC can also initiate the procedure independently for an intracell handover), the BSC informs the MSC with an ASSIGNMENT COMPLETE message that the procedure has been successful.



71

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MS BTS BSC MSC

ASSIGNMENT PROCEDURE

ASSIGNMENT REQUEST

CHAN ACTIV

ASSIGNMENT COMMAND

CHAN ACTIV ACK

SABM

CHANNEL ACTIV NEG ACK

ASSIGNMENT COMMANDASSIGNMENT FAILURE

ASSIGNMENT COMPLETE

(TASSFAIL)

UA

ASSIGNMENT COMPLETE

ESTABLISH INDICATION(TNTCHCL)

ASSIGNMENT COMPLETE

(TASSATT, ATTCHSEI,AALTCHTI, ATCHSMBS,MBTCHAMR)

(TASSSUCC, SUCTCHSE)

PHYS CONTEXT REQ

PHYS CONTEXT CONF

(MTCHBUTI)

Fig. 25 Assignment procedure



72

1.4.3 Call Setup Analysis To analyze the call setup procedure in the network the following KPIs are relevant:

• Call Setup Success Rate

• Call Setup Failure Rate. These rates are derived from the KPIs

• Number of Call Setup Attempts

• Number of Successful Call Setups

• Number of Call Setup Failures. To obtain the last three KPIs, the performance indicators of three procedures (Immediate Assignment, SSS Procedure and Assignment) that make the Call Setup have to be considered.



73

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IMMEDIATE ASSIGNMENT

SSS PROCEDURE

ASSIGNMENT

CALL ESTABLISHMENT REQUEST

Immediate Assignmentswithout MS seizures

Successful Immediate Assignments

Assignment AttemptsSSS Procedure Failures;SDCCH Drops

Successful Assignments

Successful incomingredirected calls

Assignment and QueuingFailures, Successful outgoingrederected calls

Fig. 26 Call setup phases



74

1.4.3.1 Immediate Assignment Procedure related counters and some KPIs

Counters triggered during the Immediate Assignment procedure Different counter sequences are triggered dependent on whether the procedure is started due to MOC or MTC (in general due to cause). For the counter sequence meaning please refer to the Performance Counter Manual given as Appendix 2. Triggering Event Measurement/

Counters Counter sequence

CHANNEL REQUIRED

ATIMASCA [1..14]

1...6 SDCCH required, different causes

7...10 TCH/F required, different causes

11...14 TCH/H required, different causes

CHANNEL REQUIRED

Attempted SDCCH seizures in a period

NATTSDPE [1]

ESTABLISHMENT INDICATION

Successful SDCCH seizure in a period

NASUSDPE [1]

SDCCH CONGESTIONS ATSDCMBS [1]

IMM. ASS CMD (Abis Interface)

(IMM. ASS. CMD. messages, which contain an IMM. ASS. REJ. message are not counted)

SUIMASCA [1..6]

1...6 different assignment causes

IMM. ASS CMD (Abis Interface)

(including those IMM. ASS. CMD. messages that contain an IMM. ASS. REJ. message)

TACCBPRO [1, 2]

1 number of accesses to the PCH;

2 Number to accesses to the AGCH

IMM. ASS CMD / IMM. ASS. REJ. (Um Interface)

(difference between IMM. ASS.CMD and DELETE INDICATION, including those IMM. ASS. CMD. messages that contain an IMM. ASS. REJ. message)

NACSUCPR [1..3]

1 number of successful accesses to the PCH;

2 Number to successful accesses to the AGCH

3 Number to successful accesses to the RACH

ESTABLISHMENT INDICATION

Successful immediate assignment of signaling channels

NSUCCHPC [1..24]

1...8 SDCCH assignment, different causes

9...16 TCH/F assignment, different causes

17...24 TCH/H assignment, different causes

Immediate Assignment measurements



75

Rate Related KPI for Immediate Assignment procedure Long name Immediate Assignment Loss Rate

AGCH Loss Rate

Immediate Assignment without MS Seizure Rate

Immediate Assignment Success Rate

Short name ImmAssLossRate

AGCHLossRate

ImmAssNoSeizRate

ImmAssSuccRate

Description These KPI describe the ratio of unsuccessful attempts of immediate assignment procedure due to different reasons (no SDCCH available, no AGCH, or Phantom RACH/lost SABM) and the procedure success rate.

Formula

ImmAssAttImmAssLoss RateImmAssLoss =

]TACCBPRO[2]NACSUCPR[2 - ]TACCBPRO[2 teAGCHLossRa =

GCHImmAssCmdAizImmAssNoSeizRateImmAssNoSe =

izImmAssNoSe-ImmAssAtt ImmAssSuccRateImmAssSucc =

Counters ATIMASCA, SUIMASCA, TACCBPRO, NACSUCPR , NSUCCHPC Object Cell

Unit None

(Phantom RACHs are not counted, because they are not related to MS)

The Immediate Assignment Failure Rate can be calculated as follows: Immediate Assignment Failure Rate = 1 - Immediate Assignment Success Rate or Immediate Assignment Failure Rate = Immediate Assignment Loss Rate * AGCH Loss Rate * Immediate Assignment without MS Seizure Rate Note: For all needed and in above table incorporated parameters, please refer to the KPI Manual, Appendix 4.



76

1.4.3.2 SSS Procedure related counters and some KPIs A number of failures and failure rates concerning the SSS Procedures can be evaluated with the MSC counters per MSC. All events are cell independent It is also very important to evaluate the number of SDCCH drops during call setup. SDCCH drops mainly occur in the time when SSS Procedures are running. Counters triggered during the SSS procedure Triggering Event Measurement/ Counters Counter sequence

ESTABLISH INDICATION

(Successful immediate assignment of signaling channels related to Call Setups )

NSUCCHPC [1..24]

(the case related to Call Setup :

NSUCCHPC [1..4, 9...12, 17...20] - NSUCCHPC [8])

1...8 SDCCH assignment, different causes

9...16 TCH/F assignment, different causes

17...24 TCH/H assignment, different causes

ASSIGNMENT ATTEMPTS TASSATT [1..3]

(the case related to Call Setup:

TASSATT [2..3])

1 SDCCH assignment attempt

2 TCH/F assignment attempt

3 TCH/H assignment attempt

SSS Procedure measurements

For the detailed description of the counters and counter sequences please refer to the Performance Counters Manual, Appendix 2.



77

Rate Related KPI for the SSS procedure Long name SDCCH Drop Rate related to Call Setups

SSS Procedures Failure Rate related to Call Setup

SSS Procedures Success Rate related to Call Setup

SSS Procedures Success Rate Total

Short name

SDCCHDropRateCS

SSSProcFailRateCS

SSSProcSuccRateCS

SSSProcSuccRateCStotal

Description These KPI describe the rate of SDCCH drop during SSS procedure as well as the SSS Procedure drop itself and the procedure success rate.

Formula ateSDCCHDropR

CSImmAssSuccSSDCCHDropC ateCSSDCCHDropR ≈=

CSImmAssSuccocFailCSPr SSSlRateCSSSSProcFai =

ateCSSDCCHDropR - 1 cRateCSSSSProcSuc =

CSocFailRatePr SSS-ateCSSDCCHDropR-1 alcRateCStotSSSProcSuc =

Counters NSUCCHPC, TASSATT, NRCLRREQ, TASSFAIL

Object Cell

Unit None

ImmAssSuccCS = NSUCCHPC[1..4,9..12,17..20] - NSUCCHPC[8]

SDCCHDrop=NRCLRREQ[19.. 21,23..26] – TASSFAIL[1,6,11]

SSSProcFailCS=ImmAssSuccCS – AssAtt* – SDCCHdropCS

Note: Authentication, Identity, Ciphering and MSC failures will lead to a worse Success Rate although they are not related to the BSS. Assignments of the SDCCH are not considered. For all needed and in above table incorporated parameters, please refer to the KPI Manual, Appendix 4.



78

1.4.3.3 Assignment Procedure related counters and some KPIs The Assignment Procedure is used to allocate a TCH. The Directed Retries have also to be considered. The concept how to evaluate Directed Retries for the Assignment Success Rate is comparable with the Handover Success Rate, where only outgoing Handover will be considered. Therefore all Directed Retries for an observed cell have to be counted, which where started in the observed cell and were successful in any target cell with neighbor cell measurements. Under this assumption the Assignment Success Rate can be evaluated as follows: Assignment Success Rate = (Assignment Complete + Successful outgoing redirected Calls) / Assignment Attempts. Different counter sequences are triggered dependent on whether the procedure is started due to MOC or MTC (in general due to cause). For the counter sequence meaning please refer to the Performance Counter Manual given as Appendix 2. Counters triggered during the Assignment procedure Triggering Event Measurement/


ASSIGMENT ATTEMPS TASSATT [2..3]

2 TCH/F allocation attempt 3TCH/H allocation attempt

INCOMING REDIRECTED TASSSUCC [4..5] 1..3 number of successful assignment of SDCCH, TCH/FR, TCH/HR respectively

4, 5 number of successful assignment of redirected TCH/FR, TCH/HR respectively

OUTGOING REDIRECTED CALLS SINTHINT [7] +

SUINBHDO [10*n+7] + SUOISHDO[10*m + 7];

n=0..31 (n= number of GSM ADJ-ids)

m = 0 ...63 (m= number of UMTS ADJ-ids)

7 number of Directed Retries in case of:

Internal Intercell HO,

Inter BSC HO,

Intersystem HO

ASSIGMENT COMPLETE (normal Assignment)

TASSSUCC [2..3]

2,3 number of successful assignment of TCH FR/HR channels

ASSIGMENT FAILURE TASSFAIL [6,7,8,10,11,12,13,15]

number of failed TCH assignment due to radio condit.

Queuing Failure NMSGDISQ [1,2] number of discarded TCH assignment request from queue

Assignment measurements



79

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Assignment Attempts

Assignment successful

Assignment Complete

Assignment Failure

QueuingFailure

Successful outgoingredirected calls

Successful incomingredirected calls

Fig. 27 Assignment procedure traffic flow



80

Rate Related KPI for the Assignment procedure Long name Assignment Failure Rate

(a) TCH Blocking Rate

(b) Assignment Failure Rate by Message

(c) Assignment Failure Rate due to other Reason

(d) Queuing Failure Rate

(e) Assignment Failure Rate

Assignment Success Rate

Assignment success rate when radio resources available Short name

(a) TCHBlockRate

(b) AssFailbyMessRate

(c) AssFailOtherRate

(d) QueFailRate

(e) AssFailRate

AssSuccRate

SuccAssProbNoTCHBlocking Description These KPI describe the rate of TCH Assignment Failures as well as the procedure success rate.

Formula (a)

AssAttTCHLoss teTCHBlockRa =

(b)AssAtt

essAssFailbyMessRateAssFailbyM =

(c) AssAtt

erAssFailOth erRateAssFailOth =

(d)AssAttQueFaileQueFailRat =

(e)AssAttAssFaileAssFailRat =

AssAttAssSucceAssSuccRat =

TCHLoss-AssAtt essAssFailbyM-1 kingbNoTCHBlocSuccAssPro =

Counters TASSFAIL, TASSATT , TASSSUCC, NMSGDISQ, NRCLRREQ, SINTHINT, SUINBHDO, SUOISHDO

Object Cell

Unit None



81

Note: For all needed and in above table incorporated parameters, please refer to the KPI Manual, Appendix 4.

1.4.4 Call Setup related KPI The KPIs of the previous sections are mainly used for the derivation of the Call Setup KPIs, e.g. the Call Setup Success Rate (CSSR) and the Call Setup Failure Rate (CSFR). The Call Setup Success Rate and the Call Setup Failure Rate consider the events related to the Mobile Stations. There are the 'Number related' KPIs defined:

• Number of Call Setup Attempts

• Number of Successful Call Setups

• Number of Call Setup Failures (in total and related to specific cause) and the 'Rate related' KPIs which can be divided into two groups:

• Call Setup Success Rate KPI

• Call Setup Failure Rate KPIs (in total and related to specific cause) as indicated in the table.

Note: Two indicators are available for Call Setup Success Rate, one that takes into account all Call Setup rejections (BSS Immediate Assignment, SSS security and TCH Assignment), another that only takes into account BSS related Call Setup rejections (BSS Immediate Assignment and TCH Assignment).



82

Number Related KPI for the Call Setup procedure Long name Number of Call Setup Attempts

Number of Successful Call Setups

(a) Number of Call Setup Failures

(b) Number of Call Setup Failures due to Immediate Assignment Losses

(c) Number of Call Setup Failures due to AGCH Loss

(d) Number of Call Setup Failures due to Immediate Assignment without MS Seizure

(e) Number of Call Setup Failures due to SDCCH Drops

(f) Number of Call Setup Failures due to SSS Procedure Failure

(g) Number of Call Setup Failures due to TCH Loss

(h) Number of Call Setup Failures due to Assignment Failures by Message

(i) Number of Call Setup Failures due to Assignment Failures with other Reasons

(j) Number of Call Setup Failures due to Queuing Failures Short name

CSAtt

CSSucc

(a) CSFail

(b) CSFailImmAssLoss

(c) CSFailAGCHLoss

(d) CSFailImmAssNoSeiz

CSFailSDCCHDrop

(f) CSFailSSSProcFail

(g) CSFailTCHLoss

(h) CSFailAssFailbyMess

(i) CSFailAssFailOther

(j) CSFailQueFail Description These KPI describe the number of attempted, successful and failed TCH setup.

Formula

RateImmAssSuccCSImmAssSuccCSAtt =

AssSucc=CSSucc (a) CSFail = CSAtt - CSSucc

(b) CSFailImmAssLoss = CSAtt * ImmAssLossRate

(c) CSFailAGCHLoss = CSAtt * AGCHLossRate

(d) CSFailImmAssNoSeiz = CSAtt * ImmAssNoSeizRate

(e) CSFailSDCCHDrop = CSAtt * ImmAssSuccRate * SDCCHDropRateCS

(f) CSFailSSSProcFail = CSAtt * ImmAssSuccRate * SSSProcFailRateCS

(g) CSFailTCHLoss = TCHLoss

(h) CSFailAssFailbyMess = AssFailbyMess

(i) CSFailAssFailOther = AssFailOther

(j) CSFailQueFail = QueFail

Counters TASSFAIL, TASSATT , TASSSUCC, NMSGDISQ, NRCLRREQ, SINTHINT, SUINBHDO, SUOISHDO, ATIMASCA, SUIMASCA, TACCBPRO, NACSUCPR

Object Cell

Unit None



83

Rate Related KPI for the Call Setup procedure Long name Call Setup Success Rate

Call Setup Success Rate BSS

(a) Call Setup Failure Rate

(b) Call Setup Failure Rate due to Immediate Assignment Losses

(c) Number of Call Setup Failure Rate due to AGCH Loss

(d) Number of Call Setup Failure Rate due to Immediate Assignment without MS Seizure

(e) Number of Call Setup Failure Rate due to SDCCH Drops

(f) Number of Call Setup Failure Rate due to SSS Procedure Failure

(g) Number of Call Setup Failure Rate due to TCH Loss

(h) Number of Call Setup Failure Rate due to Assignment Failures by Message

(i) Number of Call Setup Failure Rate due to Assignment Failures with other Reasons

(j) Number of Call Setup Failure Rate due to Queuing Failures Short name

CSSuccRate

CSSuccRateBSS

(a) CSFailRate

(b) CSFailRateImmAssLoss

(c) CSFailRateAGCHLoss

(d) CSFailRateImmAssNoSeiz

(e) CSFailRateSDCCHDrops

(f) CSFailRateSSSProcFail

(g) CSFailRateTCHLoss

(h) CSFailRateAssFailbyMess

(i) CSFailRateAssFailOther

(j) CSFailRateQueFail Description These KPI describe the rate of successful and failed (due to different reasons) TCH setup.

Formula

CSSuccRate = ImmAssSuccRate x SSSProcSuccRateCStotal x AssSuccRate

CSSuccRateBSS = ImmAssSuccRate x ( 1 - SDCCHDropRateCS) * AssSuccRate

(a) CSFailRate = 1 – CSSuccRate

(b) CSFailRateImmAssLoss = ImmAssLossRate

(c) CSFailRateAGCHLoss = AGCHLossRate

(d) CSFailRateImmAssNoSeiz = ImmAssNoSeizRate

(e) CSFailRateSDCCHDrops = SDCCHDropRateCS

(f) CSFailRateSSSProcFail = SSSProcFailRateCS

(g) CSFailRateTCHLoss = TCHLossRate

(h) CSFailRateAssFailbyMess = AssFailbyMessRate

(i) CSFailRateAssFailOther = AssFailOtherRate

(j) CSFailRateQueFail = QueFailRate

Counters TASSFAIL, TASSATT, TASSSUCC, NMSGDISQ, NRCLRREQ, SINTHINT, SUINBHDO, SUOISHDO, ATIMASCA, SUIMASCA, TACCBPRO, NACSUCPR

Object Cell

Unit None



84

1.4.5 Clearing sequence The clearing sequence is used to release radio resources and associated terrestrial channels. There are many reasons to start the clearing sequence, as normal clearing, radio failure, connection failure, protocol error, etc. After the BSC acknowledges with a RELEASE COMPLETE message, that a channel has to be released, the MSC starts the Clearing Sequence by sending of a CLEAR COMMAND message. The BSC instructs the MS to release the occupied mobile channels with a CHANNEL RELEASE on the FACCH. A DEACTIVATE SACCH message is also sent to the BTS to deactivate the signaling channel. After receiving of the CHANNEL RELEASE message the MS starts to deactivate the channel and sends a DISCONNECT message to the BTS. After receiving of the DISC message the BTS deactivates all the channels connected to the MS. To acknowledge the deactivation of the channels, the BTS sends a UA frame to confirm the DISC message. After receiving the UA frame the MS releases all the remaining channels and goes into “idle mode“. The BTS also informs the BSC with a RELEASE INDICATION message that all remaining channels of the MS are now released. The BSC instructs the BTS with a RF CHANNEL RELEASE message to release the channels already deactivated by the MS. After release, the BTS acknowledges this with an RF CHAN REL ACKNOWLEDGE message. At the end of this procedure the BSC sends a CLEAR COMPLETE message to the MSC to indicate that the Clearing Sequence was successful. A clearing sequence can be triggered e.g. by the call ending as normal, as handover, the end of a location update or the aborting of a connection. In the latter case the BSC is informed of this by a CONNECTION FAILURE INDICATION message sent by the BTS and further on to the MSC to start the Clearing Sequence.



85

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MS BTS BSC MSC

CLEARING SEQUENCENormal Call Release, originated by MS

DT1 (DISC)DATA IND (DISC)

I (CHAN REL)

DATA REQ (RELEASE)

DISC

DATA IND (REL CMP)

DATA REQ (CHAN REL)

DT1 (CLEAR COMPLETE)

UA

DATA IND (DISC)Cause: normal call clearing

DEACT SACCH

RLSD

RF CHAN REL ACK

RF CHAN REL

DT1 (RELEASE)Cause: normal call clearing

DT1 (REL CMP)

DT1 (CLEAR COMMAND)

RLC

T3110

T3109

T3111

T1

CLEARINGSEQUENCE

I (RELEASE)

I (REL CMP)

(MTCHBUTI (1), AALTCHTI (1) if previously started , stop),

RELEASE INDICATION

(NRCLRCMD(2))

(NCRLBRQU(1,2))

(MBTCHCH, MEBUSTCH=MEBUTSLY-ABSPDIS)

Fig. 28 Call release procedure in case of normal call release originated by MS



86

MS BTS BSC MSC

CLEARING SEQUENCENormal Call Release, originated by Network

DT1 (DISC)cause: normal call release

DATA IND (DISC)

I (CHAN REL)

DATA REQ (RELEASE)

DISC

DATA IND (REL CMP)

DATA REQ (CHAN REL)

DT1 (CLEAR COMPLETE)

UA

I (DISC)

DEACT SACCHRLSD

Cause:end user originated

RF CHAN REL ACK

RF CHAN REL

DT1 (RELEASE)

DT1 (REL CMP)

DT1 (CLEAR COMMAND)

RLC

T3109

T3111

T1

CLEARINGSEQUENCE

I (RELEASE)Cause: normal call release

I (REL CMP)

(MTCHBUTI(1), AALTCHTI(1) if previously started, stop))

RELEASE INDICATION

(NRCLRCMD(2))

T3110DT1 (CLEAR COMPL.)

(NCRLBRQU(3,4))

(MBTCHCH, MEBUSTCH=MEBUTSLY-

ABSPDIS)

Fig. 29 Call release procedure in case of normal call release originated by network



87

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MS BTS

If SDCCH -> (MBUSYSDC -ASDCALTI if previously started,

stop),

CLEARING SEQUENCEAbnormal Call Release Procedure

CONFLCause: radio link failure or

Remote transcoder failure orT_MSRFPCI expired orDistance limit exceeded

RELEASE REQUEST

(NRFLTCH(7 or 8 or 4 or 5) orNRFLSDCC(7 or 8 or 4 or 5),

respecitvely dependent on cause)

RF CHAN REL ACK

RF CHAN REL (New TCH)

***ERROR INDICATION (Cause)

CONN FAILURE INDICATION(Cause)

DT1 (CL REQ)

DT1 (CLEAR COMMAND)

If THC -> (MTCHBUTI (1), AALTCHTI(1) if previously started,

stop),(MBTCHCH,

MEBUSTCH=MEBUTSLY -ABSPDIS

RELEASE CONFIRM

Reset T_MSRFPCI

Call or dedicated connection (SDCCH or FACCH) established

Radio link counter in the BTSreaches „0“orTTRAUor TSYNC/TSYNCDL expiry

orT_MCRFPCI expiryorMB-BS distance exceeds thethreshold

(NRCLRCMD (1))

CLEARINGSEQUENCE

BSC

(NRCLRREQ ***(1 ))

MSC

Fig. 30 Abnormal call release procedure, call drop



88

Timers In the Clearing Sequence the Timers are used to supervise the release of channels. It must be sure, that in any case, first the Mobile has to release all channels and than the BTS. This is necessary, that in case of a new call setup, 2 Mobiles are not synchronized to the same channel.

T3109 Start: DATA REQUEST (CHANNEL RELEASE) message Stop: DISCONNECT message (forwarded to the BSC as RELEASE

INDICATION) Expiry: BSS deactivates all channels for this MS Default: 4 sec.

T3110 Start: CHANNEL RELEASE message Stop: UA frame Expiry: MS deactivates all channels Default: 1.5 seconds.

T3111 Start: RELEASE INDICATION message Stop: RF CHANNEL RELEASE message Expiry: BSS deactivates all channels for this MS Default: 0.5 seconds

T1 Start: RF CHANNEL RELEASE message Stop: RF CHANNEL RELEASE ACKNOWLEDGE message Expiry: BSC marks the belonging circuits as blocked Default: 6 seconds



89

1.4.6 TCH Drop related counters and some KPI A TCH may be seized during the call setup or for a handover. Then a TCH connection is established. It can drop while running due to different reasons. Here only drops related to the BSS and the radio interface are counted. Therefore the analysis of dropped TCH calls is in fact based on the counter NRCLRREQ sequence values. Different sub-counters (counter sequences) are triggered dependent on cause for abnormal call release, so that an operator can get an overview of TCH drops distribution and therefore trace the problem in the network. The TCH drops during pending incoming inter BSC HO are not counted as they are counted in the originating cell. Call Drop Rate as one very important Performance Indicator (PI) is used also to obtain the number of terminated calls. In addition there are in BR9.0 introduced counters and a corresponding KPI to measure the number of normally released TCH calls with bad call radio quality. The new KPI give the number of normal call releases of calls with bad radio quality in relation to all TCH connections of a cell. Counters triggered during the Clearing procedure (independently on whether due to normal or abnormal release) Triggering Event Measurement/


Reception (BTS->BSC)one of the following messages :

Connection Failure Indication

Error Indication

Expiry of some timers

NRFLTCH[1..36]

For each TCH channel type and for each Cell Configuration type 9 sub-counters are provided to count different causes of connection failure

The same trigger events as above NRFLSDCC [1...9]

9 sub-counters are provided to count different causes of SDCCH connection failure

The measurement is triggered by a clear request message sent from the BSC->MSC with the specific cause

NRCLRREQ[1...26] 9 sub-counters count clear request messages issued per cell, per cause, per channel type

(no counter available for SDCCH cause preemption)

The measurement is triggered by a Clear Command sent from the MSC->BSC with specific cause

NRCLRCMD[1..18] 6 different sub-counters count number of clear commands issued per cell, per cause, per channel type



90

Dropped TCH Connections related KPI Long name Number of Dropped TCH Connections

TCH Drop distribution (18 different PI related to 18 different causes to abnormally release the connection per CH type)

TCH Drop Rate

Number of Terminated Calls

Call Drop Rate

TCH Drops per Erlang hour Short name

TCHDrop

TCHDropDistxxx

TCHDropRate

Num Term calls

CallDropRate

TCHDropErlh Description These KPI describe the number and the rate of dropped TCH connections.

Formula ..18] 14 12, 5.. 3, .. NRCLRREQ[1 TCHDrop =

,TCHDrop

xx,...]NRFLTCH[x,t xxxTCHDropDis = where xxx stands for one out of 18

different causes to abnormally release the connection, and x , xx stand for the associated counters

,..2]SUCTCHSE[1

TCHDropeTCHDropRat =

,..13] 8,11 .. TASSFAIL[6- - ,13]NRCLRREQ[4 - 12] .. 10 8, .. 4 2, .. NRCLRCMD[1 lsNumTermCal =

,lsNumTermCal

TCHDropteCallDropRa =

,ygranularit

60rDRTCHTrafCar

TCHDrophTCHDropErl ∗=

Counters NRCLRREQ, NRFLTCH, UNIHIALC, UNIHIRLC, InterBSCHODrop, TCHDrop, NRCLRCMD, TASSFAIL, SUCTCHSE, MEBUSTCH, (TCHTrafCarrDR)

Object Cell

Unit None

Drop per Erlanghour is recommended to be used for quality assessment of radio network performance as the call drop rate depends on the average call duration. The longer call duration is; the higher call drop rate.



91

Normal Call Release of Calls with Bad Radio Quality related KPI Long name (a) Rate of normal call releases of calls with bad radio quality

(b) Rate of normal call releases of calls with bad radio quality, non AMR

(c) Rate of normal call releases of calls with bad radio quality, AMR

(d) Rate of normal call releases of calls with bad radio quality, non AMR, MS originating

(e) Rate of normal call releases of calls with bad radio quality, AMR, MS originating

(f) Rate of normal call releases of calls with bad radio quality, non AMR, Network originating

(g) Rate of normal call releases of calls with bad radio quality, AMR, Network originating

Short name

(a) BRQCRelRate

(b) BRQCRelRateNonAMR

(c) BRQCRelRateAMR

(d) BRQCRelRateNonAMRMsOrg

(e) BRQCRelRateAMRMsOrg

(f) BRQCRelRateNonAMRNwOrg

(g) BRQCRelRateAMRNwOrg Description These KPI describe rate of terminated TCH connections due to calls with bad radio quality.

Formula (a) ,,2]SUCTCHSE[1..4]NCRLBRQU[1eBRQCRelRat =

counters associated for thexx x,and , call a of typesdifferent for the

stands xxx where,,2]SUCTCHSE[1xx],NCRLBRQU[xexxxBRQCRelRat =

Counters NRCLRREQ, NRFLTCH, UNIHIALC, UNIHIRLC, InterBSCHODrop, TCHDrop, NRCLRCMD, TASSFAIL, SUCTCHSE, MEBUSTCH, (TCHTrafCarrDR)

Object Cell

Unit None



92

1.4.7 SDCCH Drop related KPI SDCCH Drop related KPI

Long name Number of dropped SDCCH Connections

(a)SDCCH Drop Rate

(b) SDCCH Drop Rate per SDCCH connection

SDCCH Drops per Erlanghour

Short name

SDCCHDrop

(a) SDCCHDropRate

(b) SDCCHDropConnRate

SDCCHDropErlh

Description These KPI describe number and the rates of lost SDCCH connections which can occur for any call type.

Formula ,,6,11]TASSFAIL[1 26] .. 23 21, .. 9NRCLRREQ[1 SDCCHDrop +=

(a)..6]NSUCCHPC[1

SDCCHDropateSDCCHDropR =

(b)8]3,14,16..1NRCLRCMD[1

SDCCHDroponnRateSDCCHDropC =

yGranularit60*

arr SDCCHTrafCSDCCHDroprlh SDCCHDropE =

Counters NRCLRREQ, TASSFAIL, NSUCCHPC, NRCLRCMD, MBUSYSDC (for SDCCH Carried Traffic)

Object Cell

Unit None



93

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



94

1.4.8 Handover

1.4.8.1 Types of handover Different types of handover can be distinguished with respect to the changed region: a cell, a BSS area, or an MSC area. Since release BR7.0 the SBS equipment has supported GSM-UMTS interworking as well, i.e. handover from 2G->3G cell and vice versa. Handover types for CS calls in the GSM network are illustrated in the figure below. Different types of handover can be enabled or disabled by several flags.



95

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BSC 1b

BSC 1a

MSC 1

MSC 2

1.Intracell Handover2.Intra-BSS Handover3.Intra-MSC Handover4.Inter-MSC Handover5.Intersystem Handover

4

3

1

2

3G Cell3G MSC

RNC

5

BSC 2

Fig. 31 Types of handover



96

Intracell handover If the BTS notices from the MEASUREMENT REPORT messages periodically being received from the MS, that the quality of the TCH connection is decreasing with a constant receive level, it introduces an intracell handover with an INTRA CELL HO CONDITION INDICATION message to the BSC. This message can also be sent from the BTS to the BSC in case of intracell handover due to other procedures like the Adaptative Multirate, the enhanced pairing - or also the forced intra cell handover to a preferred TRX procedure. The procedure for the SDCCH intra cell Handover is described in the SBS Message Flows Manual (see Appendix 3). The BSC selects a suitable RR and activates it, with the message CHANNEL ACTIVATION. If the TCH is successfully activated, the BTS responds with a CHANNEL ACTIVATION ACKNOWLEDGE message. The BSC instructs the MS with an ASSIGNMENT COMMAND message on the old channel to switch to the new one. If the MS receives the ASSIGNMENT COMMAND message, it releases the connection on the old channels, switches them to the new ones and activates them. After occupying the new channels the MS replies with an ASSIGNMENT COMPLETE message. When the ASSIGNMENT COMPLETE message is received, the BSC releases the old channels. If the BSS assigns a frequency to the MS, which it does not support, the MS sends an ASSIGNMENT FAILURE message and remains on the old channels. If the “Channel Mode“ requested by the BSS is not supported, the MS sends also an ASSIGNMENT FAILURE message and remains on the old channels. The BSC informs the MSC that an intra-BSC handover has been performed with a HANDOVER PERFORMED message.

Timer In the INTRA CELL Handover Procedure the Timer are used to supervise the channels. The BSS must keep the old channel as long until the MS has occupied the new one. The Mobile must have the possibility to go back to the old channel.

T10 Start: ASSIGNMENT COMMAND message Stop: ASSIGNMENT COMMAND COMPLETE message Expiry: BSS releases the new and the old channels The connection to the MS is lost. Default: 5 seconds



97

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MS BTS BSC MSC

INTRACELL HANDOVER

INTRA CELL HO COND IND

ASS COMMAND(OLD CHANNEL)

CHAN ACTIV

SABM

CHAN ACTIV ACK

ASS COMMAND(OLD CHANNEL)

ASS COMPLETE(NEW CHANNEL)

UA

MEAS REP

ESTABLISH INDICATION

(AALTCHTI, ATTCHSEI,MBTCHAMR)

HANDOVER PERFORMED

T10

MEAS REP

ASS COMPLETE(NEW CHANNEL)

ASS FAILUREASS FAILURE

(SUCTCHSE,NASUSDPE)

(MTCHBUTI)

(TNTCHCL)

(SINTHITA, SINHOBSC,SISHINTR)

(UNINHOIA,UISHINTR)

(UNIHIALC)

(ATINHIAC,AISHINTR)

Fig. 32 Intracell handover



98

Intercell handover, intra-BSC If during a connection the BTS notices from the values periodically transmitted by the MEASUREMENT REPORT messages, that the previously set threshold values for quality (RXQUAL), reception level (RXLEV), better cell or distance have been reached, the BTS decided to do a Handover. Therefore the BTS reports this to the BSC with a HANDOVER CONDITION INDICATION message. The BTS keeps a Target Cell List, which it uses as a basis to decide whether an inter-cell or an intra-cell handover is required. If the first cell on the list is in same BSC area, the BSC selects the first cell from the list, selects a suitable RR for the new BTS and activates it, with the message CHANNEL ACTIVATION. If the TCH is successfully activated, the BTS responds with a CHANNEL ACTIVATION ACKNOWLEDGE message. The BSC send a HANDOVER COMMAND message to the BTS and further on to the mobile station (MS), which contains information about the new cell and channels. With a HANDOVER ACCESS message, which can be repeated twice, the mobile station occupies the new channels it has been assigned in the target cell. If the new BTS receives the Handover Access message, it indicates the BSC, that it can see the mobile station. The BTS synchronized on the new TRX and transmits a PHYSICAL INFORMATION message to the mobile station. The mobile station replies to the PHYSICAL INFORMATION message with a HANDOVER COMPLETE to the new BTS. The HANDOVER COMPLETE message is forwarded to the BSC. The BSC indicates to the MSC with a HANDOVER PERFORM message that there was a successful Handover. If Timer 3124 in the MS expires, before the MS receives a PHYSICAL INFORMATION message from the BTS, it reverts to the old channels and sends a HANDOVER FAILURE message over the old channels to the BSC. The BSC then starts the clearing sequence to release the new channels. Other reasons for the failure of a handover may be for example:

• the BSC assigns a new channel whose mode is not supported by the MS.

• the BSC assigns a new frequency to the MS, which the MS does not support. “Synchronous“ or “pseudo-synchronous“ handovers, where the PHYS INFO message is not necessary, are not currently supported.



99

Timers In the Intra BSC Handover Procedure the Timers are used to supervise the channels. The BSS must keep the old channel as long until the MS has occupied the new one. The Mobile must have the possibility to go back to the old channel.

T3124 Start: HANDOVER ACCESS message Stop: PHYSICAL INFORMATION message Expiry: MS reverts to the old channels and sends

a HANDOVER FAILURE message. The MS proceeds on the old channels.

Default: 0,675 seconds.

T8 Start: HANDOVER COMMAND message Stop: HANDOVER COMPLETE message from BTS to BSC or

HANDOVER FAILURE message from MS Expiry: BSC releases the old channels

The connection to the MS is lost. Default: 5 seconds.

NY1 * T3105 Start: PHYSICAL INFORMATION message Stop: CORRECT FRAME from MS Expiry: BSC releases the new channels after receiving a CONNECTION

FAILURE message from the BTS with cause “Handover access failure“. The connection to the MS is lost, if no HOV failure message was received from MS

Default: NY1 = 20; T3105 = 0,080 seconds. Remark: T3124+ delta < NY1 * T3105 < T8 <= 5 sec



100

There are different scenarios for unsuccessful intra BSC handover: 1. Handover Command

MS is not able to get handover command message sent by the BSC. => Expiry of Timer T8 => BSC releases old and new channel(s) => Loss of MS connection

2. Handover Access Target BTS is not able to get handover access message sent by the MS. => Expiry of Timer T3124 => Handover failure message will be sent by the MS => BSC releases new channel(s) => MS returns to the old channel(s)

3. Physical Info MS is not able to get physical info message sent by the BTS. Case 1: => Expiry of Timer T3124 => MS sends a handover failure message to the BSC => BSC releases new channel(s) => MS returns to the old channel(s) Case 2: => Expiry of Timer NY1 * T3105 => BTS sends a connection failure message to the BSC => BSC releases old and new channel(s) => Loss of MS connection

4. Correct frame MS got a physical info message, but the target BTS is not able to get correct frame from the MS. => Expiry of Timer NY1 * T3105 => BTS sends a connection failure message to the BSC => BSC releases old and new channel(s) => Loss of MS connection

5. Handover Complete BSC is not able to get handover complete message sent by the MS via target BTS. => Expiry of Timer T8 => BSC releases old and new channel(s) => Loss of MS connection.



101

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

INTRA BSC HANDOVERMS BTS1 BSC1 BTS2 MSC

MEAS REP INTER CELLHO COND IND

(ATINHIRC, AALTCHTI,ATTCHSEI)

CHAN ACTIV(MTCHBUTI)

CHAN ACTIV ACKHO COMMAND

(AOUINHIR, AININIRH)

HO COMMANDHO ACCESS

HO ACCESSHO DETECTPHYS INFO

PHYS INFO

PHYS INFO

SABM

ESTABLISH INDUA

(TNTCHCL)

HO FAILUREHO COMPLETE

HO FAILURE(HOFITABS, UNINHOIE)

HO COMPLETE

HO PERFORMED

T3124

(SININIRH, SOUINIRH,SINHOBSC, SINTHINT)

T8 (UNIHIRLC)

NY1*T3105CONN FAILURE

(SUCTCHSE)

(NRFLTCH)

Fig. 33 Intercell handover, intra-BSC



102

Inter-BSC handover If during a connection the BTS notices from the values periodically transmitted by the MEASUREMENT REPORT messages, that the previously set threshold values for quality (RXQUAL), reception level (RXLEV), better cell or distance have been reached, the BTS decided to do a Handover. Therefore the BTS reports this to the BSC with a HANDOVER CONDITION INDICATION message. The BTS keeps a Target Cell List, which it uses as a basis to decide whether an inter-cell or an intra-cell handover is required. If the first cell on the list is in another BSC area, the BSC sends an HANDOVER REQUIRED message to the MSC. If the cell is one, which the BSC manages, it initiates an intra-BSC handover. In the case of an inter-BSC handover, the Target Cell List is contained in the HO REQUIRED message to the MSC. The MSC selects the first cell from the list and with an HANDOVER REQUEST message requests a channel for the handover from the new BSC. The BSC selects a suitable RR and activates it, with the message CHANNEL ACTIVATION. If the TCH is successfully activated, the BTS responds with a CHANNEL ACTIVATION ACKNOWLEDGE message. If the BSC can provide the requested resource, it replies to the MSC with a HANDOVER REQUEST ACKNOWLEDGE message. The MSC send a HANDOVER COMMAND message to the old BSC. The old BSC for its part forwards the HANDOVER COMMAND message, which contains information on the new mobile cell, to the mobile station (MS). With a HANDOVER ACCESS message, which can be repeated twice, the mobile station occupies the new channels it has been assigned in the target cell. If the new BTS receives the Handover Access message, it indicates the new BSC, that it can see the mobile station. The BSC forward this message further on to the MSC. The BTS synchronized on the new TRX and transmits a PHYSICAL INFORMATION message to the mobile station. The mobile station replies to the PHYSICAL INFORMATION message with a HANDOVER COMPLETE to the new BTS. The HANDOVER COMPLETE message is forwarded to the MSC. If Timer 3124 in the MS expires, before the MS receives a PHYSICAL INFORMATION message from the BTS, it reverts to the old channels and sends a HANDOVER FAILURE message over the old channels to the old BSC. The BSC informs the MSC about this failure by forwarding it to the MSC. The MSC then starts to clear the previously occupied channels in the new BSS with a clearing sequence.



103

Other reasons for the failure of a handover may be for example:

• the BSC assigns a new channel whose mode is not supported by the MS.

• The BSC assigns a new frequency to the MS, which the MS does not support. The MSC then initiates the release of the old channels with a CLEAR COMMAND to the old BSC. “Synchronous“ or “pseudo-synchronous“ handovers, where the PHYS INFO message is not necessary, are not currently supported.

Timer In the Inter BSC Handover Procedure the Timer are used to supervise the channels. The BSS must keep the old channel as long until the MS has occupied the new one. The Mobile must have the possibility to go back to the old channel.

T3124 Start: HANDOVER ACCESS message. Stop: PHYSICAL INFORMATION message. Expiry: MS reverts to the old channels and sends

a HANDOVER FAILURE message. The MS proceeds on the old channels.

Default: 0,675 seconds.

T8 Start: HANDOVER COMMAND message. Stop: CLEAR COMMAND message from MSC or

HANDOVER FAILURE message from MS. Expiry: BSC releases the old channels.

The connection to the MS is lost. Default: 5 seconds. NY1 * T3105 Start: PHYSICAL INFORMATION message. Stop: CORRECT FRAME from MS. Expiry: BSC releases the new channels after receiving a CONNECTION

FAILURE message from the BTS with cause “Handover access failure“. The connection to the MS is lost, if no HOV failure message was received from MS.

Default: NY1 = 20; T3105 = 0,080 seconds. Remark: T3124+ delta < NY1 * T3105 < T8 <= 5 sec



104

There are different scenarios for unsuccessful inter BSC handover: 1. Handover Command

MS is not able to get handover command message sent by the BSC. => Expiry of Timer T8 => MSC releases old and new channel(s) => Loss of MS connection

2. Handover Access Target BTS is not able to get handover access message sent by the MS. => Expiry of Timer T3124 => Handover failure message will be sent by the MS => MSC releases new channel(s) => MS returns to the old channel(s)

3. Physical Info MS is not able to get physical info message sent by the BTS. Case 1: => Expiry of Timer T3124 => MS sends a handover failure message to the MSC => MSC releases new channel(s) => MS returns to the old channel(s) Case 2: => Expiry of Timer NY1 * T3105 => BTS sends a connection failure message to the BSC => MSC releases old and new channel(s) => Loss of MS connection

4. Correct frame MS got a physical info message, but the target BTS is not able to get correct frame from the MS. => Expiry of Timer NY1 * T3105 => BTS sends a connection failure message to the BSC resulting in a clear request message send to the MSC => MSC releases old and new channel(s) => Loss of MS connection

5. Handover Complete BSC is not able to get handover complete message sent by the MS via target BTS. => Expiry of Timer T8 => MSC releases old and new channel(s). => Loss of MS connection



105

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

INTER BSC HANDOVERMS BTS1 BSC1 MSC BSC2 BTS2

MEAS REP INTER CELLHO COND IND

(ATINBHDO)

HO REQUIRED HO REQUEST CHAN ACTIVCHAN ACTIV

ACKHO REQUEST

ACKHO COMMANDHO COMMANDHO COMMANDHO ACCESSHO ACCESS

HO DETECT HO DETECTPHYS INFOPHYS INFO

SABM

ESTABLISH IND(TNTCHCL)

UA

HO COMPLETE

HO COMPLETE(SUCTCHSE)HO COMPLETECLEAR

COMMAND

(SUINBHDO)

T3124

T8

NY1*T3105

HO FAILUREHO FAILURE

(NRUNINHD)

(MTCHBUTI)

(ATTCHSEI,AALTCHTI)

CONN FAILURECONN FAILURE(NRFLTCH)

Fig. 34 Inter-BSC handover



106

Directed retry A handover giving the reason "directed retry" is performed if no TCH is free in the cell after the call setup on the SDCCH. Using a FORCED HO REQUEST message the BSC then arranges for the BTS to send an INTERCELL HO COND IND message with a list of suitable neighbors for a handover (Target Cell List). The BSC selects a suitable cell from the list. If the cell is within its own BSC's area, the BSC uses it to occupy a TCH and sends an ASSIGNMENT COMPLETE message to the MSC. If the cell is within another BSC's area, the BSC sends an HO REQUIRED giving the reason "directed retry" to the MSC.



107

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

DIRECTED RETRYMS BTS1 BSC1 BTS2 MSC

MEAS REP

INTER CELL HO COND IND

(ATINHIRC, AALTCHTI, ATTCHSEI

CHAN ACTIV(MTCHBUTI)

CHAN ACTIV ACKHO COMMAND(AOUINHIR, AININIRH)

HO COMMANDHO ACCESSHO ACCESS

HO DETECTPHYS INFOPHYS INFO

SABM

ESTABLISH INDUA

(TNTCHCL)

HO FAILUREHO COMPLETE

HO FAILURE(HOFITABS, UNINHOIE)

HO COMPLETE

ASS COMPLETE

T3124

(SININIRH, SOUINIRH,SINHOBSC, SINTHINT)

T8 (UNIHIRLC)

NY1*T3105CONN FAILURE

(TASSUCC,SUCTCHSE)

(NRFLTCH)

ASS REQUEST(TASSATT, ATTCHSEI,ATCHSMBS)

FORCED HO REQ

Fig. 35 Directed retry



108

1.4.8.2 Handover Procedure related counters and some KPI Counters triggered during certain Handover Procedure Counter/ INTRA MSC HANDOVER INTER MSC HANDOVER

INTRA BSC INTER BSC Kind of Handover INTRA CELL INTER CELL INTER CELL Attempted Handover

ATINHIAC (C,CA) AISHINTR (C)

ATINHIRC (C,CA) AOUINIRH (NO,CA)AININIRH (NI) AISHINTE (C)

ATINBHDO (NO, CA) AOINTESH (C)

Successful Handover

SINTHITA (C,CA) SINHOBSC (B,CA) SISHINTR (C)

SINTHINT (C,CA) SINHOBSC (B,CA) SOUINIRH (NO,CA)SININIRH(NI) SISHNTE (C)

SUINBHDO (NO, CA) SOINTESH (C)

Unsuccessful Handover without loss of call/SDCCH

UNINHOIA (C,CA) UISHINTR (C)

UNINHOIE(NO,CA) HOFITABS (B) UISHINTE (C)

NRUNINHD (NO,CA) NRINHDFL (BI) UOINTESH (C)

Unsuccessful Handover with loss of call/SDCCH

UNIHIALC (C) UNIHIRLC (C) UMSCHLC(C)

INTERSYSTEM HANDOVER Counter/ Outgoing Intersystem HO Incoming Intersystem HO Attempted /Requested HO

ATOISHDO (NO;CA) RQIISHDO (B)

Successful Intersystem HO

SUOISHDO (NO,CA) SUIISHDO (B)

Unsuccessful Intersystem HO

UNOISHDO (NO,CA) UNIISHDO (B)



109

The text in brackets has the following meaning:

B = per BSCBI = per BSC incomingC = per cellNO = per neighbor cell outgoing NI = per neighbor cell incoming CA = per cause Note: To let the handover work cell parameters have to be defined in the BSC (LAC, CI, BSIC, ...) and also in the MSC (LAC, CI). For Inter MSC Handover the Anchor LTG will take control of the call, also if there will be several Inter MSC Handover, Therefore also the External Location Area Codes (EXTLAC) of all MSC should be defined.



110

1.4.8.3 Handover related KPI

Successful Hanover Key Performance Indicators General Handover KPI related to Successful Handover

Long name Handover Success Rate

Handover Success Rate 2G to 2G

Handover Success Rate 2G to 3G

Short name

HOSuccRate

HOSuccRate2G2G

HOSuccRate2G3G

Description These KPI describe the general HO success rate, general HO success rate as an aggregation over

all HO causes from 2G to 2G and 3G systems.

Formula

ll]ATOISHDO[a ll]ATINBHDO[a ll]ATINHIRC[aall] SUOISHDO[all] SUINBHDO[ all] SINTHINT[H

++++

=oSuccRate

ll]ATINBHDO[a ll]ATINHIRC[aall] [ SUINBHDO all] [ SINTHINT2GG 2HOSuccRate

++

=

ll]ATOISHDO[aall] SUOISHDO[3G2G HOSuccRate =

Counters SINTHINT, SUINBHD, SUOISHDO, ATINHIRC, ATINBHDO, ATOISHDO,

Object Cell

Unit None

Note: These HO Performance Indicators give the general HO success rate as an aggregation over all HO causes. In the all following formulas n stands for the number of neighbor cell relations, c for the handover cause and i for the type of cell area (cell configuration type).



111

Intra Cell, Intra BSC and Inter BSC Handover KPI related to Successful Handover

Long name Intra Cell Handover Success Rate

Intra Cell Handover Success Rate per cause

Intra Cell SDCCH Handover Success Rate

Inter Cell Intra BSC Handover Success Rate

Inter Cell Intra BSC Handover Success Rate per cause

Inter Cell SDCCH Handover Success Rate

Inter Cell Inter BSC Handover Success Rate

Inter Cell Inter BSC Handover Success Rate per cause

Inter Cell Inter BSC SDCCH Handover Success Rate

Short name

IntraCellHOSuccRate

IntraCellHOSuccRateC

IntraCellSDHOSuccRate

InterCellHOSuccRate

InterCellHOSuccRateC

InterCellSDHOSuccRate

InterBSCHOSuccRate

InterBSCHOSuccRateC

InterBSCSDHOSuccRate

Description These KPI describe the HO success rate in case of different GSM handovers as an aggregation over all HO causes and are provided in addition separated per HO cause value.



112

Formula

..14]ATINHIAC[1..14]SINTHITA[1

OAttIntraCellHOSuccIntraCellHOSuccRateIntraCellH ==

defined) are causes 14 to(up

number cause for the cwith ,] ATINHIAC[c] SINTHITA[c] [cOSuccRateCIntraCellH =

]AISHINTR[1]SISHINTR[1

DHOAttIntraCellSDHOSuccIntraCellSeDHOSuccRatIntraCellS ==

∑∑

∑∑

= =

= =

++

++=

==

12

1

3

0

12

1c

3

0i

c] 12* i48 *AOUINIRH[n

c] 12* i48 *SOUINIRH[n

OAtt[n]InterCellHOSucc[n]InterCellHn]OSuccRate[InterCellH

c i

∑

∑

=

=

++

++=

==

3

0

3

c] 12* i48 *AOUINIRH[n

c] 12* i48 *SOUINIRH[n

c]OAttC[n,InterCellHc]OSuccC[n,InterCellHc][n,OSuccRateCInterCellH

i

oi

]AISHINTE[1]SISHINTE[1

DHOAttInterCellSDHOSuccInterCellSeDHOSuccRatInterCellS ==

∑

∑

=

=

+

+== 11

1

11

1

c] 11*[n ATINBHDO

c] 11*[n SUINBHDO

Att[n]InterBSCHOSucc[n]InterBSCHO]SuccRate[nInterBSCHO

c

c

c] 11* ATINBHDO[nc] 11* SUINBHDO[nc]n,SuccRateC[InterBSCHO

++

=

]AOINTESH[1]SOINTESH[1

HOAttInterBSCSDHOSuccInterBSCSDHOSuccRateInterBSCSD ==

Counters SINTHITA, ATINHIARC, AISHINTR, SISHINTR, AOUINIRH, SOUINIRH, AISHINTE, SISHINTE, SUINBHDO, ATINBHDO, SOINTESH, AOINTESH

Object Cell (Intra cell Handover)

Neighbor cell (for intercell intra/inter BSC Handover)

Unit None



113

Intersystem Handover KPI related to Successful HO Long name Outgoing Inter System Handover Success Rate

Outgoing Inter System Handover Success Rate per cause

Success Rate for Incoming Inter System HO from UMTS

Short name

InterSysOtgHOSuccRate

InterSysOtgHOSuccRateC

InterSysIncHOSuccRate

Description These KPI describe the HO success rate in case of 2G-3G outgoing and incoming handovers. They are provided as an aggregation over all HO and are in addition separated per HO cause value.

Formula

∑

∑

=

=

+

+=

==

11

1

11

1

c] 11*[n ATOISHDO

c] 11*[n SUOISHDO

gHOAtt[n]InterSysOtgHOSucc[n]InterSysOte[n]gHOSuccRatInterSysOt

c

c

c] 11* ATOISHDO[nc] 11* SUOISHDO[nc]eC[n,gHOSuccRatInterSysOt

++

=

[1] RQIISHDO[1] SUIISHDO

cHOAttInterSysIncHOSuccInterSysInecHOSuccRatInterSysIn ==

Counters SUOISHDO, ATOISHDO, SUIISHDO,RQIISHDO

Object Neighbor cell (in case of outgoing HO)

BSC (in case of incoming HO)

Unit None



114

Handover Failure and Handover Drop related KPI The Hanover Failure related KPIs give the number and rate of Intra and Inter Cell Handover Failures by meaning of unsuccessful handovers without loss of MS connection because of reversion to old channel. On the contrary, the Handover Drop related KPIs give the number and rate of Intra and Inter Cell Handover Drops by meaning of unsuccessful handovers with loss of MS connection. The indicators on the HO Failure/Drop Rate are provided as an aggregation over all HO causes and are provided in addition separated per HO cause value.



115

Intra Cell, Intra BSC and Inter BSC Handover KPI related to Handover Failure and Handover Drop Rate

Long name Intra Cell Handover Failure Rate

Intra Cell Handover Failure Rate per Handover Cause

Intra Cell Handover Drop Rate

Intra Cell Handover Drop Rate per Handover Cause

Intra Cell SDCCH Handover Failure Rate

Intra Cell SDCCH Handover Failure Rate

Inter Cell Intra BSC Handover Failure Rate

Inter Cell Intra BSC Handover Failures Rate per cause

Inter Cell Intra BSC Handover Drop Rate

Inter Cell Intra BSC Handover Drop Rate per cause

Inter Cell SDCCH Handover Failure Rate

Inter Cell SDCCH Handover Drop Rate

Short name

IntraCellHOFailRate

IntraCellHOFailRateC

IntraCellHODropRate

IntraCellHODropRateC

IntraCellSDHOFailRate

IntraCellSDHODropRate

InterCellHOFailRate

InterCellHOFailRateC

InterCellHODropRate

InterCellHODropRateC

InterCellSDHOFailRate

InterCellSDHODropRate

Description These KPI describe the HO Failure and Drop Rate in case of different initiated GSM handovers as an aggregation over all HO causes and are provided in addition separated per HO cause value.



116

Formula

...14]ATINHIAC[1..14]UNINHOIA[1

OAttIntraCellHOFailIntraCellHOFailRateIntraCellH ==

]ATINHIAC[c]UNINHOIA[c[c]OFailRateCIntraCellH =

...14]ATINHIAC[1]UNIHIALC[1

OAttIntraCellHODropIntraCellHODropRateIntraCellH ==

]ATINHIAC[c]UNINHOIA[c- ]SINTHITA[c- ]ATINHIAC[c[c]ODropRateCIntraCellH =

]AISHINTR[1]UISHINTR[1

DHOAttIntraCellSDHOFailIntraCellSeDHOFailRatIntraCellS ==

]AISHINTR[1]UISHIALC[1

DHOAttIntraCellSDHODropIntraCellSeDHODropRatIntraCellS ==

c]12*i48*[n AOUINIRH

c] 12*[n UNINHOIE

OAtt[n]InterCellHOFail[n]InterCellHn]OFailRate[InterCellH

12

1c

3

0i

12

1c

++

+=

==

∑∑

∑

= =

=

∑=

++

+= 3

0ic] 12* i48 * AOUINIRH[n

c] 12*[n UNINHOIEc][n,OFailRateCInterCellH

OAtt[n]InterCellHOFail[n]InterCellH - OSucc[n]InterCellH - OAtt[n]InterCellH

OAtt[n]InterCellHODrop[n]InterCellHn]ODropRate[InterCellH

=

==

∑

∑

∑

=

=

=

++

+−

−++

++=

=

3

0

3

0

3

0

c] 12*i 48*AOUINIRH[n

c] 12*[n UNINHOIE

c] 12*i 48*AOUINIRH[n

c] 12* i48*n SOUINIRH)[-(AOUINIRH

c][n,ODropRateCInterCellH

i

i

i



117

Formula

]AISHINTE[1]UISHINTE[1

DHOAttInterCellSDHOFailInterCellSeDHOFailRatInterCellS ==

]AISHINTE[1]UISHIRLC[1

DHOAttInterCellSDHODropInterCellSeDHODropRatInterCellS ==

Counters UNINHOIA, ATINHIAC,UNIHIALC, SINTHITA, UISHINTR, AISHINTR, UISHIALC, UNINHOIE, AOUINIRH, SOUINIRH, UISHINTE, AISHINTE, UISHIRLC

Object Cell (for Intra cell HO)

Neighbor cell (for inter cell intra or inter BSC Handover in case of TCH HO

Unit None

Note: For same KPI types concerning the Inter Cell Inter BSC HO and the Intersystem HO please refer to the Appendix 4, sections 15.4 and 15.5 respectively. They are omitted in the above table in order not to load the text too much with the similar formulas.



118

1.4.9 Radio Channel Load Analysis

1.4.9.1 Basics The traffic theory in general uses mathematical model to describe and to optimize traffic system. To dimension one telecommunication system in such a way that even during of periods of high traffic (offered) the subscribers still have a good chance to make calls, appropriate mathematical models have to be chosen. Those subscribers who do not succeed in making a call will be either lost (in pure lost-call telephone system) or the calls will be delayed (in waiting-call telephone system). Even during the so called busy hours the percentage of non successful subscribers should not exceed a predefined value known as blocking which directly affects the Quality of Service. In the GSM Telecommunication System the Erlang B for lost-call (i.e. non-queuing) system and the Erlang C for waiting-call (queuing) system is used. In the Erlang systems there are defined the following values:

• Traffic Offered

• Traffic Carried

• Traffic Lost. The traffic offered is defined as the mean number of occupations (calls) offered to the system. Both accepted and not accepted occupations contribute to the traffic offered. The traffic carried is defined as the main number of simultaneous occupations of trunks (channels). In the pure loss systems, it can happen that the traffic offered is greater than the traffic carried. The non carried traffic will be lost and is called traffic lost.

In the pure waiting system, the traffic offered is always equal to the traffic carried. All calls which cannot be served directly after request due to lack of trunks will wait for being served. Real systems are combined loss/waiting systems in which not queued calls that cannot be directly served will be lost. In such systems the traffic carried will be smaller then the traffic offered.



119

The traffic flow (traffic intensity) is the measure of the size of the traffic. The unit for the traffic flow is Erlang and is defined as: 1 trunk occupied for a duration t of a constant period T carries t/T Erlang. The Erlang B formula describes the congestion as a function of Traffic Offered and the number of trunks. For the estimation of the load of the GSM system Erlang B and C formulas are used.

∑=

=== n

0i!

!1 i

i

n,n A

A(A)BE

n

EErlang B formula

Fig. 36 Erlang B System



120

1.4.9.2 Radio Channel Load counters and KPI

Counters used to calculate Radio Channel Load related Key Performance Indicators Different counter and their sequences are used in formulas for the TCH, the SDCCH and the CCCH load related performance indicators. Note: Starting from this section the Triggering Events column is replaced by the Measurement Long Name in the Counter Tables. As there are in some measurement types a number of trigger evens their indicating would overload the tables and are therefore removed. For trigger events please refer to the Performance Counter Manual, Appendix 2.



121

TCH counters used in formulas for TCH Load related KPI Measurement Long Name Measurement/


Mean Number of Busy TCH

MEBUSTCH[1...4]

1..4 mean number of busy Full Rate, Half Rate TCH per cell area

Attempted TCH Seizure Meeting a TCH Blocked State

ATCHSMBS[1...6]

1..4 blocking due to lack of TCH (FR, HR), per cell area

5, 6 blocking due to lack of Abis resources while seizing a FR or HR TCH respectively

Attempted TCH Seizures ATTCHSEI[1,2]

1,2 number of attempts to seizure FR/HR TCH

Number of messages Discarded from the TCH Queue

NMSGDISQ[1...4] 1,2 number of discarded assignment requests per TCH type

3,4 number of discarded handover requests per TCH type

Total number of TCH connections (trigger event receipt of a valid ESTABLISHINDICATION)

TNTCHCL[1...4]

1..4 number FR/HR TCH connections dependent on cell configuration

Number of Defined TCH NRDEFTCH[1.. 12]

1..12 min, max and mean number of defined TCH per channel type and per cell area

Mean TCH queue Length MTCHQLEN[1,2] 1, 2 mean number of queue length per channel type

Mean Duration of TCH is Queued MDURTCRQ[1...4] 1,2 mean duration of queuing assignment request per TCH type

3,4 mean duration of queuing handover request per TCH type



122

FACCH counters used in formula for the FACCH KPI Measurement Long Name Measurement/ Counters Counter sequence

FACCH Supervision

(the trigger events correspond to the different codec types)

FACCHSUP [1...10]

1...5 number of transmitted I, UI and UA frames

6...10 number of transmitted FACCH blocks carrying I, UI and UA frames

SDCCH counters used in formulas for SDCCH Load related KPI Measurement Long Name Measurement/ Counters Counter sequence

Mean Number of Busy SDCCH MBUSYSD [1]

Attempted SDCCH Seizure Meeting a SDCCH Blocked State

ATSDCMBS[1]

Number of Attempted SDCCH Seizures in a Period

NATTSDPEI[1]

All Available SDCCH Allocated Time ASDCALTI[1..3] 1 all available SDCCH allocated time

2,3 shortest/longest time all available SDCCH are allocated

Number of Defined SDCCH NDESDCCH[1..3]

1..3 min, max and mean number of defined SDCCH

Number of Available SDCCH NAVSDCCH[1..3] 1..3 min, max and mean number of available SDCCH



123

CCCH counters used in formulas for CCCH Load related KPI Measurement Long Name Measurement/


Number of All Defined CCCH Channels

NDEFCCCH [1,2]

1 number of scheduled CCCH slots used as RACH (UL)

2 number of CCCH blocks scheduled for transmission (DL)

Number of Transmitted and Discarded Messages on the AGCH

NTDMAGCH[1...4]

1,2 number of transmitted CS/PS messages respectively

3,4 number of CS/PS messages discarded from the AGCH queue

Number of Transmitted and Discarded Messages on a PCH per cell

NTDMPCH[1..7]

1,2 number of transmitted CS/PS messages respectively

3,4 number of CS/PS messages discarded from the PCH queue

5 number of transmitted utilized PCH blocks on air

6,7 number of Paging Commands causing ''extended paging''/''paging re-organization'' mode respectively

Number of accesses with a Successful Result

by Procedure

NACSUCPR[1..3] 1..3 number of successful accesses to the PCH, AGCH and RACH

Number of Invalid RACH Messages NINVRACH[1..3]

1..3 signal level too weak, excessive distance, another causes for invalid RACH



124

Radio Channel Load related KPI Not all the SBS Performance Indicators defined for a traffic load will be listed in the following tables. Also not all of the performance indicators belonging to a certain type of PI mentioned, will be given. The TCH Loss Rate, TCH Traffic Offered, TCH Traffic Carried, TCH Traffic Lost, TCH Occupied Rate (Blocking) and the TCH Mean Holding Time are defined per TCH channel type (i.e. FR, HR, Dual Rate (DR)). These PI will be included in the following table only for the Full Rate TCH type as the KPI formulas for the HR TCH are the same but use another counter sequences and those for the Dual Rate TCH sum up in the same formulas all counter sequences. Load related performance indicators for the Waiting Systems are also provided by considering only the TCH Seizure attempts discarded from the TCH queue. The KPI related to TCH Load in the Waiting Systems are going to miss in the table too. Please refer to the Appendix 4, section 9.1 in order to get complete overview of the defined TCH Load related performance indicators. In the section that follows the formulas for the same type of the Load related performance indicators concerning the SDCCH will be given.



125

TCH Load related KPI TCH Loss Rate gives the TCH seizure blocked rate by meaning the rate where new TCH Seizure Attempts could not be handled by the observed cell, because all traffic channels were occupied / blocked. TCH seizure attempts for HO and Directed Retry are included in the formulas. Therefore from the perspective of a mobile subscriber, the call setup might become successful by assigning a TCH in another cell through (e.g. by applying the feature Directed Retry) even when a TCH blocking is counted, i.e. the KPIs consider the TCH access on cell level but not on connection level. TCH Traffic Offered gives the theoretical amount of traffic in Erlang which was offered to a cell. The indicators comprise the traffic explicitly induced by mobile subscribers and also additional virtual traffic emerged from radio network internal features like Directed retry and Handover. This indicator can be used for radio network capacity planning, bit in connection with the subscriber satisfaction oriented indicators (e.g. Call Setup Failure Rate due to TCH loss). TCH Traffic Carried gives the amount of carried traffic in Erlang on TCH. TCH Traffic Lost gives the amount of circuit switched traffic in Erlang which was lost for a cell due to lack of TCH resources. It is not related to the loss of traffic a subscriber experiences (e.g. during HO execution if a certain target cell candidate is fully occupied this situation is counted as lost traffic for that target cell; but from the perspective of the subscriber the HO might become successful in another target cell. For Waiting Systems (queuing) there is an indicator that takes into account amount of circuit switched traffic (measured in Erlang), which was lost due to discard from the TCH waiting queue. TCH Occupied Rate gives the TCH Blocking Rate by meaning the rate were all traffic channels were occupied. TCH Mean Holding Time gives the mean holding Time in seconds for occupied TCHs in a cell. TCH Traffic Utilization gives the TCH Traffic Rate by meaning the carried traffic divided through number of defined TCH.



126

TCH Load related KPI Long name TCH Loss Rate

(a) TCH seizure blocked Rate Full Rate

(b)TCH seizure blocked Rate

TCH Traffic Offered Full Rate

TCH Traffic Carried Full Rate

TCH Traffic Lost Full Rate

TCH Occupied Rate Full Rate

TCH Occupied Rate Dual Rate**

TCH Mean Holding Time Full Rate

TCH Traffic Utilization (a) TCH Traffic Utilization FR

(b) TCH Traffic Utilization full Rate based on Erlang

Short name

(a) TCHSeizBlckRateFR

(b) TCHSeizBlckRate

TCHTrafOffFR

TCHTrafCarrFR

TCHTrafLostFR

TCHOccRateFR

TCHOccRateDR**

TCHMHTFR

(a) TCHTrafUtilFR

(b) TCHTrafUtilFRErl

Description These KPI provide the TCH load per cell by meaning the TCH Loss, Blocking and Utilization rate as well as the number of Offered, Carried, Lost TCH Traffic.



127

Formula

(a)[1] ATTCHSEI

5] 3, [1, ATCHSMBSkRateFRTCHSeizBlc =

(b)[1..2] ATTCHSEI

*[1..4] NMSGDISQ ll] ATCHSMBS[akRateTCHSeizBlc +=

eFRTCHLossRat-13] [1, MEBUSTCHFRTCHTrafOff =

3] [1, MEBUSTCHrFRTCHTrafCar =

rFRTCHTrafCar - FRTCHTrafOff tFRTCHTrafLos =

60s*yGranularit]AALTCHTI[1FRTCHOccRate =

HRT* HRTCHOccRate FRT * FRTCHOccRate DRTCHOccRate += **

3] [1, TNTCHCL60 *y Granularit * ,3]MEBUSTCH[1TCHMHTFR =

8] [2, NRDEFTCH ,3]MEBUSTCH[1FRTCHTrafUtl =

formula B Erlang i.e. B), [2,8],f(NRDEFTCH B)f(N, A here

,A

,3]MEBUSTCH[1FRErlTCHTrafUtl

==

=

w

Counters ATCHSMBS, ATTCHSEI, NMSGDISQ, MEBUSTCH, TCHLossRateFR, AALTCHTI, FRT, HRT, Granularity in Minutes, TNTCHCL, NRDEFTCH

Object Cell

Unit Erlang (TCH Traffic Offered, Carried and Lost, TCH Traffic Utilization based on Erlang)

sec (TCH Mean Holding Time)

None (all another KPI)

Note: * The formula under (b) gives the total TCH Seizure Block Rate, i.e. includes the blocking on all the TCH in both Erlang Systems (the Blocking and the Waiting). ** When calculating the TCH Occupied Rate for Dual Rate TCH, the TCH/FR and the TCH/HR must be weighted with the TCH Traffic Distribution Rate PI for the FR and

HR traffic respectively ([1...4] MEBUSTCH

3] [1, MEBUSTCHFRT = and [1...4] MEBUSTCH

4] [2, MEBUSTCHHRT = ).



128

FACCH related KPI Long name FACCH Repetition Rate

Short name

FACCHRR

Description This KPI provides the rate of transmitted I(ASSHOCMD), UI(PHYS_INFO) and UA (the SABM confirmation) frames versus the number of transmitted FACCH-blocks used to send over the radio interface the I(ASSHOCMD), UI(PHYS_INFO) and UA (the SABM confirmation) frames.

Formula

5][k FACCHSUP [k] FACCHSUP1FACCHRR(k)

+−=

Counters FACCHSUP

Object Cell

Unit %

SDCCH Load related KPI SDCCH Traffic Offered gives the theoretical amount of traffic in Erlang on SDCCH the MS subscribers want to have due to traffic theory. SDCCH Traffic Carried gives the amount of carried traffic in Erlang on SDCCH. SDCCH Traffic Lost gives the amount of traffic in Erlang on SDCCH which were lost (blocking). SDCCH Occupied Rate gives the SDCCH Blocking Rate by meaning the rate where all SDCCH resources were occupied. SDCCH Block Rate gives the SDCCH Traffic Loss Rate by meaning the rate where new SDCCH Seizure Attempts could not be handled as all SDCCH were occupied. SDCCH Mean holding time gives the mean holding time in seconds for occupied SDCCH in a cell. SDCCH Traffic Utilization gives the SDCCH Utilization by meaning of the carried traffic divided through the number of available SDCCH. The KPI can also be based on the Erlang B function.



129

SDCCH Load related KPI Long name SDCCH Traffic Offered

SDCCH Traffic Carried

SDCCH Traffic Lost

SDCCH Occupied Rate

SDCCH Block Rate

SDCCH Mean Holding Time

(a) SDCCH Traffic Utilization

(b) SDCCH Traffic utilization based on Erlang

Short name

SDCCHTrafOff

SDCCHTrafCarr

SDCCHTrafLost

SDCCHOccRate

SDCCHBlockRate

SDCCHMHT

(a) SDCCHTrafUtilFR

(b)SDCCHTrafUtilFRErl

Description These KPI provide the SDCCH load per cell by meaning the SDCCH Loss, Blocking and Utilization rate as well as the number of Offered, Carried, Lost SDCCH Traffic.

Formula

ateSDCCHLossR-1[1] MBUSYSDCffSDCCHTrafO =

[1] MBUSYSDCarrSDCCHTrafC =

arrSDCCHTrafC - ffSDCCHTrafO ost SDCCHTrafL =

60s*yGranularit[1] ASDCALTI teSDCCHOccRa =

[1] NATTSDPE[1] ATSDCMBS teRaSDCCHBlock =

..6]NSUCCHPC[160s *y Granularit * [1] MBUSYSDCSDCCHMHT =

]NDESDCCH[2 ]MBUSYSDC[1tlSDCCHTrafU =

formula B Erlang i.e. B), [2],f(NDESDCCH B)f(N, A here

,A

]MBUSYSDC[1tlErlSDCCHTrafU

==

=

w

Counters MBUSYSDC, ASDCALTI, ATSDCMBS, NATTSDPE, NSUCCHPC, NDESDCCH

Object Cell

Unit Erlang (SDCCH Traffic Offered, Carried and Lost, SDCCH Traffic Utilization based on Erlang)

sec (SDCCH Mean Holding Time)

None (all another KPIs)



130

CCCH Load related KPI The Common Control Channel (CCCH) group consists of four logical channels which are used for common control signaling to start a connection setup. The SBS supports several channel combinations (MBCCHC, MAINBCCH, CCCH+BCCH in addition) resulting in different capacities for the CCCHs. Although a certain channel combination can serve the expected RACH traffic load, another channel combination may be necessary. The RACH is only the uplink part of the CCCH. The downlink parts (AGCH, PCH) may need a higher capacity. Therefore, the configuration of CCCH is determined by the capacity needed for the downlink channels. The RACH configuration is not critical. The PCH and the AGCH share the same physical resources DL. PCH channels may be used as AGCH channels but not vice versa. However, to ensure a mobile a satisfactory access to the system, there is a control parameter to define a fixed number of AGCH blocks in the 51 multiframe (a block consists of 4 consecutive TDMA frames). This number reduces the number of available paging blocks. In all cells where the advanced speech call item (ASCI) service is enabled, a notification channel (NCH) is defined. The NCH channels are not considered as Notification messages are used by a limited number of customers. The CCCH Load related PIs concern the PCH and the AGCH load of CCCH channels DL, and the CCCH Load UL. These load indicators are described as follows: PCH Load is the number of accessed PCH frames over the air interface in relation to the number of defined CCCH frames DL. AGCH Load is the number of accessed AGCH frames over the air interface in relation to the number of defined CCCH frames DL. CCCH Load Uplink is the number of received CCCH frames UL (RACH) over the air interface in relation to the number of defined CCCH frames UL. In addition Loss Rate per CCCH channel type DL is defined (i.e. PCH and ACGH Loss Rate). There is also the indicator that gives the Invalid RACH Rate, by meaning the number of messages received on the RACH which have not resulted in sending the CHANNEL REQUIRED message towards the BSC.



131

CCCH Load related KPI Long name PCH load of downlink CCCH channels

AGCH load of downlink CCCH channels

CCCH Load Uplink

PCH Loss Rate

AGCH Loss Rate

Invalid RACH Rate

Short name

CCCHLDPCH

CCCHLDAGCH

CCCHLDUL

PCHLossRate

AGCHLossRate

InvRACHRate

Description These KPI provide the CCCH load per cell in by meaning the PCH, AGCH and CCCH UL load and the CCCH Signals Loss rate.

Formula

]NDEFCCCH[2NTDMPCH[5]CCCHLDPCH =

]NDEFCCCH[2,2]NTDMAGCH[1CCCHLDAGCH =

]NDEFCCCH[1,2,3]NINVRACH[1 ]NACSUCPR[3CCCHLDUL +

=

[1...4] NTDMPCH[3,4] NTDMPCH tePCHLossRa =

[3] NACSUCPR [1..3] NINVRACH..3] NINVRACH[1e InvRACHRat

+=

Counters NTDMPCH, NDEFCCCH, NTDMAGCH, NACSUCPR, NINVRACH

Object Cell

Unit None



132

1.4.10 Features related KPI Flexible Abis Interface and the I-Frame Discarding are the features for which some performance indicators have been created.

1.4.10.1 Features related counters and some KPI

Abis Pool related counters and some KPI To supervise the usage of resources on the Abis interface (16kbps subchannels called SUBTSLB) and their distribution between Circuit and Packet Switched Services running in a cell, a set of counters and PIs are available. The measurement Abis Supervision evaluates the most important load related KPIs for Abis Pool. For monitoring the load and availability of the Abis Pool different counters are defined. Abis Pool counters used in KPI formulas for Abis Pool Traffic Utilization Measurement Long Name Measurement/ Counters Counter sequence

Abis Pool Distribution

ABISPDIS[1...6]

1 single Abis subchannel usage rate for CS traffic 2 single Abis subchannel usage rate for PS traffic

3...6 concatenated Abis subchannels usage rate

Abis Pool Supervision ABISPSUP[1...8]

1..3 mean number of defined, available and allocated Abis

4 max number of allocated Abis subchannels

5 all available Abis subchannels allocated time 6 number of successful Abis subchannel seizures 7 number of unsuccessful Abis subchannel seizure attempts

8 number of Abis subchannel modifications



133

Abis Pool Traffic Utilization related KPI Long name Abis Pool Traffic offered

Abis Pool Traffic carried

Abis Pool Traffic lost

Abis Pool Loss Rate

Abis Pool Blocking Probability

Abis Pool Traffic Utilization

Abis Pool Peak Traffic Utilization

Short name

AbisPTrOff

AbisPTrCar

AbisPTrLost

AbisPLossRate

AbisPBlockProb

AbisPTrafUtil

AbisPTrafUtilPeak

Description These KPI describe the Abis Pool Traffic Utilization.

Formula )

]ABISPSUP[6]ABISPSUP[7(1 * ]ABISPSUP[3 AbisPTrOff +=

]ABISPSUP[3 AbisPTrCar =

]ABISPSUP[6]ABISPSUP[7* ]ABISPSUP[3 t AbisPTrLos =

]ABISPSUP[7 ]ABISPSUP[6]ABISPSUP[7ateAbisPLossR

+=

Periody Granularit]ABISPSUP[5 ProbAbisPBlock =

]ABISPSUP[1]ABISPSUP[3 tilAbisPTrafU =

]ABISPSUP[1]ABISPSUP[4tilPeak AbisPTrafU =

Counters ABISPSUP

Object Cell

Unit None

Note: Please refer to the Appendix 4, section 14.1 in order to get more KPI related to the Abis Pool Traffic Utilization.



134

1.4.10.2 I-Frame Discarding related counters and KPI I-Frame related counters Measurement Long Name Measurement/Counters Counter sequence

I-Frame Measurements on the Abis-Interface on BSC side

IFRMABSC[1..4] 1 number of transmitted I-frames

2 number of discarded I-frames from the transmit queue

3 number of received I-frames

4 number of badly received I-frames

I-Frame Measurements on the Abis-Interface on BTSE side

IFRMABIS[1..4] the same meaning as above

KPI related to the I-Frame Discard Rate on Abis Interface BSC side

Long name Loss rate of transmitted I-Frames on BSC side

Loss rate of received I-Frames on BSC side

I-Frame Error Rate on Abis at BSC side

Short name

IFramesDiscRateTransmitted

IFramesDiscRateReceived

IFramesErrorRateBSC

Description These KPI describe the I-Frame Loss Rate by meaning the number of discarded or badly received I-Frames related to the total number of transmitted I-Frames of the LAPD protocol on the Abis Interface on BSC side..

Formula

,2]IFRMABSC[1]IFRMABSC[2 mittedcRateTransIFramesDis =

]IFRMABIS[1,4]IFRMABSC[3 - ]IFRMABIS[1 orRateBSCIFramesErr

,4]IFRMABSC[3]IFRMABSC[4 vedcRateReceiIFramesDis

=

=

Counters IFRMABSC, IFRMABIS

Object BSC

Unit None

Note: Only I-Frames with SAPI = 0 (radio signaling link) and SAPI = 62 (O&M connection) are considered. For the KPI related to the I-frame Discard Rate on A-bis Interface BTSE side, please refer to the Appendix 4, section 14.3.



135

2 GSM PS signaling procedure



136

2.1 Overview of the system interfaces and protocols

Fig. 37 Overview of the system interfaces (packet switched)



137

GPRS/E-GPRS transmission plane

MAC

GSM RF

RLC

LLC

SNDCP

IP

Application

MAC

GSM RF

RLC

NS

FR

L1

BSSGPRelay

NS

FR

L1

BSSGP

LLC

SNDCP

L1

L2 L2

IP IP

UDP UDP

GTP GTPRelay

IP

MS BSS SGSN GGSNUm Gb Gn Gi

L1

SNDCP: SubNetwork Dependent Convergence Protocol

LLC: Logical Link ControlRLC: Radio Link ControlMAC: Medium Access Control

BSSGP: BSS GPRS ProtocolNS: Network ServiceFR: Frame Relay

GTP: GPRS Tunnelling ProtocolUDP: User Datagram ProtocolIP: Internet Protocol

Fig. 38 Protocols used in the GPRS/E-GPRS transmission plane

MAC

GSM RF

RLC

LLC

GMM/SMGPRS MobilityManagement

& SessionManagement

MAC

GSM RF

RLC

NS

FR

L1

BSSGP

Relay

NS

FR

L1

BSSGP

LLC


& SessionManagement

MS BSS SGSNUm Gb

GPRS/E-GPRS signaling planeMS-SGSN

Fig. 39 Protocols used in the GPRS/E-GPRS signaling plane



138

2.1.1 Protocols used in the GPRS/E-GPRS transmission plane Protocol Structure for the interfaces Gi and Gn The following protocols are needed to pass the user data from the PDN to the SGSN (or vice versa) during GPRS transmission in the GSM-PLMN: L2‘, L1‘: L2‘ and L1‘ are the link layer and physical layer of the external networks connected via the Gi-interface to the GSM-GPRS-PLMN. As such, L2‘ and L1‘ are situated outside the GPRS definition area. However, there has to be an agreement in terms of these layers functions between the different network operators (GSM-PLMN and PDN) interconnected via the Gi-interface, or between the GSM network operator and a transit network. GTP (GPRS Tunneling Protocol) The GTP task is to tunnel user data and user signaling between the GPRS support nodes GSN of the GPRS backbone network. The data packets (protocol data units PDUs) supplied by different packet data protocols PDPs, e.g. IP, have to be encapsulated / de-capsulated by the GTP prior to tunneling. GTP is specified in Rec.09.60. UDP/TCP (User Datagram Protocol/ Transmission Control Protocol): UDP protocol is used for the transfer of data packets encapsulated by the GTP across the GPRS backbone network. It has to be supported by all GSNs as minimum solution since it transports data packets (GTP PDUs) of protocols, which require a safe data connection (e.g. IP). UDP also protects transmission against data corruption/mutilation. TCPs have to be supported in the GSNs whenever data packets of protocols have to be transported, requiring safe data connections. TCP ensures the flow control and provides protection against loss of data and data corruption. IP (Internet Protocol): is used in the GPRS backbone network for the routing of user data and network information. At the beginning, the GPRS backbone network can be based on the IP version 4. However, the objective envisaged is IP version 6. L2, L1: L2 and L1 are GPRS-internal link and physical layer. L2 and L1 are situated outside the area of GPRS definition. Operator-specific solutions are used here.



139

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

GGSNGn GiSGSN PDN(e.g. IP)

• En-/De-capsulation PDUs (IP)• tunneling of user data & signaling

data between GSNs

• transmit encapsulated GTP data packets• protect against data corruption

• UDP / TCP → Protocols for unreliable / reliable data link (z.B. IP )

• UDP : minimum solution for each GSN• TCP includes flow control & data protection

Operator specific

L2Link Layer

IPInternetProtocol

UDPUser

DatagramProtocol

TCPTransmission

ControlProtocol

GTPGPRS

TunnellingProtocol

L1Physical

Layer

L2‘Link Layer

L1‘Physical

Layer

IP

Relay

GPRS backbone networkIP V4 / V6

• extern• arrangement PLMN

-PDN necessary

Protocolsvia

Gi, GnGPRS-

transmission plane

Fig. 40 Protocols via Gi and Gn, "IP over IP"



140

Protocol Structure for the Gb (and Um) interface The following protocols are needed to pass the user data from the SGSN to the MS (or vice versa) during GPRS transmission in the GSM-PLMN: SNDCP (SubNetwork Dependent Convergence Protocol): The SNDCP supports the following functions: compression/segmentation and joining, multiplexing and de-multiplexing of data packets onto one or several LLC SAPs (service access points). The compression function is applied to the user data of the data packet and (if applicable) to the packet header. Segmentation is required to limit the size of the data packets, which is transferred by the LLC as one single unit via the radio interface. The SNDCP is specified in the GSM Rec. 04.65. LLC (Logical Link Control): The LLC layer realizes a highly reliable ciphered logical connection and thus provides the basis for maintaining communication between the SGSN and the MS. From the point of view of the LLC layer, there is a complete connection between SGSN and MS, even if the RLC/MAC do not support a physical connection, i.e. even if no data packets are transferred at that point in time. A physical connection is set-up by the RLC/MAC layer only if the LLC layer supplies the data required for transmission. LLC layer has several access points to be able to transport various types of data; also, it distinguishes between several “quality of service QoS” classes. The LLC layer is also responsible for carrying out the ciphering function in the GPRS network. LLC is specified in GSM Rec. 04.64. BSSGP (BSS GPRS Protocol): The BSSGP transports the LLC frames as well as routing and QoS-related information between the BSS (PCU) and the SGSN. The BSSGP does not carry out fault correction. It is specified in GSM Rec. 08.18. IP/FR (Internet Protocol/Frame Relay): The Network Service (NS) layer transports the BSSGP data packets. NS is based on Frame Relay (older solution) and/or IP as solution supported since the SBS Release BR8.0. They represent the link layer protocol for the connection between SGSN and PCU (Gb interface). NS is specified in GSM Rec. 08.16. L1bis: Physical Layer of the Gb-interface. L1bis is realized through E1/T1 (PCM30/PCM24) or SDH technology.



141

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RLC

MAC

SNDCPSubNetworkDependent

ConvergenceProtocol

SGSNGb Gn

• transmit LLC frames• & Routing & QoS - Infos• no error correction

Unreliable transportBSSGP PDUs

IP

UDP /

TCP

GTP

L1bisPhysical

Layer

L2

L1

Relay

BSSGPBSS

GPRSProtocol

LLCLogical Link

Control

BSS (PCU)

L1bisPhysical

Layer

IP/FR

GSM RF

BSSGPBSS

GPRSProtocol

Relay

UmE1 / T1 (PCM30/24)

• logical connection (evenwithout physical connection)

• different SAPs (SNDCP, GMM/SM, SMS), QoS,..

• Ciphering

• Compression(user data + maybe header)

• Segmentation / Re-assembly• Multiplexing / De-Multiplexing

different PDPs

Protocols via

Gb, (Um)GPRS-

transmission plane

SAP: Service Access Point

IP/FR

Fig. 41 Protocol via Gb (and Um) interface



142

Protocol Structure for the Um interface RLC (Radio Link Control) / MAC (Medium Access Control): RLC and MAC are the layers used for the implementation of a reliable physical connection via the radio interface on which data packets are transported. RLC and MAC are closely associated with each other and are defined in GSM Rec. 04.60. GSM RF (Radio Frequency): GSM RF is the physical channel used to transfer packet data via the GSM radio interface Um. These two layers will be in the following pages in details described.



143

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RLCRadio Link

Control

MACMedium Access

Control

SNDCP

SGSN

Gb

LLC

BSS (PCU)

L1bis

IP/FR

BSSGP

Relay • Segmentation / Re-assemblingLLC-frames ↔ RLC radio blocks

• Backward Error Correction BEC

Protocols via UmGPRS

transmissions plane

GSM RF

UmMS

RLCRadio Link

Control

MACMedium Access

Control

GSM RF

IP

Application

GGSN

TE

• Access Signaling Procedures(Requests, Grants)

• Sub-Multiplexing:different MSs → 1 physical channelchannel combining → 1 MS (1..8 TS)

RLC/MAC:enable reliable

physical connectionvia Um

Physical RF-channelfor packet data transmission

Fig. 42 Protocols via Um



144

2.1.2 Protocols used in the GPRS/EGPRS signaling plane The signaling plane consists of protocols for the control and support of transmission plane functions:

• Control of GPRS network access, e.g. „attaching“ and „detaching“

• Control of the data elements (attributes) of an established network connection and activation of the packet data protocol PDP (e.g. X.25 / IP) addresses.

• Control of the routing path of an established connection in terms of subscriber mobility support.

• Support of the network resource allocation to account for various user requests.

• Supplementary services implementation Signaling Plane MS-SGSN: In addition to the protocols of the transmission plane a further plane, based on the functions GSM FR, RLC/MAC and LLC, is required: GMM/SM (GPRS Mobility Management and Session Management): The GMM/SM protocol supports mobility management functions such as GPRS attach, GPRS detach, safeguarding functions, routing area & location update), and session management functions as PDP context activation & deactivation & modification.



145

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

MAC

GSM RF

RLC

LLC


& SessionManagement

MAC

GSM RF

RLC

FR/NS

L1 bis

BSSGP

Relay

FR/NS

L1 bis

BSSGP

LLC


& SessionManagement

MS BSS SGSNUm Gb

GPRS signaling planeMS-SGSN

Mobility Management functions• GPRS attach / detach• security functions• Update Location (CGI, RAI)• PDP context (de-) activation / modification

Fig. 43 GPRS signaling plane, GMM/SM



146

Signaling SGSN - HLR / EIR / SMS-GMSC, GGSN - HLR: For signaling via Gr-, Gf-, Gd- and Gc-interface, i.e. between the SGSN and the HLR, EIR, SMS-GSMC and between the GGSN and the HLR the same protocols of Signaling System No. 7 (SS7) are used as in the NSS of GSM-PLMN (Phase1/2). The realization of the Message Transfer Parts MTP (L1 – L3), of the Signaling Connection Control Part SCCP as well as of the Transaction Capabilities Application Parts TCAP are identical. MAP (Mobile Application Part): The MAP used in GSM (Phase1/2) needs to be expanded by mobility management functions particularly in view of the information exchange between SGSN and GGSN and between SGSN and HLR respectively (GSM Rec. 09.02.) The information flow between GGSN and HLR can also flow across further GSNs and is tunneled in this case by using the GPRS tunneling protocol GTP between the GSNs (Gn-interface). Signaling plane SGSN – MSC/VLR Signaling via the Gs-interface, i.e. between SGSN and MSC/VLR, uses the same protocols of the SS7 as the ones used via the A-interface of the GSM-PLMN (GSM Rec. 09.16). BSSAP+ (BSS Application Part+): Signaling is performed via a subset of the BSSAP functions used on the A-interface (GSM Rec. 09.18). Signaling plane GSN-GSN: The exchange of signaling information between the different GPRS Support Nodes GSN (Gn-interface), i.e. via the IP-based GPRS backbone uses the corresponding transmission plane protocols: L1, L2 (operator-specific), IP (V4, later V6), UDP (User Datagram Protocol) and GTP (GPRS Tunneling Protocol). The GTP tunnels both user and signaling data between the various SGSN and GGSN.



147

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

L1

SCCPSignaling Connection

Control Part

TCAPTransactionCapabilities

Application Part

MAPMobile

ApplicationPart

MTP L2

MTP L3

L1

SCCP

TCAP

MAPMobile

ApplicationPart

MTP L2

MTP L3

L1

SCCP

MTP L2

MTP L3

L1

SCCP

MTP L2

MTP L3

BSSAP+BSS Application

Part +

BSSAP+BSS Application

Part +

SGSN HLR, EIR, SMS-GMSCGr ,f, d

GPRS signaling plane

SGSN MSC /VLRGs

GGSN HLRGc

MAP enhanced for GPRS Subset of BSSAP functions

Fig. 44 GPRS signaling plane, protocol stack for CSS7-interfaces



148

2.1.3 Um interface

2.1.3.1 Layer 1 By introducing GPRS services into the GSM-PLMN, modifications are necessary in the area of physical transmission (layer 1) via the air or radio interface Um. The tasks of layer 1 radio interface relate to the transmission of user and signaling data as well as to the measuring of the receiver performance, cell selection, determination and updating of the delayed MS transmission (timing advance TA), power control PC and channel coding.

Logical Channels on the Um Interface for Packet Switched Technology The packet data logical channels are mapped onto the physical channels that are dedicated to packet data. The physical channel dedicated to packet data traffic is called a Packet Data Channel (PDCH). GPRS introduces the following new types of logical channels:

• PCCCH (packet common control channels)

• PBCCH (packet broadcast control channels)

• PDCCH (packet dedicated control channels)

• PDTCH (packet data traffic channels)

PCCCH (Packet Common Control Channel) PCCCH comprises the following logical channels for common control signaling used for packet data.

• PRACH (Packet Random Access Channel) PRACH is used by MS to initiate uplink transfer for sending data or signaling information. Packet Access burst and Extended Packet Access burst are used on PRACH. This channel is used uplink only.

• PPCH (Packet Paging Channel) PPCH is used to page an MS prior to downlink packet transfer. PPCH use paging groups in order to allow usage of DRX mode. PPCH can be used for paging of both circuit switched and packet data services. The paging for circuit switched services on PPCH is applicable for class A and B GPRS MSs in Network operation mode I, see 3GPP TS 03.60 [3]. This channel is used downlink only.

• PAGCH (Packet Access Grant Channel) PAGCH is used in the packet transfer establishment phase to send resource assignment to an MS prior to packet transfer. This channel is used downlink only.



149

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PCCHPacket Control CH

PRACH = PacketRandom Access CH

PDTCH = PacketData Traffic CH

PTCHPacket Traffic CH

PDCCH PacketDedicated Control CH

PBCH = PacketBroadcast CH

PCCCH = PacketCommon Control CH

PAGCH = PacketAccess Grant CH

PPCH = PacketPaging CH

PNCH = PacketNotification CH

PBCCH = PacketBroadcast Control CH

PACCH = PacketAssociated Control CH

PTCCH/U = PacketTA Control CH uplink

PTCCH/D = PacketTA Control CH downlink

Logical Channels

Fig. 45 Logical channels on the air-interface for packet switched technology



150

• PNCH (Packet Notification Channel) PNCH is used to send a PTM-M (Point To Multipoint - Multicast) notification to a group of MSs prior to a PTM-M packet transfer. DRX mode shall be provided for monitoring PNCH. Furthermore, a “PTM-M new message" indicator may optionally be sent on all individual paging channels to inform MSs interested in PTM-M when they need to listen to PNCH. The PTM-M service is not specified in GPRS Phase 1. This channel is used downlink only.

Packet Broadcast Control Channels (PBCCH)

• Packet Broadcast Control Channel (PBCCH) PBCCH broadcast packet data specific System Information. If PBCCH is not allocated, the packet data specific system information is broadcast on BCCH. This channel is used downlink only.

Packet Dedicated Control Channels (PDCCH)

• PACCH (Packet Associated Control Channel) PACCH conveys signaling information related to a given MS. The signaling information includes e.g. acknowledgements and power control information. PACCH carries also resource assignment and reassignment messages, comprising the assignment of a capacity for PDTCH(s) and for further occurrences of PACCH. The PACCH shares resources with PDTCHs, that are currently assigned to one MS. Additionally, an MS that is currently involved in packet transfer, can be paged for circuit switched services on PACCH. A PACCH when used for single timeslot operation may be either full-rate (PACCH/F) or half-rate (PACCH/H) depending on whether it is carried on a PDCH/F or PDCH/H respectively. See 3GPP TS 05.02 [11]. A PACCH, when used for multislot operation shall be full-rate. DTM capable MS shall support PACCH/H.

• PTCCH/U (Packet Timing advance Control Channel, uplink) PTCCH/U is used to transmit random access burst to allow estimation of the timing advance for one MS in packet transfer mode. PTCCH/U shall not be used for DTM.

• PTCCH/D (Packet Timing advance Control Channel, downlink) PTCCH/D is used to transmit timing advance information updates to several MS. One PTCCH/D is paired with several PTCCH/U’s. PTCCH/D shall be ignored by MS operating in DTM.



151

Packet Traffic Channel (PTCH)

• PDTCH (Packet Data Traffic Channels) PDTCH is a channel allocated for data transfer. It is temporarily dedicated to one MS or to a group of MSs in the PTM-M case. In the multislot operation, one MS may use multiple PDTCHs in parallel for individual packet transfer. All packet data traffic channels are unidirectional, either uplink (PDTCH/U), for a mobile originated packet transfer or downlink (PDTCH/D) for a mobile terminated packet transfer. A PDTCH when used for single timeslot operation may be either full-rate (PDTCH/F) or half-rate (PDTCH/H) depending on whether it is carried on a PDCH/F or PDCH/H respectively. See 3GPP TS 05.02 [11]. A PDTCH, when used for multislot operation shall be full-rate. DTM capable MS shall support PDTCH/H.

2.1.3.2 Layer 2/3 The RLC and MAC are the layers used for the implementation of a reliable physical connection via the radio interface. They are closely associated with each other and are defined in GSM Rec. 04.60. To establish complete logical connection MS-SGSN, the RLC/MAC protocol is relevant between the MS and the BSC, while the BSS GPRS Protocol (BSSGP) is used on the Gb Interface between the BSC and the SGSN.

MS BSC SGSN

RLC/MAC BSSGP

Fig. 46 Layer 3 connections between the MS and the network for packet switched traffic



152

Radio Link Control (RLC) The RLC function defines the procedures for segmentation and re-assembly of LLC PDU into RLC/MAC blocks and supplies a reliable connection (Backward Error Correction, BEC) via the radio interface. For the GPRS/EGPRS transmission in RLC acknowledged mode of operation the BEC procedures enable the selective retransmission of unsuccessfully delivered RLC/MAC blocks. In RLC acknowledged mode of operation, the RLC function preserves the order of higher layer PDU provided to it. The RLC function provides also Link Adaptation. In EGPRS in RLC acknowledged mode of operation, the RLC function may provide Incremental Redundancy (IR). The RLC function is responsible for:

• Interface primitives allowing the transfer of Logical Link Control layer PDU (LLC PDU) between the LLC layer and the MAC function.

• Segmentation of LLC PDU into RLC data blocks and re-assembly of RLC data blocks into LLC PDU.

• Segmentation of RLC/MAC control messages into RLC/MAC control blocks and re-assembly of RLC/MAC control messages from RLC/MAC control blocks.

• Backward Error Correction (BEC) procedures enabling the selective retransmission of RLC data blocks.

Medium Access Control (MAC) The MAC function defines the procedures that enable several mobile stations to share a common transmission medium, which may consist of several physical channels. The function allows a mobile station to use several physical channels in parallel, i.e. to use several timeslots within the TDMA frame. For the mobile station originating access, the MAC function provides the procedures, including the contention resolution procedures, for the arbitration between multiple mobile stations simultaneously attempting to access the shared transmission medium. For the mobile station terminating access, the MAC function provides the procedures for queuing and scheduling of access attempts. The Medium Access Control procedures support the provision of Temporary Block Flows (TBF) that allow the point-to-point transfer of signaling and user data within a cell between the network and a mobile station. The MAC provides the establishment of a Temporary Block Flow (TBF), which is a physical connection between one specific MS and the network to support the unidirectional transfer of LLC Packet Data Units on packet data physical channels.



153

The TBF is an allocated radio resource on one or more PDCH and comprise a number of RLC/MAC blocks carrying one or more LLC PDU. A TBF to/from the MS is maintained only for the duration of the data transfer. Each TBF is assigned a Temporary Flow Identity (TFI) by the network. The TFI is assigned in a resource assignment message and will be stored in the first octet of the RLC/ MAC block. The TBF is identified by the TFI together with information about:

• direction (UL or DL) in which the RLC data block is sent, in case of a RLC data block,

• direction (UL or DL) in which the RLC/MAC control message is sent and the message type, in case of a RLC/MAC control message.

The importance of the TFI can be understood when considering the multiplexing of more MS on the same PDCH. The TBF can be initiated by either the MS or the network. Moreover, the Medium Access Control procedures include the procedures for reception of PBCCH and PCCCH, which permits autonomous cell reselection performed by the mobile station (see 3GPP TS 05.08).

Packet idle mode In packet idle mode no temporary block flow (TBF) exists. In packet idle mode, the mobile station monitors the relevant paging subchannels on PCCCH, if such is present in the cell. If a PCCCH is not present in the cell, the mobile station monitors the relevant paging subchannels on CCCH. In packet idle mode, upper layers may require the transfer of a LLC PDU, which implicitly triggers the establishment of a TBF and the transition to packet transfer mode. In packet idle mode, upper layers may require the establishment of a RR connection. When the mobile station enters dedicated mode (see 3GPP TS 04.18), it may leave the packet idle mode, if the mobile station limitations make it unable to handle the RR connection and the procedures in packet idle mode simultaneously.



154

Packet transfer mode In packet transfer mode, the mobile station is allocated radio resource providing a TBF for a physical point-to-point connection on one or more packet data physical channels for the unidirectional transfer of LLC PDU between the network and the mobile station. Successive transfer of one or more LLC PDU is possible. Concurrent TBF may be established in opposite directions. The RR sublayer provides the following services:

• transfer of LLC PDU in RLC acknowledged mode;

• transfer of LLC PDU in RLC unacknowledged mode. When a transfer of LLC PDU terminates, in either downlink or uplink direction, the corresponding TBF is released. In packet transfer mode, when all TBF have been released, in downlink and uplink direction, the MS returns to packet idle mode.

Main procedures in packet idle and packet transfer modes:

• Cell reselection

• Release of RR connection

• Continuation of PBCCH and BCCH information

• System information on PBCCH or BCCH

• Discontinuous reception (DRX)

• Page mode procedures on PCCCH

• Frequency Parameters

• TLLI management

• Packet Flow Context (PFC)

• System Information broadcasting

• Paging The message types of RLC / MAC are given in the following table.



155

RLC / MAC CONTROL MESSAGES (GSM 04.60-870) Uplink TBF establishment messages: Reference Packet Access Reject Packet Channel Request EGPRS Packet Channel Request Packet Queuing Notification Packet Resource Request Packet Uplink Assignment Additional MS Radio Access Capabilities

11.2.1 11.2.5 11.2.5a 11.2.15 11.2.16 11.2.29 11.2.32

Downlink TBF establishment messages: Reference Packet Downlink Assignment 11.2.7

TBF release messages: Reference Packet TBF Release 11.2.26

Paging messages: Reference Packet Paging Request 11.2.10

RLC messages: Reference Packet Downlink Ack/Nack EGPRS Packet Downlink Ack/Nack Packet Uplink Ack/Nack

11.2.6 11.2.6a 11.2.28

System information messages: Reference Packet System Information Type 1 Packet System Information Type 2 Packet System Information Type 3 Packet System Information Type 3 bis Packet System Information Type 3 ter Packet System Information Type 4 Packet System Information Type 5 Packet System Information Type 6 Packet System Information Type 7 Packet System Information Type 8 Packet System Information Type 13

11.2.18 11.2.19 11.2.20 11.2.21 11.2.21a 11.2.22 11.2.23 11.2.23a 11.2.23b 11.2.24 11.2.25



156

RLC / MAC CONTROL MESSAGES (GSM 04.60-870) Miscellaneous messages: Reference Packet Control Acknowledgement Packet Cell Change Failure Packet Cell Change Order Packet Downlink Dummy Control Block Packet Uplink Dummy Control Block Packet Measurement Report Packet Measurement Order Packet Mobile TBF Status Packet Enhanced Measurement Report Packet PDCH Release Packet Polling Request Packet Power Control/Timing Advance Packet PRACH Parameters Packet PSI Status Spare Spare Spare Packet Pause Packet Timeslot Reconfigure

11.2.2 11.2.3 11.2.4 11.2.8 11.2.8b 11.2.9 11.2.9b 11.2.9c 11.2.9d 11.2.11 11.2.12 11.2.13 11.2.14 11.2.17 11.2.24 11.2.27 11.2.30 11.2.30a 11.2.31



157

GPRS/E-GPRS RLC/MAC Block Structure For data transfer and transfer of control messages different RLC/MAC blocks are specified in UL and DL direction. In total 6 different types of RLC/MAC blocks are used

• DL RLC/MAC control blocks (used for both, GPRS and E-GPRS)

• UL RLC/MAC control blocks (used for both, GPRS and E-GPRS)

• GPRS DL RLC/MAC data blocks

• GPRS UL RLC/MAC data blocks

• E-GPRS DL RLC/MAC data blocks E-GPRS UL RLC/MAC data blocks

TFI

8 7 6 5 3 2 14 Bit-No

USFS/PPayload Type RRBP

RTI AC

PR D

RBSN FS

Control Message Contents

MAC header

octet 1

octet 2octet M

octet 22octet 21

optionaloctets

Controlheader

RLC/MACsignaling

Fig. 47 Downlink RLC/MAC control block

spare

8 7 6 5 3 2 14 Bit-No

Payload Type R

Control Message Contents

MAC headeroctet 1octet 2

octet 22octet 21

RLC/MACsignaling

Fig. 48 Uplink RLC/MAC control block



158

BSN

8 7 6 5 3 2 14 Bit-No

USFS/PPayload Type RRBP

TFI FBIPR

Length Indicator

E

EM

Length Indicator EM

RLC data

Spare bitsSpare bits

MAC header

octet 1

octet 2octet 3

octet M+1octet M

octet N-1octet N(if present)

optionaloctets

RLCheader

RLCdataunit

Fig. 49 GPRS Downlink RLC/MAC data block



159

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BSN

.

.

.

8 7 6 5 3 2 14 Bit-No

Payload Type Countdown Value

TFI TI

Length Indicator

E

EM

Length Indicator EM

RLC data

Spare bitsSpare bits

MAC header

octet 1

octet 2

octet 3

octet M+5

octet M

octet N-1octet N(if present)

Optionaloctets

RLCheader

RLCdataunit

TLLI

SI R

octet M+1

octet M+4

PIspare

PFI E

Fig. 50 GPRS Uplink RLC/MAC data block



160

8 7 6 5 3 2 14

ES/P USFRRBPTFITFIPRBSN1

BSN1BSN1BSN2

BSN2CPS


BSN1BSN1CPS


BSN1BSN1CPSSPB

Fig. 51 E-GPRS Downlink RLC/MAC data block (upper block for MCS-7-9, middle for MCS-5-6, lower for MCS-1-4)



161

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8 7 6 5 3 2 14

Countdown value SITFITFI

PI

BSN1BSN1

RSBBSN2

BSN2

CPS

R

sp.spare


PI

BSN1BSN1

RSBCPS

CPS

R

sparespare


PI

BSN1BSN1

RSBCPS

CPS

R

sp. SPB

Fig. 52 E-GPRS Uplink RLC/MAC data block (upper block for MCS-7-9, middle for MCS-5-6, lower for MCS-1-4)



162

GPRS RLC Data Block size / E-GPRS RLC Data Block size Each GPRS RLC data block consists of a RLC header, a RLC data unit, and spare bits. A GPRS RLC/MAC block containing a RLC data block may be encoded using any of the available channel coding schemes CS-1, CS-2, CS-3, or CS-4. RLC/MAC blocks encoded using CS-1 do not contain spare bits. The size of the GPRS RLC data block for each of the channel coding schemes is shown in the table below. E-GPRS radio blocks consist of one (for MCS-1 up to MCS-6), respectively two (in case of MCS-7, MCS-8 or MCS-9) RLC data blocks.

GPRS Coding Scheme

GPRS RLC data block size without spare bits (in octets)

Number of spare bits

GPRS RLC data block size including spare bits (in octets)

CS-1 22 0 22

CS-2 32 7 32 + 7/8

CS-3 38 3 38 + 3/8

CS-4 52 7 52 + 7/8

EGPRS Modulation and Coding Scheme

E-GPRS RLC data unit size (in octets)

MCS-1 22

MCS-2 28

MCS-3 37

MCS-4 44

MCS-5 56

MCS-6 74

MCS-7 2x56

MCS-8 2x68

MCS-9 2x74



163

Logical Link Control (LLC) The LLC layer realizes a highly reliable ciphered logical connection and thus provides the basis for maintaining communication between the SGSN and the MS (layer 3). From the point of view of the LLC layer, there is a complete connection between SGSN and MS, even if the RLC/MAC layer does not support a physical connection, i.e. even if no data packets are transferred at that point in time. A physical connection is set-up by the RLC/MAC layer only if the LLC layer supplies the data required for transmission. LLC layer has several access points to be able to transport various types of data; also, it distinguishes between several “quality of service QoS” classes. The LLC layer is also responsible for carrying out the ciphering function in the GPRS network. LLC is specified in GSM Rec. 04.64.



164

2.1.4 Gb Interface In contrast to the A-interface, where a single user has the sole use of a dedicated physical resource throughout the lifetime of a call irrespective of information flow, the Gb-interface allows many users to be multiplexed over a common physical resource. GPRS signaling and user data may be sent on the same physical resources. Access rates per user may vary from zero data to the maximum possible bandwidth (e.g. the available bit rate of an E1). Across the Gb-interface the following peer protocols have been identified:

• the Base Station Subsystem GPRS Protocol (BSSGP) and

• the underlying network service (NS). The NS shall transport BSSGP PDUs between a BSS and an SGSN (refer to 3GPP TS 08.16 [16]).



165

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

RLC

MAC

SNDCPSubNetworkDependent

ConvergenceProtocol

SGSNGb Gn

• transmit LLC frames• & Routing & QoS - Infos• no error correction

Unreliable transportBSSGP PDUs

FRFrame Relay

IP

UDP /

TCP

GTP

L1bisPhysical

Layer

L2

L1

Relay

BSSGPBSS

GPRSProtocol

LLCLogical Link

Control

BSS (PCU)

L1bisPhysical

Layer

FRFrame Relay

GSM RF

BSSGPBSS

GPRSProtocol

Relay

UmE1 / T1 (PCM30/24)

• logical connection (evenwithout physical connection)

• different SAPs (SNDCP, GMM/SM, SMS), QoS,..

• Ciphering

• Compression(user data + maybe header)

• Segmentation / Re-assembly• Multiplexing / De-Multiplexingdifferent PDPs

Protocols via

Gb, (Um)GPRS-

transmission plane

SAP: Service Access Point

Fig. 53 Protocols via Gb (and Um)



166

2.1.4.1 Base Station System GPRS Protocol (BSSGP) The BSSGP transports the LLC frames as well as routing and QoS-related information between the BSS (PCU) and the SGSN. The BSSGP does not carry out fault correction. It is specified in GSM Rec. 08.18. The primary functions of the BSSGP include:

• in the downlink, the provision by an SGSN to a BSS of radio related information used by the RLC/MAC function;

• in the uplink, the provision by a BSS to an SGSN of radio related information derived from the RLC/MAC function; and

• the provision of functionality which enables two physically distinct nodes, an SGSN and a BSS, to operate node management control functions.

The Base Station System GPRS Protocol (BSSGP) messages are given in the following table.



167

BSSGP PDUs (GSM 08.18) BBSGP PDU Type Remarks Direction DL-UNITDATA This PDU is sent to the

BSS to transfer a LLC-PDU across the radio interface to a MS

SGSN to BSS

UL-UNITDATA This PDU transfers a MS's LLC-PDU and its associated radio interface information across the Gb-interface

BSS to SGSN

RA-CAPABILITY This PDU informs the BSS about the new Radio Access Capability of a MS

SGSN to BSS

PAGING PS This PDU indicates that a BSS shall initiate the packet paging procedure for a MS within a group of cells

SGSN to BSS

PAGING CS This PDU indicates that a BSS shall initiate a circuit-switched paging procedure for a MS within a group of cells

SGSN to BSS

RA-CAPABILITY-UPDATE This PDU requests that the SGSN sends a MS's current Radio Access capability or IMSI to the BSS

BSS to SGSN

RA-CAPABILITY-UPDATE-ACK

This PDU provides the BSS with a MS's current Radio Access capability and IMSI

SGSN to BSS

RADIO-STATUS This PDU indicates that an exception condition related to the radio interface has occurred

BSS to SGSN



168

BSSGP PDUs (GSM 08.18) BBSGP PDU Type Remarks Direction SUSPEND This PDU indicates that a

MS wishes to suspend its GPRS service

BSS to SGSN

SUSPEND-ACK This PDU positively acknowledges the reception of a SUSPEND PDU for a MS

SGSN to BSS

SUSPEND-NACK This PDU negatively acknowledges the reception of a SUSPEND PDU for a MS

SGSN to BSS

RESUME This PDU indicates that a MS wishes to RESUME its GPRS service

BSS to SGSN

RESUME-ACK This PDU positively acknowledges the reception of a RESUME PDU for a MS

SGSN to BSS

RESUME-NACK This PDU negatively acknowledges the reception of a RESUME PDU for a MS

SGSN to BSS

FLUSH-LL This PDU informs a BSS that a MS has moved from one cell to another

SGSN to BSS

FLUSH-LL-ACK This PDU indicates that LLC-PDU(s) buffered for a MS in the old cell have been either deleted or transferred to the new cell within the NSE (Network Service Entity)

BSS to SGSN

LLC-DISCARDED This PDU indicates that a number of buffered LLC-PDUs in a cell for a MS have been deleted inside the BSS (because of PDU lifetime expiration or cell-reselection for example)

BSS to SGSN



169

BSSGP PDUs (GSM 08.18) BBSGP PDU Type Remarks Direction FLOW-CONTROL-BVC This PDU informs the flow

control mechanism at a SGSN of the status of a BVC's maximum acceptable SGSN to BSS throughput on the Gb interface

BSS to SGSN

FLOW-CONTROL-BVC-ACK

This PDU informs the flow control mechanism at the BSS that the SGSN has received the FLOW-CONTROL-BVC PDU indicated by the Tag information element

SGSN to BSS

FLOW-CONTROL-MS This PDU informs the flow control mechanism at a SGSN of the status of a MS's maximum acceptable SGSN to BSS throughput on the Gb interface

BSS to SGSN

FLOW-CONTROL-MS-ACK

This PDU informs the flow control mechanism at the BSS that the SGSN has received the FLOW-CONTROL-MS PDU indicated by the TLLI and the Tag

SGSN to BSS

BVC-BLOCK This PDU indicates that the contained BVC shall be blocked at the recipient entity

BSS to SGSN

BVC-BLOCK-ACK This PDU acknowledges that a BVC has been blocked

SGSN to BSS

BVC-UNBLOCK This PDU indicates that the identified BVC shall be unblocked at the recipient entity

BSS to SGSN

BVC-UNBLOCK-ACK This PDU acknowledges that a BVC has been unblocked

SGSN to BSS



170

BSSGP PDUs (GSM 08.18) BBSGP PDU Type Remarks Direction BVC-RESET This PDU indicates that

BVC initialization is required, e.g. because of a BVC failure

SGSN to BSS, BSS to SGSN

BVC-RESET-ACK This PDU indicates that BVC initialization has been executed

BSS to SGSN, SGSN to BSS

STATUS This PDU indicates that an exception condition occurred

SGSN to BSS, BSS to SGSN

SGSN-INVOKE-TRACE This PDU indicates that the BSS shall begin the production of a trace record for a MS.

SGSN to BSS

DOWNLOAD-BSS-PFC

This PDU requests a SGSN to initiate a CREATE-BSS-PFC procedure

BSS to SGSN

CREATE-BSS-PFC This PDU allows the SGSN to request that a BSS should create or modify a BSS Packet Flow Context

SGSN to BSS

CREATE-BSS-PFC-ACK This PDU allows the BSS to acknowledge a request from the SGSN for the creation or modification of a BSS Packet Flow Context

BSS to SGSN

CREATE-BSS-PFC-NACK This PDU allows the BSS to Nack a request from the SGSN for the creation of a BSS Packet Flow Context

BSS to SGSN

MODIFY-BSS-PFC This PDU allows the BSS to request a modification of a BSS Packet Flow Context

BSS to SGSN



171

BSSGP PDUs (GSM 08.18) BBSGP PDU Type Remarks Direction MODIFY-BSS-PFC-ACK This PDU allows the SGSN

to acknowledge a modification to a BSS Packet Flow Context

SGSN to BSS

DELETE-BSS-PFC This PDU allows the SGSN to request that a BSS deletes a BSS Packet Flow Context

SGSN to BSS

DELETE-BSS-PFC-ACK This PDU allows the BSS to acknowledge a request for the deletion of a BSS Packet Flow Context

BSS to SGSN



172

2.2 Message flow of basic packet switched BSS procedures

2.2.1 GPRS procedures In the first part of this section the general procedures for GPRS Mobility Management and GPRS Session Management are described. The temporary block flows (TBF), which are used to transport signaling messages and user data between mobile and BSS are described in section 2.2.2.



173

2.2.1.1 GPRS mobility management: attach procedure

Fig. 54 Attach procedure

The Attach procedure is used by the mobile to register for GPRS services. 1. The mobile sends Attach Request containing information about its mobile

capabilities, its multislot class and its IMSI or P-TMSI for identification. 2. If the MS identifies itself with its P-TMSI but the P-TMSI is unknown in SGSN, the

SGSN sends an Identity Request to the MS. The MS responds with Identity Response including its IMSI.

3. In contrast to ciphering in existing GSM (between BTS and MS) GPRS ciphering is a function of the LLC layer in the SGSN and in the mobiles. If enabled in the SGSN it initiates the authentication and ciphering procedure.

4. The network informs the MS that the Attach was accepted. The network may include a new P-TMSI in the Attach Accept message.

5. If the Attach Accept contained a new P-TMSI the MS confirms the reception with Attach Complete.



174

2.2.1.2 GPRS mobility management: detach procedure

Fig. 55 Detach procedure initiated by MS

The detach procedure is used by the mobile to deregister from GPRS services. 1. The mobile initiated detach might be triggered by user command from mobile

menu or when the mobile is switched off. 2. If the detach Type indicates that detach is not due to power switch off, the SGSN

sends a Detach Accept to the MS.



175

Fig. 56 Detach procedure initiated by network

The network may initiate the GPRS detach when GPRS services are no longer accepted for a subscriber (e.g. the subscriber is cancelled from the HLR database). 1. The SGSN informs the MS that it has been detached by sending Detach Request

to the MS. 2. The mobile confirms detach with a Detach Accept message.



176

2.2.1.3 GPRS session management: activate PDP context

Fig. 57 Activate PDP context

A PDP context represents a logical connection between a mobile and the network with a specific PDP address for data routing (e.g. fixed or dynamic local IP address) and a specific Quality of Service profile (QoS). The Activate PDP Context procedure is used to establish the connection. If supported by the mobile several PDP Contexts with different QoS profiles might be active handling different applications. 1. In the Activate PDP Context Request the mobile includes a requested QoS. The

MS shall use the PDP Address Information Element to indicate whether it requires the use of a static PDP Address or whether it requires the use of a dynamic PDP address. The MS leaves the PDP Address IE empty to request a dynamic PDP address.

2. The network verifies if it can support the requested QoS and if it is allowed for this subscriber. Depending on the result the SGSN may accepts the Activate PDP Context request with the requested or another QoS or the SGSN rejects the Activate PDP Context Request. If requested by the mobile, the SGSN assigns a dynamic PDP -address. The MS either accepts the negotiated QoS profile, or deactivates the PDP context.

3. In the XID messages parameters of the LLC and SNDCP layer are negotiated between the mobile and the SGSN.



177

2.2.1.4 GPRS session management: deactivate PDP context

Fig. 58 Deactivate PDP context

The deactivate PDP Context procedure is used to deactivate a specific PDP Context. E.g. the related dial up connection is disconnected. The mobile remains GPRS attached. Network initiated PDP Context Deactivation is done with reverse message directions.



178

2.2.1.5 GPRS: paging

Fig. 59 Paging

In GMM STANDBY status a mobile performs routing area updates but it doesn’t inform the network about cell changes. A MS in STANDBY state must be paged by the SGSN before a downlink transfer to that MS is possible. The Paging procedure is used by the network to determine the cell where the mobile is located and moves the GMM state to READY. 1. The SGSN includes the IMSI, information about the area in which the mobile

shell be paged and if available a P-TMSI. If included, the BSC shall use the P-TMSI instead of IMSI in the PAGING message on the Um-interface.

2. In response to a GPRS page, the mobile usually sends an unnumbered information frame (UI). However any other uplink data from the MS can be a valid paging response. The BSC adds the Cell Global Identity (CGI) including RAC and LAC of the cell where the message was received before passing the message to the SGSN.



179

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.2.1.6 GPRS mobility management: routing area update

Fig. 60 Routing area update



180

A routing area update takes place when a GPRS attached MS detects that it has entered a new RA, when the periodic RA update timer has expired, or when a suspended MS is not resumed by the BSS. 1. In the new cell the mobile sends a Routing Area Update Request including the

old Routing Area Identification and the reason for the routing area update. The BSC adds the new Cell Global Identity including RAC and LAC of the cell where the message was received before passing the message to the SGSN.

2. When the SGSN detects the routing area update, it sends a FLUSH-LL PDU to the old BVC to initiate the following procedure: - at a cell change between two NSEIs or between two routing areas, LLC-PDU(s) stored at the "old" BVCI for the TLLI are deleted. - in response to a FLUSH-LL PDU the BSS shall send a FLUSH-LL-ACK PDU to the SGSN containing: -the TLLI received in the FLUSH-LL PDU.

3. The SGSN validates the MS's presence in the new RA. If due to regional subscription restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, then the SGSN rejects the routing area update with an appropriate cause. If all checks are successful, then the SGSN updates the GMM context for the MS. A new P-TMSI may be allocated. A Routing Area Update Accept (RAAC) is returned to the MS.

4. The MS acknowledges the new P-TMSI by returning a Routing Area Update Complete (RACO).

5. Data transfer is continued in the new routing area.



181

2.2.1.7 GPRS mobility management: cell update

Fig. 61 Cell update

1. A cell update takes place when the MS enters a new cell inside the current RA

and the MS is in READY state. The MS performs the cell update procedure by sending an uplink LLC frame of any type containing the MS's identity to the SGSN. Towards the SGSN, the BSS adds the BVCI and Cell Global Identity including RAC and LAC.

2. When the SGSN detects the cell change, it send a FLUSH-LL PDU to the old BVC to initiate the following procedure:

3. at a cell change within one NSEI (e.g. one PCU represents one NSEI) and within one routing area, LLC-PDU(s) for a given TLLI stored at an "old" BVCI (corresponding to the old cell) are either deleted or transferred to a "new" BVCI (corresponding to the new cell) with which the TLLI is currently associated.

4. In response to a FLUSH-LL PDU the BSS shall send a FLUSH-LL-ACK PDU to the SGSN containing the TLLI received in the FLUSH-LL PDU and an indication of whether the LLC-PDU(s) were "transferred" or "deleted". In case the SDUs were "transferred" the BVCI (new) IE shall be included.

5. Data transfer is continued in the new cell.



182

2.2.1.8 GPRS: suspend / resume The Suspend / Resume procedure is used to interrupt GPRS data traffic temporarily to allow circuit switched services e.g. answer to Paging for an incoming call, a periodic Location Update or in our example a mobile Originating Call. 1. The mobile is transferring data. 2. The mobile leaves the Packet data traffic channels and switches to the BCCH. It

requests a signaling channel (SDCCH) by sending CHNREQ on the Random Access Channel.

3. If a downlink TBF is active during this time, it will fail because the mobile is no longer monitoring the PDTCHs. The BSC reports this lost downlink TBF with a Radio Status (RSTA) and the number of not transferred with a LLC-discarded (LLCD) towards the SGSN.

4. The mobile sends a GPRS Suspend Request on the SDCCH. The BSC forwards the Suspend to the SGSN. The call set-up continues.

5. The call ends and the circuit switched resources are released. 6. In BR5.5 the optional Resume Procedure is not implemented. Therefore the MS

shall resume GPRS services by sending a Routing Area Update Request message to the SGSN, as described in sub clause "Routing Area Update".

7. Whether data transfer is continued or not depends on the recovery mechanism and time out of the suspended application.



183

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 62 GPRS suspend / resume



184

2.2.1.9 Inter System Cell Reselection Procedure (2G <--> 3G), packet oriented (PO), intra SGSN inter system change

Successful Inter System Cell Reselection Procedure (2G --> 3G) The inter system change from A/Gb mode to Iu mode takes place when a GPRS attached MS changes from A/Gb mode to GERAN or UTRAN IU mode. Depending on the GPRS mobility management state before the inter system change and whether the Routing Area (RA) is changed or not, one of the following procedures is initiated by the MS:

• when an MS in STANDBY state changes to Iu mode inside the current RA, the MS shall follow the selective RA update procedures.

• when an MS in STANDBY state changes to Iu mode and the RA changes, the MS shall initiate the Iu mode RA update procedure.

• when an MS in READY state changes to Iu mode independent of whether the RA has changed or not, the MS shall initiate the Iu mode RA update procedure and afterwards initiate the Radio Access Bearers (RABs) by the Service Request procedure.

The RA update procedure is either combined RA / LA update or only RA update. If the network operated in mode I, an MS that is both PS-attached and CS-attached shall perform the Combined RA / LA Update procedure. This concerns only idle mode (acc. to 3GPP TS 23.122), as no combined RA / LA updates are performed during a CS connection. In the context of this specification, the terms RNS (or RNC) refer also to a GERAN BSS (or BSC) when serving an MS in Iu mode. 1. The MS or the RAN decides to perform an inter system change which makes the

MS switch to a new cell where Iu mode has to be used, and stops transmission to the network.

2. The MS initiates an RRC connection establishment and sends a Routing Area Update (RAU) Request (P-TMSI, Old RA, Old P-TMSI Signature, Update Type, CM) message to the combined 2G+3G-SGSN. Update Type shall indicate RA update or combined RA / LA update or combined RA / LA update with IMSI attach requested. A combined RA / LA update with IMSI attach requested occurs also if the MS has a follow on request, i.e. if there is pending uplink traffic (signaling or data). As an implementation option, the SGSN may use the follow-on request indication to release or keep the Iu connection after the completion of the RA update procedure. The SRNS shall add an identifier of the area where the message was received before passing the message to the 2G+3G-SGSN. The 2G+3G-SGSN stops transmission of N-PDUs to the MS.



185

Fig. 63 Inter System Cell Reselection Procedure (2G --> 3G), part one

Fig. 64 Inter System Cell Reselection Procedure (2G --> 3G), part two



186

3. Authentication/Ciphering functions may be executed.4. Security functions may be executed.

4. Security functions may be executed. 5. The 2G+3G-SGSN validates the presence of the MS in the new RA. If due to

roaming restrictions the MS is not allowed to be attached in the RA, or if subscription checking fails, the 2G+3G-SGSN rejects the RAU with an appropriate cause. If all checks are successful, the 2G+3G-SGSN updates MM and PDP contexts for the MS. A new P-TMSI may be allocated. A RAU Accept (P-TMSI, P-TMSI Signature) message is returned to the MS. For this inter system change, the 2G+3-SGSN derives the corresponding PDCP sequence numbers from the N-PDU sequence numbers stored in the SGSN PDP contexts by adding eight most significant bits “1”. These PDCP sequence numbers are stored in the SGSN PDP contexts.

6. The MS acknowledges the new P-TMSI by returning a RAU Complete message to the SGSN.

7. A Modify PDP context request N -> MS is sent from 2G+3G-SGSN to the MS. 8. If the MS has pending uplink data or signaling, it shall send a Service Request

(P-TMSI, RAI, CKSN, Service Type) message to the SGSN. Service Type specifies the requested service. Service Type shall indicate one of the following: Data or Signaling.

9. The MS/UE responds with a Modify PDP context accept to the 2G+3G-SGSN MS -> N.

10. - 12. The 2G+3G-SGSN requests the SRNS to establish a radio access bearer by sending an RAB Assignment Request (RAB ID(s), QoS Profile(s), GTP-SNDs, GTPSNUs, PDCP-SNUs) message to the SRNS. The PDCP sequence numbers are derived from the N-PDU sequence numbers and stored in the PDP contexts in step 5. The SRNS sends a Radio Bearer Setup Request (PCDP-SNUs) message to the MS. The MS responds with a Radio Bearer Setup Complete (PDCP-SNDs) message. The SRNS responds with a RAB Assignment Response message.

Note: The NSAPI value is carried in the RAB ID IE.



187

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



188

2.2.2 RLC/MAC message flows All afore mentioned GPRS Mobility Management and Data Transfer procedures use the RLC/MAC message flows described below. Data and GMM messages are transferred in Temporary Block Flows (TBF). Each TBF consists of the resource allocation, the transfer of RLC/MAC data blocks itself, the respective acknowledgements if required and the release of the resources. Four basic TBF types exist:

• Uplink TBF

• Downlink TBF

• Concurrent Uplink TBF

• Concurrent Downlink TBF Up- and downlink resources are allocated to the mobiles depending on their multislot classes. The MS capability of combining a number of timeslots is defined with its multislot class. An updated list can be found in the recent version of the 3GPP specification 45.002. It is important to understand the resource allocation for different mobiles on the RLC/MAC layer. As most MS use internally one RF part for both reception and transmission, the multislot class not only defines the maximum number of timeslots a MS can use but furthermore the time needed for the switching between DL and UL operation.



189

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

……………………35

1c)11265534

1c)11264533

1c)11263532

1c)11262531

1c)11261530

1c)2b)2NA8829

TypeMinimum number of slotsMaximum number of slots

Multislotclass

……………………19

2000NANA8818

……………………15

2a)3a)NANA4414

2a)3a)NANA3313

1121254412

1121353411

1121352410

112135239

112135148

113134337

113134236

113134225

113134134

113233223

113233122

124232111

TrbTraTtbTtaSumTxRx

Type 1 MS needs not to receive and transmit simultaneously

Fig. 65 Multislot classes



190

2.2.2.1 Uplink TBF

Uplink TBF / One Phase Access on CCCH The purpose of the packet access procedure is to establish an uplink TBF to transfer LLC PDUs in the direction from the mobile station to the network. The scenario describes the packet access procedure on CCCH (no PBCCH is configured in the cell). With the one phase access only a single PDCH can be allocated in the uplink direction, otherwise a two-phase access is required. 1. The MS sends a Channel Request message with the establishment cause. For

One phase packet access with request for single timeslot uplink transmission; one PDCH is needed“ (011110xx, 01111x0x, 01111xx0).

2. If no PDCH has been activated, a single timeslot will be configured as PDCH and the Time Alignment procedure is performed.

3. The BSC sends an Immediate Assignment towards the MS. A set of GPRS related parameters is included indicating e.g. the Temporary Flow Identifier (TFI), the Uplink State Flag (USF) and the Coding Scheme (CS).

4. Packet Downlink Dummy Control Blocks (PDDCB) with the USF value previously assigned to the MS are transmitted in the allocated PDCH. The MS monitors the USF of all downlink blocks on this timeslot to send its uplink data blocks as response to the occurrence of its assigned USF. The PDDCBs continue during the whole uplink TBF - only the first one is drawn in the message flow!

5. A Mobile might send a Packet Uplink Dummy Control Block (PUDCB) as first block of an uplink TBF. This is probably because the uplink user data is not yet ready for transmission inside the MS.

6. The MS starts to send user data (LLC-frames) inside the uplink RLC/MAC blocks. The TLLI of the MS is included until the Contention Resolution procedure is completed (first PUAN with TLLI). The data blocks are counted up with the Block Sequence Number BSN (modulo 128). The Countdown Value CV remains at its maximum value as long as more than 15 RLC/MAC data blocks remain to be sent.

7. The BSC acknowledges the first received uplink data block with a Packet Uplink Ack/Nack message (PUAN). As soon as the MS receives this first PUAN message including its TLLI, the Contention Resolution is completed and the MS continues sending its uplink data blocks without its TLLI inserted. The MS is now clearly identified - concurrent TBF handling according to its multislot capabilities is possible.

8. The BSC acknowledges every single uplink data block received from the mobile with a moving window mechanism. For this purpose the BSC sends every N-th block (N=NRLCMAX; BSS database parameter) a PUAN message indicating which blocks were correctly received or not. Missing blocks will be repeated by the mobile and acknowledged in the next scheduled PUAN message.

9. If the MS has sent most of its uplink data, the Countdown Value CV starts counting down towards the final block. This allows the network to calculate the remaining blocks of the running uplink TBF.



191

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 66 Up link TBF



192

10. As soon as CV=0 is reached, the MS has transferred all uplink data. The uplink TBF however remains open until the last sent blocks were acknowledged by the BSS. The MS repeats uplink blocks that have been sent already before until the final PUAN is received.

11. The BSC confirms the remaining uplink blocks with the final PUAN – the Final Ack Indication is set. Additionally the MS is polled with the RRBP-bit set to confirm the reception of this final PUAN.

12. The Packet Control Ack (PCA) confirms the reception of the previous final PUAN. Now the uplink TBF is complete and the MS returns to monitor the BCCH.



193

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 67 Up link TBF



194

2.2.2.2 Downlink TBF Downlink TBF / Example with a 3+1 Mobile / CCCH only A downlink TBF is initiated by the network as soon as LLC data coming from the GSN must be transferred towards the mobile. This scenario assumes the MS is in GMM ready state, therefore no paging is required or it was already performed including the paging response. 1. Downlink data (LLC-frame) arrives on the Gb-interface from the SGSN. 2. If no PDCH has been activated, the required number of timeslots will be

configured as PDCH. The actually activated number of timeslots basically depends on the MS capabilities (which are known to the BSC since its GPRS attach), however less timeslots are possible under various circumstances (e.g. traffic load). For each timeslot a separate CHNAV/CHNAK message is required - the timeslot numbers indicated in the message flow are regarded as relative numbers!

3. The BSC sends an Immediate Assignment for a downlink TBF towards the MS. A set of GPRS related parameters is included, indicating e.g. the Temporary Logical Link Identity (TLLI) of the MS and the Temporary Flow Identifier (TFI) of the TBF. The IA message is either sent on the AGCH or the PCH - depending if the MS is still in Non-DRX Mode or not. Only a single timeslot can be allocated with the Immediate Assignment message.

4. The MS moves to the allocated PDCH timeslot (according the IA) where it receives the Packet Downlink Assignment (PDAS). This message now allocates all intended downlink timeslots (in our case three) and includes e.g. the TLLI as well as the TFI. Additionally the poll bit is set (RRBP=1) - the BSC requests a confirmation from the MS about the correct reception of the PDAS message.

5. The MS responds to the polling with a Packet Control Ack (PCA) - the PCA format is 4 access bursts. These access burst are used by the BSC to calculate the initial timing advance value for the mobile.



195

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 68 Down link TBF



196

6. Downlink data transfer starts on timeslot 1. The MS listens on the assigned 3 timeslots to all downlink blocks with its own TFI, the RLC/MAC blocks are counted up with the Block Sequence Number (BSN).

7. The initial timing advance value is send to the MS with a Packet Power Control/Timing Advance message (PPCTA). This allows the mobile to transmit (e.g. PDAN) before a continuous timing advance value is available.

8. Every N-th downlink data block (N=NRLCMAX, in this case the default value NRLCMAX= 20 is used) the BSC polls the MS for a Packet Downlink Ack/Nack message (PDAN). This polling can only be sent on the timeslot of the TBF, which is used for uplink signaling purpose - in case of a 3+1 MS timeslot #2 is used.

9. The MS answers the polling with a PDAN message. All RLC/MAC data blocks received by the MS until the transmission of this PDAN are acknowledged. A moving window mechanism is used. If blocks were not correctly received by the mobile, the BSC will repeat them soon after the reception of the PDAN. The repeated blocks will then be acknowledged in the next PDAN message.

10. If the end of the downlink transfer is reached (last BSN=z), the BSC sets the Final Block Indicator bit (FBI) in this last block and polls the MS for a final PDAN (RRBP=1).

11. The MS confirms the remaining downlink blocks with a PDAN. The Final Ack Indication is set, the downlink TBF is complete and no retransmissions are required. The MS remains on the PDCH and listens for new assignments until the timer T3192 expires. Afterwards it returns to listen to the BCCH.



197

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Fig. 69 Down link TBF



198

2.2.3 GPRS/E-GPRS counters and KPI

2.2.3.1 Basics GPRS/E-GPRS measurements and their associated sub-counter sequences are divided in the following groups of measurements:

• Packet Channel Configuration Measurements

• Packet Flow Establishment Measurements

• Active Packet Flow Measurements

• Packet Flow Release Measurements

• Gb Interface Related Measurements

• Cell Reselection Related Measurements

• DTM Related Measurements. As in the section 1, the counters will not be separately described but in connection with certain Performance Indicator. Also only some PI assumed as important (KPI) will be given in the following tables in usual way, i.e. with their full names, short names, short description, formulas, elementary object, etc. The KPIs for GPRS/E-GPRS are grouped according to targeted users and their tasks. Therefore the GPRS/E-GPRS KPIs are making the following groups:

• User Oriented KPI

• Network Planning KPI

• Network Optimization KPI

• Cell Reselection.



199

2.2.3.2 Counters and some User Oriented KPI These Key Performance Indicators concern the TBF establishments for Uplink and Downlink per cell as well as their release due to normal or abnormal release request. This means the successful and failed TBF establishments and corresponding rates, and the TBF drops and drop rates, respectively. The formulas for the chosen Performance Indicators will be given for one direction only (Uplink) as they (the formulas) differ only in a counter sequence of a measurements involved in a formula. Counters used to calculate User Oriented KPIs Measurement Long Name Measurement/


Min, Max, Mean Number of Used (Active TBF) PDCHs (Uplink/Downlink) per Cell

NALLPDCH [1…6]

1..3 minimum, maximum, mean number of used PDCH uplink

4..6 minimum, maximum, mean number of used PDCH downlink

Number of Attempted PDCH Assignments (Uplink/Downlink) per Cell per traffic class (streaming, interactive, background)

NUACATCL [1...6]

1..3 attempted PDCH for an UL TBF per traffic class

4..6 attempted PDCH for an DL TBF per traffic class

Number of Successful PDCH Seizures (Uplink/Downlink) per Cell per traffic class (streaming, interactive, background)

SULACCEL[1...6]

1..3/4..6 number of successful PDCH seizures for an UL/DL TBF respectively per class

Number of Rejected PDCH Assignments (Uplink/Downlink) per cause per traffic classc (streaming, interactive, background, respectively)

REJPDASS [1..25]

1..3/13..15 no Abis subchannel available for an TBF UL/DL

4..6/16..18 no PDT at PCU available for an TBF UL/DL

7..9/19..21 no radio resource (PDCH) available for a TBF UL/DL

10..12/22..24 other reasons UL/DL respectively

25 Short TDPC timer expiration for TBF

Number of Successful PDCH Assignments (Uplink/Downlink) per Cell per traffic class

SUCPDASA [1..6]

1..3/4..6 successful PDCH assignments for an TBF UL/DL respectively

Number of Successful Terminated TBFs (Uplink/Downlink) per Cell per traffic class

SUCTETBF [1...6]

1..3/4..6 number of successful terminated UL/DL TBFs

Number of Degraded PDCH Seizures (UL/DL) per Cell per traffic class

UNSPDCSE [1...16] 1..8/9..16 number of degraded PDCH seizures due to the same reasons as for REJPDASS UL/DL respectively



200

Measurement Long Name Measurement/


Max, Mean Number of TBFs Allocated per PDCH (Uplink/Downlink) per Cell

NTBFPDC [1..4] 1,2 maximum, mean number of allocated TBF per PDCH uplink

3,4 maximum, mean number of allocated TBF per PDCH downlink

Number of Unsuccessful Terminated TBFs (Uplink/Downlink) per Cell per Cause per traffic class

UNSTETBF [1..51]

1..3/4..6 abnormal release of TBF UL/DL by expiration of timer T3169/T1395

7..9/10..12 Complete preemption due to CS calls 13..15/16..18 Gb link related component is out of service

19..21/22..24 Abis/BTS component is out of service

25..27/28..30 termination when transmitting PCCO to MS

and so on..

Total and Mean Number of Active TBFs (Uplink/Downlink) per Cell

NACTTBF [1..16] 1..4 and 9..12 total number of active TBF per service class, UL/DL

5..8 and 13.. 16 mean number of active TBF per service class, UL/DL

Mean User Data Throughput (Uplink/Downlink) per Coding Scheme per Cell on the RF Interface

MUTHRF [1..26] 1...4 and 14..17 mean user data throughput per GPRS CS, UL/DL

5..13 and 18..26 mean user data throughput per EGPRS MCS, UL/DL, respectively

Retransmitted Mean User Data Throughput (Uplink/Downlink) per Coding Scheme per Cell on the RF Interface

REMUTHRF[1..26] 1...4 and 14..17 retransmitted mean user data throughput per GPRS CS, UL/DL, respectively

5..13 and 18..26 retransmitted mean user data throughput per EGPRS MCS UL/DL, respectively

Mean Signaling Data Throughput UL/DL per cell on the RF i

MSTHRF [1,2] 1/2 Mean Signaling Data Throughput UL/DL, respectively

Number of Attempted Packet Resource Reassignments (Uplink/Downlink) per Cell

NATPRRE[1,2]

1/2 number of attempted packet resource reassignment per an TBF UL/DL, respectively

Number of Successful Packet Resource Reassignments (Uplink/Downlink) per Cell

NSUPRRE [1,2]

1/2 number of successful packet resource reassignment per an TBF UL/DL, respectively



201

Measurement Long Name Measurement/


LLC User Data Throughput (Uplink/Downlink) per Cell per Traffic Class

MUTLLC[1..80] 1..5 and 11..15 weighted LLC data throughput per Class and technique (GPRS) UL/DL respectively

6..10 and 16.20 weighted LLC data throughput per Class and technique (EGPRS),UL/DL respectively

21..25 and 31...35 weighted LLC data throughput per Time Slot, per Class, per technique (GPRS) UL/DL respectively

26 ... 30 and 36 ... 40 weighted LLC data throughput per Time Slot, per Class, per technique (GPRS) UL/DL respectively

41..45 and 51..55 percent timeslot resources achieved per Class, per technique (GPRS), UL/DL respec.

46 50 and 56..60 percent timeslot resources achieved per Class, per technique (EGPRS), UL/DLrespec.

61..65 and 71..75 LLC Data Volume per Class, per technique (GPRS), UL/DL respectively

66..70 and 76..80 LLC Data Volume per Class, per technique (EGPRS), UL/DL respectively

Number of Transmitted PDUs (Uplink/Downlink) per Coding Scheme per Cell on the RF Interface

NTRAPDU[1..26] 1..13 number of transmitted PDUs per GPRS/EGPRS Coding Schemes uplink

14..26 number of transmitted PDUs per GPRS/EGPRS Coding Schemes downlink

Number of Retransmitted PDUs (Uplink/Downlink) per Coding Scheme per Cell on the RF Interface

NRETPDU[1..26] 1..13 number of retransmitted PDUs per GPRS/EGPRS Coding Schemes uplink

14..26 number of retransmitted PDUs per GPRS/EGPRS Coding Schemes downlink



202

User Oriented KPI Long name TBF establishment Success Rate Uplink/Downlink

TBF establishment failure rate for PDCH congestion Uplink/Downlink

TBF establishment failure rate for no reaction from mobile Uplink/Downlink

Rate of successful UL/DL TBF establishment with reduced PDCH assignment

Uplink/Downlink TBF drop rate*

Uplink/Downlink TBF drops frequency

Mean time between TBF drop of uplink/downlink TBF

Short name TBFEstSuccRateUL/DL

TBFEstFailRateConUL/DL

TBFEstFailRateNoReacUL/DL

TBFEstSuccRedRateUL/DL

TBFDropRateUL/DL*

TBFDrFrequUL/DL

TBFDrMeanTimeUL

Description These KPIs provide the ratio of successful and unsuccessful establishment of the TBF, the rate of

the TBF drops, the TBF drops frequency and mean time between TBF drop.

Formula

..3]NUACATCL[1..3]SULACCEL[1RateULTBFEstSucc =

..3]NUACATCL[1..9]REJPDASS[7 RateConULTBFEstFail =

..3]NUACATCL[1..3]SULACCEL[1 - [1..3]SUCPDASA ULRateNoReacTBFEstFail =

..3]SULACCEL[1 / 1..6] UNSPDCSE[ RedRateULTBFEstSucc =

..3]SULACCEL[1..21],13..15,19 ..3UNSTETBF[1eUL TBFDropRat = *

.45]37..39,43. ,.27,31..3319..21,25. 3..15,..3,7..9,1UNSTETBF[1useULTBFDrAllCa

is where,...8] NACTTBF[5

*useULTBFDrAllCaULTBFDrFrequ gran

60

==

=

ULTBFDrFrequ3600imeULTBFDrMeanT =

Counters SULACCEL, REJPDASS, NUACATCL, SUCPDASA, UNSPDCSE,UNSTETBF, NACTTBF

Object Cell

Unit None

Occurrences per hour (1/h) in case of TBF Drop Frequency KPI

sec in case of Mean Time between TBF Drop KPI



203

User Oriented KPI Long name Mean user data throughput per uplink/downlink TBF averaged over all Coding Schemes**

Mean user data throughput per uplink/downlink TBF depending on Coding Scheme

Packet resource reassignment success rate for uplink/downlink TBFs

Packet resource reassignment failure rate for uplink/downlink TBFs

Mean Uplink/Downlink TBF duration

Mean Uplink/Downlink TBF duration acc. to Interactive traffic class

Mean Uplink/Downlink TBF duration acc. to Streaming traffic class

Mean Uplink/Downlink TBF duration acc. to Background traffic class

Short name

UserDataThrTBFAvUL/DL

UserDataThrTBFCSUL/DL

ReasSuccRateTBFUL/DL

ReasFailRateTBFUL/DL

MeanTBFDurUL

MeanTBFDurULInt

MeanTBFDurULStream

MeanTBFDurULBg

Description These KPIs provide the user mean LLC throughput on air interface UL/DL per active user, i.e. TBF over all coding scheme and depending on Coding Scheme. Retransmissions are excluded. Here defined KPIs give the Packet Resource Reassignment success/failed rate and the Mean TBF Duration also.

Formula

10008*

[13..16] NACTTBF26] 4..REMUTHRF[1 - 26] .MUTHRF[14.rTBFAvDLUserDataTh

,1000

8*[5..8] NACTTBF

13]MUTHRF[1..rTBFAvULUserDataTh

=

=

NATPRRE[1]NSUPRRE[1]teTBFULReasSuccRa =

NATPRRE[1]NSUPRRE[1]-1 teTBFULReasFailRa =

...4] NACTTBF[1gran * 8] ... [5 NACTTBF ULMeanTBFDur =

NACTTBF[2]gran * [6] NACTTBF ULInt MeanTBFDur = ***

Counters MUTHRF, REMUTHRF, NACTTBF, NSUPRRE, NATPRRE

Object Cell

Unit Kbit per second in case of Mean user throughput KPI

none in case of Reassignment KPI

second in case of Mean TBF duration



204

Notes: * SULACCEL shall be taken as denominator because only TBFs shall be considered which are assigned from MS point of view. Preemption, Packet Cell Change Order and Flush_LL counters shall not be considered. **Observed throughput per user might be unexpectedly low due to the following phenomenon:

• The release of a DL TBF is normally delayed for 1,5 seconds (default value of configuration parameter TIMTBFREL)

• The amount of short duration TBFs for GMM (GPRS Mobility management) and SM (Session management) might be high compared to TBF which serve for transmission of end-to-end user data

• Different treatment of UL and DL direction in the formula. ***The Mean TFB duration KPI formula for two another service types is the same but contains different counter sequence and therefore is assumed no need to be given in the table.



205

User Oriented KPI Long name Weighted GPRS LLC User Data Throughput, UL/DL

Weighted EDGE LLC User Data Throughput, UL/DL

Short name WGprsLLCUsrThUL

WEdgeLLCUsrThUL

Description These KPIs provide the Weighted LLC User Data Throughput UL/DL per technique

Formula

∑

∑

=

=

+

+= 5

1i

5

1i

60]i MUTLLC[

60]i MUTLLC[* i] MUTLLC[rThULWGprsLLCUs

∑

∑

=

=

+

++= 5

1i

5

1i

65]i MUTLLC[

65]i MUTLLC[* 5]i MUTLLC[rThULWEdgeLLCUs

Counters MUTLLC

Object Cell

Unit Kbit per second

Note:

Weighted LLC User Data Throughput is the throughput per user during the Continuous Data Transmission.



206

Network Planning KPI Long name Total packet Throughput per cell on radio interface in uplink/downlink direction

User Data Throughput per cell on radio interface uplink/downlink

Total packet throughput on Gb uplink/downlink

User Data Throughput on Gb uplink/downlink

Short name TotThrUmCellUL/DL

UserThrUmCellUL/DL

TotThrGbCellUL/DL

UserThrGbCellUL/DL

Description First two indicators provide the air interface related packet load UL/DL of a cell in terms of throughput and the mean LLC throughput on the air interface per cell, UL/DL.

Another two indicators provide the Gb interface related total packet load UL/DL of a cell in terms of throughput and the mean throughput on LLC layer on the Gb interface per cell, UL/DL.

Formula

10008*MSTHRF[1])

..13]REMUTHRF[1.13](MUTHRF[1.llULTotThrUmCe

+

++=

10008*13]MUTHRF[1.. ellULUserThrUmC =

10008* MSTHBS[1]) .3](MUTHBS[1. llULTotThrGbCe +=

10008* 3]MUTHBS[1.. ellULUserThrGbC =

Counters MUTHRF, REMUTHRF

Object Cell

Unit kbit per second

Note: The signaling and retransmission loads are included in case of Total Packet Throughput KPI, but excluded in case of the User Data Throughput. In the last mentioned KPI only the amount of data transmitted on behalf of the application layer (here LLC) is considered. The DL retransmitted throughput is included in measurement MUTHRF (DL), but not the UL retransmitted throughput is included in MUTHRF(UL). Retransmissions due to bad radio link quality are not included in measurement MUTHRF (UL).



207

Network Planning KPI Long name Mean User Throughput uplink/downlink per busy PDCH cumulated on all Coding Schemes

Mean User Throughput uplink/downlink per busy PDCH depending on the Coding Scheme

Mean number of uplink/downlink TBFs multiplexed on the same PDCH

Mean number of allocated PDCHs per uplink/downlink TBF

Short name MeanUserThrBusyPdchUL/DL

MeanUserThrBusyPdchCSUL/DL

MeanTBFMultiplPDCHUL/DL

MeanAllocPdchTbfUL

Description Mean User Throughput per busy channel KPIs provide the mean RLC packet throughput depending on used Coding Scheme per busy PDCH, per cell, UL/DL and the Mean RCL throughput cumulated over all Coding Schemes.

This indicator provides the mean number of TBFs multiplexed on the same PDCH (horizontal allocation) for the uplink and downlink direction.

Mean number of allocated PDCH per UL/DL TBF KPIs provide the mean number of PDCHs assigned to a TBF for the uplink and downlink direction (horizontal allocation).

Formula

[ ]3NALLPDCHtRateULMeanPDCHBi LrBusyPdchUMeanUserTh =

NTBFPDC[2] tiplPDCHULMeanTBFMul =

[ ] [ ][ ] [ ]clULCSDistrCel*3NALLPDCH

ceULCSPDCHBitRatcSULrBusyPdchCMeanUserTh =

.8]NACTTBF[5. ]NALLPDCH[3*NTBFPDC[2]dchTbfULMeanAllocP =

Counters NALLPDCH, NACTTBF; NTBFPDC, PDCHBitRateULCS

Object Cell

Unit kbit per second

none in case of Mean number of allocated PDCH per TBF

Note: c=1…13 means used GPRS/EGPRS Coding Scheme No RLC/MAC signaling blocks and no RLC/MAC headers are included in indicator Mean throughput per busy PDCH. Also retransmissions are excluded. Therefore the total amount of data transmitted via RLC/MAC layers per PDCH is higher. PDCH Bit Rate per Coding Scheme in UL/DL provides the LLC throughput per Coding scheme per cell and is calculated as:

[ ] [ ][ ] [ ] )(20

*cNRETPDUcNTRAPDU

cNTRAPDUceULCSPBCHBitRatms

Blocksize+

=



208

Network Optimization KPI Long name Uplink/Downlink retransmission Rate on radio interface per cell per coding scheme

Retransmitted user Throughput on radio interface per cell per coding scheme in uplink/downlink direction

Short name RetransRateUmCellUL/DLCS

UserThrRetrCellUmUL/DLCS

Description These indicators provide the retransmission rate on the radio interface per coding scheme and the retransmitted user throughput on the radio interface per cell, per coding scheme UL/DL.

Formula [ ]

NRETPDU[c]NTRAPDU[c]NRETPDU[c] cSeUmCellULCRetransRat

+=

[ ]

[ ]1000

8*] 13REMUTHRF[c cSrCellUmDLCUserThrRet

,1000

8*] REMUTHRF[c cCStrCellUmUL UserThrRe

+=

=

Counters NTRAPDU, NRETPDU, REMUTHRF

Object Cell

Unit none for the Retransmission Rate

kbit per second none for Retransmitted User Throughput



209

Cell Reselection KPI Long name Network controlled Intra BSC cell reselection success rate

Network controlled Intra BSC cell reselection failure rate for different causes

(a) Network controlled Intra BSC cell reselection failure rate for cause Frequency not implemented

(b) Network controlled Intra BSC cell reselection failure rate for cause No response on target cell

(c) Network controlled Intra BSC cell reselection failure rate for cause Imm. Assignment Reject or Packet Access Reject on target cell

(d) Network controlled Intra BSC cell reselection failure rate for cause Ongoing CS connection

(e) Network controlled Intra BSC cell reselection failure rate for cause MS in GMM standby state

(f) Network controlled Intra BSC cell reselection failure rate for cause Forced to the standby state

Network controlled cell reselection failure rate

Short name NCIntrBSCCellSucRate

(a) NCIntrBSCResFailRateFrequNotImpl

(b) NCIntrBSCResFailRateNoRespTarget

(c) NCIntrBSCResFailRateAccessRejTarget

(d) NCIntrBSCResFailRateCSOngoing

(e) NCIntrBSCResFailRateGMMStandby

(f) NCIntrBSCResFailRateForcedStandby

NCResFailRate

Description These indicators provide rate of the successful and failed network controlled Intra BSC cell reselections per cell.

Formula [ ],9]ATCRORIG[1

1,3SUCRORIG ellSucRateNCIntrBSCC =

(a) ]ATCRORIG[1

1] UNCRORIG[ plFrequNotImesFailRateNCIntrBSCR =

(b) ]ATCRORIG[1

2] UNCRORIG[ RespTarget NoesFailRateNCIntrBSCR = and so on

[ ],2,3,9,10]ATCRORIG[1

all UNCRORIateNCResFailR = *

Counters UNCRORIG, SUCRORIG, ATCRORIG

Object Cell

Unit none

Note: The last KPI provides the number of unsuccessful network controlled cell reselection, i.e. it is the general formula for cell reselection.



210

Signaling Procedures for GSM Radio System

Documents

Transcript of Signaling Procedures for GSM Radio System