Bss System Desc

Alcatel-Lucent GSM
BSS System Description
BSS Document
Concept Guide
Release B10
3BK 21222 AAAA TQZZA Ed.08

BLANK PAGE BREAK
Status RELEASED
Short title System Description

All rights reserved. Passing on and copying of this document, use
and communication of its contents not permitted without written
authorization from Alcatel-Lucent.
2 / 304 3BK 21222 AAAA TQZZA Ed.08

Contents
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.1 Alcatel-Lucent Radio Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.2 Extended GSM Band (E-GSM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.3 GSM 850 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.4 Frequency Band Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.1.5 GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2 BSS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.1 Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.2.2 Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.3 Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.4 Operations & Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3 BSS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.1 Base Station Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.3.2 Base Transceiver Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.3.3 Transcoder And Transmission Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.3.4 The Multi-BSS Fast Packet Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.4 Extended GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.4.1 E-GSM Mobile Station Recognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.4.2 E-GSM Management After Initial Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.4.3 E-GSM Determination at Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.4.4 TCH Allocation for E-GSM and P-GSM Mobile Stations . . . . . . . . . . . . . . . . . . . . 31
1.5 External Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
1.5.1 Network Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.5.2 Mobile Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.5.3 Phase 2 Mobile Support in a Phase 1 Infrastructure . . . . . . . . . . . . . . . . . . . . . . . 38
1.5.4 Operations and Maintenance Center-Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
1.6 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.6.1 Telecommunications Management Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.6.2 Q3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.7 BSS Telecommunications Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
1.7.1 Call Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.7.2 Mobility Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.7.3 Radio Resource Management Sub-layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.7.4 The A Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
1.7.5 The Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.7.6 The Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
1.7.7 HSL Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.7.8 Satellite Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
1.7.9 The Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.7.10 System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
1.7.11 Dynamic SDCCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
1.8 Networks Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
1.8.1 2G and 3G Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
1.8.2 2G to 3G Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
1.8.3 2G to 3G Reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
1.8.4 GAN System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
1.8.5 Number of BCCH Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2 GPRS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.1.1 Packet Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.1.2 GPRS Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3BK 21222 AAAA TQZZA Ed.08 3 / 304

Contents
2.2 GPRS Channels and System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

2.2.1 Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.2.2 Virtual Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.2.3 System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.3 GPRS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.3.1 The Gb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.3.2 The BSCGP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.3.3 The GCH Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.3.4 Specific LCS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.4 GPRS Network Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.4.1 MAC and RLC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.4.2 Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.4.3 Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.4.4 Enhanced Packet Cell Reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
2.4.5 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.4.6 Radio Power Control and Radio Link Measurement . . . . . . . . . . . . . . . . . . . . . . . . 77
2.5 Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.5.1 Timeslot Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
2.5.2 Autonomous Packet Resource Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
2.5.3 Packet Flow Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.5.4 Dynamic Abis Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.5.5 Enhanced Transmission Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.5.6 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
2.5.7 PCM Link Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.5.8 TBF Resource Re-allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
2.5.9 Dynamic Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
2.5.10 Extended Dynamic Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.6 Traffic Load Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
2.6.1 Smooth PDCH Traffic Adaption to Cell Load Variation . . . . . . . . . . . . . . . . . . . . . . 88
2.6.2 Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.6.3 M-EGCH Statistical Multiplexing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
2.6.4 GPRS Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
2.7 Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.7.1 GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
2.7.2 Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
2.7.3 Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
2.7.4 Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
2.7.5 GPRS Suspend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
2.7.6 GPRS Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
2.7.7 GPRS Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
2.8 Location Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.8.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
2.8.2 Logical Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
2.8.3 LCS Positioning Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
2.8.4 LCS Scenario in Circuit-Switched Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
2.8.5 Physical Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
2.8.6 SMLC Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
2.8.7 BSS and Cell Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
2.8.8 LCS O&M . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
2.9 High Speed Data Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
2.9.1 HSDS Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
2.9.2 GPRS CS3/CS4 and EGPRS Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
2.9.3 Transmission Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
2.9.4 Cell/GPU Mapping Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
2.10 Gb over IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3 Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
4 / 304 3BK 21222 AAAA TQZZA Ed.08

Contents
3.1.1 Call Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

3.1.2 Call Set Up Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3.2 Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3.2.1 Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3.2.2 Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
3.2.3 Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
3.3 Mobile-Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
3.3.1 Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
3.3.2 Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
3.3.3 Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
3.3.4 Off Air Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
3.3.5 IMSI Attach-Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
3.4 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.4.1 Paging Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
3.4.2 Discontinuous Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
3.5 Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
3.5.1 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
3.5.2 In-queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
3.5.3 Pre-emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
3.6 Classmark Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
3.6.1 Classmark IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
3.6.2 Classmark Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
3.6.3 Location Updating with Classmark Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
3.7 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.7.1 IMSI/TMSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
3.7.2 Authentication Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
3.8 Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.8.1 Mobile Station Ciphering Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
3.8.2 BSS Ciphering Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
3.8.3 Ciphering Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
3.8.4 Ciphering Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
3.9 Tandem Free Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
3.9.1 TFO Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
3.9.2 TFO Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
3.9.3 TFO Optimization and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
4 Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
4.2 In-Call Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
4.2.1 In-Call Modification Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
4.2.2 Circuit-Switched Group 3 Fax Data Rate Change . . . . . . . . . . . . . . . . . . . . . . . . . 179
4.2.3 Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
4.3 Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
4.3.1 Baseband Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
4.3.2 Synthesized Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4.4 Speech Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4.4.1 Continuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4.4.2 Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
4.4.3 Voice Activity Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
4.4.4 BSS Discontinuous Transmission Towards Mobile Station . . . . . . . . . . . . . . . . . 184
4.4.5 Mobile Station Discontinuous Transmission Towards BSS . . . . . . . . . . . . . . . . . 185
4.5 Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
4.5.1 BTS Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4.5.2 Mobile Station Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4.5.3 Radio Link Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
4.5.4 Power Control Decision and Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
4.5.5 Change Power Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
4.6 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
3BK 21222 AAAA TQZZA Ed.08 5 / 304

Contents
4.6.1 Principal Handover Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

4.6.2 Radio Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
4.6.3 Handover Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
4.6.4 Target Cell Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
4.6.5 Synchronous and Asynchronous Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
4.6.6 Circuit-Switched Telecom Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
4.7 Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
4.7.1 BTS Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
4.7.2 BSC Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
4.8 Call Re-establishment by the Mobile Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
5 Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
5.2 Call Release Procedures in Normal Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
5.2.1 Normal Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
5.2.2 Calls Terminated Following a Channel Change . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
5.3 Call Release - Special Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.3.1 Call Release Following Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.3.2 BSC-Initiated Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
5.3.3 BSC-Initiated SCCP Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
5.3.4 BTS-Initiated Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
5.3.5 Mobile Station-Initiated Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
5.3.6 Remote Transcoder Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
5.4 Preserve Call Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
5.4.1 Normal Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
5.4.2 Abnormal Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
6 Handling User Traffic Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
6.2 Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
6.2.1 Analog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.2.2 Interleaving and Forward Error Correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.2.3 Speech Data Bursts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
6.2.4 Digital Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.2.5 Digital 64 kbit/s A-law Encoded Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
6.2.6 Enhanced Full-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
6.2.7 Half-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.2.8 Adaptive Multiple Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
6.2.9 Channel Mode Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
6.2.10 VGCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
6.3 Circuit-Switched Data Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
6.3.1 Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
6.3.2 Non-Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
6.4 Short Message Service - Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
6.4.1 SMS-CB Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
6.4.2 Phase 2+ Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
6.5 Support of Localized Service Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
6.6 PLMN Interworking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
7 Cell Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
7.1.1 Rural and Coastal Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
7.1.2 Urban Coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
7.2 Concentric Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
7.3 Sectored Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
7.4 Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
7.4.1 Standard Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
7.4.2 Enlarged Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
7.4.3 PS in Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
6 / 304 3BK 21222 AAAA TQZZA Ed.08

Contents
7.5 Umbrella Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

7.5.1 Mini Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
7.5.2 Microcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
7.5.3 Indoor Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
7.6 Cell Shared by Two BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
7.7 Unbalancing TRX Output Power per BTS Sector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
8 Operations & Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
8.1.1 Subsystem O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
8.1.2 System O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
8.2 O&M Control - Subsystems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
8.2.1 LMTs and IMT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
8.2.2 OML Auto-Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
8.2.3 Managed Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
8.2.4 Security Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
8.3 O&M Control via OMC-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
8.3.1 Multiple Human-Machine Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
8.3.2 ACO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
8.3.3 Connection from BSC to OMC-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
8.3.4 Electronic Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
8.4 Configuration Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
8.4.1 Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
8.4.2 Logical Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
8.4.3 Default Parameter Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
8.4.4 Software Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
8.4.5 Auto-Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
8.4.6 OML Auto-Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
8.4.7 Network Element Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
8.5 Fault Management - Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
8.5.1 Alarm Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
8.5.2 Alarm Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
8.5.3 BSC Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287
8.5.4 BTS Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
8.5.5 Alarms Detected by the TSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
8.5.6 MFS Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293
8.5.7 Recovery Example: Carrier Unit Failures with BCCH . . . . . . . . . . . . . . . . . . . . . . 294
8.5.8 Automatic Power-Down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
8.5.9 BSC Alerter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
8.6 Performance Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
8.6.1 Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
8.6.2 Performance Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
8.6.3 Radio Measurements Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
8.6.4 Results Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
8.7 Audits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
8.7.1 Audit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
8.7.2 Audit Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
8.8 Remote Inventory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
3BK 21222 AAAA TQZZA Ed.08 7 / 304

Figures
Figures
Figure 1: BSS in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Figure 2: Logical Position of External Components Associated with BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 3: Location Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 4: TMN System Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figure 5: Timeslot 4 of a TDMA Frame Supporting Access Grant Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 6: Model LLC Packet Data Unit used in GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 7: The Alcatel-Lucent GPRS Solution in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Figure 8: Mobile Station-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 9: GGSN-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figure 10: Mobile-Originating Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 11: Network-Originating Packet Data Protocol Context De-activation Processes . . . . . . . . . . . . . . . 105
Figure 12: Radio and Link Establishment for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Figure 13: Connection for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
Figure 14: Normal Assignment for Mobile-Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Figure 15: Radio and Link Establishment for Mobile-Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Figure 16: CCCH with Three Blocks Reserved for AGCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Figure 17: Four TDMA Frame Cycles Providing 24 Paging Sub-channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Figure 18: Location Update with Mobile Station Sending Location Area Identity of Previous VLR . . . . . . . 165
Figure 19: Example of TFO Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Figure 20: Different Forms of Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Figure 21: Power Output Balancing Based on Received Quality and Signal Levels . . . . . . . . . . . . . . . . . . . . 190
Figure 22: Umbrella Cell Load in Mobile Velocity Dependent Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Figure 23: Mobile Station Disconnecting a Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Figure 24: Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Figure 25: Initiation of Normal Release by MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Figure 26: BSC/BTS/Mobile Station Interactions in Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Figure 27: Normal Release Final Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Figure 28: Call Release Following Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Figure 29: BSC-initiated Call Release Toward the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Figure 30: BTS-initiated Call Release following LAPD Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
Figure 31: Call Release due to Mobile Station-Initiated Radio Link Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Figure 32: Call Release Due to Communication Failure Detected by Transcoder . . . . . . . . . . . . . . . . . . . . . . 231
Figure 33: Encoded Speech Transmission Across the BSS with 9120 BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Figure 34: Multiplexed Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Figure 35: Data Transmission Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Figure 36: Example: Cell Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Figure 37: Sectored Site Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Figure 38: Example of Extended Cell Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Figure 39: Umbrella Cell with Mini Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
8 / 304 3BK 21222 AAAA TQZZA Ed.08

Figures
Figure 40: Indoor Cell Example Network Hierarchy with Three Layers and Two Bands . . . . . . . . . . . . . . . . 264
Figure 41: Multiple HMI Access to OMC-Rs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Figure 42: ACO Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Figure 43: X.25 Without Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Figure 44: X.25 With Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Figure 45: RSL Correlation on the Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Figure 46: Example Alarm Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Figure 47: Example: Loss of Carrier Unit Holding BCCH. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
3BK 21222 AAAA TQZZA Ed.08 9 / 304

Tables
Tables
Table 1: System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Table 2: Network Operation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Table 3: Cell List Identifier and Paging Performed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Table 4: Paging Request Message and Mobile Station Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Table 5: Downlink Discontinuous Transmission Status in Channel Activation . . . . . . . . . . . . . . . . . . . . . . . . . 184
Table 6: Operator Discontinuous Transmission Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Table 7: Mobile Station Maximum and Minimum Power Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Table 8: Software Version versus Hardware Board/Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Table 9: Circuit-Switched Data Rate Conversions Across the Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
10 / 304 3BK 21222 AAAA TQZZA Ed.08

Preface
Preface
Purpose This document provides detailed descriptions of the functions and features of
the Alcatel-Lucent BSS. Note that some of the functions and features may not
be available on the system installed at your location.
The technical information in this document covers:
Mobile Communications Support

These sections describe how the BSS handles communications between a
mobile station and the NSS. It follows a call through the Alcatel-Lucent BSS,
and describes how each element in the system functions individually, and
with other elements, showing how the BSS and its units react as a system.
Operations and Maintenance (O&M).

These sections describe the O&M functions within the system, and in
particular, both local and distributed O&M functions in the BSS.
What’s New In Edition 08

Updated section 2G and 3G Cells (Section 1.8.1) due to rapport 2G and
3G cells.
Updated section Extended Cell (Section 7.4) due to 3 extended cells allowance
on BTS.
Updated section System Information Messages (Section 1.7.10)due to system
improvement.
In Edition 07
Improve section 2G to 3G Reselection (Section 1.8.3) due to system evolution.
In Edition 06
Improve section BTS Radio Power Control (Section 4.5.1)due to adjustment
of BTS power level
Improve section LMTs and IMT (Section 8.2.1)due to several IMT session
with admin acces possible per MFS
In Edition 05
3BK 21222 AAAA TQZZA Ed.08 11 / 304

Preface
Introduce the max number of BCCH frequencies for the set of all target cells,
in Number of BCCH Frequencies (Section 1.8.5).
In Edition 04
Update with the new equipment naming.
In Edition 03
Overall document quality was improved following a quality review.
Illustrations and layout were checked and improved.
In Edition 02
Overall document quality was improved following an editorial review.
Information concerning GAN interoperability was added in GAN System
(Section 1.8.4).
The following sections were updated:
Transcoder And Transmission Function (Section 1.3.3)

Mobile Station Multislot Class Handling (Section 2.9.2.3).
12 / 304 3BK 21222 AAAA TQZZA Ed.08

Preface
The following sections were modified:

Information concerning GAN was added in GAN System (Section 1.8.4)
Information concerning GboIP was introduced in Gb over IP (Section 2.10)
Information concerning EDA was introduced in Extended Dynamic

Allocation (Section 2.5.10)
Information concerning AMR-WB and TFO was added in Adaptive Multiple

Rate (Section 6.2.8)
Information concerning TC IP supervision and STM-1 was added in

Transcoder And Transmission Function (Section 1.3.3) and Remote
Inventory (Section 8.8).
In Edition 01
The following sections were updated after a review:
Extended GSM (Section 1.4)
GPRS Channels and System Information Messages (Section 2.2)
Results Analysis (Section 8.6.4).

The following sections were updated:
Information concerning compressed messages in the call setup step was

added in 2G to 3G Handover (Section 1.8.2)
Information concerning the TDSCDMA feature was added in 2G to 3G

Reselection (Section 1.8.3)
Information concerning availability in the case of NC2 was added in 2G

to 3G Reselection (Section 1.8.3)
Information concerning the NC2 related restriction was added in Cell

Reselection Modes (Section 2.4.3.1)
Information concerning the recommendation on IR activation was added in

Modulation and Coding Schemes (Section 2.9.2.2)
Information concerning one GSL configured on GPU was added in

Multi-GPU per BSS (Section 1.3.4.3).
The following sections were modified:
Information concerning MX capacity improvements was added in HSL

Links (Section 1.7.7)
Information concerning MCCCH was added in Control Channels (Section

1.7.9.4)
Information concerning DTM was added in Dual Transfer Mode (Section

1.7.9.5)
Information concerning MCS reduction on the flight and WRR was added in
MAC Algorithm (Section 2.7.3.8).
3BK 21222 AAAA TQZZA Ed.08 13 / 304

Preface
Audience This manual is for people requiring an in-depth understanding of the functions
of the Alcatel-Lucent BSS:
Network decision makers who require an understanding of the underlying

functions of the system, including:
Network planners
Technical design staff
Trainers.
Operations and support staff who need to know how the system operates in
normal conditions, including:
Operators
Support engineers
Maintenance staff
Client Help Desk personnel.
Assumed Knowledge The document assumes that the reader has an understanding of:
GSM
GPRS
Mobile Telecommunications
Network Management concepts and terminology.
14 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1 Introduction
This section gives a brief overview of the Alcatel-Lucent BSS, its functions
and features.
3BK 21222 AAAA TQZZA Ed.08 15 / 304

1 Introduction
1.1 Overview
The BSS provides radio coverage for GSM subscribers in a defined area. Its
principal role is to provide and support signaling and traffic channels between
mobile stations and the NSS.
The following figure shows the BSS within the PLMN, and its links to the PSTN
and the PSDN in a fixed network.
PLMN
Mobile Network Fixed

Stations Base Station Subsystem Subsystem Network
MSC PSTN
TC
BTS BSC
MFS
SGSN PSDN
OMC−R
NMC
MFS : Multi-BSS Fast Packet Server

NMC : Network Management Center
PSDN : Packet Switched Data Network
PSTN : Public Switched Telephone Network
SGSN : Serving GPRS Support Node
Figure 1: BSS in the PLMN
16 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.1.1 Alcatel-Lucent Radio Solutions

To respond to the swiftly evolving needs in the BSS, Alcatel-Lucent offers
specific Radio Solutions.
The Alcatel-Lucent Radio Solutions include the following BSS equipment:
9120 BSC
9130 BSC
G2 Transcoder
9125 Transcoder
BTS 9100
BTS 9110
9135 MFS
9130 MFS.
Note: BTS G1 and BTS G2 are still supported by Alcatel-Lucent.
1.1.2 Extended GSM Band (E-GSM)

The Alcatel-Lucent BSS supports the E-GSM band. E-GSM consists of:
The 900 MHz primary band, called the P-GSM band. This uses 890-915
MHz for uplink, and 935-960 MHz for downlink
The 900 MHz extended band, called the G1 band. This uses 880-890 MHz
for uplink, and 925-935 MHz for downlink.
This corresponds to a total number of 174 addressable frequencies.
1.1.3 GSM 850

The GSM 850 MHz band was introduced in Release 1999 of the 3GPP
Standard in 1999 to allow operators to progressively replace the D-AMPS and
CDMA technologies that were using these frequencies. Besides certain Asian
countries, the GSM 850 MHz band concerns in particular the Latin American
countries where many operators already use the GSM system in their network
with GSM 1900 MHz to extend or replace their existing D-AMPS network. The
term GSM 850 applies to any GSM system which operates in the 824 MHz to
849 MHz band for the uplink direction and in the 869 MHz to 894 MHz band for
the downlink direction. The GSM 850 band is defined by 124 absolute radio
frequency channel numbers (ARFCN) among the 1024 ARFCNs available in
the GSM standard.
3BK 21222 AAAA TQZZA Ed.08 17 / 304

1 Introduction
1.1.4 Frequency Band Configurations

The Alcatel-Lucent BSS supports the following multiband network
configurations:
BSS with a mix of GSM 850 and GSM 1900 cells

BSS with a mix of GSM 900 and GSM 1900 cells.
For more information, refer to the Basic GSM System Specifications.
1.1.5 GPRS
GPRS, the solution chosen by European Telecommunication Standards
Institute (ETSI) in response to the demand for increased data transmission
rates, is available in the Alcatel-Lucent BSS.
This means there are now two parallel systems in the PLMN:
Circuit-switched transmission for voice

Packet-switched transmission for data.
For information about how GPRS functions in the BSS, see GPRS in the
BSS (Section 2).
18 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.2 BSS Functions

Functions are defined by the International Telecommunications Union and
European Telecommunication Standards Institute recommendations.
This section provides an overview of the BSS functions with a system-wide
view; that is, how the BSS functions work together within the system. Network
elements and functional units are indicated where applicable, but are not
described. For more information, refer to the specific network element
description manuals, such as the BTS Functional Description.
The BSS provides signaling and traffic channels between the mobile station
and the NSS. To ensure a high level of service to the subscribers, the BSS
offers the following functions:
Call Set Up
Call Handling
Call Release
Operations & Maintenance.
1.2.1 Call Set Up

Call Set Up is used for speech and data calls. The following tables shows three
basic types of call.
Type of Call Description
Mobility Management Mobility Management calls, such as location updates, are used by the
system to gather mobile station information. The exchanges are protocol
messages only. Therefore, only a signaling channel is used.
Supplementary Service Supplementary service calls, such as SMS, allow the mobile station to send
and receive messages to and from the BTS. These calls pass small amounts
of information. Therefore, only a signaling channel is used.
User Traffic User traffic calls, such as speech or data calls to a correspondent, can pass
large amounts of information. Therefore, they require greater bandwidth
than a signaling channel. These calls use traffic channels.
Call set up processes include:
Radio and Link Establishment to assign a signaling channel between

the mobile station and the NSS
Classmark handling to manage different mobile station power and ciphering

capabilities
Ciphering to ensure data security on the Air Interface

The normal assignment process to assign a traffic channel between the
mobile station and the NSS.
For more information, refer to Call Set Up (Section 3).
3BK 21222 AAAA TQZZA Ed.08 19 / 304

1 Introduction
1.2.2 Call Handling

The call handling function supervises and maintains calls which are in progress.
Call handling involves:
In-call channel modification during a call

Maintenance of call integrity and quality through features such as Frequency
Hopping, Discontinuous Transmission or Radio Power Control
Handover to change channels when a mobile station moves from one

cell to another
Handover when the quality of the current channel drops below an acceptable
level
Ciphering to ensure data security on the Air Interface
Overload control to manage the call load on the system.
For more information, refer to Call Handling (Section 4).
1.2.3 Call Release

The call release function ensures that resources allocated to a call are free for
reuse when they are no longer required by the current call.
Specifically the Call Release function includes:
Call Release in normal service:

Calls terminated by call management
Calls terminated following a channel change.
Special cases:
Call release following a reset
BSC-initiated release
BTS-initiated release
Mobile station-initiated release.
For more information, refer to Call Release (Section 5).
1.2.4 Operations & Maintenance

O&M provides the operator interface for the management and control of the
BSS, and its interconnection to the NSS. O&M is divided into three principal
areas:
Configuration Management
Fault Management
Performance Management.
For more information, refer to Operations & Maintenance (Section 8).
20 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.3 BSS Components

There are three main units in the BSS:
The BSC, which acts as the controller of the BSS. The BSC provides
control of the BTS and their resources, and performs switching functions
within the BSS
The BTS, which provides the radio transmission and reception functions
for a cell
The Transcoder, which performs rate adaptation and encoding/decoding of

speech and data between the MSC and the BSC.
The BSS, as shown in Figure 1, is supervised by the OMC-R. In a large

network, one or more high-level supervisors, such as NMCs, can exist to
centralize network management activities. The NMC has the authority to send
directives to the OMC-R.
For more information about the NMC, refer to documentation supplied with
the NMC.
1.3.1 Base Station Controller

The BSC provides control of the BTS and manages radio resources and radio
parameters. From a transmission point of view, the BSC also performs a
concentration function if more radio traffic channels than terrestrial channels are
connected to the MSC. A single BSC can control a large number of BTS. The
exact number is a function of the BSC equipment and the configurations used.
The BSC provides:
Resource management
Database management
Radio measurement processing
Channel management
Operations and maintenance functions within the BSS
Communication with the OMC-R
Switching between the Air Interface channels (and their associated Abis
channels), and the A Interface channels.
For more information about these interfaces, refer to:
The A Interface (Section 1.7.4)
The Abis Interface (Section 1.7.6)
The Air Interface (Section 1.7.9).
3BK 21222 AAAA TQZZA Ed.08 21 / 304

1 Introduction
The 9120 BSC also incorporates the following transmission equipment:

The Base Station Interface Equipment (BSIE), which performs signaling and
submultiplexing on the Abis Interface
The Transcoder Submultiplexer Controller (TSC), which collects and

processes transmission data. It also provides an operator interface to
certain transmission functions via a Local Maintenance Terminal.
For a more detailed description of the 9120 BSC, refer to the BSC/TC Overall
Description.
In the 9130 BSC, the transmission equipment is replaced by virtual
transmission processes, to ensure the same functions as in the 9120 BSC.
For a more detailed description of the 9130 BSC, refer to the 9130 BSC
Evolution Functional Description.
1.3.2 Base Transceiver Station

The BTS provides the radio transmission, control and baseband functions
for a cell. The BTS also supports the Air Interface with the mobile stations.
Alcatel-Lucent provides two families of BTS:
BTS G1 or G2
BTS 9100 or BTS 9110.
These families of BTS have different architectures, and are not functionally
identical, (e.g., only the BTS 9100 or BTS 9110 can support GPRS).
The BTS performs the following functions under the control of the BSC:
Transmit and receive functions
Antenna diversity
Frequency hopping
Radio channel measurements
Radio frequency testing.
The BTS also includes BIEs which enable it to communicate with the BSC over
the Abis Interface. In the BTS 9100 and BTS 9110, the BIE is integrated
into the SUM.
For a more detailed description of the BTS, refer to the:
BTS Functional Description
BTS 9100/9110 Functional Description.
For the BTS name, it is possible to use any combination of the following
characters: a-z, A-Z, 0 - 9, -, _ (hyphen, underscore). Blank spaces are also
permitted in the BTS name. For more information about naming rules, refer
to the O&M Parameters Dictionary.
22 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.3.2.1 Antenna Diversity

Antenna Diversity is a BTS feature that protects against multipath fading. This
is achieved by duplicating the receive antenna and receive path up to the Frame
Unit of the BTS (or the TRE for a BTS 9100 or BTS 9110). The Frame Unit
(or TRE) uses the data burst which has the fewest errors. This increases the
low-power mobile station range, thereby allowing larger cells.
1.3.2.2 G1 and G2 BTS Antenna Diversity

Antenna diversity on G1 and G2 BTS duplicates the receive antenna and
receive path up to the Frame Unit. The Frame Unit uses the data burst which
has the fewest errors. This increases low-power mobile station range, therefore
allowing larger cells and lowering infrastructure investment.
The following figure shows the antenna diversity path through the G1 and
G2 BTS.
Other Antennae
TX
C
O
U
P
L
I
B F N
I FU H CU G
E U a
U RX
a N
a a I
T
ab
Best of a&b
b b RX
b
b
(Option)
OMU
CONTROL BASEBAND BASEBAND RADIO COUPLING

CONTROL
BIE : Base Station Interface Equipment
CU : Carrier Unit
FHU : Frequency Hopping Unit
FU : Frame Unit
OMU : Operations and Maintenance Unit
RX : Receiver
TX : Transmitter
3BK 21222 AAAA TQZZA Ed.08 23 / 304

1 Introduction
1.3.2.3 BTS 9100/9110 Antenna Diversity

Antenna diversity on the BTS 9100 or BTS 9110 follows the same principle as
in the G1 and G2 BTS. The antennae are used for both transmit and receive,
and the receive path is duplicated up to the TRE, providing the same gain in
efficiency and low-power mobile station range.
The following figure shows the antenna diversity path through the BTS 9100.
TRE 1
Best of a a
ab a&b
b ANT a
Tx / Rx
TRE 2
a
Best of a
ab a&b
S b
U b
M
TRE 3
Best of
ab ab b
a&b
a
TRE 4 b b
Best of b ANT b
ab a&b a Tx / Rx
a
ANy ANx
ANC
BASEBAND BASEBAND RADIO RADIO
CONTROL COMBINING DUPLEXING
ANT : Antenna
ANx : Antenna Network Type x
ANy : Antenna Network Type y
SUM : Station Unit Module
TRE : Transmitter/Receiver Equipment
Note: The configuration shown above (1 Sector, 3X4 Transceivers) is one example
only. Other combinations of Antennae and TREs are possible. There is no ANy
in the BTS 9110, and ANy is not needed if the sector has two TREs.
24 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.3.3 Transcoder And Transmission Function

The Transcoder is the key component for the transmission function, which
provides efficient use of the terrestrial links between the equipment of the BSS.
In addition to the Transcoder, Submultiplexers are also used for transmission
functions.
The Transcoder provides:
Conversion between A-law and Radio Test Equipment-Long Term Prediction

encoded traffic (speech)
Conversion between A-law and Algebraic Code Excited Linear Prediction

encoded traffic (speech)
Rate adaptation (data)

O&M control of the transmission function.
The Transcoder is normally located next to the MSC.

The Submultiplexer performs submultiplexing on the Ater Interface, between
the MSC and the BSC. When submultiplexing is used, a Submultiplexer is
located at each end of the link.
The following figure shows how transmission components are distributed in
the BSS with an 9120 BSC.
TSC
OMC−R
BTS BIE BIE BSC SM SM TC
MSC
BTS BIE BIE BSC TC
TSC
BTS

SM : Submultiplexer
TSC : Transcoder Submultiplexer Controller
TC : Transcoder
3BK 21222 AAAA TQZZA Ed.08 25 / 304

1 Introduction
BSS with the 9130 BSC differs from BSS with the 9120 BSC, in that the
transmission components are replaced by virtual transmission processors.
There are two types of transcoders:
G2
There are 2 types of G2 TC:
G2 TC equipped with ASMC and TRCU
G2 TC equipped with ASMC/TRCU + MT120 boards (in the case
of an extension).
9125
The 9125 TC can be equipped with up to 48 sub-units (referred to as MT120
boards). Each MT120 offers an Atermux connection to a BSC and up to 4
Atrunk connections to the MSC.
The 9125 Compact TC can have 2 9125 TC STM-1 boards, active and
standby. They are inserted in a dedicated 9125 TC STM-1 subrack, which
is located in the bottom part of the TC rack. Each TC MT120 board is
connected to both TC 9125 STM-1 boards (dual star).
1.3.4 The Multi-BSS Fast Packet Server

The MFS is preferably located at the Transcoder/MSC site.
It is internal to the BSS and provides the following functions:
PCU (Packet Control Unit) functions:
PAD (packet assembly/disassembly) function
Scheduling of packet data channels
Automatic Retransmission Request functions
Channel access control functions
Radio channel management functions.
The Gb Interface protocol stack.
The MFS converts GPRS frames, carried on multiple 16 kb/s links from multiple
BTS, to one or more frame relay channels connected to the SGSN on the Gb
Interface. For more information, refer to The Gb Interface (Section 2.3.1).
The set up of Packet Data Channels is controlled by the MFS. It also negotiates
resources with the BSC and routes GPRS packets. When an additional channel
is required on a BTS, the MFS asks the BSC to allocate a channel and to
connect it to an Ater channel which the MFS controls.
The Alcatel-Lucent solution also supplies two dedicated GPRS interfaces
between the MFS and the BSS:
The BSCGP Interface supplies routing of GPRS messages and resource

negotiation between the BSC and the MFS
The GCH Interface routes user data traffic and signaling between the MFS
and the BTS transparently (to the BSC).
The IMT ensures the hardware and software management of the MFS.
26 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.3.4.1 GPRS Processing Units

The MFS is divided into GPRS processing units (GPU) which are
interconnected via an Ethernet bus and controlled by a control station. The
GPU handles the O&M and telecom functions of several cells, but a cell cannot
be shared between several GPUs.
A GPU cannot be connected to more than one BSC, which means that each
GPU cannot manage several BSSs simultaneously. Even so, the use of several
GPUs per BSS is required for traffic capacity reasons. The MFS is in charge of
associating each cell with a GPU. This is referred to as GPU cell mapping.
The GPU is in charge of:
O&M functions:
Initialization of the MFS
Software download
Software configuration
Performance monitoring.
Telecom functions:
Radio and transmission resource control
Radio link control of packet connections
Common control channels management
MS radio resource control
Logical Link Control (LLC)
Protocol Data Unit (PDU) transfer
Multiframe management
Congestion control
Gb Interface management
Signaling management on the GSL Interface.
1.3.4.2 GPU Protocol Management

The GPU is split into two sub-units, the Packet Management Unit (PMU)
and the Packet Traffic Unit (PTU).
The protocols handled by a GPU are split in the following manner:
Protocols handled by the PTU:

Radio Interface protocols (RLC and MAC)
GCH Interface protocols (L2-GCH and L1-GCH).
The PTU manages the corresponding GCH Interface (for more information,
refer to The GCH Interface (Section 2.3.3)).
Protocols handled by the PMU:

Gb Interface protocols (BSSGP, Network Service, and Full Rate)
BSC Interface protocols (BSCGP, L2-GSL, and L1-GSL)
RRM protocol.
The PMU manages the corresponding Gb and GSL interfaces.
3BK 21222 AAAA TQZZA Ed.08 27 / 304

1 Introduction
1.3.4.3 Multi-GPU per BSS

To increase the GPRS capacity of the BSS in terms of the number of PDCH,
several GPU boards can be connected to the BSC to support the PCU function.
This feature is applied regardless of the BTS type.
For one BSC, in the case of a multi GP configuration, if the last GSL of any
GPU is lost, all GPUs assigned to the BSS will be reset (reset_data) and
PS outage occurs.
The only exceptions are the following:
GSL loss on GPU which have all cells locked
GSL loss on GPU and the other GPU have also their GSL down.
1.3.4.4 Cell Mapping

Mapping a cell means that a cell is associated with a GPU. Remapping a
cell means that a cell, already linked to a GPU, is moved to another GPU.
The mapping of cells onto GPUs is performed by the MFS, which actually
defines the mapping of cells onto LXPUs (logical GPU). An LXPU is either
the primary GPU, or the spare GPU in the case of switchover. All the GPRS
traffic of one cell is handled by only one GPU. The following figure shows an
example of cell mapping.
MFS
Cell 1
Cell 4 Cell 2 GPU1
Cell 3
Cell 5
Cell 6
BSC GPU2
Cell 7
Cell 8
Cell 12 Cell 9 GPU3
Cell 11
Cell 10
Cell 14
Cell 13
GPU4
GPU : GPRS Processing Unit
28 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.4 Extended GSM

Two 10 MHz extended bands for GSM 900 in the range 880-890 MHz/925-935
MHz are specified as an option on a national basis. The reason for this is
mainly due to the lack of primary band frequencies in countries outside Europe.
The term "G1" is used for the extended band. The term "P-GSM" is used
for the primary band. The term "E-GSM" is used for the whole GSM 900
frequency band, i.e., the primary band (890-915 MHz/935-960 MHz) plus
the extended band (880-890 MHz/925-935 MHz). This corresponds to 174
addressable carrier frequencies and leads to an increase of 40% against the
124 frequencies in the primary band.
With the Enhanced E-GSM Band Handling feature, which is supported by
Alcatel-Lucent BTS only, (E)GPRS and all types of signaling channels
are carried on the frequencies in the entire E-GSM band (e.g., primary
and extended), when the EGSM_RR_ALLOC_STRATEGY parameter is set
to 1 (same behavior for E-GSM capable mobile stations). When the
EGSM_RR_ALLOC_STRATEGY parameter is set to the default value of 0 (different
behavior for E-GSM capable mobile stations), the OMC-R does not allow the
operator to define the BCCH, CCCH, SDCCH and CBCH on an E-GSM TRX.
Both P-GSM only and E-GSM mobile stations are supported in the
network, but are handled differently, depending on the value to
which the EGSM_RR_ALLOC_STRATEGY parameter is set. When the
EGSM_RR_ALLOC_STRATEGY parameter is set to the default value of 0, the
BSS handles E-GSM capable mobiles stations differently from P-GSM only
mobile stations. When the EGSM_RR_ALLOC_STRATEGY parameter is set to 1,
the BSS handles P-GSM only and E-GSM capable mobile stations in E-GSM
cells in the same way, that is, the BSS assumes that all GSM 900 mobiles
are E-GSM capable.
E-GSM TRXs are preferred to support (E)GPRS in E-GSM cells, and only when
the EGSM_RR_ALLOC_STRATEGY parameter is set to 0. An E-GSM cell is one in
which FREQUENCY_RANGE = EGSM or EGSM-DCS1800.
An E-GSM TRX is a TRX configured with:
Frequencies in the G1 band only, or

Frequencies in both the P-GSM and G1 bands.
For information about radio resource allocation with Enhanced E-GSM Band
Handling, refer to TCH Allocation for E-GSM and P-GSM Mobile Stations
(Section 1.4.4).
1.4.1 E-GSM Mobile Station Recognition

From messages sent by the mobile station, the BSS determines if a mobile
supports the E-GSM band.
The mobile station is determined to be E-GSM if:
The FC bit of Classmark 2 is set to 1 (regardless of the value of the Band
2 bit of Classmark 3) or
The FC bit of Classmark 2 is set to 0, and the Band 2 bit of Classmark

3 is set to 1.
If the information is not available, the mobile station is considered as not

supporting the G1 band. The BSS never triggers a Classmark Interrogation
procedure to obtain the E-GSM ability of a mobile station.
3BK 21222 AAAA TQZZA Ed.08 29 / 304

1 Introduction
1.4.2 E-GSM Management After Initial Determination

Once the E-GSM ability is initially determined as described above, the mobile
station radio characteristics might change during a transaction. If the BSC
receives a classmark change message, it takes this into account and updates
the E-GSM ability according to the content of the received message.
1.4.3 E-GSM Determination at Handover

In the case of internal handover, the E-GSM ability of a mobile station is
stored in the BSC memory. In the case of external incoming Handover, the
handover request message includes either Classmark 1 or Classmark 2 IE,
and optionally Classmark 3 IE. If Classmark 1 is present and Classmark 3 is
not present or Classmark 3 is present but does not contain the Band 2 bit,
the mobile station is not considered as E-GSM. If both Classmark 1 and
Classmark 3 are present, and Classmark 3 contains the Band 2 bit, the BSC
gets the E-GSM ability of the mobile station from Classmark 3. If Classmark
2 is present and Classmark 3 is not present, or Classmark 3 is present but
does not contain the Band 2 bit, the BSC gets the E-GSM ability of the mobile
station from Classmark 2 ("FC" bit).
If both Classmark 2 and Classmark 3 are present, the mobile station is seen
as E-GSM:
If the FC bit of Classmark 2 is set to 1 (whatever the value of the band 2

bit of Classmark 3)
If the FC bit of Classmark 2 is set to 0 and the band 2 bit of Classmark
3 is set to 1.
After an incoming external handover, if a classmark change message is

received from the mobile station, the BSC ignores any subsequent classmark
update message received from the MSC.
30 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.4.4 TCH Allocation for E-GSM and P-GSM Mobile Stations

The allocation of G1 band channels can be done for Normal Assignment
(NASS), Internal Channel Change (ICC), or External Channel Change (ECC).
Each TRE has the capability to support the P-GSM or the E-GSM band. Each
TRX is configured as a P-GSM TRX or an E-GSM TRX. As enhanced E-GSM
band handling allows P-GSM and G1 frequencies to be mixed in the FHS, when
a TCH is needed, the BSC first checks the frequencies in the FHS. If at least
one frequency belongs to the G1 band, the related TRX is considered as an
E-GSM TRX. TCHs are then allocated as described below.
In an E-GSM cell, when the EGSM_RR_ALLOC_STRATEGY parameter is set to 0 ,
when allocating a TCH to serve circuit-switched requests, the BSC selects the
TCH in the following order:
For E-GSM capable mobile stations

First, a radio timeslot which IS E-GSM capable but NOT PS capable
Next, a radio timeslot which is NEITHER E-GSM capable NOR PS
capable
Thirdly, a radio timeslot which is NOT E-GSM capable but IS PS capable
Lastly, a radio timeslot which is E-GSM capable and PS capable.
For P-GSM capable only mobile stations

First, a radio timeslot which is NEITHER E-GSM capable NOR PS
capable
Next, a radio timeslot which is NOT E-GSM capable but IS PS capable.
When the EGSM_RR_ALLOC_STRATEGY parameter is set to 1, the BSS assumes

that all GSM 900 mobile stations are E-GSM capable, and handles P-GSM only
and E-GSM capable mobile stations in E-GSM cells in the same way.
In multiband concentric cells, the above allocation only applies to the outer zone.
When the EGSM_RR_ALLOC_STRATEGY parameter is set to 0, in an E-GSM
cell, when allocating a PDCH to serve packet-switched requests and based
on the TRX ranking provided to the MFS, the BSC selects the TCH in the
following order:
First, a radio timeslot which is E-GSM capable AND PS capable
Next, a radio timeslot which is NOT E-GSM capable but IS PS capable.
When the EGSM_RR_ALLOC_STRATEGY parameter is set to 1, the BSS handles

P-GSM only and E-GSM capable mobile stations in E-GSM cells in the same
way.
3BK 21222 AAAA TQZZA Ed.08 31 / 304

1 Introduction
1.5 External Components

The BSS communicates with three external components:
The NSS on the A Interface
The mobile station on the Air Interface
The OMC-R on the BSS/OMC-R Interface.
The following figure shows the logical position of the External Components.
PLMN
Mobile Network Fixed

Stations Subsystem Network
Base Station Subsystem
A
Ater Interface Interface MSC PSTN
BTS
Transcoder
BTS BSC
MFS
BTS Gb Interface
SGSN GGSN PSDN
Abis
Interface
OMC−R HLR
NMC
GGSN : Gateway GPRS Support Node

HLR : Home Location Register
PSDN : Packet Switched Data Network
Figure 2: Logical Position of External Components Associated with BSS
32 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.5.1 Network Subsystem

Managing communication within the PLMN and external networks is the primary
role of the NSS. The NSS manages the subscriber administration databases.
It contains the following components.
Component Description
MSC Performs and coordinates the outgoing and incoming Call Set Up function.
The MSC is a large capacity switch used for passing mobile traffic to
mobile subscribers, or to subscribers of external networks. This part of
the NSS interfaces with the BSS.
Home Location Register The HLR is the central database within a given network for mobile
subscriber specific data. It contains static data such as access
authorization, information about subscribers and supplementary services.
It also controls the dynamic data about the cell in which the mobile station
is located.
Visitor Location Register The VLR temporarily stores information about mobile stations entering its
coverage area. Linked to one or more MSCs, the VLR transmits data to a
new VLR when a mobile station changes areas.
Authentication Center The AuC manages the security data used for subscriber authentication.
Equipment Identity Register The EIR contains the lists of mobile station equipment identities.
3BK 21222 AAAA TQZZA Ed.08 33 / 304

1 Introduction
1.5.2 Mobile Stations

Mobile stations provide radio and processing functions which allow subscribers
to access the mobile network via the Air Interface. Subscriber-related
information is stored on a specific device called a SIM.
The SIM is a removable smart-card that conforms to internationally recognized
standards. It contains the IMSI. This is used by the Network Operator to
identify the subscriber in the network and to provide security and protection
against misuse.
Each mobile station has its own IMEI. The IMEI is used by the Network
Operator to prevent stolen or non-type approved mobile stations from accessing
the network.
There are three types of mobile station in GSM:
Phase 1
Phase 1 extended
Phase 2.
For information about GPRS mobile stations, refer to GPRS Elements (Section
2.1.2).
Mobile stations have different capabilities according to the class of mobile
station and the purpose for which the mobile station was designed. These
differences include power output and ciphering.
Only phase 2 mobile stations can turn off ciphering, or change the ciphering
mode, during a channel change procedure such as a handover. The ciphering
capability of a mobile station is signalled to the BSS in the mobile station
classmark.
Ciphering is used to protect information transmitted on the Air Interface. This
is performed between the BTS and the mobile station (i.e., Air Interface).
Transmission ciphering does not depend on the type of data to be transmitted
(i.e., speech, user data, signaling), but on normal transmission bursts. For
more information about mobile station ciphering capabilities, refer to Ciphering
(Section 3.8).
1.5.2.1 Mobile Station Idle Mode

A mobile station is in idle mode when it is switched on but not communicating
with the network on an SDCCH or a traffic channel.
The BSS supports four idle mode functions:
Cell selection and cell reselection
GSM/GPRS to UMTS cell reselection
Location updating
Overload control.
34 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.5.2.2 Mobile Station Cell Selection and Reselection

A mobile station monitors the broadcast messages from the BTS. This includes
monitoring the FCCH and SCH.
The mobile station chooses the best cell on which to camp. If this cell is in a
location area other than that stored in the mobile station memory, then the
mobile station initiates a location update procedure. For a mobile station to
camp on a cell, it has to synchronize with the cell.
The BTS broadcasts an FCCH and an SCH at a defined time in the BCCH
cycle. These channels are used as reference points for the mobile station to
synchronize with the BCCH. Once synchronized, the mobile station continues
to monitor these channels to stay synchronized.
This type of synchronization, along with cell configuration and channel
frequency information, enables the mobile station to calculate where channels
occur in the multiframe sequences.
Timing advance information is sent to the mobile station when an SDCCH is
assigned. The mobile station uses the channel configuration information
to calculate which part of the CCCH contains its paging message, and
therefore which timeslot to monitor for paging messages. When the mobile
station is camped on a cell, it continues to monitor the BCCH transmissions
from neighboring cells. The BCCH frequencies of the neighboring cells are
transmitted on the BCCH of the home cell (sys_info 2). The mobile station can
decide to camp on a new cell if it receives a better signal from an adjacent cell.
Reasons for moving to a new cell include:
A problem in the existing cell

The mobile station moving.
If the mobile station moves to a new cell which is in the same location area
as the one currently in its memory, it does not initiate a location update. It
recalculates its paging group and monitors the new paging channel. Paging
messages are broadcast from all cells in a particular location area.
1.5.2.3 GSM/GPRS to UMTS Cell Reselection

The reselection of a UTRAN cell is triggered by a multi-RAT mobile station
in circuit-switched idle mode, packet-switched idle mode, or packet-switched
transfer mode. In NC0 mode, a multi-RAT mobile station can reselect a
UTRAN cell in any GMM state. In dedicated mode, the multi-RAT mobile
station follows the GSM handover procedures. The BSS then broadcasts the
set of UTRAN cell parameters which allows the multi-RAT mobile station to
reselect a UTRAN cell on its own.
For more information about 2G to 3G cell reselection, see GSM-to-UMTS
Cell Reselection (Section 2.7.3.7).
3BK 21222 AAAA TQZZA Ed.08 35 / 304

1 Introduction
1.5.2.4 Location Updating

The location update procedure is always initiated by the mobile station.
Location update is performed after the call has finished (cell reselection).
Reasons for location updates include:
A periodic update
The mobile station performs a periodic location update after a lack of
signaling activity for a specific time. If the timer expires, the mobile station
initiates a location update, even if it has not changed location area. The
duration of the mobile station timer is defined by the network and sent to the
mobile station as system information messages on the BCCH. The time can
be between six minutes and 25 hours.
A handover to a cell in a new location area.

When a mobile station is handed over to a cell in a new location area, there
is no automatic location update in the network. A new Location Area Identity
in the BCCH (sys_info 3 and sys_info 4) is detected by the mobile
station when the current call is finished, and initiates the location update
procedure. This saves the system performing several location updates if the
mobile station is handed over several times during a call.
The mobile station camps on a cell with a different location area code to the one
in the mobile station memory. The mobile station initiates the location update
procedure by sending a Channel_Request message indicating that the call is
for a location update. The BSS assigns a dedicated signaling channel and
establishes a signaling path between the mobile station and the MSC. See
Mobile-Originated Call (Section 3.2) for more information.
When a signaling path is established, the mobile station sends the Location
Area Identity of the old cell on which it was camped to the MSC. The new VLR
interrogates the old VLR for authentication and subscriber information. For
more information, see Location Updating with Classmark Procedure (Section
3.6.3) and Authentication (Section 3.7).
The Location Area Identity comprises:
Mobile Country Code
Mobile Network Code
Location Area Code.
36 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
The BSS adds the cell identity of the mobile station’s current location to the
message sent to the MSC. This information is sent in a Mobility Management
sub-layer message and is transparent to the BSS. The NSS stores this
information either in its HLR or its VLR. Following a location update procedure,
the VLR can assign a new Temporary Mobile Subscriber Identity (TMSI) to the
mobile station. For more information about the TMSI, refer to Authentication
(Section 3.7). The following figure shows a mobile station as it moves to a
new location area.
Mobile BTS BSC

BSC MSC VLR
Station
Mobile Station connecting

in a new location area
Protocol Messages
Mobile MSC VLR
Station
BTS BSC
BSC
VLR : Visitor Location Register

Figure 3: Location Update
1.5.2.5 Overload Control

To protect itself against overload, the system can bar access to mobile stations
by changing the RACH control information in the system information messages
described in Table 1.
For more information, refer to:
GPRS Overload Control (Section 2.6.4)

Overload Control (Section 4.7).
3BK 21222 AAAA TQZZA Ed.08 37 / 304

1 Introduction
1.5.3 Phase 2 Mobile Support in a Phase 1 Infrastructure

When a phase 2 mobile station is used in a phase 1 infrastructure network,
the BSS functions as phase 2 on the Air Interface and has the capability of
functioning as phase 1 or phase 2, depending on the MSC capabilities. The
infrastructure (BSS and MSC) remains phase 1. This conforms to updated
GSM recommendations for phase 1.
Problems that may occur when using phase 2 mobile stations on a phase
1 network include:
The implementation rules for phase 1 are not strictly defined, therefore some
implementations cannot function with phase 2 mobiles.
For example, some of the spare bits in phase 1 are now used by the phase
2 protocol. However, some phase 1 infrastructures reject the message as
spare bits are used.
Some protocol changes in phase 2 changed or replaced a phase 1 protocol

For example, power and quality measurements sent by phase 2 mobile
stations have a finer range of power control, which the phase 1 infrastructure
must process.
Phase 2 mobile stations send some phase 2 messages even though they
are in a phase 1 environment.
For example, phase 2 mobile stations send either new messages or new
elements in messages, which the phase 1 infrastructure could reject. This
blacklists the mobile station due to an invalid protocol message for phase
1. Depending on what these messages are, the updates to the phase 1
infrastructure would accept these messages/elements. The messages can
be either ignored or only partially treated. This is based on information
contained in the messages or elements.
1.5.4 Operations and Maintenance Center-Radio

The OMC-R supervises one or more BSSs.
It performs the following functions:
Manages the BSS software versions
Acts as the central repository for configuration data
Manages fault and performance measurement reports
Handles supervision of alarms and events

Manages the MFS.
The reported data is available to the operator from the OMC-R’s central
database. The OMC-R only performs O&M activities. It does not perform user
traffic processing or call establishment and control activities. Refer to the
Operations & Maintenance Principles for more information.
Operator actions via the terminal interface trigger commands throughout the
BSS. The OMC-R provides object-oriented management information, and
supports a Manager/Agent scheme to perform and control management
activities. The terminal interface supports different user profiles with different
access rights.
38 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.6 Network Management

Normally the OMC-R provides all the network management and control
functions required by the BSS. However, the management and control
functions are proprietary to the system supplier. In keeping with International
Telecommunications Union and European Telecommunication Standards
Institute recommendations, the Telecommunications Management Network
(TMN) model standardizes the Network Management function. Network
Management is compatible with all equipment, even that of different
manufacturers. Network Management is controlled from one or several NMCs.
1.6.1 Telecommunications Management Network

The ability to transfer management information across the Telecommunications
Management Network environment is defined by a protocol suite, the Q
Interfaces. The following figure shows the hierarchical structure of the TMN. It
graphically defines the respective management responsibilities in the three
main levels of the Management Information Tree (MIT).
For more information about the Telecommunications Management Network,
refer to the BSS/MFS and TMN Functions section of the Operations &
Maintenance Principles document.
NMC Operator Network Management
(Resource Management)
OSS &
NMC
Network Element
Management
Q3
OMC−R Operator OMC−R Mediation Function

(Resource and Equipment
Management)
Network Element
MFS
Security Block (SBL) BSC BSS

Management
BTS
BTS
BTS
OSS : Operation Support System

Figure 4: TMN System Hierarchy
3BK 21222 AAAA TQZZA Ed.08 39 / 304

1 Introduction
1.6.2 Q3 Interface
Communication between the NMC and the OMC-R takes place across the
Q3 Interface (see Figure 4).
The Q3 protocols can be divided into:
Association connection and disconnection mechanisms

Message format and structure
Command types.
For more information about Network Management and the Q3 Interface, see
the Operations & Maintenance Principles.
1.7 BSS Telecommunications Layers

The telecommunications functions of a GSM network are split into layers.
These layers are split into two basic categories, Application and Transmission:
The Application layer is split into sub-layers, to control:
Call Management
Mobility Management
Radio Resource Management.
The Transmission layers, which provide transmission between the various

components.
Note: These Transmission layers relate to the OSI layers, that is, the Physical Layer
(i.e., Layer 1) and the Data Layer (i.e., Layer 2). The protocols used for these
layers are standard.
The following figure shows the general distribution of the telecommunication
functions within a GSM network.
MS BTS BSC NSS
CM
MM GSM
Application
Layers
RRM
TRANSMISSION
CM : Call Management
MM : Mobility Management
MS : Mobile Station
RRM : Radio Resource Management
40 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.7.1 Call Management Sub-layer

The Call Management sub-layer performs Call Control to establish, maintain
and release calls. SMS within Call Management allows the mobile station to
send and receive messages of up to 160 characters. The Supplementary
Service functions are also provided to the mobile stations as part of Call
Management.
1.7.2 Mobility Management Sub-layer

The Mobility Management sub-layer is used by the NSS to manage the
subscriber database, including information about subscriber location and
authentication. It is also used by the mobile stations to send location updates
when they move to new location areas.
1.7.3 Radio Resource Management Sub-layer

The Radio Resources Management sub-layer establishes, maintains and
releases stable connections between the mobile station and the MSC for the
duration of a call. This includes functions such as managing the limited radio
resources, to ensure high service availability. It also performs handovers
when a mobile station moves during a call, or the channel quality falls below
an acceptable level. RRM functions occur mainly between the mobile station
and the BSC.
3BK 21222 AAAA TQZZA Ed.08 41 / 304

1 Introduction
The following figure shows the application layers, transmission layers and
Interfaces of the BSS.
MS BTS BSC MSC
BSSAP BSSAP BSSAP

CM
MM
RRM
} GSM
Application
Layers
LAPDm LAPDm LAPD LAPD

SCCP
SS7
SCCP
SS7 } Layer 2
Layer 1 Layer 1 Layer 1 Layer 1 Layer 1 Layer 1
08.60 TC
Air Interface Abis Interface A Interface
BSSAP : BSS Application Part
CM : Call Management
LAPD : Link Access Protocol on the D Channel
LAPDm : Link Access Protocol on the Dm Channel
Layer 1 : Physical Layer
Layer 2 : Data Link Transfer Layer
MM : Mobility Management
RRM : Radio Resource Management
SCCP : Signal Connection Control Part
SS7 : Signaling System No. 7
TC : Transcoder
42 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.7.4 The A Interface

The A Interface is used for communication between the BSC and the MSC.
The connection between the BSC and MSC can be either terrestrial lines or
a satellite link.
The A Interface includes the:
Physical Layer 1
The physical layer provides a physical connection to transport the signals.
It supports a 2 Mbit/s link divided into 32 x 64 kbit/s channels by Time
Division Multiplex. The actual physical link used depends on Network
Operator implementation.
Data Link Layer 2

Layer 2 provides the frame handling functions for the interface. It is also used
to pass signaling messages using the International Telecommunications
Union (ITU) SS7 protocol.
This comprises the:
Message Transfer Part, which provides the mechanism for reliable
transfer of the signaling messages
Signaling Connection Control Part, which provides the mechanism to
identify transactions relating to a specific communication.
Application Sub-Layer 3 RRM

To transfer Layer 3 messages relating to a transaction, the SCCP uses the
BSS Application Part. This is divided into two parts:
Direct Transfer Application Part, which transfers messages directly
between the MSC and the mobile station. These messages are not
interpreted by the BSS. The BSS must read and recognize the initial
message as a DTAP message.
BSS Management Application Part which supports procedures between
the MSC and the BSC, such as resource management and handover
control.
On the A Interface, the process is terminated at the BSC. Messages for the
BSS, passed by the BSSMAP, are interpreted by the BSC Layer 3.
3BK 21222 AAAA TQZZA Ed.08 43 / 304

1 Introduction
1.7.5 The Ater Interface

The part of the A Interface between the Transcoder and BSC is known as the
Ater Interface. It is a set of 2Mbit/s PCM/E1 links.
Ater Mux Interface

The Ater Mux Interface is the result of multiplexing four Ater Interfaces.
Transcoding is a Layer 1 process, therefore the difference between the two
interfaces is at the physical level.
Optimized Ater Interface Mapping
This feature improves efficiency on the Ater Mux PCM connection between
the 9120 BSC and the G2 Transcoder.
Four Ater Interfaces are submultiplexed onto the Ater Mux connection. This
interconnects four Digital Trunk Controllers and four Transcoder Rate
Adaption Units, achieving a 4:1 mapping.
The 4:1 mapping of the 9120 BSC and G2 Transcoder allows up to 116
traffic channels.
1.7.6 The Abis Interface

The Abis Interface is used for communication between the BSC and the BTS.
The Abis Interface includes:
Physical Layer 1
The physical layer provides a physical connection to transport the signals. It
supports a 2 Mbit/s link divided into 32 x 64 kbit/s channels by TDM.
The physical link used depends on the Network Operator implementing
the interface.
Data Link Layer 2
The data link layer provides frame handling and signaling functions using
the LAPD.
This layer supports three types of signaling links:
The Radio Signaling Link for signaling to the mobile station (including
SMS)
The O&M Link for O&M information
The OML Auto-detection feature (see OML Auto-Detection (Section
8.4.6)) allows the timeslot reserved for the O&M Link to be used for
signaling (if there are no G1/G2 BTS on the Abis Interface). This provides
for an increase in the amount of telecom traffic on the Abis Interface.
The Layer 2 Management Link for the Layer 2 management functions
such as frame checking and error correction.
Application Layer 3: BTS Management Sub-layer

The BTS management sub-layer carries Layer 3 messages between the
BSC and the BTS. Some of these messages are transparent to the BTS.
These are passed directly to the mobile station using the BTS RRM
sub-layer 3 on the Air Interface. Non-transparent messages include
messages for radio link layer control and channel management.
44 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.7.7 HSL Links

The 9130 BSC capacity depends on a High Speed Signaling Link (HSL)
introduction, between the BSC and the MSC. The ports where HSL are
physically connected cannot be used for other purposes. The HSL is similar to
the Low Speed Signaling Link (LSL) (N7). The same operations are allowed
on their SBL. The mixed mode, HSL + LSL, is not allowed. These links are
exclusive.
1.7.8 Satellite Links

The Abis and Ater interfaces were designed to use terrestrial transmission links.
However, in developing countries, the terrestrial transmission infrastructure
does not exist and in many cases is difficult and costly to provide. There is also
a need in the developed world to provide temporary GSM coverage for transient
mobile population density increases, for example at sporting events. Using
geostationary earth orbiting satellites is a simple and relatively low-cost solution
to these problems. Unfortunately, there is one major drawback: transmission
delay. The Geostationary orbit is located at an altitude of 35,786 km above
the equator, therefore propagation delay of radio signals can vary between
119 ms at the equator to a maximum delay of 139 ms. The delay for one hop
(the path from one point on earth to another point, via one satellite link) varies
between 238 and 278 ms. This delay degrades speech quality, but although the
degradation is worse than experienced in the PSTN, it is usable. The delay also
has an effect on signaling messages.
Satellite links can be used on the Abis Interface or on the Ater Interface, but
not both.
Parameter modification is done from the OMC-R and propagated to the BSC
and the concerned BTS. A new connection type parameter is associated with
each Abis link. The operator can set the parameter at Abis creation time. If
the satellite link is made using the Ater Interface, the new connection type
parameter associated with the Ater as a whole is used. Both Abis and Ater
connection types can be either terrestrial or via satellite. The default value for
each is terrestrial.
Note: This is not a standard GSM feature and Alcatel-Lucent cannot guarantee the
performance because there are so many unknown factors, such as error rate
and mobile population variations, which have significant effects because of
the delay.
1.7.8.1 Abis Interface Using Satellite Links

This feature is available only for Alcatel-Lucent BTS and later. When the link is
installed on the Abis Interface, for those BTS where the satellite link is installed,
the following features are not available:
Closed multidrop
PCM synchronization (the BTS must be configured as free running).
Synchronous handovers, fax and data (in circuit-switched mode, transparent

and not transparent) are supported.
3BK 21222 AAAA TQZZA Ed.08 45 / 304

1 Introduction
1.7.8.2 Ater Interface Using Satellite Links

On the Ater Interface, the satellite link can be installed either on the Ater
(between the BSC and the Transcoder), or on the A Interface (between the
Transcoder and the MSC). Because the latter case is rare, the wording Ater
is used for both cases. When only some of the timeslots are routed via the
satellite, at least the Qmux and the X.25 (if the satellite link is on the A Interface)
must be routed. Channels that are not routed must be blocked, either from
the MSC or from the OMC-R. If only one link is forwarded, there is no longer
redundancy on the following: SS7, X.25, and Qmux.
1.7.9 The Air Interface

The Air Interface is the radio interface between the BTS and the mobile station.
The Air Interface includes:
Physical Layer 1
Data Link Layer 2
RRM sub-layer 3 of the application layer.
1.7.9.1 Air Interface Layers

The Air Interface layers comprise:
Physical Layer 1 is a radio link where channels are divided by time and
frequency
Data Link Layer 2 provides frame handling and signaling functions, using a
modified version of the LAPDm
Application Sub-Layer Radio Resources Management. On the Air

Interface, most of the Layer 3 messages are transparent to the BTS. The
BTS uses Layer 3 to extract certain information from some messages before
passing on the equivalent message.
For example, when the BTS receives an encryption_command message
from the BSC, it reads the Ki value and the algorithm to be used, before
passing on the cipher_mode_command message. For more information
about this procedure, refer to Ciphering (Section 3.8).
46 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.7.9.2 Air Interface Channels

The Air Interface is divided by frequency and time, using Frequency Division
Multiplex Access (FDMA) and Time Division Multiple Access (TDMA). This
provides frames of eight timeslots for each frequency supported by the
cell. The channels of the cell are then assigned to specific timeslots within
the TDMA frames.
GPRS traffic uses the same radio resources as circuit-switched traffic, and
is carried on the same type of physical channel. Refer to GPRS in the BSS
(Section 2) for information about GPRS channels.
However, not all channels require the full capacity of a timeslot at each
occurrence of a frame. Channels are configured to share timeslots by only
using certain occurrences of the frame. The cycle of frame occurrences is
known as a multiframe. A multiframe can be 26 or 51 occurrences of a frame,
depending on the channels configured within it. Within a multiframe, the same
physical channel can support more than one logical channel.
The following figure shows timeslot four of a TDMA frame supporting Access
Grant Channels.
A A A A A
G G G G G
C C C C C
H H H H H
Frame 1 Frame 2 Frame 3 Frame 4 Frame 5

AGCH : Access Grant Channel
Figure 5: Timeslot 4 of a TDMA Frame Supporting Access Grant Channels
Channels can be divided into traffic channels and control channels.
3BK 21222 AAAA TQZZA Ed.08 47 / 304

1 Introduction
1.7.9.3 Traffic Channels

A traffic channel can be used for speech or data. The Alcatel-Lucent BSS
supports the following types of traffic channels.
Traffic Types
Channel
Speech Speech
Full-rate speech traffic channel
Enhanced full-rate speech traffic channel
Half-rate speech traffic channel.
Data Data
Full-rate data traffic channel (9.6 Kbit/s)
Full-rate data traffic channel (4.8 Kbit/s)
Half-rate data traffic channel (4.8 Kbit/s)
Full-rate data traffic channel (<2.4 Kbit/s)

Half-rate data traffic channel (<2.4 Kbit/s).
Note: A timeslot that is configured as a TCH timeslot can be used as a PDCH, a

VGCH (Voice Group Call Services Channel), or a standard CS TCH. In terms of
radio resource management, there is no practical difference between Voice
Group Call Services (VGCS) traffic and standard point-to-point CS traffic, and
the operator only configures the TCH.
48 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.7.9.4 Control Channels

CCHs control communications between the BSS and the mobile stations. The
following table describes the four types of CCH.
Control Description
Channel
BCCH The BCCH broadcasts cell information to any mobile station in range. Three channels use
the BCCH timeslot:
FCCH: used on the downlink for frequency correction of the mobile station with the BTS
SCH: used on the downlink for frame synchronization of the mobile station with the BTS
BCCH: used to broadcast system information to the mobile stations on the downlink, to
give the cell configuration, and how to access the cell.
CCCH The CCCH communicates with mobile stations in the cell before a dedicated signaling
channel is established. Three channels use the CCCH timeslot:
RACH: used on the uplink by the mobile station for initial access to the network
PCH: used on the downlink for paging messages to the mobile station
AGCH: used on the downlink to give the mobile station access information before a
dedicated channel is assigned.
The multiple CCCH feature allows the operator to use only one additional CCCH, so two
Timeslots TS0 and TS2 are used. The operator decides to configure either 1 or 2 TS for
mCCCH, i.e. no dynamic allocation by the BSS depending on the load is foreseen.
DCCH The DCCH passes signaling information for a specific mobile station transaction. Two
channels use the DCCH timeslot:
SDCCH: used for signaling and short message information
CBCH: uses an SDCCH channel for Short Message Service - Cell Broadcasts.
ACCH The ACCH passes signaling information for a specific mobile station transaction. An ACCH
channel is always associated with a traffic channel. Two channels use the ACCH timeslot:
FACCH: associated with a traffic channel, and can steal slots out of 24 or 26 slots which are
normally dedicated to the traffic channel for signaling purposes as well as the SACCH slot.
SACCH: associated with a traffic channel, which uses one out of 26 slots for signaling
purposes.
3BK 21222 AAAA TQZZA Ed.08 49 / 304

1 Introduction
1.7.9.5 Dual Transfer Mode

A dual transfer mode capable MS uses a radio resource for CS traffic and
simultaneously one or several radio resources for PS traffic.
The following DTM principles apply:
DTM allocation means 1 TCH (established in FR) and at least 1 PDCH

allocated by MFS
In DTM, no PS measurements are done (no cell reselection while in DTM,

only emergency CS HO)
CS has priority over PS (direct transition from PTM to DTM is not possible,
direct transition from DTM to PTM is not possible, direct transition from Idle
mode to DTM is not possible, transition from DTM to dedicated mode, and
from dedicated mode to DTM are possible)
Allocated TCH and PDCH are contiguous
Multi slot allocation (3GPP): MS class 5 (1 TCH, 1 PDCH), MS class 9 (1

TCH, 2 PDCH DL, 1 PDCH UL), MS class 3x: up to 5 TS in DL, max 6 TS
UL+DL, MS class 4x: up to 6 TS in DL, max 7 TS UL+DL
(2+3) configuration is supported (requires EDA)(1PDCH DL, 2PDCH UL,

1TCH UL, 1TCH DL)
DTM TBFs are always allocated in NRT
TCH changes must be avoided due to PS outage (only emergency HO are

allowed, all PS reallocation triggers are forbidden in first step, in second
step for EDA, T3 is mandatory).
Specific constraints apply for PS resources to be allocated in DTM:
The PDCH must be allocated in the MFS (i.e. the PDCH is in an "allocated"
state, but not in the "not allocated" or "de-allocating" state)
The PDCH must be located in the "non preemptable PS zone" of the cell
The PDCH must not be in the "Full" state in the considered direction
The PDCH must not be "locked" due to a CS preemption process.
Specific constraints apply for CS resources to be allocated in DTM :

The RTS must be allocated in the MFS (i.e. the PDCH is in an "allocated"
state, but not in the "not allocated" or "de-allocating" state)
The RTS must be located in the "non preemptable PS zone" of the cell
The RTS position must be compatible with the DTM multislot class of the MS
The RTS does not support any RT PFC
The RTS does not support any PACCH channel (when considering all the
DL and UL TBFs established on this RTS and all the RT PFCs created
on this RTS)
The basic Abis nibble mapped onto the RTS is "available" (i.e. it is either free
or it is used in an M-EGCH link from which it is possible to release one GCH).
50 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.7.10 System Information Messages

System information messages transmit information about the cell to the mobile
station. System information messages 2 and 5 have several variations to avoid
compatibility problems with phase 1 mobile stations.
The following table shows the system information messages, the channel on
which they are transmitted and the type of information in each message.
Message Channel Information
Sys_info 1 BCCH Cell channel description

RACH control information
Sys_info 2 BCCH Neighbor cell BCCH frequency list

Indication of which Network Color Code it is allowed to
monitor
Sys_info 2bis BCCH Extended Neighbor cell BCCH frequency list in the same
(multiband systems band as the serving cell. This message is only sent
only) if Sys_info 2 is not sufficient to encode all available
frequencies.
Spare bits
Sys_info 2ter BCCH Extended Neighbor cell BCCH frequency list in different band
(multiband systems as serving cell
only)
The minimum number of cells, if available, to be reported in
each supported band in measurement results.
3G cell description
Spare bits
3BK 21222 AAAA TQZZA Ed.08 51 / 304

1 Introduction
Sys_info 3 BCCH Specific Cell Identity

Location Area Identity
Control channel description
Cell options:
Power central information
Discontinuous Transmission (mechanism) information
Radio link time out

Cell selection parameters:
Cell reselect hysteresis for Location Area reselection
Maximum transmit power allowed in cell
Additional reselection parameter
Allows/forbids new establishment causes (phase 2 mobile

stations)
Minimum receive level to access cell.

Spare bits setting flags and timers
Sys_info 4 BCCH Location Area Identity.

Cell selection parameters:
Cell reselect hysteresis for Location Area reselection
Maximum transmit power allowed in cell

Additional reselection parameter
Allows/forbids new establishment causes (phase 2 mobile

stations)
Minimum receive level to access cell.
CBCH channel description
CBCH Mobile Allocation
Spare bits setting flags and timers
Sys_info 5 SACCH Neighbor cell BCCH frequency list

For VGCS, only VGCS capable neighbor cell BCCH
frequency list
52 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
Sys_info 5bis SACCH Extended Neighbor cell BCCH frequency list

(multiband systems
This message is only sent if:
only)
The serving cell is a GSM 1800 cell and Sys_info 5 is not
sufficient to encode all GSM 1800 neighbor frequencies
The serving cell is a GSM 900 cell, and

The mobile station is phase 2, and
There are neighboring GSM 1800 cells, and
Sys_info 5ter is not sufficient to encode all of the GSM
1800 cells.
frequency list
Sys_info 5ter SACCH Extended Neighbor cell BCCH frequency list in different band
(multiband systems as serving cell
and phase 2 mobile
The minimum number of cells, if available, to be reported in
stations only)
each supported band in measurement results
frequency list
Sys_info 6 SACCH Specific Cell Identity

Location Area Identity
Cell options:
Power control information
Discontinuous Transmission information
Radio link time out
Indication of which Network Color Code it is allowed to

monitor.
For VCGS, status of the NCH, and an indication of

whether paging channel restructuring has taken place
Sys_info 7 BCCH SI 7 Rest Octets

Sys_info 8 SI 8 Rest Octets
SI 4 Rest Octets_S
LSA Parameters
LSA ID information
LSA identity
Sys_info 10 SACCH $(ASCI)$ message providing information for cell reselection

in group receive mode
3BK 21222 AAAA TQZZA Ed.08 53 / 304

1 Introduction
Sys_info 13 BCCH SI 13 Rest Octets without PBCCH configured in the cell:

SI 13 Rest Octets
GPRS Mobile Allocation
GPRS cell options
GPRS Power Control parameters.

SI 13 Rest Octets with PBCCH configured in the cell:
SI 13 Rest Octets
GPRS Mobile Allocation
PBCCH description.
Sys_info 16 BCCH SI 16 Rest Octets

Sys_info 17 SI 17 Rest Octets
LSA Parameters
LSA ID information
LSA identity
Table 1: System Information Messages
54 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.7.11 Dynamic SDCCH Allocation

Dynamic SDCCH allocation is a specific timeslot used for signaling (SDCCH) or
for traffic (TCH), depending on the overload. The operator configures:
A set of static SDCCH/x timeslots to handle normal SDCCH traffic

A set of dynamic SDCCH/8 timeslots, used for TCH traffic, or for SDCCH
traffic.
The general principles for dynamic SDCCH are:
Automatic allocation of SDCCH/8 timeslots (minimum and maximum)

on a cell basis
Only SDCCH/8 timeslots are concerned. It is not necessary to add or delete

a SDCCH/3, or a SDCCH/4, or a SDCCH/7 timeslot
The set of static SDCCH/x and dynamic SDCCH/8 timeslots represents the
maximum number of allocatable SDCCH timeslots
The static SDCCH/8 timeslots cannot be used for TCH purposes
The dynamic allocatable SDCCH/8 timeslots are allocated for SDCCH when
all the static SDCCH/8 timeslots are busy
A TCH call cannot free a timeslot for SDCCH/8 allocation
A TCH is preferably not allocated dynamic SDCCH/8 timeslots.
Note: VGCS calls cannot use dynamic SDCCH allocation.
3BK 21222 AAAA TQZZA Ed.08 55 / 304

1 Introduction
1.8 Networks Interworking

1.8.1 2G and 3G Cells
Cells references
A 2G cell is completely defined in the BSS by:

Absolute Radio Frequency Channel Number (ARFCN)
Base Station Identity Code (BSIC).
A 3G cell is completely defined by:

UTRAN ARFCN (UARFCN)
Primary scrambling code. Like the BSIC in GSM, the primary scrambling
code allows the UE/MS to discriminate UTRAN FDD cells having the
same UARFCN.
Identification 2G cells 3G cells
Complete radio reference ARFCN + BSIC UARFCN + Primary scrambling code
Partial radio reference Only ARFCN Only UARFCN or (UARFCN + Scrambling

codes per scrambling code group)
Cell Global Identifier CGI = MCC + MNC +LAC + MCC + MNC + RNC-ID + C-ID
CI
Partial identifiers LAC + CI, CI UC-ID = RNC-ID + C-ID, C-ID
O&M cell identifier Local Cell Identifier
Cells rapport:
The max number of 2Gto3G Adjacency for one cell is 12
In case of 9120 BSC:

The max number of 3G external cell per BSC is 450
The max number of 2Gto3G Adjacency per BSC is 980
In case of 9130 BSC:

The max number of 3G external cell per BSC is 850
The max number of 2Gto3G Adjacency per BSC is 1850
56 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.8.2 2G to 3G Handover
The following rules apply for 2G to 3G handover:
A 2G to 3G handover is based on the measurements reported by the UE/MS.

As soon as measurements above a given threshold are reported for one
or several 3G cells, those cells are candidate for handover. The averaged
measurements received along a given time must be above a given threshold.
The only measurements requested by the UE/MS are the CPICH Ec/No.
Nevertheless, an internal parameter (FDD_REP_QUANT) is defined to
choose the type of measurement.
The feature can be activated (or deactivated) on a per cell basis, by an O&M
parameter (EN_3G_HO)
When a dual mode UE/MS enters the RR dedicated mode, it sends a

CLASSMARK CHANGE message and/or a UTRAN CLASSMARK CHANGE
message which contains the INTER RAT HANDOVER INFO. There is no
acknowledgement from the network at layer 3
If the UTRAN CLASSMARK CHANGE is to be sent by the MS, the

CLASSMARK CHANGE message is sent first
If a condition is met to perform handover from 2G to 3G, the BSS does not
perform an intersystem handover via directed retry. The BSS proceeds with
the normal assignment procedure
If a condition is met to perform handover from 2G to 3G on the SDCCH, the
BSS does not perform an intersystem handover. The BSS proceeds with the
normal assignment procedure on the allocated SDCCH
When handover to 3G occurs, the LAC can also be used as additional

information but it is not part of the cell identifier.
There are two types of lists to describe the neighbor cells in the serving cell:
Distribution lists
The list is shared between all the MS of the serving cell and consequently
built from information sent within the SYSTEM INFORMATION family
messages on the BCCH or PACKET SYSTEM INFORMATION family
messages on the PBCCH.
Non-distribution lists
The list is given to an individual UE/MS camping on the serving
cell and consequently built from information sent in the dedicated
SYSTEM INFORMATION family, MEASUREMENT INFORMATION and
PACKET MEASUREMENT INFORMATION messages on the SACCH or
PACCH/PCCCH.
For 2G to 3G CS handover, in the call setup step of dual mode mobiles, the
INTER RAT HO INFO element via the UTRAN CLASSMARK CHANGE
message is not segmented and it is compressed. There is a gain of 700ms
and a reduction of SDCCH load during call setup.
3BK 21222 AAAA TQZZA Ed.08 57 / 304

1 Introduction
The following dimensioning and support constraints apply:

In the Alcatel-Lucent UTRAN, 2G to 3G handover is supported from Rel-4
This feature is limited to TCH/2G to TCH/3G handover
SDCCH/2G to SDCCH/3G handover will not be implemented
SDCCH/2G to TCH/3G handover will not be implemented
When both 2G and 3G candidate cells are determined, the 3G cell(s) prevail
A dual mode UE/MS only in dedicated transfer mode can be handed over
to UTRAN
Maximum number of outgoing 2G to 3G adjacencies at the most per 2G

cell: 8
Maximum number of outgoing 2G to 3G adjacencies at the most per BSC:

980
Maximum number of 3G (external) cells at the most per BSC: 450
Maximum number of distinct 3G FDD_ARFCN neighboring one 2g cell: 3
MEASUREMENT REPORT message is limited to 6 measurements.
1.8.3 2G to 3G Reselection
2G to 3G reselection in PTM and NC2 in medium radio condition is not
permitted. NC2 2G to 3G reselection is allowed in good coverage conditions.
2G to 3G/TDSCDMA cell reselection is available and optional, lockable
at the OMC-R.
The parameters EN_2G_TO_3GTDD_CELL_RESELECTION and
EN_2G_TO_3G_CELL_RESELECTION cannot be enabled at the same time.
58 / 304 3BK 21222 AAAA TQZZA Ed.08

1 Introduction
1.8.4 GAN System

GANs extends the radio coverage of 2G and 3G networks by allowing adapted
dual mode (GSM/UMTS and GAN) mobiles to be connected to a 2G or 3G
MSC through an unlicensed radio access (WIFI, Bluetooth).
GANC (GAN Controller) is connected to a legacy GSM/GPRS Core Network.
In the GSM system, the GANC system interoperates with the 2G, through
pseudo GAN cells.
Each pseudo GAN cell allows the handover between the 2G to GANC (in charge
of the real GAN system). A pseudo GAN cell must be adjacent to the 2G cell.
The MS decides when it is relevant to perform a handover and then the BSS
executes the handover.
There are no requirements on the packet side.
Handover from a GAN cell to 2G has no impact on the BSS:
Incoming External from GSM or from GAN
The counters related to incoming external handovers take into account
handovers coming from GAN and from GSM. No specific counters are
provided for incoming handover from GAN.
Outgoing External to GSM or to GAN

The counters related to outgoing external handovers take into account
handovers to GAN in the same way as for GSM handovers. No specific
counters are provided for outgoing handover to GAN.
1.8.5 Number of BCCH Frequencies

The max number of BCCH frequencies for the set of all target cells must be
controlled as follow:
Serving cell is:
Non-Evolium cell
For Reselection adjacencies, if the neighbourhood of the serving cell is:
2G only
There are up to 32 different BCCH 2G frequencies for the set of all
target cells
Mixed 2G and 3G
target cells
Evolium cell
For reselection adjacencies
If the neighbourhood of the serving cell is:
2G only
target cells
Mixed 2G and 3G
target cells
For handover adjacencies
3BK 21222 AAAA TQZZA Ed.08 59 / 304

1 Introduction
If the neighbourhood of the serving cell is:

2G only
target cells
Mixed 2G and 3G
target cells.
60 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2 GPRS in the BSS
This section provides an introduction to GPRS and describes:
Packet Switching
GPRS Elements
GPRS Channels and Interfaces

GPRS Network Functions
GPRS Data Transmission.
3BK 21222 AAAA TQZZA Ed.08 61 / 304

2 GPRS in the BSS
2.1 Overview
The success of GSM runs parallel to the explosion of interest in the Internet
and related data services. Presently, data transmission over the Air Interface
is limited to 9.6 kb/s, too slow for use of graphic-intensive services such
as the World Wide Web and personal video conferences. In addition, the
circuit-switched method used for data transmission makes inefficient use of
radio resources, which are under increasing pressure from the growth in
GSM subscribers and use.
The solution chosen by the ETSI for the double challenge of increased demand
for data service and pressure on radio resources is called General Packet
Radio Service (GPRS). The ETSI recommendations establish a standard for
inserting an alternative transmission method for data in the PLMN (packet
switching instead of circuit switching).
The Alcatel-Lucent GPRS solution follows the ETSI GSM phase 2+
recommendations closely.
2.1.1 Packet Switching

In circuit switching, a connection is established and maintained during the entire
length of the exchange, whether data is being transmitted or not. Resources
are dedicated to a single end-to-end connection, and a radio channel in a cell,
with its associated transmission channels, may be unavailable for use even
when little or no information is passing across it at a given moment.
In packet-switched systems, data is transmitted over virtual circuits, which exist
only while data is actively being transmitted over them. This means that during
idle time, timeslots can be used for carrying other data.
Packet-switching systems operate according to the following general
procedures:
1. The PAD function disassembles data into "packets" of a predefined size.
2. The PAD encloses the packets in a data envelope (headers and footers).
This data envelope includes information about origin and destination points,
and the order in which the packet’s contents are to be reassembled at the
destination. The figure below shows a model of a GPRS Packet Data
Unit at the LLC layer.
3. Packets move from origin to destination point by different routes and can
arrive at the destination in a different order than that in which they were sent.
62 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
4. At the destination, another PAD reads the envelope information, strips it off,
and reassembles the data in the proper order.
Header DATA Footer
Address Control
Field Field Information Field FCS
ENVELOPE
Address Field Contains: Control Field − 4 possible types:

Protocol discriminator Confirmed information transfer
Command/response SAPI Supervisory functions
(mobility management, Unconfirmed information transfer
QoS, SMS) Control functions
FCS : Frame Check Sequence
SAPI : Service Access Point Indicator
Figure 6: Model LLC Packet Data Unit used in GPRS
Examples of packet-switching protocols include X.25 and Internet Protocol.

Since GPRS is compatible with these widely used protocols, it is suitable for
access to public or custom packet data services, or to the Internet. Mobile
telephones using packet data services must be connected to a portable
computer or an electronic organizer.
2.1.2 GPRS Elements

The different elements shown in the figure below represent a parallel system to
the circuit-switched system used in GSM until now.
To Public Data
Networks
OMC−R
MS
Gb Gb
FRDN
Packet
SGSN Switched GGSN
Traffic
BSS
BTS MFS
GCH BSCGP
Abis
Transcoder Circuit
BTS Ater
BSC Switched
Traffic To PSTN
MSC/
GCH GCH VLR
BSCGP : BSC GPRS Protocol

FRDN : Frame Relay Data Network
GCH : GPRS Channel
Figure 7: The Alcatel-Lucent GPRS Solution in the PLMN
3BK 21222 AAAA TQZZA Ed.08 63 / 304

2 GPRS in the BSS
In the Alcatel-Lucent solution, the MFS with its associated interfaces is the BSS
element. All other components are external to the BSS.
This section describes the following internal and external components:
GPRS mobiles
The Serving GPRS Support Node

The Gateway GPRS Support Node
The Multi-BSS Fast packet Server.
2.1.2.1 GPRS Mobiles

There are three classes of GPRS capable mobile stations: Class A, Class B,
and Class C.
Currently, only Class B and C mobile stations are supported:
Class A
Class A mobile stations can handle circuit-switched voice and GPRS
traffic simultaneously.
Class B
Class B mobile stations can be IMSI attached and GPRS attached at the
same time, but use only one service (circuit switched or packet switched)
at a time.
A GPRS-attached Class B mobile station can initiate an IMSI connection
and suspend its GPRS service in the following cases:
When the user is not engaged in any GPRS data transfer, and either:
A mobile station-originated call is initiated
The mobile station receives a mobile-termination call.
When the user is engaged in a GPRS session (e.g., an Internet session),

and either:
A mobile station-originated call is initiated
The mobile station receives a mobile-termination call.
The mobile station performs a LAU procedure in network mode II or

network mode III.
Class C
Class C mobile stations can be either IMSI-attached or GPRS-attached, but
not both, and can use circuit-switched or GPRS services alternately.
64 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.1.2.2 The Serving GPRS Support Node

The SGSN is a GPRS network entity at the same hierarchical level as the
MSC. It is external to the BSS and communicates with it via Frame Relay
over the Gb Interface. The SGSN is involved in requesting specific network
resources for GPRS traffic. It performs GPRS paging, authentication, and
cipher setting procedures based on the same algorithms, keys and criteria
as in circuit-switched GSM traffic.
When a mobile station wants to access GPRS services, it makes its presence
known to the network by performing a GPRS Attach procedure. This
establishes a logical link between the mobile station and the SGSN. The mobile
station is then available for SMS over GPRS, paging from the SGSN, and
notification of incoming GPRS data.
The SGSN also participates with other network elements in the routing and
relaying of packets from one node to another.
One SGSN can be connected to many MSCs and many MFSs.
2.1.2.3 The Gateway GPRS Support Node

The GGSN is connected to SGSNs via an IP-based backbone. It provides
interworking between the GPRS network and external packet-switched
networks. It is external to the BSS.
When the mobile station sends or receives GPRS data, it activates the Packet
Data Protocol address that it wants to use. This has the effect of making the
mobile station known to the GGSN. User data is transferred transparently from
the mobile station and external data systems by the GGSN using encapsulation
and tunnelling. This allows data packets equipped with GPRS-specific protocol
information to be transferred between the mobile station and GGSN, in turn
reducing the requirement for the GPRS system to interpret external data
protocols.
The GGSN also works with other network elements in the routing and relaying
of packets from one node to another.
2.1.2.4 The Multi-BSS Fast Packet Server

For more information about the MFS, refer to the The Multi-BSS Fast Packet
Server (Section 1.3.4).
3BK 21222 AAAA TQZZA Ed.08 65 / 304

2 GPRS in the BSS
2.2 GPRS Channels and System Information Messages

GPRS traffic uses the same radio resources as circuit-switched traffic, and
is carried on the same type of physical channel. When a physical channel is
allocated to carry packet logical channels (using TDMA frames, as does
circuit-switched traffic), it is called a Packet Data Channel, or PDCH.
2.2.1 Logical Channels

The types of logical channels which can be carried on a PDCH are the:
Packet Traffic Channel

This channel is analogous to a circuit-switched traffic channel, and is
used for user data transmission and its associated signaling. It has two
sub-channels:
Packet Data Traffic Channel which contains the user data traffic
Packet Associated Control Channel (bi-directional) which contains
the signaling information.
If multiple PDTCHs are assigned to one mobile station, the PACCH is always
allocated on one of the PDCHs on which PDTCHs are allocated.
The function of these sub channels is analogous to their circuit-switched
counterparts.
Packet Timing Advance Control Channel.
This bi-directional channel is used for maintaining a continuous timing
advance update mechanism.
2.2.2 Virtual Channels

Packet switching is a mode of operation adapted to transmission of "bursty" data
- that is, data which comes in intense "bursts" separated by periods of inactivity.
The network establishes a connection during the transmission of such a "burst"
of data. If there is no activity on this connection, the connection is taken down.
When the original user needs to send or receive another burst of data, a new
temporary connection is set up. This can be on another channel in the same
cell, or in another cell if the mobile station is in motion. The routing of one burst
of data may be different from the routing of another.
The establishment and disestablishment of temporary connections is
transparent to the user. The user sees an exchange of data that seems to be
a continuous flow, unless the network is over congested. This semblance of
continuous flow is a Virtual Channel.
A virtual channel can be represented as the flow of data between two terminals
during a user session. The user has the impression of a single continuous
connection, but in the network, this is not the case.
A single data transfer, either in the uplink or in the downlink direction, can
pass between the MFS and the mobile station via one or more PDCH. A
PDCH is shared between multiple mobile stations and the network. It contains
asymmetric and independent uplink and downlink channels.
66 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.2.3 System Information Messages

GPRS system information messages, like their GSM counterparts, transmit
information about the cell to the mobile station. GSM BCCH messages, shown
in Table 1 , are also used in GPRS. In addition, GPRS also uses the messages
shown in the following tables.
SI 13 BCCH The SI 13 message is sent on the BCCH and

contains all the necessary information required
for GPRS. It also indicates the presence and
the location of the PBCCH in the serving cell.
The SI 13 message is broadcast only if GPRS
is supported in the cell.
SI 2quater BCCH The SI 2quater message is sent on the BCCH

during 2G to 3G cell reselection and contains
information about:
3G cells
3G measurement parameters
GPRS 3G measurement parameters, when

there is no PBCCH.
3BK 21222 AAAA TQZZA Ed.08 67 / 304

2 GPRS in the BSS
2.3 GPRS Interfaces

This section describes the GPRS interfaces, and in particular, the new
interfaces introduced for GPRS needs. These interfaces link the MFS and
the SGSN, the BTS, and the BSC.
2.3.1 The Gb Interface

The Gb Interface uses frame relay techniques to link the PCU function of the
MFS and the SGSN.
Physically, it can be routed in a variety of ways:
A direct connection between the MFS and the SGSN

Via a public Frame Relay Data Network
Via the MSC
Via the Ater Mux Interface through the Transcoder to the MSC. In this
case, it carries a combination of packet-switched and circuit-switched
traffic and signaling.
Combinations of these methods are also possible. See Figure 7 for the position
of the Gb Interface in the system.
The Gb Interface provides end-to-end signaling between the MFS and the
SGSN, and serves as the BSS-GPRS backbone. Its principal functions are
shown in the following table.
Function Description
Network services Transfer of BSSGP-PDUs between the BSS and

the SGSN
Allocation and load sharing of PDUs among

Virtual Channels
Access to intermediate Frame Relay Data Network
BSS-GPRS Protocol Radio resource information

services
Quality of Service Information
Routing information
Transfer of LLC-PDUs between the BSS and the
SGSN
Suspend and Resume procedures for Class B

mobile stations
68 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.3.2 The BSCGP Interface

The BSCGP Interface provides communication between the BSC and the MFS
(see Figure 7). The BSC GPRS Protocol controls two LAPD connections (for
redundancy) using 64 kb/s timeslots. The BSCGP Interface carrier following
information.
Function Description
Common radio signaling Circuit-switched and packet-switched paging

(MFS to BSC)
Channel Requests from BSC to MFS
Uplink and downlink channel assignment (MFS

to BSC)
GPRS radio resource Allocation/de-allocation of resources (MFS to

management BSC)
Release indication (BSC to MFS)
Load indication: this limits the allocation for GPRS

traffic (BSC to MFS)
Note: The common radio signaling functions of the BSCGP are handled on the GPRS
Signaling Link, which is carried inside the Ater Interface.
3BK 21222 AAAA TQZZA Ed.08 69 / 304

2 GPRS in the BSS
2.3.3 The GCH Interface

The GCH Interface provides a synchronous connection between the MFS and
the BTS, using one to five 16 kb/s timeslots. The GCH links pass transparently
through the BSC (see Figure 7). Its functions are as follows:
Transfer of PDUs between the MFS and the BTS. (Therefore, packet data
is not directly handled by the BSC but passes transparently through it on
the GCH interface.)
Synchronization with the radio interface at GCH link establishment
Correction of clock drifts between Abis and BTS clocks.
The protocol for the GCH Interface uses the two layers described below:
L1-GCH Layer
L1-GCH is the physical layer based on ITU-T recommendations G.703.
The L1-GCH layer uses digital transmission at a rate of 2048 kbit/s with a
frame of 32 x 64 kbit/s timeslots. An L1-GCH channel has a transmission
rate of 16 kbit/s.
L2-GCH Layer
L2-GCH is the data link layer which is an Alcatel-Lucent proprietary
protocol. This layer is in charge of the data transfer of the GCH frames
between the MFS and the BTS.
The L2-GCH layer offers a service of data transport for the RLC/MAC
layers located in the MFS.
Its main functions are:
GCH link establishment and release
Synchronization with the radio interface
RLC/MAC PDUs transfer.
For more information about GSM transmission, refer to Call Set Up (Section 3).
The M-EGCH (Multiplexed-EGCH) link is available. The M-EGCH is a link
established between the MFS and the BTS and is defined per TRX. An
M-EGCH is made up of one to 36 GCHs.
The M-EGCH link of a TRX carries:
TBF traffic when TBFs are established on the PDCHs of the TRX
TBF signaling messages on the TBF PACCH

MFS-BTS control messages
Uplink signaling messages after one-block allocation (in UL two-phase

access).
70 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.3.4 Specific LCS Interfaces

For LCS, the following specific interfaces are used:
SAGI
Supports the exchange of messages between SMLC and the external GPS
server following an Assisted GPS positioning request in the circuit-switched
domain
RRLP(BSCLP)
Supports the exchange of messages between BSC and the SMLC (i.e.,
MFS) in the circuit-switched domain.
2.4 GPRS Network Functions

This section describes various GPRS-specific network functions necessary
for successful packet data transfer. This includes paging, cell reselection,
error checking and re-establishment, as well as radio power control and link
measurement.
2.4.1 MAC and RLC Functions

Since multiple mobile stations can be competing for the same physical
resource(s), an arbitration procedure is necessary. This is provided by the
Medium Access Control (MAC) function.
The MAC function operates between the MFS and the mobile station, and
works in conjunction with the Radio Link Control (RCL) function. RCL defines
the procedures for retransmission of unsuccessfully delivered data blocks (error
correction) and for the disassembly and reassembly of PDUs.
2.4.2 Temporary Block Flow

When PDUs need to be transferred between the MFS and the mobile station,
a temporary point-to-point physical connection is set up to support the
unidirectional transfer of PDUs on one or more PDCHs. This connection is
called a Temporary Block Flow (TBF).
A TBF is maintained only for the duration of the data transfer. The TBF is
allocated radio resources on one or more PDCHs and comprises a number
of RLC/MAC blocks carrying one or more PDUs.
A typical user session, in which data is exchanged bi-directionally, requires
the establishment of one TBF in each direction. The path of each TBF can be
different.
3BK 21222 AAAA TQZZA Ed.08 71 / 304

2 GPRS in the BSS
2.4.3 Mobility Management

The GPRS Mobility Management (GMM) activities related to a GPRS
subscriber are characterized by the following states:
State Description
Idle In idle mode, the subscriber is not attached to the GPRS MM and therefore not known to
the different GMM entities. The GMM context holds no valid location or routing information
for the subscriber.
GMM Ready When the mobile station starts the GPRS attach procedure, the mobile station enters the
GMM Ready state to request access to the network.
GMM When the GMM Ready timer expires or is de-activated by the network, the mobile station
Standby returns to GMM Standby state.
2.4.3.1 Cell Reselection Modes

Network-controlled reselection modes are defined below.
Mode Description
NC0 A GPRS mobile station performs autonomous cell reselection without sending measurement
reports to the network.
NC1 A GPRS mobile station performs autonomous cell reselection. Additionally, when it is in the
GMM Ready state, it periodically sends measurement reports to the network.
NC2 A GPRS mobile station in GMM Ready state does not perform autonomous cell reselection.
When in GMM Ready state, it sends measurement reports to the network that controls
the cell reselection.
NC2 is used only from R’4 MS.
2.4.3.2 Error Checking

Since the integrity of the data transmitted is crucial, packet-switched networks
employ a method of error checking. This confirms that the data received
corresponds exactly to the data transmitted.
In GPRS, an LLC-PDU includes a Frame Check Sequence used to detect errors
in the header and information fields of the PDU (see Figure 6). The Frame
Check Sequence uses the Cyclic Redundancy Check method of error checking.
Most of the mobile stations use non-acknowledged LLC transmission (which
can be incompatible with TCP). Error detection is done at the RLC level. In the
case of cell reselection, the Alcatel-Lucent BSS retransmits the last LLC-PDU if
all its RLC blocks were not acknowledged.
72 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.4.3.3 Mobility Management Process

Mobility Management in GPRS can be accomplished by the combination of
autonomous cell reselection by the mobile station and packet error correction.
The process is as follows:
1. The mobile station performs an autonomous cell reselection. The process is
based on average measurements of received signal strength on the BCCH
frequencies of the serving cell and the neighbor cells as indicated in the
GPRS neighbor cell list. This refers to NC0.
The cell reselection procedure is the same as for circuit-switched traffic,
but based on GPRS reselection parameters that can be configured by
the operator.
If the cell does not have a PBCCH, the mobile station applies existing circuit
switching parameters using the BCCH.
2. Once the mobile station is camped on the new cell, the data transfer is
resumed. If an LLC-PDU has not been correctly received, it is re-emitted.
This process produces a slight overhead on throughput but has the advantage
of greatly simplifying the cell change process.
2.4.3.4 Link Re-establishment

If the mobile station detects a radio link failure, it will re-establish the link with
the SGSN. The BSS transmits the reselection configuration parameters to be
used by the mobile station. Mobile-controlled reselection is equivalent to
circuit-switched call re-establishment. Refer to Call Re-establishment by the
Mobile Station (Section 4.8) for more information.
2.4.3.5 Full Intra-RA LLC-PDU Rerouting

This feature is implemented for a cell handled by another GPU when there is an
absence of information about the target cell to which the mobile station moves.
The BSS links the old and new cells, using the information they have in
common for that mobile station, namely the TLLI and the RAI. Once this link is
set up, the BSS reroutes data from the old cell to the new cell.
The BSS autonomously decides to perform LLC-PDU rerouting on a cell change
when the SGSN does not support the Inter-NSE Rerouting (INR) R4 option. If
the SGSN supports this option, then autonomous rerouting does not occur.
2.4.3.6 NC2 for Mobile Stations in Packet Transfer Mode

To reduce the number of cell reselections, the mobile station in packet transfer
mode does not make autonomous reselections. It sends measurement reports
to the network, therefore NC2 mode is selected.
2.4.4 Enhanced Packet Cell Reselection

In addition to enhanced cell reselection for R97-onwards MS, packet cell
reselection is further improved with the following new features:
Network Assisted Cell Change

Packet SI Status and Packet PSI Status procedures
NC2 Cell ranking with load criteria.
3BK 21222 AAAA TQZZA Ed.08 73 / 304

2 GPRS in the BSS
2.4.4.1 Enhanced Cell Reselections for R97 Onwards Mobile Stations

NC2 mode is activated when the mobile station enters the packet transfer mode
and NC2 mode is de-activated either at the end of the packet transfer mode or
at GMM Ready timer expiry (O&M parameter) This reduces the number of cell
reselections triggered during GPRS sessions. When this feature is activated,
the BSS prevents multi-RAT mobile stations from monitoring 3G cells while
in packet transfer mode. This allows network control of mobile station cell
reselection in packet transfer mode.
NC2 for mobile stations in packet transfer mode is activated by O&M. When
activated, the network controls cell reselection of each mobile station in a
packet data transfer. Each of these mobile stations periodically reports its
measurements to the serving cell and on the six strongest neighbor cells.
This enables the network to decide whether or not an NC cell reselection is
performed and which neighbor cell is the best candidate for reselection.
This feature reduces the number of cell reselections triggered when the mobile
station is in packet transfer mode.
2.4.4.2 Network Assisted Cell Change
Network Assisted Cell Change (NACC) is a one of the new features
implemented to reduce the duration of packet cell reselection. With NACC,
control of cell reselection can be managed by the either the MS or the network,
if NC2 mode is not being used. NC2 has priority over NACC.
NACC takes place in the serving cell and consists of the following independent
procedures:
Cell Change Notification
Cell System Information Distribution.
NACC is enabled/disabled by the EN_NACC parameter.

An MS supports Cell Change Notification (CCN) under the following conditions:
CCN is activated in the (P)SI
The MS is not in Dedicated Mode or Dual Transfer Mode
The MS is in NC0 mode

The MS is in packet transfer mode.
74 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
If the MS fulfills these conditions, when it detects a best new cell, using CCN:
1. The MS informs the BSS it wants to move from serving cell A to target cell B.
2. The BSS sends the required system information for the target cell on the
PACCH.
For a target cell without PBCCH, the SI13, SI1 and SI3 messages contain
the required information. For a target cell with PBCCH, system information
is contained in PSI14, PSI1 and PSI2.
3. The BSS also returns either a Packet Cell Change Continue or a Packet
Cell Change Order message to the MS.
4. If the MS receives a Packet Cell Change Continue message, it switches
to the previously selected target cell B.
If the MS receives a Packet Cell Change Order message, the CCN
procedure is ended and the BSS (in NC2 mode) takes control of cell
reselection using the Cell System Information Distribution procedure.
The Packet Cell Change Order message is sent to the MS when the
MS-selected target cell does not correspond to the target cell selected
by the BSS.
5. Upon receipt of the Packet Cell Change Order message, the MS starts
a timer and sends a Channel_Request message to the network-selected
target cell.
6. When the MS receives a successful response to its Channel_Request
message, along with the necessary system information, the MS switches to
the new target cell.
2.4.4.3 Packet PSI Status and Packet SI Status Messages

The Packet PSI and Packet SI Status feature is implemented to reduce the
amount of time required for GPRS cell reselection. This feature allows an MS to
access a new cell without first receiving the full set of (P)SI messages sent on
the BCCH (for SI messages) or the PBCCH (for PSI messages). The MS only
has to read the information needed for GPRS operations in the target cell.
The necessary GPRS information is contained in the following (P)SI messages:
SI13
SI3
SI1 (for SI, only if present; for PSI only if the PBCCH is hopping)
PSI1
PSI2
After receiving the necessary information, the MS sends the appropriate

status message (PACKET PSI STATUS or PACKET SI STATUS) to the BSS. This
status message tells the BSS what information the MS received in the earlier
(P)SI messages. The BSS then sends the remaining SI messages needed
by the MS on the PACCH if the MS has not returned to the packet idle state.
If the MS has returned to the packet idle state, the MS can read the missing
SI messages itself.
The new EN_PSI_STATUS parameter is used to enable/disable:
Packet SI Status in cells without BCCH

Packet PSI Status in cells with PBCCH.
3BK 21222 AAAA TQZZA Ed.08 75 / 304

2 GPRS in the BSS
2.4.4.4 Cell Ranking with Load Criteria

In NC2, cell ranking with load criteria avoids directing mobile stations towards
high loaded cells. This reduces the possibility of an MS being served with
non-optimum resources or being rejected due to congestion. The following two
parameters control cell ranking with load criteria.
This parameter... Is used to...
EN_NC2_LOAD_RANKING Enable/disable ranking the load of the target cell during NC2 cell ranking.
THR_NC2_LOAD_RANKING Set the threshold above which a cell is considered to be in a PS high

load situation for NC2 cell reselection.
2.4.5 Paging
Paging is the procedure by which the network contacts a mobile station.
The network can co-ordinate circuit-switched and packet-switched paging if
there is a Gs Interface between the MSC and the SGSN. This means that
circuit-switched paging messages can be sent on the channels used for
packet-switched paging messages, and vice-versa. Three modes are defined.
Mode Description
Network Operation Mode 1 Circuit-switched paging messages are sent via the SGSN and MFS.
The circuit-switched paging message for the GPRS-attached mobile
station is sent on the PPCH or CCCH paging channel, or on the PACCH.
This means that the mobile station only needs to monitor one paging
channel. It receives circuit-switched paging messages on the PACCH
when the mobile station is in packet transfer mode.
Network Operation Mode 2 Circuit-switched paging messages are sent via the MSC and BSC, but
not the MFS.
station is sent on the CCCH paging channel. The channel is also
used for packet-switched paging messages. This means that the
mobile station only needs to monitor the PCH. Circuit-switched paging
continues on the PCH even if the mobile station is assigned a PDCH.
Network Operation Mode 3 Circuit-switched paging messages are sent via the MSC and BSC, but
not the MFS.
station is sent on the CCCH paging channel. The packet-switched
paging message is sent on either the PPCH (if allocated) or on the
CCCH paging channel.
Table 2: Network Operation Modes
Packet-switched paging does not use the Local Area for paging, but a GPRS
Routing Area (RA). The RA is smaller, and fewer cells are involved.
76 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
For VGCS, Notification messages are broadcast periodically in the cell, on

NCH, and optionally on FACCH, for ongoing point-to-point calls, to notify the
VGCS mobile station of a new VGCS call being established.
This process is similar to the Paging procedure used for standard calls.
Different notification procedures are applied, depending on the mode of the
mobile station to be notified:
Idle Mode Notification messages are broadcast on the NCH of the

cell for new or ongoing VGCS calls
Group Receive Mode or Group Transmit Mode Notification messages

are broadcast on the FACCH of other ongoing VGCS calls to notify the new
VGCS calls that are being setup in the cell
Dedicated Group Transmit Mode Notification messages are broadcast

on the FACCH of the dedicated TCH allocated to the talker
Dedicated Mode Notification messages are broadcast on the FACCH of
all ongoing point-to-point calls in the cell to notify the new VGCS calls that
are being setup in the cell.
2.4.6 Radio Power Control and Radio Link Measurement

In order to decrease the level of interference in a network, the uplink and
downlink transmissions are constantly measured and a balance is maintained
between transmission power and the actual quality of the link. In GPRS,
power control is implemented in an open loop on the uplink path. This
maintains speech quality in the network and keeps a low bit error rate for
data transmission.
The BSS broadcasts the configuration parameters necessary for the mobile
station. When it first accesses a cell, the mobile station sets its output power as
defined in the system information. It then resets its power output according to
the parameters broadcast, and to an evaluation of the uplink path loss.
3BK 21222 AAAA TQZZA Ed.08 77 / 304

2 GPRS in the BSS
2.5 Resource Management

In order to provide flexibility to the operator in managing the use of resources
by circuit-switched and packet-switched traffic, resources are shared between
the MFS and the BSC. Use of these resources by one system or the other can
be controlled by a variety of parameters to meet operators’ needs. The MFS
and BSC co-ordinate resource management over the BSCGP Interface.
In GPRS, resource management refers principally to the allocation of Packet
Data Channels. PDCHs are dynamically allocated according to criteria that
can be defined by the user.
When a TBF request is made, resources are allocated on one or more PDCH
for the transfer of PDUs. The allocation process takes place as follows:
1. A TBF establishment request is received through a Packet Channel request
for the uplink, or through a downlink LLC-PDU for the downlink.
2. The number of PDCHs is determined by the:
Mobile station multislot class. This is not always known in the uplink case
O&M parameter (MAX_PDCH_PER_TBF). This defines the maximum
number of allocatable PDCHs per TBF.
3. If the requested number of PDCHs is not available, a request to establish a

TBF is sent to the BSC.
4. PDCHs are allocated to the TBF.
78 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.5.1 Timeslot Allocation

GPRS allows bandwidth to be shared between several mobiles. On a radio
timeslot, bandwidth can be shared between up to nine users on the downlink
path and six on the uplink path, or up to 16 GPRS requests within one timeslot.
Circuit-switched data services require at least one timeslot per user.
The radio blocks on each timeslot are equally distributed among the users
assigned to the channel. For example, on the uplink path when coding scheme
2 is used, the minimum raw bit rate per user is 1.9 kbit/s (13.4/7) instead of 13.4
kbit/s. The following table describes the parameters for timeslot allocation.
This parameter: Is used to:
MAX_UL_TBF_SPDCH Define the maximum number of users (between one and six) that share a
PDCH in the uplink direction.
MAX_DL_TBF_SPDCH Define the maximum number of users (between one and nine) that share a
PDCH in the downlink direction.
N_TBF_PER_SPDCH Define the optimum number of shared users per direction and per PDCH. This
ensures a good bit rate as long as the GPRS load is normal.
However, setting the N_TBF_PER_PDCH parameter ensures a compromise

between resource efficiency and quality of service. For example, if
N_TBF_PER_PDCH = 2 and coding scheme 2 is used, the preferred raw bit rate
per user will be 6.7 kbit/s/s (13.4/2). When the number of users on the PDCH
reaches the N_TBF_PER_PDCH value (2), the PDCH is declared "busy" and will
preferably not accept a third user. But if the GPRS load is such that all PDCHs
are busy, the BSS will override the number of users set in N_TBF_PER_PDCH
and increase the number of shared resources to the maximum, using the
MAL_XL_TBF_SPDCH value.
For VGCS, a timeslot configured as a TCH timeslot is considered by the BSC to
be a TCH timeslot reserved for VGCS and normal traffic when it is identified
as TCH/SPDCH. When there are VGCS only timeslots available (configured
but currently free) in the cell, these timeslots are used for VGCS. If there are
no VGCS only timeslots available, the other free VGCS capable timeslots are
used. Otherwise, VGCS calls are handled as normal calls and are managed
using the same timeslot allocation strategy as for standard calls.
3BK 21222 AAAA TQZZA Ed.08 79 / 304

2 GPRS in the BSS
2.5.2 Autonomous Packet Resource Allocation

Autonomous Packet Resource Allocation introduces a new way of sharing radio
resources between the MFS and the BSC. With this feature, the MFS no longer
needs to request radio timeslots from the BSC. Instead, the MFS is always
aware of all the available timeslots. This speeds up PDCH establishment and
decreases the BSC and MFS CPU loads.
Because the MFS is aware of all available timeslots, the choice of the best
allocation to serve the TBFs in the MFS is simplified. The SPDCHs are
ordered by the BSC to ensure consistent circuit-switched and packet-switched
allocation. The BSC ranks the PS TRXs and sends this ranking to the MFS
on the BSCGP interface at cell creation and if the cell is modified during an
O&M operation. The BSC defines the number of SPDCHs allocated to the
MFS by computing the MAX_SPDCH_LIMIT. The resulting SPDCH allocation
is based on the whole BSS load (CS plus PS load), with the PS load being
provided periodically by the MFS. The BSC informs the MFS of the number
of PS timeslots with the highest priority for PS traffic in the Radio Resource
Allocation Indication message.
Autonomous Packet Resource Allocation works as follows:
1. The MFS periodically sends the BSC a Radio Resource Indication
Usage message. This message contains the number of SPDCHs in the
MFS and their use.
2. Upon receipt of this message, the BSC estimates the PS traffic load. Then,
the BSC sends a Radio Resource Allocation Indication message providing
the number of radio resources allocated to the MFS.
3. The MFS updates its SPDCH allocation table. If necessary, the MFS
pre-empts a few SPDCHs in order to release them to the BSC.
4. The MFS sends a new Radio Resource Indication Usage message to
the BSC acknowledging the new SPDCHs and indicating the de-allocated
SPDCHs (if any).
The following table shows the how the Autonomous Packet Resource Allocation
uses a CS/PS resource-sharing concept with radio resources.
A Timeslot Defined as.... Is...
Reserved for PS Reserved for PS traffic only. The number of Reserved for PS timeslots is
defined by the MIN_SPDCH parameter.
Priority for PS Used for either CS or PS traffic, but PS traffic has priority. The number
of Priority for PS timeslots is defined by the MAX_SPDCH_HIGH_LOAD and
MIN_SPDCH parameters.
Priority for CS Used for either CS or PS traffic, but CS traffic has priority. The number of
Priority for CS timeslots available is the difference between the MAX_SPDCH
and MAX_SPDCH_HIGH_LOAD parameters.
Reserved for CS Reserved for CS traffic only. The number of Reserved for CS timeslots is
defined by the MAX_SPDCH parameter.
This feature introduces a new parameter, MAX_SPDCH_LIMIT. It defines the

number of SPDCHs that can be granted by the BSC to the MFS, and replaces
the MAX-SPDCH_DYN parameter.
80 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.5.3 Packet Flow Context

The Packet Flow Context (PFC) provides end-to-end QoS management. It
allows the BSS to differentiate between different types of traffic on the radio
interface, by reading the QoS profiles listed in each PDP context defined by
the subscriber.
A PFC describes the QoS characteristics of ongoing data transmission. The
BSS recognizes three QoS classes:
The streaming class
This class is a real-time stream and enforces jitter constraints. Video
streaming and Push over Cellular (PoC) are typical applications.
The interactive class
This class corresponds mainly to traditional Internet applications like web
browsing.
The background class
This class corresponds to Best Effort services such as e-mail downloading,
SMS and ftp downloading.
When the PFC is activated, the BSS can reject or negotiate the QoS
parameters in order to provide an optimum level of service by:
Favouring conversational and streaming traffic over interactive and

background traffic by reserving resources for these types of traffic
This is particularly useful for subscribers who request a specific quality of
service (QoS) profile for each PDP context, according to their requirements
(for example, contexts associated with e-mail can tolerate lengthy response
times, while other applications such as interactive real-time applications
require a very high level of throughput).
Defining a flow aggregate based on the lifetime of the flows, in order to

determine admission control and QoS based resource allocation in the BSS.
In a basic case of mobile station initiated PDP context , PFC works as follows:
1. The mobile station defines the required QoS parameters and sends an
Activate_PDP_Context_Request or a Modify_PDP_Context_Request
message to the SGSN.
2. The SGSN determines the QoS it wants, based on:
The QoS requested by the mobile station
The subscribed QoS stored in the HLR
Network QoS constraints.
The SGSN then performs internal call admission control and resource
allocation.
3. The SGSN asks the GSGN to create the PDP context.
4. The GSGN performs internal call admission control and can eventually
downgrade the QoS requested by the SGSN.
3BK 21222 AAAA TQZZA Ed.08 81 / 304

2 GPRS in the BSS
5. The SGSN uses the PFC feature to read and, if necessary, manage the
QoS (for example, to downgrade resources when there is a cell change to
a congested cell).
6. The SGSN informs the GSGN of any changes and informs the mobile
station of the PDP context creation or modification, including the final
QoS established in the network.
Note: PFC can only be used if both the BSS and the SGSN support the feature.
For more information about PDP context management, refer to Packet Data
Protocol Context Activation (Section 2.7.2).
2.5.4 Dynamic Abis Allocation

This feature dynamically allocates Abis nibbles among the different TREs used
for PS traffic in a given BTS. That is, the telecom mapping of the Abis nibbles to
the TREs in the BTS is done dynamically. This means that unused Abis nibbles
on one timeslot can be switched to another timeslot as needed. Dynamic Abis
allocation reduces the average number of Abis nibbles used for PS traffic. It
allows a higher average Abis bandwidth per PDCH and increased BSC capacity
in terms of TREs. With dynamic Abis allocation, some BTS configurations do
not need a second Abis link. This feature simplifies the dimensioning of the
Abis interface since TRX-level dimensioning is no longer needed.
Dynamic Abis allocation works with M-EGCH statistical multiplexing (see
M-EGCH Statistical Multiplexing (Section 2.6.3)). As a reminder, a GCH
channel in an M-EGCH link corresponds to a 16k link between the MFS and
the BTS and uses one Abis nibble plus one Ater nibble switched together in
the BSC. When needed for PS traffic, the GCH channel is activated. When
no longer in use, the GCH channel is de-activated. In order to activate GCH
channels at the BTS, TREs must listen to the Abis nibbles to detect the GCH
activation messages. With dynamic Abis allocation, the BSC, when requested
by the MFS, performs Abis-Ater switching / de-switching. Abis-Ater switching
allows the BSC to switch N 16k Abis nibbles to N 16k Ater nibbles (n > 1).
Abis-Ater de-switching does the reverse, i.e., N 16k Ater nibbles are switched
for N 16k Abis nibbles.
In conjunction with dynamic Abis allocation, the process also uses Abis Nibble
Pools (Section 2.5.4.1) and a new Abis Resource Manager (Section 2.5.4.2).
82 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.5.4.1 Abis Nibble Pools

Dynamic Abis allocation uses logical pools of Abis nibbles. An Abis nibble pool
is a set of basic and extra Abis nibbles which can be dynamically allocated
among TREs. The nibbles of a given pool can only be used by a fixed set of
TREs. That is, there is a one-to-one logical association between a pool of Abis
nibbles and a set of TREs. The basic and extra Abis nibbles in the pool are not
shared among TREs in the same way.
The different types of Abis nibbles in a pool are shared as follows:
Extra Abis nibbles are shared at BTS level (e.g., among all TREs of the BTS)
Bonus basic Abis nibbles are also shared at BTS level
Basic Abis nibbles are shared at cell level (among all the TREs of the same
sector in a shared cell). Note that in a cell shared over two BTS, only
one BTS sector supports PS traffic.
To build Abis nibble pools, each basic Abis nibble is statically mapped on an
Abis timeslot. There are two 64k Abis timeslots reserved per TRE. This is
important for CS traffic because a TCH always uses the basic Abis nibble that
was initially mapped on its timeslot. For the extra Abis nibbles, a number of 64k
Extra timeslots (EXTS) are defined for each BTS.
2.5.4.2 Abis Resource Manager
The Abis resource manager handles the pools of basic and extra Abis nibbles
associated with a given BTS. There is one Abis resource manager per BTS.
The manager acts upon requested received from a higher-level transmission
resource manager at GCH level. The Abis resource manager is located in
the MFS since the MFS must manage the Abis nibbles in order to manage
pre-emption due to CS traffic. Because there is a manager for each BTS, the
Abis resource manager for a given BTS is located on one unique GPU in the
MFS. Abis nibbles are allocated to a TRE using the GSL-RSL interfaces. Abis
nibbles are identified in the BSS by a physical identifier. The Abis resource
manager must be able to address an Abis nibble at both the BSC and BTS
sides. A physical identifier for the nibble means that no BSC Abis nibble
id-to-BTS Abis nibble id conversion is necessary. This avoids complexity and
BSC load-related problems.
3BK 21222 AAAA TQZZA Ed.08 83 / 304

2 GPRS in the BSS
2.5.4.3 Abis Nibble Pool Management

The Abis resource manager uses the following input messages to manage
the Abis nibble pools:
Cell State Response / Cell State Change messages (the contents of the two
messages are the same)
Extra Abis Pool Configuration messages, indicating the list of extra Abis
timeslots available for PS traffic in a BTS
RR Allocation Indication messages, indicating which radio timeslots are

available for PS traffic (i.e., which radio timeslots whose basic Abis nibbles
can be used / can no longer be used for PS traffic)
Cell Deletion messages.
Depending on the message and its contents, the Abis resource manager
acts as described below.
For a Cell State Change message:
When a PS capable TRE is removed, the corresponding basic Abis nibbles

are immediately removed from the Abis pool. The Abis resource manager
triggers the release of the current GCHs of the TRE and the release of the
GCHs currently using the basic Abis nibbles initially mapped to the TRE (if
any). All the basic nibbles associated with the TRE are de-allocated from
the TREs using them. The Abis and Ater nibbles of the concerned GCHs
are then de-switched in the BSC.
When a PS capable TRE is added, the resource manager does nothing.
If the basic Abis nibble-to-timeslot mapping for a TRE has changed, the old
basic Abis nibbles are immediately removed from the pool. The manager
triggers the release of the current GCHs of the TRE and of the GCHs
currently using the old basic Abis nibbles of the TRE (if any). The Abis and
Ater nibbles of the impacted GCHs are then de-switched in the BSC.
If some basic Abis nibbles used for the BCCH or the static SDCCH are no
longer present in the Cell State Change message, the corresponding
basic Abis nibbles are immediately removed from the Abis pool. The
corresponding GCH links (if any) are released.
If there are new basic Abis nibbles available for PS traffic due to BCCH /
static SDCCH channels in the Cell State Change message, these basic
nibbles are added to the Abis nibble pool.
84 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
Upon receipt of an Extra Abis Pool Configuration message, the resource

manager:
Deletes from the Abis pool any EXTSs indicated as removed from the list of
available EXTSs. The corresponding GCHs are released and the Abis and
Ater nibbles are then de-switched in the BSC.
Adds new EXTSs to the Abis pool. From that moment on, the new EXTSs
are available to any M-EGCH in the BTS.
Upon receipt of an RR Allocation Indication message, the Abis resource

manager:
Pre-empts any basic Abis nibbles whose timeslots are no longer available
for PS traffic. The corresponding GCHs (if any) are released and Abis-Ater
de-switching is done in the BSC.
Adds any basic Abis nibbles whose timeslots are newly available for PS
traffic to the Abis pool.
When a Cell Deletion message is received by the MFS, the Abis resource
manager immediately removes all the basic nibbles of the cell (TREs BCCH,
static SDCCH) from the pool. All the GCHs using these nibbles are released
(but they can be used in another cell). Then Abis-Ater de-switching is done in
the BSC.
2.5.5 Enhanced Transmission Resource Management

With the M-EGCH Statistical Multiplexing and the Dynamic Abis Allocation
features, better management of transmission resources (Ater and Abis
nibbles) is possible. This reduces the consumption and waste of transmission
resources. A dedicated transmission resource manager operating at MFS /
GPU level is also added. This resource manager handles both Abis and Ater
resources at the GCH level.
The transmission resource manager is in charge of:
Creating and removing the M-EGCH links
Selecting, adding, removing and redistributing GCHs over the M-EGCH links
Managing transmission resource pre-emptions
Managing Abis and / or Ater congestion states

Optionally, monitoring M-EGCH link use, according to the (M)CS of their
supported TBFs (UL and DL).
2.5.6 Frequency Hopping

Frequency hopping improves the bit error rate and therefore contributes
to overall network quality. Frequency hopping, already provided for
circuit-switched channels, is extended to the packet-switched channels for
GPRS implementation. The BSS sends the hopping law when setting up
a connection. All GPRS channels then use the same hopping law in a
synchronized scheme.
For more information about frequency hopping, refer to Call Set Up (Section 3).
3BK 21222 AAAA TQZZA Ed.08 85 / 304

2 GPRS in the BSS
2.5.7 PCM Link Sharing

Resource allocation is made easier by the use of a shared 2048 kb/s PCM link.
GPRS signaling and traffic channels can be multiplexed with circuit-switched
traffic channels on this link between the MFS and the BSC.
Traffic on the Ater Mux Interface between the MFS and the Transcoder is either
processed by the MFS as GPRS traffic, or passed transparently through the
cross-connect in the MFS to the BSC as circuit-switched traffic.
2.5.8 TBF Resource Re-allocation

Resource re-allocation is enabled using the EN_RES_REALLOCATION parameter.
The feature provides radio and transmission resources for a TBF following an
uplink request received from the mobile station, or following one or more
downlink LLC-PDUs received from the SGSN, when there is no established
TBF for the mobile station. More than one TRX can be allocated to GPRS
services in any given cell. Resource allocation must be prioritized, so priority is
set on PDCH groups. The allocation is granted to the PDCH group with the
highest priority. This avoids PDCH groups in a congested state and PDCH
groups that are dual-rate capable.
The requested throughput is served by the:
Maximum number of slots allowed by the mobile station multislot class
GPRS service constraints (the operator gives the maximum number of

allowed slots for one GPRS connection)
Network constraints (resource availability).
The allocation strategy consists of maximizing the allocated PDCH(s) use and,
if necessary, requesting additional PDCH(s) from the BSC. EGPRS traffic has
priority over GPRS traffic. For example, TRXs with high throughput are used for
EGPRS traffic. Although GPRS throughput is optimized using TRXs with high
throughput, this occurs only when there is no conflict with EGPRS traffic.
86 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
The following table describes the four types of TBF re-allocations.
This type of Is used to...

re-allocation...
T1 Maintain a TBF alive despite a pre-emption.
T2 Re-allocate an ongoing TBF when establishing a concurrent TBF when:
A downlink TBF is established concurrent with an existing uplink TBF, which is

allocated with the maximum number of timeslots supported in the direction of the
bias, re-allocation cannot be given to the mobile station
An uplink TBF is established concurrent with a downlink TBF.
T3 Offer better throughput to ongoing TBFs when:

A TBF cannot be served with the maximum number of PDCHs it supports because:
Of lack of resources at the time of the request
The EGPRS class is used to establish a GPRS TBF, where the GPRS mobile
station class allows a greater number of allocated PDCHs with better PDCH
allocation available to serve the TBF.
"Signaling traffic" becomes "data traffic"
An EGPRS TBF is served on a TRX which offers a higher throughput (i.e., a better
TRX class).
In this case, "Signaling traffic" becomes "data traffic", and an EGPRS TBF is served
on a TRX which offers a higher throughput (i.e., a better TRX class).
T4 Move an uplink GPRS TBF sharing one PDCH with a downlink EGPRS TBF onto
PDCHs which do not support a downlink EGPRS TBF. When one PDCH is shared
between an uplink GPRS TBF and a downlink EGPRS TBF, the downlink EGPRS TBF
is limited to GMSK (i.e., MCS4). Consequently, after a T4 re-allocation the downlink
EGPRS TBF is able to use 8-PSK (i.e., up to MCS9).
T4 re-allocation is not used with dual transfer mode mobile stations.
2.5.9 Dynamic Allocation

When an uplink TBF is established for a mobile station, the network provides to
the mobile station the list of the uplink PDCHs assigned for that TBF and the list
of the USF identifiers of this TBF.
One unique USF is assigned per TBF per assigned PDCH. During the lifetime
of the TBF, the mobile listens to the downlink PDCHs corresponding to
its uplink assigned PDCHs.
On one assigned PDCH, whenever the mobile station detects its USF (note
that in this example, there is only one TBF established per mobile station per
direction, i.e. that there is no “multiple TBF” feature), which means that it is
allowed to transmit on the same uplink PDCH in the next Block Period.
3BK 21222 AAAA TQZZA Ed.08 87 / 304

2 GPRS in the BSS
2.5.10 Extended Dynamic Allocation

The Extended Dynamic Allocation (EDA) is an extension of the basic Dynamic
Allocation (E)GPRS MAC mode to allow higher throughput in uplink for type 1
mobile stations (supporting the feature) through the support of more than two
radio transmission timeslots.
With EDA mode, the mobile station detects an assigned USF value for any
assigned uplink PDCH and allows the mobile station to transmit on that PDCH
and all higher numbered assigned PDCHs.
The mobile station does not need to monitor all the downlink PDCH
corresponding to its uplink PDCH allocated, which allows the type 1 mobile
station to support configurations with more uplink timeslots (and therefore
with less downlink timeslots).
The feature is mainly used only whenever the mobile station relies on its
own resources.
2.6 Traffic Load Management

Traffic load conditions affect PDCH allocation, as described in Congestion
Control (Section 2.6.2).
A PDCH can have one of four possible states, as shown in the following table.
State Explanation
Empty No established TBFs.
Active At least one established TBF and the total number of established TBFs is smaller
than a defined threshold (O&M parameter N_TBF_PER_SPDCH).
Busy The number of established TBFs is greater than or equal to O&M parameter
N_TBF_PER_SPDCH but smaller than the maximum allowed (O&M parameter
MAX_UL/DL_TBF_SPDCH).
Full The number of established TBFs is equal to the maximum set by O&M parameter
MAX_UL/DL_TBF_SPDCH.
2.6.1 Smooth PDCH Traffic Adaption to Cell Load Variation

To avoid wasting GPRS traffic resources when entering a high load situation
(with the ability to allocate GPRS traffic on multiple TRXs, the gap between
MAX_PDCH and MAX_PDCH_HIGH_LOAD can be much bigger than in release B6.2),
the BSC evaluates the total (circuit and packet-switched) traffic per cell and
indicates the number of PDCHs that can be granted for GPRS traffic to the MFS.
The BSC notifies the MFS about any change in the number of available GPRS
resources. Therefore, the GPRS traffic is constantly adapted to the actual
traffic situation in the cell.
The Load_EV_Period_GPRS parameter controls smooth PDCH traffic
adaptation. It calculates the number of load samples (calculated every
TCH_INFO_PERIOD) for the PDCH traffic adaptation load averaging algorithm.
88 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.6.2 Congestion Control

Capacity on demand allows operators to both reserve a number of PDCH for
GPRS traffic and reserve other PDCH for shared traffic, according to the real
traffic load in the cell at any given moment. The actual GPRS traffic load is
dynamically matched by allocating or de-allocating PDCH after negotiation
between the MFS and the BSC.
The BSC is the master in the negotiation process, which means if
circuit-switched traffic is heavy in a cell, there is no guarantee a GPRS mobile
station can establish a call. To ensure GPRS calls are possible at any time,
the MIN_PDCH parameter can be set at the OMC-R to define the number of
PDCH permanently allocated to GPRS in a cell. Using this parameter to set the
minimum number of PDCH allocated to GPRS traffic also sets the maximum
number of radio timeslots allocated to circuit-switched traffic. For GPRS calls, it
is also necessary to get an Ater resource. The function "fast GPRS access" (at
least one PDCH always established in a cell) fulfills this requirement.
2.6.3 M-EGCH Statistical Multiplexing

M-EGCH Statistical Multiplexing provides a means of sharing Ater and Abis
nibbles between the radio timeslots of a TRX. With this feature, transmission
resources left available by a PDCH can be re-used by other PDCHs belonging
to the same TRX. This avoids wasting transmission bandwidth on both the Ater
and Abis interfaces.
The feature reduces the amount of GCH resources used, especially on the Ater.
It multiplexes the blocks of all the PDCHs of a TRX on a single transmission
link, the M-EGCH (Multiplexed-EGCH) link. This link is established between the
MFS and the BTS. M-EGCH links are defined per TRX (instead of as a single
EGCH link per PDCH). This allows the (M)CS variations of the TBFs mapped
on a TRX to compensate each other without requiring more transmission
resources. With M-EGCH statistical multiplexing, in the downlink, the TBF is
selected first and then the PDCH.
For more information about the M-EGCH link, see The GCH Interface (Section
2.3.3).
3BK 21222 AAAA TQZZA Ed.08 89 / 304

2 GPRS in the BSS
2.6.4 GPRS Overload Control

To prevent traffic overload conditions, the SGSN and the BSS constantly
exchange traffic load information. This exchange of information, or flow control,
regulates the downlink traffic between the SGSN and the BSS. The BSS sends
mobile station and BSSGP Virtual Connection radio status information to the
SGSN, which then regulates the output traffic to the BSS when needed.
Flow control is therefore applied at two levels:
Mobile station, and
BVC.
Because more than one Network Service Virtual Connection can be used
between the BSS and the SGSN, the traffic load can be shared and smoothly
distributed over the Gb Interface. During data transfer uplink initialization, a
Network Service Virtual Connection is selected and the uplink bandwidth is
reserved. If a Network Service Virtual Connection is unavailable, traffic is then
put on another Network Service Virtual Connection. The reserved bandwidth
on the Network Service Virtual Connection is released at the end of the transfer.
Load sharing allows different data transfers within the same cell to be carried
by different Network Service Virtual Connection.
90 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.7 Data Transmission

This section describes the GPRS data transmission process, and
explains Attach/Detach procedures, Packet Data Protocol Context
Activation/De-activation, and mobile-originated and mobile-terminated data
transfer.
2.7.1 GPRS Attach

To access GPRS services, the mobile station performs a GPRS Attach or
combined GPRS/IMSI Attach to the SGSN. For more information about the
mobility feature IMSI Attach-Detach, see IMSI Attach-Detach (Section 3.3.5)).
This procedure establishes a logical link between the mobile station and the
SGSN, and allows the mobile station to be available for paging from the SGSN
and notification of incoming GPRS data.
This is shown in the following figure.
MS BTS BSC MFS SGSN HLR
GPRS
Attach
Reque
st
Update
Locati
on
er
nticati
on scrib
Authe Sub ta
Da
Subs
c
Data riber
ACK
ate
Upd ACK
a t i o n
Loc
t
Accep
Attach
GPRS
GPRS
Attach
Comp
lete

MS : Mobile Station
GPRS : General Packet Radio Service
3BK 21222 AAAA TQZZA Ed.08 91 / 304

2 GPRS in the BSS
In the GPRS Attach process:

1. The mobile station sends a GPRS Attach Request to the SGSN.This
request contains:
The mobile station identity (IMSI or P_TMSI)
The mobile station Routing Area Identity

The type of Attach procedure requested (GPRS Attach, or combined
GPRS/IMSI Attach)
The mobile station classmark.
2. The SGSN verifies the mobile station identity, sends a location update to
the HLR, (if the attach requested is a combined GPRS/IMSI Attach, the
MSC/VLR is also updated), and requests a subscriber data profile.
3. The HLR sends a location acknowledgment back to the SGSN with the
subscriber data inserted.
4. The SGSN then assigns a P_TMSI to the mobile station.
5. The mobile station acknowledges the P_TMSI, and the Attach procedure
is complete.
Once the GPRS Attach procedure is performed, the mobile station is in Standby
and can activate Packet Data Protocol contexts.
2.7.2 Packet Data Protocol Context Activation

A Point-To-Point GPRS subscription contains one or more Packet Data Protocol
addresses. Each Packet Data Protocol address is defined by an individual
Packet Data Protocol context in the mobile station, the SGSN, and the GGSN.
Before a mobile station can send or receive data, a Packet Data Protocol context
must be activated. Only the GGSN or a mobile station in Standby or Ready
can activate Packet Data Protocol contexts. The process for mobile-station
originating activation and GGSN-originating activation are described separately.
92 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.7.2.1 Mobile Station-Originating Activation

The following figure illustrates Mobile Station-Originating Activation.
MS BTS BSC MFS SGSN GGSN
Activate
PDP C
ontext
Reque
st
Create
PDP
Contex
t Requ
est
DP
te P
Crea sponse
e
xt R
Conte
t
Accep
ontext
te PDP C
Activa

MS : Mobile Station
PDP : Packet Data Protocol
Figure 8: Mobile Station-Originating Packet Data Protocol Context Activation
For Mobile Station-originating Packet Data Protocol context activation:

1. The mobile station sends an Activation Request to the SGSN.This request
contains:
Transaction Identifier
Packet Data Protocol type
Packet Data Protocol address
Access Point Name
Quality of Service requested

Packet Data Protocol configuration options.
2. The SGSN verifies the mobile station subscriber data, creates a Tunnel
Identifier (TID - a logical bi-directional tunnel between the mobile station and
the GGSN), and sends the new Packet Data Protocol type and address
to the GGSN.
3. The GGSN creates a context, sends an acknowledgment to the SGSN,
which sends an acknowledgment to the mobile station.
4. The GGSN can now send data through the SGSN, and billing begins.
3BK 21222 AAAA TQZZA Ed.08 93 / 304

2 GPRS in the BSS
2.7.2.2 GGSN-Originating Activation

The following figure shows the GGSN Packet Data Protocol context activation
process.
MS BTS BSC MFS SGSN HLR GGSN
Info PDU
ting PDP
Rou est
u
Req
Routin
g Info
ACK
t
eques
tion R
otifica
PDU N
PDU N
vation otificati
xt Acit on Res
Conte ponse
t PDP
Reques
PDP C
ontext
Activati
on

MS : Mobile Station
PDU : Protocol Data Unit
Figure 9: GGSN-Originating Packet Data Protocol Context Activation
For GGSN-originating Packet Data Protocol context activation:

1. When the GGSN receives data, it sends a message to the HLR requesting
the mobile station location.
2. The HLR sends the GGSN location information and the current SGSN IP
address.
3. The GGSN sends a PDU Notification Request to the SGSN, which indicates
that a Packet Data Protocol context needs to be created.
4. The SGSN returns a PDU Notification Response to the GGSN, and sends
a Request Packet Data Protocol Context Activation message to
the mobile station. This message contains the Packet Data Protocol type
and address.
5. The mobile station then begins a Packet Data Protocol context activation
procedure as described above.
94 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.7.3 Data Transfer

When the mobile has data to transfer through the network, data transfers
can be mobile originated or mobile terminated. This section describes each
transfer type.
2.7.3.1 Mobile-Originated Data Transfer
The following figure illustrates the data transfer process when it is mobile
originated.
MS BSS SGSN
Pack
1 et Ch
Requ annel
est
F
L TB
et U t
Pack ignmen
2 Ass
RLC
3 PDU
PDU
RLC ACK
4 K / N
AC
UL L
LC P
DU
5
PDU
RLC ACK
/N
ACK
6
LLC : Logical Link Control

MS : Mobile Station
RLC : Radio Link Control
TBF : Temporary Block Flow
UL : Uplink
When the mobile station has data to send:

1. An Uplink Temporary Block Flow is requested (either on the PRACH, if there
is a master PDCH, or on the RACH).
2. An Uplink Temporary Block Flow is established.
3. Data is sent to the network through the Radio Link Control Protocol Data
Units.
4. RLC PDUs are acknowledged by the network.
5. RLC PDUs are re-assembled into Logical Link Control PDUs and sent
to the SGSN.
6. On receipt of the last RLC PDUs, an acknowledgment is returned and the
Uplink Temporary Block Flow is released.
3BK 21222 AAAA TQZZA Ed.08 95 / 304

2 GPRS in the BSS
2.7.3.2 Mobile-Terminated Data Transfer

The following figure illustrates the data transfer process when it is mobile
terminated, that is, when the network originates the data transfer.
MS BSS SGSN
STAND BY
S 1
ing P
Pag
PCH
H or
PPC
2
Pack
et Ch
Requ annel
3 est
F
L TB
et U t
Pack ignmen
Ass
4 LLC
PDU
UL −
LLC
PDU
READY
PDU 5
LLC
DL −
F
L TB
et D t
Pack ignmen
6 Ass
DL : Downlink
MS : Mobile Station
LLC : Logical Link Control
PCH : Paging Channel
PPCH : Packet Paging Channel
PS : Packet Switched
TBF : Temporary Block Flow
UL : Uplink
When the network has data to send to the mobile:

1. The SGSN receives a downlink Packet Data Protocol PDU for a mobile
station, and sends a paging request to the BSS.
2. The BSS sends packet paging requests to all the cells in the routing area, on
the PPCH if there is a master PDCH in the cell, or on the PCH.
3. The mobile station requests the establishment of an uplink TBF from the
BSS.
4. The uplink TBF is established, which allows the mobile station to send
a Logical Link Control PDU to the SGSN in order to acknowledge the
paging message.
96 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
5. The SGSN sends the data LLC-PDUs to the BSS.

6. The BSS establishes a Downlink TBF on receipt of the first LLC-PDU, and
releases after sending of the last LLC-PDU.
2.7.3.3 Delayed Downlink TBF Release

Delaying the release of downlink TBFs allows enhancement of the data
throughput served to mobile station end users. It also significantly reduces the
GPRS signaling load. GPRS RLC/MAC procedures were designed for non
real-time data transfer where the data arrives as one large block. However,
the true nature of packet traffic is usually different from this assumption. For
example, TCP-based applications often send small packets between peer
entities before the actual data transfer starts. This leads to a high number of
TBF establishments and releases. Consequently, resource use is far from
optimal and transmission delays unnecessarily long. The problem can be
avoided by delaying TBF release for a short period (e.g., 0.5-2s) after the
transmission buffer becomes empty.
Delayed downlink TBF release can occur in either of the following modes:
Acknowledged Mode
When the network wishes to delay the release of the TBF, it sends the last
RLC data block but does not set the Final Block Indicator (FBI) bit. The
network only sets the FBI bit when it wishes to permanently end the TBF.
Once the network has sent the RLC data block containing the last octets of
the most recent LLC frame to the mobile station, the network maintains the
downlink TBF by occasionally sending dummy downlink RLC data blocks to
the mobile station, incrementing the BSN with each dummy data block sent.
When the network receives a new LLC frame, it begins to transmit new RLC
data blocks to the mobile station, beginning with the next available BSN.
When the network wishes to poll the mobile station for a Packet Downlink
Ack/Nack when it has no LLC data to send, the network sends a dummy
downlink RLC data block. The dummy downlink RLC data block is formed by
inserting an LLC Dummy UI Command into a CS1 downlink RLC data block.
The LLC Dummy UI Command is an invalid LLC-PDU and is discarded by
the LLC entity in the mobile station.
Unacknowledged Mode.
In RLC unacknowledged mode, the mobile station detects the end of the
TBF by detecting the Final Block Indicator (FBI) bit set to 1. The mobile
station then transmits a Packet Control Acknowledgement, acknowledging
the end of the TBF. The procedure for delayed release of downlink TBF
in RLC acknowledged mode applies except that no retransmission of
data blocks is done.
3BK 21222 AAAA TQZZA Ed.08 97 / 304

2 GPRS in the BSS
2.7.3.4 Extended Uplink TBF Mode

In normal TBF release, a countdown procedure is used to release the TBF.
Once the countdown is started, PDUs received after the start of the countdown
cannot be transmitted in the current TBF. A new TBF must be requested
and established, causing release and establishment delays. Extended UL
TBF Mode avoids these delays and increase data throughput by extending
the duration of an UL TBF. With Extended UL TBF Mode, the existing TBF is
maintained so data transmission can be quickly restarted without having to
re-establish a new UL TBF even though the countdown has started.
Extended UL TBF Mode allows the network to initiate the sending of data
to the MS without performing a DL TBF establishment on the CCHs. With
this mode, the MS can send data from newly-arrived LLC frames after the
countdown procedure starts. In other words, the MS can restart an existing
countdown procedure when there is new data. In the delayed state, the
network occasionally allocates some radio blocks to the MS to see if the MS
has data to transmit. But if radio resources are requested by the BSC and
this request involves the PDCH carrying the PACCH of the TBF, then T1
allocation is performed. The re-allocated TBF keeps the same mode it had
before the re-allocation.
Extended UL TBF Mode is used whenever allowed by the MS capabilities. If an
MS does not support Extended UL TBF Mode, the BSS uses the normal TBF
release procedure. If the BSS does not know the MS capabilities at UL TBF
establishment, the BSS can switch to the new mode if the MS capabilities are
received before the start of the UL TBF release procedure.
2.7.3.5 TBF Establishment Time Improvement
TBF Establishment Time Improvement reduces the TBF setting duration in
the following ways:
Downlink TBF establishment protocol alignment, reducing downlink TBF

establishment on PACCH by about 160 ms
Immediate uplink TBF establishment to avoid waiting for the establishment

of some GCHs before serving an incoming UL request. An UL TBF is
established immediately if one of the TRXs of the cell already owns n
M-EGCH link
Downlink TBF extension is an enhancement of the delayed downlink TBF

release feature (re-activation of the delayed downlink TBF release when an
uplink TBF is established)
Mobile station context handling (called Handling of mobile station
session/enhanced mobile station context in the System Features
Description) to keep mobile station characteristics as long as possible
Modification of Dummy UI command period when a concurrent uplink TBF is
ongoing (to avoid the 10% throughput waste in case of uplink FTP transfer).
98 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.7.3.6 GPRS Fast Access

The M-EGCH resource guarantees fast access in a cell when combined with the
Immediate uplink TBF establishment feature (described in TBF Establishment
Time Improvement (Section 2.7.3.5)). By implementing both features, the first
uplink TBF establishment in a cell is sped up by 300 to 400 ms.
Initial M-EGCH resource establishment, combined with the Immediate uplink
TBF establishment, optimizes TBF establishment times. Initial M-EGCH
resource establishment guarantees that a first uplink TBF establishment request
in a cell is served immediately. It also guarantees the availability of minimum
resources in a cell and speeds up the first uplink TBF establishment time.
This ensures that a given cell always has at least one established TRX (i.e., a
TRX with an associated M-EGCH link) allowing the "Immediate uplink TBF
establishment" sub-feature to take full advantage of the initial reservation
and perform well in all cases (except congestion). Additionally, with a high
packet-switched load, the blocking probability because of unavailable Ater
resources is reduced.
A flag in the OMC-R is set to guarantee, or not, at least one established Slave
PDCH in a given cell, usable for GPRS and EGPRS traffic.
The user chooses the best compromise between short access times and
resource consumption. Typically, a user reserves terrestrial resources for dense
urban cells, where there is often GPRS traffic, in order to minimize access
times. In rural areas, the user can chose to optimize the Ater consumption and
not reserve any terrestrial resources.
When disabled, no M-EGCH link is established by anticipation for a TRX of
the cell. M-EGCH link establishment is done as soon as a TBF needs to be
established. The Immediate uplink TBF establishment does not show its
best performance.
When enabled, one TRX is established (i.e., one TRX of the cell has an
associated M-EGCH link) even without GPRS traffic. The number of GCHs
to be established is indicated by N_GCH_FAST_PS_ACCESS. The need for TRX
establishment is evaluated at cell start, when EN_FAST_INITIAL_GPRS_ACCESS
is set from disabled to enabled. Accordingly, a TRX is then established or not.
A periodic background mechanism verifies every T_CANDIDATE_TBF_REALLOC
seconds that at least one TRX is established in the cell.
The EN_FAST_INITIAL_GPRS_ACCESS parameter is set according to overall
system dimensioning. These initial resources are statically established and
cannot be pre-empted for packing switching needs (intra-cell or inter-cell
GCH pre-emption).
Note that for G2 DRFU BTS, a slave PDCH is established for GPRS fast
access, since M-EGCH statistical multiplexing is not supported in DRFU BTS.
3BK 21222 AAAA TQZZA Ed.08 99 / 304

2 GPRS in the BSS
2.7.3.7 GSM-to-UMTS Cell Reselection

The three 3G-neighbor frequencies are set at cell level, enabling network
operators to declare different 3G neighborhoods per GSM cell. The Packet
System Information is updated in order to lighten mobile station processing,
and de-activates 3G measurements when the mobile station switches from
PBCCH to circuit-switched dedicated mode. A new feature, Improved 3G Cell
Reselection is implemented to further reduce MS processing time.
This feature contains the following improvements for broadcasting 3G FDD
neighboring cell information:
3G neighboring cell information broadcast in the SI2quarter message

Sending this information in an SI2quarter message allows the MS to receive
and refresh its knowledge of 3G neighboring cells more quickly. SI2quarter
messages are sent on the Extended BCCH, if enabled. Otherwise they are
sent on the BCCH.
3G neighboring cell information instantiated at GSM cell level

This improves 3G cell detection by the MS as only frequencies which are
really covered are broadcast. In addition to the 3G search parameters,
instantiation includes the 3G local cell ID.
Complete 3G neighboring cell description broadcast

When enabled, the cell description includes the Primary Scrambling codes
and the diversity parameter of the neighboring 3G cells, in addition to the
UTRAN frequencies. The operator can define the 3G cell so that when a
scrambling code is changed in that 3G cell, the code is also changed in all
servicing cells with an adjacent link to the 3G cell.
UTRAN frequencies instantiated at BSS level

To enable operators to keep their existing 3G cell planning, the UTRAN
frequencies can be instantiated at the BSS level instead of at cell level.
However, only one instantiation level is allowed. Therefore, the operator
must choose either BSS level or cell level.
Alcatel-Lucent BTS support these improvements.

The 3G search de-activation ensures that no 2G-to-3G cell reselection is
triggered when the mobile station is in Packet Transfer mode.
If NC2 or NC0 is activated, the mobile station cannot perform a cell reselection
towards 3G or measure 3G signal strength during the transfer. The mobile
station stops receiving the declared 3G frequencies as soon as it receives the
Packet Measurement Order message, ceasing the search for 3G cells when
in Packet Transfer mode.
100 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.7.3.8 MAC Algorithm

The following rules apply for MAC algorithm scheduling:
TBFs are ordered in queues
The TBF is selected, then a PDCH for this TBF
TBF round robin and PDCH round robin per TBF
Each time a TBF gets a block/USF scheduled on a PDCH, it is moved

at the end of the queue
A TBF which cannot get a block/USF scheduled remains at the same

position in the queue
RT TBFs are scheduled according to their credit, then NRT TBFs are
scheduled
Credit management for RT TBFs (decrease, reset)

Extra scheduling of RT TBFs
TDM mode: scheduling of TBFs according to available MEGCH capacity

(both in DL and in UL)
T_MAX_FOR_TBF_SCHEDULING timer in RLC

The weight, a parameter to control scheduling of NRT TBFs: no more
absolute scheduling of NRT TBFs
Reduce the number of TBF queues in MAC 5 queues instead of 16 queues

for QoS (P0 to P15)
P0 for PNCD/PSCD messages
P1 for GMM signalling
P2: not used
RT (GBR traffic): note that this is not really real time traffic as there is no
constraint on the transfer delay to the mobile
NRT TBF: all NRT TBS in the same queue whatever the priority P4 to P15
Extra scheduling now applies to NRT TBFs also (with a small change in
RT TBF extra scheduling)
DL and UL TBFs are put in the same queue: no more separate scheduling
processes for the DL, then the UL TBFs
3BK 21222 AAAA TQZZA Ed.08 101 / 304

2 GPRS in the BSS
GPRS faulty management: no DL Dummy TBF created for UL GPRS TBF

The following rules now apply during the TBFs scheduling in each RT and
NRT queue:
A DL EGPRS block (whatever the MCS) can be scheduled on a PDCH if
and only if there is no UL GPRS USF already scheduled or reserved
block on this PDCH in this 20 ms period
An UL GPRS USF can be scheduled on a PDCH if and only if no DL
EGPRS block is scheduled on this PDCH in this 20 ms period
A PDDCB can be sent on a PDCH with an UL GPRS USF but no useful
DL CS block.
The main principles of MAC algorithm are as follows:
For any DL or UL TBF, RT or NRT TBF, there are 2 scheduling phases:

The basic scheduling for which the credit or weight of the TBF must be
greater or equal to the basic_scheduling_limit (current assumption =1)
The extra scheduling for TBFs which credit or weight can be below the
basic_scheduling_limit
This leads to 4 scheduling phases for TBFs:

RT basic scheduling
NRT basic scheduling
RT extra scheduling credit of RT TBF is decreased by 1 when scheduled
in this phase
NRT extra scheduling
A basic scheduling phase stops:

Either when all resources (radio & transmission) are consumed
Or when all the RT (resp. NRT) TBFs have a credit (resp. weight) <
scheduling_limit
Or when no RT (resp. NRT) TBF is schedulable anymore (e.g their
(M)CS is higher than the available transmission resources)
The scheduling of P0 to P2 TBF is not restricted by any credit nor weight

(i.e still absolute).
The following principles concerning the enhanced PDDCB solution apply:
All NRT UL and NRT DL TBFs are managed in the same TBF queue, which
leads to the TBF round robin applied between DL TBF and UL TBF
All the RT UL and RT DL TBFs are managed in another common TBF queue
No need to insert virtual dummy DL TBF for the UL GPRS TBF.
102 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
Weight management for NRT TBF:

The current_weight is initialized to the init_weight when the TBF is activated
(or re-activated)
The current_weight is decreased by 1 each time the corresponding TBF

is scheduled on one PDCH, unless the current_weight has reached the
minimum limit
The current_weight is set to null when an UL NRT TBF enters the extended
mode or when a DL TBF enters the delayed mode
Reset of current_weight" means the following:current_weight = MIN

(current_weight + init_weight, maximum_credit_weight)
Reset of DL NRT TBFs and UL NRT TBFs weights performed independently:

reset of DL current_weights is performed when all the conditions are
verified for DL NRT TBFs, even if the conditions are not satisfied for UL
NRT TBFs; and vice versa
Reset conditions are checked at the beginning of every 20 ms period (e.g to

take into account the status change of a NRT TBF that may occur after the
scheduling in the previous block period).
2.7.4 Packet Data Protocol Context De-activation

Before a GPRS Detach procedure can be initiated, the Packet Data Protocol
context must be de-activated. The de-activation can be done by the mobile
station or by the network.
3BK 21222 AAAA TQZZA Ed.08 103 / 304

2 GPRS in the BSS
2.7.4.1 Mobile-Originating De-activation

The following figure illustrates this process.
1
De−Ac
tivate
PDP C
ontext
Reque
st
Delete
2 Con PDP
text R
eques
t
3 P
te PD
4 Dele esponse
x t R
Conte
t
xt Accep
Conte
tivate PDP
De−Ac

MS : Mobile Station
Figure 10: Mobile-Originating Packet Data Protocol Context De-activation
For Mobile-originating Packet Data Protocol context de-activation:

1. The mobile station sends a De-activate Packet Data Protocol Context
Request to the SGSN.
2. The SGSN sends a Delete Packet Data Protocol Context Request to the
GGSN, which contains the TID.
3. The GGSN deletes the Packet Data Protocol context, and sends a Delete
Packet Data Protocol Context Response with the de-activated TID to the
SGSN.
4. The SGSN sends a De-activate Packet Data Protocol Context
Accept message to the mobile station, confirming the de-activation.
104 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.7.4.2 SGSN-Originating De-activation

The following figure shows the network-originated Packet Data Protocol context
de-activation processes.
Delete
PDP
1 Conte
xt Req
SGSN−Originating uest
2
DP
te P
Dele sponse
t R e
x
Conte
3
quest
text Re
te PD P Con
De− Activa
4
De−Ac
tivate
PDP C
ontext
Accep
t
GGSN−Originating 1
DP
te P
Dele equest
x t R
te
Con
2
st
Reque
ontext
PDP C
tivate
De−Ac
3
De−Ac
tivate
PDP C
ontext
Accep
t
4 Delete
Conte PDP
xt Res
ponse

MS : Mobile Station
Figure 11: Network-Originating Packet Data Protocol Context De-activation Processes
3BK 21222 AAAA TQZZA Ed.08 105 / 304

2 GPRS in the BSS
For network-originated Packet Data Protocol context de-activation processes:

1. The SGSN sends a Delete Packet Data Protocol Context Request to the
GGSN, which contains the TID.
2. The GGSN de-activates the Packet Data Protocol context and sends a
Delete Packet Data Protocol Context Response to the SGSN.
3. The SGSN sends a De-activate Packet Data Protocol Context Request to
the mobile station.
4. The mobile station de-activates the context, and returns a De-activate
Packet Data Protocol Context Accept.
2.7.4.3 GGSN-Originating De-activation
For GGSN-originating de-activation:
1. The GGSN sends a Delete Packet Data Protocol Context request to the
SGSN, which contains the TID.
2. The SGSN sends a De-activate Packet Data Protocol Context Request to
the mobile station.
3. The mobile station de-activates the context and returns a De-activate
Packet Data Protocol Context Accept.
4. The SGSN sends a Delete Packet Data Protocol Context Response to the
GGSN, which deletes the context.
Figure 11 shows this process.
106 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.7.5 GPRS Suspend

The following figure shows the GPRS suspend processes.
MS BTS BSC MFS SGSN
1
RR Su
spend
2
Susp
end
3
Susp
end
T3 4
nd Ack
Suspe
nd Ack
Suspe
5

For the GPRS Suspend process:

1. The mobile station sends an RR Suspend (TLLI, RAI, suspension cause)
message to the BSC. This is sent as soon as possible after entering the
dedicated mode. If the GPRS suspension procedure was initiated during a
GPRS transfer, the mobile station releases all its GPRS resources.
2. The BSC sends a Suspend (TLLI, RAI, suspension cause) message to the
MFS, via the GSL link. The BSC stores TLLI and RAI in order to be able
to request the SGSN (via the MFS) to resume GPRS services when the
mobile station leaves dedicated mode. A timer is not necessary to monitor
the Suspend Ack reception. If this acknowledgment is not received (i.e., no
Suspend Reference Number (SRN) reception, see step 4), the Resume will
not be sent at circuit-switched call completion.
3. The MFS sends a Suspend (TLLI, RAI) message to the SGSN.
4. The MFS receives aSuspend Ack from the SGSN, in which there is a
Suspend Reference Number which is used in the GPRS resume process.
The acknowledgment of the SGSN is supervised by a timer (T3).
5. The MFS sends a suspend acknowledgment to the BSC, with the Suspend
Reference Number information.
3BK 21222 AAAA TQZZA Ed.08 107 / 304

2 GPRS in the BSS
2.7.6 GPRS Resume

The following figures shows the GPRS resume processes.
MS BTS BSC MFS SGSN
1
Resu
me
2
Resu
me
T_GPRS_Resume T4
ck
me A
3 Resu
4
ck
me A
Resu
5
ase
annel Rele
RR Ch

MS : Mobile Station
RR : Radio Resource
For the GPRS Resume process:

1. The BSC determines that the circuit-switched radio channel must be
released (typically upon circuit-switched call completion). If the BSC is able
to request the SGSN to resume GPRS services (i.e., the suspend procedure
succeeded and the BSC received the Suspend Reference Number, and
no external handover has occurred), the BSC sends a Resume (TLLI, RAI,
Suspend Reference Number) message to the MFS. After sending the
Resume message, the BSC starts a guard timer (T_GPRS_Resume) and
waits for a Resume Ack message from the MFS. The guard timer is set as
short as possible, so as to be compatible with the usual RR connection
release procedure, and therefore not delay the procedure. However, this
message is not sent in the case of successful completion of an external
handover. In this case, the BSC deletes any stored data or suspend/resume
context related to that mobile station.
2. On receipt of a Resume message from the BSC, the MFS sends a Resume
(TLLI, RAI, Suspend Reference Number) message to the SGSN, starts a
guard timer (T4) and waits for a Resume Ack message from the SGSN.
3. The MFS receives a Resume Ack from the SGSN.
108 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
4. On receipt of the Resume Ack from the SGSN, the MFS stops the guard
timer (T4) and sends a Resume Ack message to the BSC. If no Resume
Ack is received from the SGSN before expiry of the guard timer (T4), the
MFS sends a Resume Nack to the BSC. On receipt of the Resume Ack or
Resume Nack message from the MFS, the BSC stops the guard timer
(T_GPRS_Resume).
5. The BSC sends an RR Channel Release (GPRS Resumption) message
to the mobile station and deletes its suspend/resume context. GPRS
Resumption indicates whether the BSS has successfully requested the
SGSN to resume GPRS services for the mobile station, (i.e., whether the
Resume Ack was received in the BSS before the RR Channel Release
message was transmitted). The mobile station then exits dedicated mode.
If the guard timer expired, or if a Resume Nack message was received by
the BSC, the Channel Release message includes the GPRS Resumption
indication equal to NOK.
6. The mobile station resumes GPRS services by sending a Routing Area
Update Request message in the following cases:
Reception of a Channel Release with GPRS Resumption = NOK
Reception of a Channel Release without GPRS Resumption IE

T3240 expiry.
2.7.7 GPRS Detach

After the Packet Data Protocol Context is de-activated, the mobile station or the
network can perform a GPRS Detach procedure.
Whether the detach is initiated by the mobile station or the network, the results
are the same:
The mobile station leaves the Ready mode and enters the Idle mode
All Packet Data Protocol contexts are deleted
The mobile station returns to the circuit-switched system.
3BK 21222 AAAA TQZZA Ed.08 109 / 304

2 GPRS in the BSS
2.7.7.1 Mobile Station-Originating Detach

The following figure illustrates this process.
1
Detac
h Req
uest
2 Delete
Conte PDP
xt Req
uest
3 P
te PD
Dele esponse
R
text
4 Con
hA ccept
Detac
GPRS

MS : Mobile Station
For the Mobile-originating GPRS Detach processes:

1. The mobile station sends a GPRS Detach Request to the SGSN. This
message contains:
The type of Detach (GPRS or GPRS/IMSI)
An indication if the Detach is due to a mobile station switch off.
2. The SGSN tells the GGSN to de-activate the Packet Data Protocol context.
3. The GGSN responds to the SGSN with a message that it has de-activated
the Packet Data Protocol context.
4. The SGSN sends a Detach Accept message to the mobile station.
110 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.7.7.2 Network-Originating Detach

The following figure shows the Network-originating GPRS Detach procedures.
MS BTS BSC MFS SGSN GGSN HLR
n
o catio
cel L
Can
1 Delete
2 PDP
Conte
xt Req
uest
uest
h Req
Detac 3
GPRS
DP
te P
Dele sponse
t R e
x
Conte
4
Detac
h Acce
pt
2
Cance
l Loca
tion AC
K

MS : Mobile Station
A GPRS Detach can be initiated by both the SGSN and the HLR.
An SGSN Detach is the most common network Detach.
In this procedure:
1. The SGSN sends a Detach Request to the mobile station, which contains
the Detach type. The Detach type tells the mobile station if it needs to
re-attach and re-activate the Packet Data Protocol context previously used.
2. The SGSN tells the GGSN to de-activate the Packet Data Protocol contexts.
3. The GGSN responds to the SGSN with a message that it has de-activated
the Packet Data Protocol context.
4. The mobile station sends the Detach Accept message to the SGSN.
If the Detach is requested by the HLR:
1. The HLR sends a Cancel Location message to the SGSN, which initiates
the above process.
2. The SGSN confirms the Packet Data Protocol context deletion by sending a
Cancel Location Acknowledgment to the HLR.
3BK 21222 AAAA TQZZA Ed.08 111 / 304

2 GPRS in the BSS
2.8 Location Services

2.8.1 Introduction
Location Services (LCS) provide mobile station geographical location (i.e.,
longitude, latitude). LCS is applicable to any target mobile station whether
or not the mobile station supports LCS, but with restrictions on positioning
method when LCS or individual positioning methods are not supported by
the mobile station.
LCS clients make requests to the PLMN LCS server for location information
about one or several target MSs with a set of parameters such as LCS Client
Type, LCS Priority, LCS Quality of Service (QoS), which includes requested
position accuracy and allowed response time. LCS clients reside in an entity
(including the mobile station) within the PLMN or in an entity external to the
PLMN. The target mobile station is positioned by the LCS. Depending on the
positioning techniques, some LCS functions reside in the mobile station.
LCS in the packet-switched domain is not supported.
Network Measurements Results (NMR) are not supported with LCS.
112 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.8.2 Logical Architecture

LCS Services support requires new network elements in the network
subsystem and optionally, depending on positioning techniques and network
synchronization, on the radio side.
These network elements are:
Gateway Mobile Location Center (GMLC)
Serving Mobile Location Center (SMLC).
LCS Client
LMU
Type A
BTS
A Interface
GMLC
Lg
BTS BSC MSC Lh
MS
Lb Gs
Interface CBC Interface HLR
Lg
BTS
(LMU Type B)
SMLC SGSN
MFS
Gb Interface
LSN1 LSN2
A−GPS
Router
server
SAGI
As depicted in the above figure:
The GMLC is the first network element for external Location Application
(LA) access in a GSM PLMN. The GMLC requests routing information from
the HLR via the Lh Interface. After performing registration authorization, it
sends positioning requests to the MSC or to the SGSN and receives final
location estimates from the MSC or the SGSN via the Lg Interface
The SMLC is the network element serving the mobile station. The SMLC
manages the overall co-ordination and scheduling of resources required to
perform positioning of a mobile station. It also calculates the final location
estimate and accuracy. The SMLC controls to obtain radio Interface
measurements enabling mobile station location in the service area. The
SMLC is connected to the BSS (via the Lb Interface). It dialogs with other
SMLCs (via the Lp Interface) to obtain measurements managed by another
SMLC when the mobile station is at the border of the SMLC-covered area.
3BK 21222 AAAA TQZZA Ed.08 113 / 304

2 GPRS in the BSS
2.8.3 LCS Positioning Methods

In LCS, the SMLC, a functional network element in the BSS, is integrated in the
MFS and is configured by the OMC-R, if the MFS also provides the GPRS
services to several BSCs. The SMLC performs locations services for this set of
BSCs. Location requests are received on the A Interface from the NSS.
The LCS uses an Alcatel-Lucent proprietary interface, BSCLP, for signaling
protocol between the BSC and the SMLC.
LCS supports the following positioning methods:
TA Positioning
Conventional GPS Positioning
Assisted GPS (A-GPS) Positioning.
2.8.3.1 TA Positioning
TA Positioning delivers Cell ID, Timing Advance, and, optionally, Measurement
Report information to the SMLC. TA Positioning regroups several distinct
methods, depending on the availability and the relevance of the elementary
information:
The Time Advance (TA)
Cell Id (CI), only in omnidirectional cells, the geographic co-ordinates of the

BTS is returned instead of the real mobile station position. The TA value is
used to determine the region as a circle or a ring
Cell Id + Timing Advance (CI+TA).
With the TA positioning method, no signaling exchange is required between the

SMLC and the mobile station. The TA positioning applies to all mobile stations,
whether they support LCS or not.
2.8.3.2 Conventional GPS Positioning

Conventional GPS Positioning is based on the GPS location estimate
performed in the mobile station and provided to the SMLC.
2.8.3.3 Assisted GPS (A-GPS) Positioning

Assisted GPS (A-GPS) Positioning is split into Mobile Station-Assisted A-GPS
and Mobile Station-Based A-GPS positioning methods, depending on where
the location calculation is processed: in the network or in the mobile station.
For Mobile Station-Assisted A-GPS, the mobile station receives GPS Assistance
Data from the SMLC, performs GPS measurements and returns the GPS
measurements to the SMLC. The SMLC provides these GPS measurements to
the external GPS server, which computes the mobile station location estimate.
For Mobile Station-Based A-GPS, the mobile station receives GPS Assistance
Data from the SMLC, performs GPS measurements and location calculation,
and returns its location estimate to the SMLC.
114 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.8.4 LCS Scenario in Circuit-Switched Domain

In the circuit-switched domain, an LCS scenario is as follows:
1. An external LCS Client requests the current location of a target mobile
station.
2. This request is handled by the GMLC, which verifies the LCS Client identity
and authorizations, and determines the MSC of the target mobile station.
3. The MSC receives the location request containing the type of location
information requested (current location, assistance data for the mobile
station), the mobile station subscriber’s IMSI, LCS QoS information
(accuracy, response time). In idle mode, the MSC performs circuit-switched
paging, authentication and ciphering to establish an SDCCH with the mobile
station. The mobile station subscriber is only aware of circuit-switched
paging when a GPRS mobile station in Packet Transfer Mode suspends
GPRS traffic to answer circuit-switched paging.
4. When the mobile station is in dedicated mode (after a specific SDCCH
establishment for location, or during an ongoing call), the MSC sends the
location request to the BSC in the existing SCCP connection for the current
call, which forwards it to the SMLC.
5. The SMLC chooses a positioning method and triggers the appropriate
procedure to locate the mobile station. Some message exchanges take
place between the SMLC and the BSC.
6. The MSC then sends a response to the GMLC. The LCS-related messages
exchanged between the BSC and the MFS are conveyed through current
GSLs (same SAPI as for GPRS-related messages).
2.8.5 Physical Implementation

The GPU software supports both GPRS and SMLC, and is handled as a whole.
For a BSC connected to several GPUs, the SMLC is supported by the pilot
GPU (the pilot GPU is the GPU handling procedures at the BSS level). When
the pilot GPU is reselected, the SMLC function restarts on the new pilot GPU.
The LCS-related configuration data is downloaded from the control station to
the new pilot GPU. The former pilot GPU clears all the LCS-related telecom
contexts as well as the LCS-related configuration data.
3BK 21222 AAAA TQZZA Ed.08 115 / 304

2 GPRS in the BSS
2.8.6 SMLC Functions

The SMLC performs the following functions:
Handles LCS protocols towards the BSC and the mobile station, and
towards the external GPS server
Manages call-related location context per mobile station
Selects a positioning method
Triggers the position calculation process for the TA positioning method and
presents the location estimate of the mobile station in a standard format.
For Conventional GPS or Mobile Station-Based A-GPS, the calculation is
performed in the mobile station
Requests and receives GPS Assistance Data destined for the mobile
station, when Mobile Station-Assisted and Mobile Station-Based A-GPS
Provides GPS measurements performed by the mobile station to the

external GPS server, for Mobile Station Assisted A-GPS, to retrieve the
mobile station location estimate
Uses O&M information present in the MFS or SMLC, provided by the OMC-R
Handles errors.
2.8.7 BSS and Cell Configuration

LCS is an optional feature of the Alcatel-Lucent BSS. It can be blocked by the
manufacturer, and enabled or disabled by the operator at the OMC-R level.
For LCS cell support, the user activates LCS on the BSS handling this cell,
and also activates GPRS for this cell. For example, setting MAX_PDCH to
a value greater than zero is mandatory; the cell is locked for GPRS if the
operator does not want GPRS running on this cell. The user configures the
required transmission resources (Ater and Gb resources) on the GPU(s)
connected to this BSC.
The O&M characteristics of the serving cell are:
Enabled LCS positioning method in the cell
Preferred GPS method when several GPS methods are candidates for the
location procedure
Configuration data availability
SMLC and GPS server interface state.
116 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.8.8 LCS O&M

The OMC-R provides LCS centralized management.
Two alarms are used:
An alarm indicating the concerned LSN.

This alarm’s attributes are:
alarm label: "GPS server not reachable through LSN"
alarm type: communicationsAlarm
probable cause: lan error
perceived severity: minor.
An alarm with the following attributes:

alarm label: "GPS server not reachable"
alarm type: QoS
probable cause: underlying resource unavailable
specific problem: alarmId translation, component translation (identifying
Fabric)
perceived severity: major.
The user correlates this information with the current router state and with
the Ethernet links state between GPUs and hubs.
3BK 21222 AAAA TQZZA Ed.08 117 / 304

2 GPRS in the BSS
2.9 High Speed Data Service

2.9.1 HSDS Description
High Speed Data Service (HSDS) supports CS1 to CS4 in GPRS and supports
EGPRS with MCS1 to MCS9. The coding scheme and the radio modulation
are modified to increase the data traffic throughput of a given radio timeslot,
resulting in an increase of throughput on the Abis and Ater interfaces.
On the Ater Interface, several Ater nibbles are allocated dynamically by MFS
telecom to handle throughput higher than 16kbit/s
On the Abis Interface, a group of 16k nibbles is associated with each radio
timeslot. Depending on the coding scheme or the MCS, from one to five 16k
channels are necessary per PDCH between the MFS and the BTS.
The following table explains HSDS terminology.
Term Explanation
M-EGCH Set of n-associated multiplexed 16k channels used to transport PS traffic.

There is one M-EGCH per TRX (and not per PDCH).
GCH Any of the n 16k channels composing an M-EGCH.
Nibble 16k channel.
Basic Abis nibble 16k Abis channel either used for circuit-switched or packet-switched traffic.
Extra Abis nibble 16k Abis channel exclusively used for packet-switched traffic.
PS capable TRX TRX which can be used for packet-switched traffic, at least for GPRS traffic,
characterized by TRX_Pref_Mark = 0.
8-PSK capable TRX TRX which is EGPRS capable and with n > 1. At least two GCHs are
necessary for 8-PSK (MCS5).
TRX class n For a TRX class n, the MFS will use n GCHs to establish one M-EGCH.
TRX EGPRS capability Possibility for the TRX to support EGPRS or not and if it is able to support
EGPRS, its maximum MCS.
Established TRX The corresponding radio and transmission resources are allocated and the
corresponding M-EGCH is activated.
Allocated PDCH The corresponding radio resource is allocated by the BSC, but no associated
Ater resources are allocated.
118 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.9.2 GPRS CS3/CS4 and EGPRS Protocol

2.9.2.1 EGPRS
For HSDS, EGPRS enables data transmission support at a bit rate exceeding
GPRS capabilities and uses new modulation and coding schemes on the Air
Interface. Data throughput is optimized in concordance with radio propagation
conditions (Link Adaptation).
2.9.2.2 Modulation and Coding Schemes

Nine modulation and coding schemes enhance packet data communications
(EGPRS), providing raw RLC data rates ranging from 8.8 kbit/s (minimum value
per timeslot, under the worst radio propagation conditions) up to 59.2 kbit/s
(maximum value achievable per timeslot under the best radio propagation
conditions). Data rates above 17.6 kbit/s require that 8-PSK modulation are
used on the A Interface, instead of GMSK.
Link adaptation changes Modulation and Coding Schemes (MCS) according to
radio conditions. When radio conditions worsen, a protected MCS with more
redundancy is chosen, leading to a lower throughput. Inversely, when radio
conditions improve, a less protected MCS (less redundancy) is chosen for
higher throughput.
The following table describes the three families of coding schemes and their
unit payloads.
This Family... Contains... Payload Unit
Family A MCS3, MCS6 and MCS9 37 bytes
Family A padding MCS3+padding, MCS6+padding and MCS8 34 bytes
Family B MCS2, MCS5 and MCS7 28 bytes
Family C MCS1 and MCS4 22 bytes
When a block is retransmitted with a given MCS, it can be retransmitted (if

needed) via ARQ with a more robust MCS of the same family.
Two selective ARQ mechanisms are used for the transfer of EGPRS RLC data
blocks in the acknowledged RLC/MAC mode:
Type I ARQ mechanism

With this mechanism, when a RLC data block is retransmitted, the same or
another MCS from the same family is selected.
Type II ARQ mechanism (also called Incremental Redundancy (IR)

In this case, a different "puncturing scheme" is applied to the same MCS, if
an error is detected.
IR and re-segmentation are activated on a per cell basis.
Note: Ensure that the two features are not activated at the same time.
Four Coding Schemes are used for GPRS (CS1 to CS4).

GPRS and EGPRS signaling always uses CS1.
3BK 21222 AAAA TQZZA Ed.08 119 / 304

2 GPRS in the BSS
MCS1 to MCS4 are based on GMSK modulation, while MCS5 to MCS9 are
based on 8-PSK modulation. The Alcatel-Lucent BSS supports MCS5-MCS9 in
both the uplink and the downlink direction.
Coding Scheme Modulation Maximum rate [kbps]

per radio timeslot
basis
MCS9 8-PSK 59.2
MCS8 8-PSK 54.4
MCS7 8-PSK 44.8
MCS6 8-PSK 29.6
MCS5 8-PSK 22.4
MCS4 GMSK 17.6
MCS3 GMSK 14.8
MCS2 GMSK 11.2
MCS1 GMSK 8.8
CS4 GMSK 21.55 (UL)

20 (DL)
CS3 GMSK 15.75 (UL)

14.4 (DL)
CS2 GMSK 13.455 (UL)

12 (DL)
CS1 GMSK 9.2 (UL)

8 (DL)
2.9.2.3 Mobile Station Multislot Class Handling

With GPRS/EGPRS, an GPRS/EGPRS mobile station multislot class is
introduced.
The multislot classes 30-33 are considered for GPRS and EGPRS:
PTM (Packet Transfer Mode): 30-33 classes mobile
DTM (Dual Transfer Mode): 31-32 classes mobile. Class 33 terminals are
supported as MS class 32 in DTM mode.
The available throughputs are:

In PTM mode: Up to 5 DL PDCHS instead of 4 (5 + 1 vs 4 + 1)
In DTM mode: Up to 3 DL PDCHs instead of 2 (4 + 2 vs 3 + 2).
120 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.9.2.4 Incremental Redundancy in UL

With EGPRS, performance in terms of maximum user throughput decreases
quickly when the distance between the MS and the antenna increases. This
means that for the end user the quality of service depends on the position
of the MS relative to the antenna. Therefore, it is important to improve the
maximum user throughput under these conditions. By improving the decoding
performances of the BTS with EGPRS, incremental redundancy increase the
maximum user throughput in the uplink, particularly when the MS is far from the
antenna. This is especially useful when the MS is at the border of to cells.
Incremental redundancy uses a type II hybrid ARQ mechanism and is only
used with EPGRS data blocks sent in RLC acknowledge mode, using MCS1 to
MCS9. Incremental redundancy is not used with RLC unacknowledged mode.
Incremental redundancy is based on the reception of RLC data blocks coded
with different puncturing schemes. This lets the BTS enhance the decoding of
the data blocks using soft combining. By taking into account the erroneous
RLC data blocks and combining them with the retransmitted data blocks, the
BTS increases the probability of decoding the blocks correctly. This reduces
the number of times the BTS uses a slower coding scheme compared to
situations where incremental redundancy is not used. As a result, the average
throughput is increased.
The BTS supports incremental redundancy with RLC data blocks transmitted
with the same MCS and with data blocks retransmitted with the following
MCS combinations:
MCS7 / MCS5
MCS9 / MCS6
MCS8 / MCS6 with padding.
Incremental redundancy is enabled / disabled with the Enable_IR_UL

parameter. By default, the feature is disabled.
2.9.3 Transmission Handling

The following sections describe transmission handling.
2.9.3.1 TRX Hardware Configuration Management

The Abis timeslots are connected to the TCUs through the BIUA. The
BTS connects each radio timeslot to one Abis nibble. All the nibbles for
circuit-switched traffic (basic nibbles) for a given TRE are connected to the
same TCU.
The extra 16k nibbles are connected to any TSU TCU carrying the primary
Abis, or any TSU TCU carrying the secondary Abis.
3BK 21222 AAAA TQZZA Ed.08 121 / 304

2 GPRS in the BSS
2.9.3.2 Logical Configuration Management and TRX/RSL Mapping

In standard configurations, TRXs are mapped to TREs using the current
algorithm.
After mapping, the following adjustment occurs:
TREs are classified according to their packet switching capability and Full
Rate/Dual Rate usage, from the highest to the lowest priority: from G4 High
Power Full Rate, G4 High Power Dual Rate, G4 Medium Power Full Rate,
G4 Medium Power Dual Rate, Alcatel-Lucent 9100 Full Rate, and finally
to Alcatel-Lucent 9100 Dual Rate
If PS_Pref_BCCH_TRX = True (i.e., the BCCH TRX has the highest priority for
PS traffic), the TRX with BCCH is mapped to the highest priority TRE
TRXs with TRX_Pref_Mark = 0 are mapped to the TREs with the highest
priority, beginning with the TRXs which have the biggest PDCH-group size.
2.9.3.3 TRX Ranking

The BSC determines the ranking of packet switch capable TRXs for
circuit-switched and packet-switched calls to ensure consistent allocation. By
this ranking, the TRXs selected first by the BSC for circuit-switched calls are
those selected last by the MFS for packet-switched calls.
Packet switch capable TRXs are ranked according to the following criteria, from
the highest to the lowest:
TRX supporting the BCCH, if PS_Pref_BCCH_TRX = True

TRX capability (G4 High Power, then G4 Medium Power, and then
Alcatel-Lucent 9100)
Dual Rate capability (Full Rate TRXs have a higher priority than Dual
Rate TRXs)
The number of radio timeslots available for PS traffic.
Circuit switch only TRXs are not provided to the MFS.
122 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.9.3.4 Connection of Extra Abis Nibbles to TREs in the BTS

Extra Abis nibbles are connected to the BTS TREs as follows, enabling a given
radio timeslot to be connected to n nibbles overall in the BTS:
1. The BSC informs the BTS via the OML of the static mapping of each extra
16k nibble on the Abis to each TRX.
2. The BSC groups extra Abis nibbles so that 8 x (n-1) extra Abis nibbles
are mapped on BTS, on top of the already-mapped basic Abis nibbles
( n = 1 to 5).
3. Extra Abis timeslots are only mapped on a TCU supporting TRE Full Rate.
A Dual Rate TCU does not support extra Abis TS. The same constraint
exists between Full Rate TRE and Dual Rate TRE as between Extra Abis
timeslot and Dual Rate TRE.
4. To perform Full Rate TRE or extra Abis timeslot extension, the operator
triggers a compact reshuffling to group all Dual Rate TRE to free TCU for
Full Rate TRE or extra Abis timeslot.
2.9.3.5 Second Abis Link
When there are insufficient Abis timeslots on one Abis link, a second Abis
can be attached to the BTS.
In this case, the OML, RSL, and basic timeslots are always mapped to the first
link and extra timeslots for the TRX transmission pools are split over the two
Abis links and the second Abis link supports extra 16k nibbles for packet traffic.
This link does not carry circuit-switched traffic and cannot cross-connect on
the secondary Abis.
Only Alcatel-Lucent BTS with SUMA boards or Alcatel-Lucent 9110-E support
the second Abis link. Alcatel-Lucent BTS with SUMP boards must be upgraded.
An Alcatel-Lucent BTS can manage two termination points. It is therefore
impossible to do the following:
Connect a BTS in chain after a BTS with two Abis
Change the Abis from chain to ring if there is a BTS with two Abis
Attach a second Abis to a BTS that is not at the end of an Abis chain
Attach a second Abis to a BTS that is in an Abis ring.
3BK 21222 AAAA TQZZA Ed.08 123 / 304

2 GPRS in the BSS
2.9.3.6 Transmission Power

The three types of transmission power are:
GMSK Output Power

The BTS sets all TRE transmit GMSK output power to the same level, the
minimum value among the maximum TRE output power in a sector and in
a given band.
8-PSK Output Power

For one given TRE, the maximum output power is lower in 8-PSK than
in GMSK because of the 8-PSK modulation envelope which requires a
quasi-linear amplification. The TRE transmit power in 8-PSK does not
exceed the GMSK transmit power in the sector and in the band. In 8-PSK,
the applicable leveling aligns, when necessary, the 8-PSK transmit power to
the GMSK transmit power in the sector and in the band.
Modulation Delta Power.
The Modulation Delta Power is the difference between the GMSK output
power of the sector for the TRE band and the 8-PSK output power of
the TRE.
8-PSK High Power Capability is true if Modulation Delta Power is less than 3
dB, else it is an 8-PSK Medium Power Capability type TRE.
2.9.4 Cell/GPU Mapping Modification

The algorithm which maps the cells on the GPUs takes into account the number
of extra Abis nibbles allocated per TRX. This avoids all cells having static
GCHs, mapped on the same GPU and thus limits the risk of Ater blocking.
The cell/GPU mapping process includes:
A new parameter (Nb_Extra_Abis_TS) per cell to the MFS in order to steer

the cell - GPU mapping. Nb_Extra_Abis_TS is the number of auxiliary 64k
channels in the TRX Transmission pools of the cell
The number of GCHs used by the initial PDCH, when

En_Fast_Initial_GPRS_Access = True
One GCH, if Nb_Extra_Abis_TS = 0
Two GCHs, if Nb_Extra_Abis_TS differs from 0.
After a change of pools configuration, the cell is "misaligned" and the operator
must resynchronize the MFS.
124 / 304 3BK 21222 AAAA TQZZA Ed.08

2 GPRS in the BSS
2.10 Gb over IP
With the introduction of GBoIP, the telecom traffic, towards/from the SGSN,
goes through the router from/in the MFS.
The following rules apply
For an 9130 Evolution MFS:

O&M one LAN:
O&M/Telecom flows are using the same IP interface. This is the default
topology.
O&M/Telecom flows use a different IP interface.
O&M two LAN:
The case of a same IP interface used for O&M/Telecom flows is not
supported.
The case of different IP interfaces used for O&M/Telecom flows is
not recommended.
For an 9135 MFS:

O&M one LAN:
O&M/Telecom flows use the same IP interface. This is the nominal case.
O&M/Telecom flows use a different IP interface.
O&M two LAN:
Not applicable.
3BK 21222 AAAA TQZZA Ed.08 125 / 304

2 GPRS in the BSS
126 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3 Call Set Up
This section provides an overview of how a call is set up between the NSS and
the mobile station. It describes the various kinds of calls that can be set up. It
also describes the type of teleservice and bearer service required.
3BK 21222 AAAA TQZZA Ed.08 127 / 304

3 Call Set Up
3.1 Overview
Call set up is required to establish communication between a mobile station
and the NSS. The NSS is responsible for establishing the connection with the
correspondent. Different types of calls require different teleservices. These
teleservices are defined in the GSM specifications. The type of teleservice
and bearer service to be used is negotiated before the normal assignment
procedure. See Normal Assignment (Section 3.2.3) for more information.
3.1.1 Call Types

The following table shows the three basic types of call.
Type of Call Description
Mobility Management Calls These calls, e.g., location update, are used by
the system to gather mobile station information.
The exchanges are protocol messages only;
therefore, only a signaling channel is used.
Figure 3 illustrates the location update
procedure.
Service Calls These calls, e.g., SMS and SS calls, pass

small amounts of information. Therefore, only
a signaling channel is used.
User Traffic Calls These calls, e.g., speech or data calls to a

correspondent, can pass large amounts of
information. Therefore they require greater
bandwidth than a signaling channel. These
calls use traffic channels.
The channels used for calls are the SDCCH for signaling (static SDCCH), for
traffic and signaling (dynamic SDCCH), and the traffic channel for user traffic
(see The Air Interface (Section 1.7.9) for more information). These channels
are associated with FACCH/SACCH. An SDCCH is always assigned for call set
up, even if a traffic channel is later required for the call.
The role of the BSS in call set up is to assign the correct channel for the
call, and to provide and manage a communications path between the mobile
station and the MSC.
128 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.1.2 Call Set Up Phases

The following table shows the phases involved in call set up.
Phase Composition
Radio and Link Paging (for mobile-terminated calls only) informs the mobile station that it is being
Establishment called.
If attach_detach_allowed is activated, the mobile station IMSI_detach message
can eliminate the need for paging. See IMSI Attach-Detach (Section 3.3.5).
The immediate assignment procedure allocates a resource to the mobile station
and establishes a Radio Signaling Link between the BSS and the mobile station.
A Interface connection, to assign an SCCP signaling channel between the BSC
and MSC
Assignment of a switching path through the BSC.
Authentication and Classmark handling.

Ciphering
Authentication.
Ciphering.
Normal assignment Teleservice/bearer service negotiation.

Channel allocation.
Physical context procedure.
Traffic channel assignment, if required.
Call connection.
For more information about the phases, refer to:

Mobile-Originated Call (Section 3.2)
Mobile-Terminated Call (Section 3.3).
3BK 21222 AAAA TQZZA Ed.08 129 / 304

3 Call Set Up
3.2 Mobile-Originated Call

A call initiated by a mobile station can either be a subscriber call, where
speech and/or data is passed across the network, or a location update call
from a mobile station in idle mode. Location update information is passed
on the signaling connection. Therefore, the initial call set up procedure is
similar to a subscriber call. The location update does not require allocation
of a traffic channel.
3.2.1 Radio and Link Establishment

When a connection with a mobile station is required, the following must happen:
A radio channel must be assigned to permit communication between the

mobile station and the BSS
A terrestrial link must be established in order to signal the presence of
the mobile station to the network.
The procedure for obtaining these initial connections is called radio and link
establishment.
The radio and link establishment procedure establishes signaling links between:
The BSS and the mobile station via the SDCCH channel
The BSS and the MSC via the SCCP link.
These links pass the information for call negotiation, and set up a traffic
channel, if required.
Figure 12 shows radio and link establishment for a mobile-originated call.
Note: A VGCS call initiated by a mobile station uses the same general call set up
procedures as a standard mobile call; any exceptions are described in the
relevant procedure descriptions below.
3.2.1.1 Channel Request

The mobile station initiates a call by sending a Channel_Request message,
with an REF. The REF includes an establishment cause and a RAND (used for
authentication). It is transmitted on the RACH channel. The RACH channel
is associated with the CCCH channel which the mobile station is monitoring
while in idle mode.
The establishment cause field of the REF specifies:
An emergency call
Call re-establishment
Response to paging
Mobile station-originating speech call
Mobile station-originating data call
Location update
Service call (SMS, etc.).
130 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
The mobile station notes the random number and frame number associated
with each Channel_Request message. These are used by the mobile station to
recognize the response sent from the BSS. This response is sent on the AGCH,
which can be monitored by many mobile stations. The mobile station decodes
all messages sent on this AGCH, and only accepts a message with a random
number and frame number matching one of the last three requests sent.
MS BTS BSC MSC
Channe
l Reque
st (RAC
H)
REF
Chann
el Requ
ired
REF+RF
N+TA
REF stored
in MS SDCCH
memory Allocation
vation
el Acti
Chann wer
H+po
DCC
TA+S
Chann
el Activ
ation A
ck
nd
omma
te as sign c
Immedia +REF
wer +RFN
CH) H+po
nt (AG DCC
ass ignme TA+S
MS compares ediate
message with Imm DCCH
TA+S
REF in memory RFN+
REF+
Switch to SABM
SDCCH
+ cm + S
ervice Re
quest Establi
sh Indic
ation
UA cm + Serv SCCP
ice Requ Conne
est ction R
t equest
eques cm + Serv
Ser vice R ice Requ
est
Service Request must
match original sent onfirm
tion C
by MS in the SABM C onnec
SCCP
cm : Classmark
ID : Mobile Station identity
power : Mobile Station power or BTS power
REF : Random access information value
RFN : Reduced frame number
SDCCH : Description of the allocated SDCCH (Standalone Dedicated Control Channel)
Service : Initial Layer 3 message
Request
TA : Timing advance
UA : Unnumbered acknowledgment
Figure 12: Radio and Link Establishment for Mobile-Originated Call
The mobile station continues to transmit Channel_Request messages until it

receives a response.
3BK 21222 AAAA TQZZA Ed.08 131 / 304

3 Call Set Up
If no response is received before the mobile station has transmitted a

predefined number of retries, the mobile station:
Displays a network error message for all calls except location updates
Performs automatic reselection for location update calls. This means that
the mobile station attempts random access on a different cell.
On receipt of the Channel_Request message from the mobile station, the BTS
sends a Channel_Required message to the BSC. This message contains the
random number sent by the mobile station, and the timing advance measured
by the BTS.
Note: Under peak load conditions, resources may be over allocated due to this
process. See below for details on how the Immediate Assignment Extended
feature works to alleviate this problem.
In order to establish a radio connection on a VGCH between a mobile
station which is in group receive mode on that channel and the
BTS, the mobile station sends an Uplink_Access message with the
Subsequent_Talker_Uplink_Request parameter on the voice group call
channel. The Uplink_Access message is similar to a Channel_Request
message but is sent only on the group call channel uplink.
The mobile station sends an Uplink_Access message when:
A subsequent talker uplink is required

The BTS performs any necessary contention resolution and grants the
uplink to one mobile station by sending a VGCS_Uplink_Grant message
to the mobile station in unacknowledged mode on the main signalling
link. The BSS sends Uplink_Busy messages on the main signalling link
in all cells of the group call area.
There is a reply to an uplink access request.
Note: For emergency VGCS calls, the Channel_Request message contains the
Emergency_VGCS_Channel_Request parameter, which indicates that the
fast call set up procedure should be initiated. See Immediate Assignment
(Section 3.2.1.3).
3.2.1.2 SDCCH Channel Activation

The BSC checks the Channel_Required message to ensure it can accept the
request. It allocates an SDCCH channel if one is available. The resource
management software of the BSC allocates the SDCCH on the basis of which
traffic channel has the most available SDCCHs. This ensures the load is
spread between the traffic channels.
The BSC then sends a Channel_Activation message to the BTS. It also
sets a timer to wait for an acknowledgment from the BTS, indicating that
it is ready to activate the channel.
The Channel_Activation message contains:
A description of the SDCCH to be used
The timing advance

Mobile station and BTS power commands. The mobile station and BTS
power are set to the maximum allowed in the cell.
132 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
The BTS initiates the physical layer resources for the channel and sets the
LAPDm contention resolution ready for the first mobile station message on the
SDCCH. It then sends a Channel_Activation_acknowledgment message to
the BSC. The BSC stops its guard timer.
Note: Contention resolution prevents two mobile stations connecting to the same
SDCCH.
The following figure shows the Channel Activation procedure.
MS BTS BSC MSC
SDCCH
Allocation
vation
el Acti
Chann
wer
H+po
DCC
TA+S
Chann
el Activ
ation A
ck
power : Mobile Station power or BTS power

TA : Timing advance
For emergency VGCS calls, the immediate call set up procedure is used. If the
O&M flag En_FAST_VGCS_SETUP is set to "disabled", when the BSC receives
the Emergency_VGCS_Channel_Request message, it ignores the message.
If the O&M flag En_FAST_VGCS_SETUP is set to "enabled", when the BSC
receives the Emergency_VGCS_Channel_Request message, it allocates the
SDCCH. Once the SDCCH is established, the mobile station uses it to send an
Immediate_Set_Up message to core network (this message is transparent
for the BSS).
3BK 21222 AAAA TQZZA Ed.08 133 / 304

3 Call Set Up
3.2.1.3 Immediate Assignment

The BSC builds and sends an Immediate_Assign_Command message repeating
the information given in the Channel_Activation message. This message
also includes the random number and frame number of the original mobile
station request to which the BSC is replying. It also instructs the BTS to inform
the mobile station of the SDCCH channel assignment. The BSC starts a guard
timer for the mobile station to respond.
The following figure shows the Immediate Assignment procedure.
MS BTS BSC MSC
d
mman
assign co
ediate RFN
Imm REF+
GCH) +po wer+
ent (A DCCH
ssignm TA+S
diate a CH
Imme +SDC
TA
Switch to RFN+
REF+
SDCCH

TA : Timing advance
The BTS sends the Immediate_Assignment message to the mobile station

on the AGCH.
The mobile station checks the random number and frame number in the
Immediate_Assignment message. If it matches those from one of its last
three Channel_Request messages, the mobile station switches to the
indicated SDCCH and sets its timing advance to the value indicated in the
Immediate_Assignment message.
When a mobile station requires an emergency VGCS call, it sends an
Immediate_Setup message. When the BSC receives this message, it sends
a SCCP_Connection_Request message to establish the dedicated SCCP
connection. The user data field of this message contains the Immediate_Setup
message.
The call is then set up as for a standard voice and/or data call
and a SCCP_connection_confirm message is sent, containing the
Assignment_Request message in the user field.
134 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.2.1.4 Immediate Assignment Reject

When there is congestion on the SDCCH, the mobile station could retry
repeatedly without success to access a channel.
This produces the following undesired effects:
Undesirable messages on the mobile station screen

The subscriber has to restart his call attempt manually
Repeated futile attempts to connect overload the RACH and Abis Interface
"Ping-pong" cell reselection by the mobile station.
Therefore, the system implements a special Immediate_Assignment_Reject

message when the following conditions are met:
The BSC flag EN_IM_ASS_REJ is set to true. This flag is set on a BSC basis,
and can be viewed but not modified from the OMC-R
All SDCCHs in the cell are busy
The BSC receives a Channel_Required message from the BTS with one of
the following establishment causes:
Emergency call
Call re-establishment
Mobile station-originating call
Location update
Service Calls.
The Immediate_Assignment_Reject message is contained in the information

element of the Immediate_Assign_Command message. This message starts a
timer in the mobile station which causes it to wait in idle mode until the timer
expires, before sending new Channel_Request messages. The length of the
timer is dependent upon the establishment cause, and can be set by the user.
If an Immediate_Assign_Command message is received before expiration
of the timer, it has priority and the mobile station will respond to it, thereby
connecting the call.
Note: This message cannot be used when the mobile station is responding to paging,
i.e., in the case of a mobile-terminated call.
For VGCS emergency calls, when all SDCCH sub-channels in the cell are
busy, the BSC sends an Immediate_Assignment_Reject message with
"Wait Indication" corresponding to the GSM timer T3122, the value of which
depends on the establishment cause in the Channel_Required message. The
corresponding value for T3122 is usually equal to 2 seconds (which is the
same value as for the establishment cause "emergency call" for the normal a
point-to-point call).
3BK 21222 AAAA TQZZA Ed.08 135 / 304

3 Call Set Up
3.2.1.5 Immediate Assignment Extended

Under peak load conditions, it is likely that the mobile station will send several
Channel_Request messages before receiving an Immediate_Assignment
message indicating that a channel is allocated to it. At this stage, the BSC
is unable to identify the mobile station which sent a given Channel_Request
and so it will grant several SDCCHs to the same mobile station, thus wasting
resources and reducing throughput on the AGCH.
If several Immediate_Assignment messages are queued on the AGCH, the
BTS will try to build an Immediate_Assignment_Extended message, passed
to the mobile station on the Air Interface, constructed from pieces of two
Immediate_Assignment messages as follows:
The first Immediate_Assignment message in the queue (i.e., the oldest)
The first of the remaining Immediate_Assignment messages in the queue,

which are able to be merged according to one of the following criteria:
At least one of the two allocated channels is non-hopping
If both allocated channels are hopping, they share the same Mobile
Allocation (see Baseband Frequency Hopping (Section 4.3.1) for more
information about Mobile Allocation).
If there are several Immediate_Assignment messages in the AGCH queue,

but the first one cannot be merged with any other in the queue (using the
above criteria), a "classic" Immediate_Assignment message is sent on the Air
Interface.
3.2.1.6 Set Asynchronous Balanced Mode

The first Layer 2 frame sent on the SDCCH is a standard LAPDm type frame,
known as the Set Asynchronous Balanced Mode. This is equivalent to the
Set Asynchronous Balanced Mode Extended frame in the LAPD. On the Air
Interface, it establishes the LAPDm connection with the BTS. This frame
can also contain Layer 3 messages.
136 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.2.1.7 Contention Resolution

The mobile station starts its LAPDm connection and sends a Layer 3 message
in its first frame. The BTS uses this message for contention resolution. The
BTS sends an acknowledgment to the mobile station containing the same
Layer 3 message. Therefore, only the mobile station that sent the message can
accept the acknowledgment from the BTS and consider itself connected.
The following figure shows the establishment of the connection for a mobile
originated call.
MS BTS BSC MSC
SABM
+ cm + S
ervice R
equest Establis
h Indic
ation
cm + Ser
UA vice Req SCCP
uest Conne
ction R
t equest
Reques cm + Ser
Service vice Req
uest
onfirm
ction C
Conne
SCCP
cm : Classmark
Service : Initial Layer 3 message including the mobile station identity and classmark
Request
UA : Unnumbered acknowledgment
Figure 13: Connection for Mobile-Originated Call
For a mobile-originated call, the Layer 3 message from the mobile station
contains:
An Information Element indicating:

CM service request (speech/data, SMS, emergency call)
Location updating request (location updating procedure)
CM re-establishment request (after a failure)
IMSI detach indication (mobile station power off - see IMSI Attach-Detach
(Section 3.3.5) for more information).
The mobile station identity (see Authentication (Section 3.7) for more
information)
The mobile station classmark (see Classmark Handling (Section 3.6) for
more information).
The network uses this message to decide which call negotiation procedures are
required and whether to assign a traffic channel.
3BK 21222 AAAA TQZZA Ed.08 137 / 304

3 Call Set Up
For VGCS calls, the BSS considers that there are three levels of contention
resolution:
At cell level
The BTS immediately sends a VGCS_Uplink_Grant message as soon
as it receives the first correctly decoded Uplink_Access message.
Further Uplink_Access messages are ignored. The BTS sends only one
Talker_Detection message to the BSC.
At BSC level
The BSC sends an Uplink_Busy message to all BTS (except the BTS that
sent the first Talker_Detection message) in the BSC area involved in
the VGCS call as soon as the BSC receives the first Talker_Detection
message, in order to prevent too many incoming Talker_Detection
messages.
If another BTS receives an Uplink_Access message between the
time the Talker_Detection message was received by the BSC and
an Uplink_Busy message was received by other BTS, then the BSC
manages a queue with an initial fixed size of 5. If the queue is full (the sixth
Talker_Detection message is received), an Uplink_Release message is
immediately sent to the respective BTS.
The BSC sends an Uplink_Release message after the first
Talker_Detection message is received from any of the BTS.
An Uplink_Release message is sent to all the BTS that have a
Talker_Detection message in the queue (possibly 0 to 4), with the
exception of the first BTS which sent the Talker_Detection message. The
BSC then sends an Uplink_Request_Confirmation message to the MSC.
At the network level

If uplink requests have been made by more than one BSC, the contention
resolution is performed by the MSC.
3.2.1.8 Establish Indication

The BTS sends an Establish_Indication message to the BSC to indicate
that the mobile station has connected. The BSC stops the guard timer, extracts
the classmark information, and initiates an SCCP connection with the MSC.
138 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.2.1.9 SCCP Connection

For standard calls:
The BSC sends an SCCP_Connection_Request message to the MSC
The MSC replies with an SCCP_Connection_Confirm message. This

message can contain a classmark request or a cipher mode command.
The signaling link is established between the mobile station and the MSC.
For VGCS calls:
The MSC sends a SCCP_Connection_Request message to the BSC

establish the VGCS call controlling SCCP connection. The user data field of
this message contains the VGCS/VBS_Setup message
When the BSC receives the SCCP_Connection_Request containing the

VGCS/VBS_Setup , it allocates the necessary resources for the requested
call.
The BSC then sends a SCCP_Connection_Confirm message to the MSC.

The user data field of this message contains the VGCS/VBS_Setup_Ack
message.
Note: When a mobile station makes an emergency VGCS call, it sends an

Immediate_Setup message. When the BSC receives this message, it sends
a SCCP_Connection_Request message to establish the dedicated SCCP
connection. The user data field of this message contains the Immediate_Setup
message.
3.2.2 Authentication and Ciphering

The content of the classmark IE sent during radio and link establishment
depends on the type of mobile station. The classmark information is used for
mobile station power control and to set ciphering. The MSC can request a
classmark update to ensure that it has the correct information. Classmark
procedures are described in Classmark Handling (Section 3.6).
The authentication procedure:
Authenticates the mobile station identity
Checks the mobile station has the correct Individual Subscriber

Authentication Key value on the SIM for the ciphering procedure
Sends the Random Number for the ciphering and authentication procedures.
For more information about this procedure, refer to Authentication (Section 3.7).
Information passed on the Air Interface must be protected. The MSC can
request that the BSS set the ciphering mode before information is passed on
the SDCCH. Ciphering is described in Ciphering (Section 3.8).
3BK 21222 AAAA TQZZA Ed.08 139 / 304

3 Call Set Up
3.2.3 Normal Assignment

Figure 14 shows the normal assignment process for a mobile originated call.
Once the Radio and Link Establishment procedure is successfully completed,
the mobile station has a signaling link with the network. If the call requires a
traffic channel to communicate with a called party, the mobile station sends a
setup message. This indicates the teleservice and bearer service required,
and the called party number. The information is sent transparently through the
BSS. This message can contain more than one bearer service element, and
a parameter indicating that the subscriber may request a change of service
(In-Call Modification) during the call. See In-Call Modification (Section 4.2)
for more information.
The MSC sends a Call_Proceeding message to the mobile station. This
indicates that the call parameters have been received, and that attempts to
establish communication with the called party are under way.
3.2.3.1 Channel Request

The MSC initiates the assignment of the traffic channel by sending the
Assignment_Request message and sets a timer to supervise the response
from the BSC.
The BSC checks the message which must contain a channel type (for a traffic
channel this is speech or data plus data rate). This message also contains
the mobile station classmark which the BSC uses if it has not received the
classmark from the mobile station.
The Assignment_Request message may contain a codec list, giving, in order of
preferences, the type of codec it prefers to use (for example, one that supports
enhanced full-rate speech). In this case, the BSC checks the list against those
supported by the cell, and chooses the preferred codec type that can be used
by both the BTS and by the mobile station.
140 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
If the BSC finds an error in the Assignment_Request message, it sends an

assignment_failure message. If no error is detected, it starts the normal
assignment procedure towards the mobile station.
MS BTS BSC MSC
set up
(SDCCH)
tele/bearer service layer 3 CC

called party no. layer 3 CC
layer 3 CC call proceeding

layer 3 CC
quest
ment re
assign
e+cm
el typ
chann
TCH
allocation
quest
text re
al con
physic
physical
context
confirm
power +
TA
vation
el acti
chann
er
+ ciph
+ TA
H) TCH p ower
(SACC + DT
X +
ates
r upd channel ac
powe tivation
TA + e6 acknowledg
s y s info 5 e
+
nd
omma
ment c
assign
H)
(SDCC
mand
me nt com
assign
Release
SDCCH SABM
(FACC
H)
establis
h indic
ation
Set
CCH) Transcoder
UA (FA
assign
ment co
Set switching
mplete
(FACC
Path
H)
assign
ment co
mplete
Initiate SDCCH
Release alerting
layer 3 CC
layer 3 CC
connect
layer 3 CC
layer 3 CC
connect acknowledgement
layer 3 CC
cipher : Encryption algorithm + ciphering key

cm : Classmark
DTX : Discontinuous transmission flags
TA : Timing advance
Figure 14: Normal Assignment for Mobile-Originated Call
3BK 21222 AAAA TQZZA Ed.08 141 / 304

3 Call Set Up
3.2.3.2 Traffic Channel Allocation

The BSC ensures that it is not running any other procedures for the mobile
station and then allocates resources for the traffic channel. The resources
allocated are calculated using an algorithm in the BSC. The BSC can receive
an Assignment_Request message in various situations.
Therefore, it has traffic channel resource allocation algorithms for:
Normal assignment
In-call modification
Intercell handover
Intracell handover
Directed retry
Concentric cells
Microcells.
In normal conditions (mobile-originated call, normal assignment), the normal

assignment algorithm is used. The BSC keeps a table of idle channels in which
the channels are classified by their interference level (1 = low, 5 = high).
The interference level of all free channels is monitored by the BTS. This
information is periodically sent to the BSC in the RF_resource_indication
message. The BSC does not automatically allocate a channel from the lowest
interference level, as a number of channels can be reserved for handover.
After all reserved channels are accounted for, the channel allocated is from
the lowest interference level. If the number of reserved channels exceeds
the number of free channels, then the BSC allocates a channel from the
highest interference level. If no channels are available, the BSC sends an
assignment_failure message to the MSC indicating the cause of the failure.
3.2.3.3 TCH Allocation for VGCS

A channel used for VGCS is referred to as VGCH. A VGCH is simply a normal
TCH timeslot that is used for VGCS. One VGCH channel is allocated by the
BSS in each cell involved in a VGCS call. If the MSC asks the BSC for
immediate allocation of a VGCH, allocation is performed just after the VGCS
setup procedure and is based on the Resource Controlling SCCP connection
associated with the VGCH.
For VGCS calls, the BSS can allocate one VGCH for each cell involved
in the VGCS.
If immediate allocation of a VGCH is required (for example, for an emergency
call), then VGCS allocation is performed immediately after call set up, and is
based on the Resource Controlling SCCP connection associated with the
VGCH.
142 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.2.3.4 Traffic Channel Activation

The BSC sends a Physical_Context_Request message to the BTS, to find
out the current power and timing advance being used by the mobile station on
the SDCCH. The BTS responds with a Physical_Context_Confirm message,
containing the relevant information. If no channel is available, and queuing is
enabled, the call is placed in the queue. Refer to Congestion (Section 3.5)
for more information about queuing.
The following figure shows the channel activation process for the traffic channel.
MS BTS BSC MSC
TCH
allocation
quest
ext re
al cont
physic
physical
context co
nfirm
power + TA
ion
l activat
channe
er
+ ciph
+ TA
H) TCH ower
(SACC X+p
+ DT
ates
r upd
powe channel
TA + &6
activation
fo 5 acknow
sys in ledge
+
m mand
ment co
assign
CCH)
d (SD
mman
ment co
assign
cipher : Encryption algorithm + ciphering key

DTX : Discontinuous transmission flags
MS : Mobile Station
TA : Timing advance
TCH : Traffic Channel
The BSC sends a Channel_Activation message to the BTS.

This contains:
A description of the traffic channel to be used
The mobile station timing advance to be applied

The encryption algorithm and ciphering key (same as for SDCCH
assignment)
A Discontinuous Transmission indicator for uplink (not used) and downlink

(see Speech Transmission (Section 4.4) for more information)
The mobile station power to be used (see Radio Power Control (Section
4.5) for more information)
The BTS power to be used.
The BSC starts a timer, and waits for the BTS to acknowledge that it has
activated the channel.
3BK 21222 AAAA TQZZA Ed.08 143 / 304

3 Call Set Up
The BTS initializes its resources for the traffic channel, sets the ciphering
mode, sends timing advance and power information to the mobile station
on the SACCH associated with the traffic channel, which is constantly
monitored by the mobile station. At the same time, the BTS sends a
Channel_Activation_Acknowledgment message to the BSC. The BSC stops
its timer and sends an Assignment_Command message on the SDCCH to the
mobile station. This instructs the mobile station to change to the traffic channel.
When the mobile station receives the Assignment_Command message, it
disconnects the physical layer, and performs a local release to free the LAPDm
connection of the SDCCH.
For VGCS calls, when the BSC receives a
Channel_Activation_Acknowledgment message from the BTS, the BSC
sends a VGCS_Assignment_Result message.
3.2.3.5 Traffic Channel Assignment
The following figure shows the channel assignment process for the traffic
channel.
MS BTS BSC MSC
Release
SDCCH SABM
(FACC
H)
establi
sh ind
ication
Set
CH) Transcoder
U A (FAC
Set Switching
Path
assign
ment c
omple
te (FA
CCH)
assign
ment c
omple
te
FACCH : Fast Associated Control Channel

MS : Mobile Station
SABM : Set Asynchronous Balanced Mode
UA : Unnumbered Acknowledgment
The mobile station then establishes the LAPDm connection (via the SABM on
the FACCH) for the traffic channel. The BTS sends an Establish_Indication
message to the BSC. It also sets the Transcoder and its radio link failure
detection algorithm. The BTS sends a Layer 2 acknowledgment to the mobile
station. The mobile station sends an Assignment_Complete message to
the BSC.
When the BSC receives the Establish_Indication message, it establishes
a switching path between the allocated Abis and A Interface resources.
When it receives the Assignment_Complete message, it sends an
Assignment_Complete message to the MSC and initiates release of the
SDCCH (see Call Handling for more information).
144 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
For VGCS, a dedicated TCH is allocated:

To the first calling mobile station
To subsequent calling mobile stations
To listening mobile stations moving into a cell where a VGCH has not
been allocated.
3.2.3.6 Connecting the Call

Once communication with the called party is established (but before the call is
answered), the MSC sends an alerting message to the mobile station. The
mobile station generates a ring tone.
When the called party answers, the MSC sends a connect message to the
mobile station. The mobile station responds with a connect_acknowledgment
message. The call is established.
The following figure shows the call connection process for a mobile originated
call.
MS BTS BSC MSC
initiate SDCCH
alerting
layer 3 CC layer 3 CC release
layer 3 CC connect
layer 3 CC
connect acknowledgement
layer 3 CC
MS : Mobile Station
SDCCH : Standalone Dedicated Control Channel
3.2.3.7 Off Air Call Set Up

Off Air Call Set Up (OACSU) is a method available in the BSS whereby the
network assigns a traffic channel only when the called party has answered the
call. This improves the efficiency of traffic channel allocation as unsuccessful
calls will not take up any traffic channel resources. This feature is controlled by
the MSC.
The Layer 3 alerting message is sent by the MSC just after the
Call_Proceeding message. The mobile station then enters the ringing phase.
The Assignment_Request message is not sent by the MSC until the called
party answers. The rest of the Layer 3 exchanges between MSC and BSC take
place after the mobile station sends the Assignment_Complete message to
the MSC.
When OACSU is in use, the mobile station may provide internally generated
tones to the user (in a Mobile-Originated call) during the ringing phase, as the
traffic channel is not yet available for tones or in-band announcements to be
sent.
This feature increases the probability of an internal (SDCCH-to-SDCCH)
handover being initiated by the BSS while the Normal Assignment procedure is
being initiated by the MSC.
3BK 21222 AAAA TQZZA Ed.08 145 / 304

3 Call Set Up
3.3 Mobile-Terminated Call

A call from the NSS to a mobile station can be either a call routed through
the NSS from a calling party, or it can be initiated by the NSS for mobility
management.
A mobile-terminated call set up follows the same basic procedures as a
mobile-originated call. This section describes only those procedures which
are different. The following figure shows radio and link establishment for
a mobile-terminated call.
MS BTS BSC MSC
paging
t
cell lis
IMSI +
TMSI/
and
comm
paging
+
group
aging
(PCH) IMSI p
TMSI/ l n u m ber
e
reque
st chann
paging
IMSI
TMSI/
chann
el requ
est
(RACH
)
chann
el requ
ired
IMSI : International Mobile Subscriber Identity

MS : Mobile Station
RACH : Random Access Channel
TMSI : Temporary Mobile Subscriber Identity
Figure 15: Radio and Link Establishment for Mobile-Terminated Call
146 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.3.1 Radio and Link Establishment

Before the BSS sets up a signaling link, the mobile station has to be paged.
This procedure is initiated by the MSC. It sends a paging message to the BSC
controlling the location area from which the mobile station last performed
a location update.
This message is sent in connectionless mode and contains:
The mobile station identity (TMSI or IMSI of the mobile station to be paged)
A cell identifier list which identifies the cells where the paging request is to
be sent. This could be all cells or a group of cells.
The MSC sets a timer to wait for a Paging_Response message from the
mobile station.
The BSC checks the Paging message and, if valid, calculates the mobile
station paging group and the CCCH timeslot for the paging group.
The BSC sends a Paging_Command message to each BTS, indicating the TMSI
or IMSI, the paging group and the channel number.
Each BTS formats the information and broadcasts a Paging_Request message
on the Paging Channel.
The mobile station listens to messages sent to its paging group. When
it receives a paging message with its mobile station identity, it sends a
Channel_Request message on the RACH to the BTS, indicating that the
request is in response to a Paging_Request message.
The BSS then performs the radio and link establishment procedure described
in Mobile-Originated Call (Section 3.2).
Note: When the mobile station sends the SABM, it indicates that the connection is
in response to a paging request. For more information about paging, see
Paging (Section 3.4).
3.3.2 Authentication and Ciphering

The system handles authentication and ciphering for a mobile-terminated call
in the same manner as a mobile-originated call.
Authentication and Ciphering (Section 3.2.2)
Classmark Handling (Section 3.6)
Authentication (Section 3.7)
Ciphering (Section 3.8).
3BK 21222 AAAA TQZZA Ed.08 147 / 304

3 Call Set Up
3.3.3 Normal Assignment

The normal assignment procedure for a mobile-terminated call is initiated by
the MSC. This is shown in the figure below.
The MSC sends a Layer 3 Call Control Set_Up message to the mobile station,
indicating the bearer service and teleservice to be used for the call. The MSC
can indicate more than one bearer service.
The mobile station checks this message. If it can accept the call, it sends a
Call_Confirmation message which can contain a bearer capability parameter
indicating which bearer service is preferred.
The BSS performs the physical context and channel assignment. This is
described in Normal Assignment (Section 3.2.3). Once the traffic channel
is assigned, the mobile station alerts the user and sends an Alerting
message to the MSC. When the mobile station user answers, the mobile
station sends a Connection message to the MSC. The MSC sends a
Connection_Acknowledgment message to the mobile station and connects
the call.
All these messages are Layer 3 Call Control messages, and are transparent to
the BSS.
MS BTS BSC MSC
set up
r service
tele/beare
layer 3 CC
layer 3 CC
call confirm
ed (SDCCH)
bearer service layer 3 CC
layer 3 CC
ring
tone alerting
layer 3 CC
layer 3 CC
user
answer connect
layer 3 CC
layer 3 CC
e
knowledg
connect ac
layer 3 CC
layer 3 CC
MS : Mobile Station
148 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.3.4 Off Air Call Set Up

If Off Air Call Set Up (OACSU) is in use, it is possible that at one moment the
called party may have answered the call, but the traffic channel is still not
assigned by the network (for example, the call is queued). In this case, the
mobile station may supply tones to the answering user, so that the user does
not hang up before the Normal Assignment procedure completes.
3.3.5 IMSI Attach-Detach

IMSI Attach-Detach is a mobility feature which primarily concerns the MSC
and the mobile station. Used together with the periodic location update
procedure, IMSI Attach-Detach allows the network to provide more efficient
control and use of resources.
For example, if a mobile-terminated call arrives for a mobile station which is
"detached", the MSC knows that the mobile station is not active and does not
need to start a paging request. For the BSS, this can reduce load on the PCH.
Initiation of the IMSI Attach-Detach procedure is controlled by a parameter
in the BSS, Attach_Detach_Allowed. When this parameter is set, the BSS
broadcasts system information on all cells indicating that the network supports
IMSI Attach-Detach.
Mobile stations which have successfully connected and logged themselves
onto the network are then obliged to perform IMSI Attach-Detach procedures.
Refer to documentation supplied with mobile stations which support this
function.
For more information about the Attach_Detach_Allowed parameter, see the
9153 OMC-R Configuration Handbook.
IMSI Attach-Detach is also used for other functions at the MSC. Refer to
documentation for your network’s MSC equipment.
3BK 21222 AAAA TQZZA Ed.08 149 / 304

3 Call Set Up
3.4 Paging
Paging is the procedure by which the network contacts a mobile station. For
example, if the network needs to inform the mobile station of an incoming call, it
pages the mobile station to prompt it to request a channel. After the immediate
assignment procedure, the Service_Request message from the mobile station
indicates that the connection is in response to a paging message.
Paging messages are sent on the CCCH. The downlink CCCH carries the
AGCH and the PCH.
The PCH is divided into sub-channels, each corresponding to a paging group.
To save the mobile station from monitoring every occurrence of the PCH,
each mobile station is assigned a paging group calculated from the IMSI.
Each mobile station calculates its paging group and monitors only that PCH
sub-channel. This saves mobile station battery power.
The number of paging groups and the CCCH organization varies for each
configuration. The mobile station knows the CCCH organization from the
information passed on the BCCH (sys_info 3).
The AGCH sends the Immediate_Assignment message to the mobile station.
A number of blocks can be reserved for the AGCH using the BS_AG_BLKS_RES
parameter. If this parameter is set to 0, then the Immediate_Assignment
message is sent on the PCH. The following figure shows a TDMA frame with
nine CCCH blocks, three of which are reserved for the AGCH and the rest for
the PCH. The parameter to reserve these blocks is set to BS_AG_BLKS_RES = 3.
TDMA Frame Cycle
CCCH0 CCCH1 CCCH2 CCCH3 CCCH4 CCCH5 CCCH6 CCCH7 CCCH8
Reserved for AGCH Available for PCH channels

CCCH : Common Control Channel
TDMA : Time Division Multiple Access
Figure 16: CCCH with Three Blocks Reserved for AGCH
150 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
In the example shown in the figure above, BS_AG_BLKS_RES is set to three.

Every occurrence of the TDMA frame cycle carrying the CCCH has three
AGCHs and six PCHs. However, more than six paging groups can be defined
by assigning a different group of six PCHs to a number of TDMA multiframe
cycles. This is specified using the parameter BS_PA_MFRMS , as shown in
the following figure.
First TDMA Frame cycle
AGCH AGCH AGCH PGR0 PGR1 PGR2 PGR3 PGR4 PGR5
Second TDMA Frame cycle
Third TDMA Frame cycle
Fourth/1 TDMA Frame cycle
These four TDMA frames represent 24 PCHs. The parameter

to reserve these is BS_PA_MFRMS =4

PGR : Paging Group
TDMA : Time Division Multiple Access
Figure 17: Four TDMA Frame Cycles Providing 24 Paging Sub-channels
3BK 21222 AAAA TQZZA Ed.08 151 / 304

3 Call Set Up
3.4.1 Paging Control

The MSC has to initiate the paging procedure, as it holds the information on the
last mobile station location update.
The MSC sends the Paging message to the BSC(s) and sets a timer for
the Paging_Response from the mobile station, which is sent as part of the
service_request message after the immediate assign procedure.
The Paging message from the MDC contains a cell list identifier IE, identifying
the cells in which the Paging message is to be transmitted.
The BSC checks the cell identifier list and builds a Paging_Command message
for the relevant BTS. The following table shows the different cell identification
lists and the paging performed by the BSC.
Cell List Identifier Paging Performance
No IE present Paging performed in all cells controlled by BSC
IE indicates all cells Paging performed in all cells controlled by BSC
Error in IE Paging performed in all cells controlled by BSC
IE indicated specific Paging performed only in those cells specified

cell(s)
IE indicates specific Paging performed in all cells of each location area

location area(s) specified
Table 3: Cell List Identifier and Paging Performed
The BSC calculates the paging group of the mobile station for each cell and
the CCCH timeslot. It then sends a Paging_Command message to each BTS,
indicating the CCCH timeslot number, mobile station paging group and the
mobile station identity (IMSI/TMSI).
152 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
The BTS builds a Paging_Request_Type_x message to send to the mobile

station. There are three types of paging request messages, as the BTS can
page more than one mobile station at a time. The following table shows the
relationship between the paging message type, the number of mobile stations
to be paged and the mobile station ID used.
Paging Request Message Mobile Station Identification
Type_1, identifying up to two IMSI or TMSI (for one mobile station)

mobile stations.
IMSI, IMSI or TMSI, TMSI or IMSI, TMSI
(for two mobile stations)
Type_2, identifying three mobile TMSI, TMSI, TMSI or

stations.
TMSI, TMSI, IMSI
Type_3, identifying four mobile TMSI, TMSI, TMSI, TMSI

stations.
Table 4: Paging Request Message and Mobile Station Identification
By using a combination of paging message types, several mobile stations can

be simultaneously paged. This is done even if some mobile stations are paged
using the IMSI and others are paged using the TMSI.
The Paging_Request messages are stored in a buffer, while waiting to be
sent on the relevant PCH sub-channel. If this buffer becomes full, the next
Paging_Command message is discarded.
3BK 21222 AAAA TQZZA Ed.08 153 / 304

3 Call Set Up
When the mobile station receives the Paging_Request message, it sends a

Channel_Request message to initiate the immediate assign procedure. The
service request message following the immediate assign procedure indicates
that the Channel_Request is in response to a Paging_Request message.
MS BTS BSC MSC
paging
t IE
and + cell lis
comm
paging
slot
reque
st H time
paging + CCC g group
in
IMSI + pag
TMSI/
chan
nel r
eque
st
chan
nel re
quire
REF d
+ RF
SABM N+T
A
+ serv
ice req
(pagin ue establi
g resp st sh ind
onse) ication
CCCH : Common Control Channel

IE : Information Element
MS : Mobile Station
TA : Timing advance
154 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.4.2 Discontinuous Reception

Discontinuous Reception adds to the power-saving abilities of the system,
extending mobile station autonomy under battery operation.
The DRX feature implements a receiver off/on ratio of 98 to 2. When the mobile
station is in idle mode, DRX allows the mobile station to switch off its receiver
and data processing. Instead of the mobile station listening continually on the
Paging Channel sub-channel of the CCCH for a paging message, it only listens
to that part of the PCH which corresponds to its paging group. The PCH is
split into a number of paging sub-channels, each of which serves the mobile
stations of a particular paging group.
The mobile station calculates its paging group and the part of the PCH it
has to monitor. It gets the information from its IMSI, and from the Control
Channel description sent on the BCCH (sys_info 3). The paging information
is transmitted at predefined regular intervals. The mobile station only turns on
its receiver to listen to its paging group and then turns itself off again. This
occurs cyclically, between 0.95 seconds and 4.25 seconds, depending on
the configuration of the cell.
Apart from listening to the PCH, the mobile station monitors the home cell’s
BCCH up to once every 30 seconds, and the top six neighboring cells up to
once every five minutes. For more information about Paging, refer to Paging
(Section 3.4).
3.5 Congestion
To prevent an Assignment_Request or an external Handover_Request
message from being rejected, the BSS allows queueing of traffic channel
requests. Congestion occurs when all traffic channels are busy for a particular
cell and the message arrives at the BSC. Queueing is allowed if indicated by
the MSC in the request message.
3.5.1 Queueing
Queueing is used to achieve a higher rate of successful call set up and external
handover completion in cases of traffic channel congestion. This is achieved by
queueing the request for a defined period of time. During this time a traffic
channel can become available and the traffic channel assignment can then
be completed.
When all traffic channels of a cell are busy, assignment and external handover
requests for traffic channel allocation can be queued, if:
Requested by the MSC

If the MSC allows queueing, this information and the priority of the request
for queueing are sent in the Priority Information Element of the request.
Configured in the BSC.

The BTS can perform queueing if specified in the BSC configuration. BTS
queueing can be enabled/disabled by an operator command through the
OMC-R. Setting the BTS_Queue_Length parameter to 0 disables queueing.
If either the MSC or BSC does not allow the request to be queued, the request
is immediately rejected and an Assignment_Failure message is sent to
the MSC.
3BK 21222 AAAA TQZZA Ed.08 155 / 304

3 Call Set Up
3.5.2 In-queue
If queueing is allowed, the request cannot be queued if one of the two queue
limits is exceeded. These limits are:
The maximum number of requests that can be queued per BTS if defined by
the O&M parameter BTS_Queue_Length. The range is from 1 to 64. This
can be individually set for each BTS
The global limit of 64 queued requests in the BSS. The sum of all BTS
queue lengths cannot exceed 64.
When one of the queue limits is exceeded, the request may still be queued if
there is a lower priority request in the queue. If the priority of the incoming
request is higher than the lowest in the queue, the incoming request is queued
and the oldest lowest priority request is then rejected.
Once a request is queued, the BSC informs the MSC by sending a
Queueing_Indication message.
A timer is activated when the request is queued. If the timer expires or the
request is preempted by a higher priority request, the request is rejected.
Once in the queue, the request waits to be either accepted or rejected due to
one of the following events: traffic channel availability or Forced Directed Retry.
3.5.2.1 Traffic Channel Availability
If another traffic channel disconnects within the cell, the request at the top of
the queue is assigned to the newly available traffic channel. The request is
removed from the queue. An Assignment_Complete message is sent to the
MSC notifying it of the successful assignment of a traffic channel.
3.5.2.2 Forced Directed Retry

The BSC detects that the call can be supported on another cell, and
implements Forced Directed Retry.
If the BSC detects the possibility of a handover for the queued request, it
generates an internal or external handover alarm and initiates the appropriate
handover procedure. A handover from an SDCCH in the serving cell to a traffic
channel in a target cell is known as directed retry.
On detection of the handover alarm, the BSC cancels the queued request,
stops the timer, and selects a neighbor cell in the target cell list. The target cell
must be able to support the ciphering requirements of the call. Once a cell is
selected, a traffic channel is chosen and a handover is attempted (SDCCH to
traffic channel). If the handover fails, another cell is chosen from the target cell
list. This procedure continues until a successful handover or the handover limit
(number of handover attempts allowed) is exceeded.
The MSC is notified of a successful handover by an Assignment_Complete
message. The direct retry finishes if the number of handover attempts is
exceeded, or there are no more cells left in the target cell list. Finally an
Assignment_Failure message is sent to the MSC indicating that there are no
radio resources available.
156 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.5.2.3 Queue Pre-emption

If a higher priority request arrives in the queue, Queue Pre-emption is
implemented.
If one of the queue limits is exceeded and the request is the oldest of the lowest
priority requests in the queue, the request is rejected. An Assignment_Reject
message is sent to the MSC indicating that there are no radio resources
available.
3.5.2.4 Timer Expires

If the timer expires, the request is de-queued and rejected. An
Assignment_Reject message is sent to the MSC indicating that there are no
radio resources available.
3.5.2.5 Fast Traffic Handover
Another possibility to save resources in case of traffic peaks is to force
handovers toward neighbor cells which have less traffic. The fast traffic
handover searches in the whole cell for a mobile which can perform a handover
to a neighbor cell with less traffic if the received signal level of the BCCH is
good enough. It is much more efficient than the forced directed retry when the
overlap of adjacent cells is reduced, e.g., in the case of single layer networks,
or for deep indoor coverage (if the umbrella cell does not overlap totally the
microcells). Fast traffic handover is enabled on a per cell basis, by setting the
EN_FAST_TRAFFIC_HO parameter to TRUE. Setting the EN_FAST_TRAFFIC_HO
parameter to ’False’ disables fast traffic handover for that cell.
Fast traffic handover is enabled when all of the following conditions are met:
A request is queued at the top of the queue. The request is of full-rate

type for assignment or emergency external incoming handover, and is not
in the HOLD state
The parameter EN_FAST_TRAFFIC_HO is set to TRUE.
The queued request is an assignment. If it is an external incoming handover, it

is an emergency handover to trigger the algorithm; otherwise the algorithm is
not triggered.
3BK 21222 AAAA TQZZA Ed.08 157 / 304

3 Call Set Up
3.5.3 Pre-emption
Pre-emption is an optional feature and is initiated during congestion periods.
The feature allows radio resources in a cell to be allocated to those calls which
are deemed to be the most important. The importance of the connection
is given by the MSC to the BSC via signaling on the A Interface. During
congestion periods, the BSC ensures that high priority transactions obtain the
resources they require. The BSC performs a release of radio resources in order
to obtain the radio resource for the higher priority call.
For Phase 1 and Phase 2 GSM, the signaling for priority and pre-emption exists
on the A Interface. The setting of this data on the A Interface is controlled by
the MSC. The conditions under which the information is set is up to operator
choices. For Phase 2+ GSM, the priority and pre-emption information is based
on subscription data which is stored in the HLR and downloaded to the VLR via
MAP protocols. This information can also be used by the MSC when setting the
priority level and pre-emption attributes for the call.
The pre-emption attributes of a call are defined by three bits:
pci: The pre-emption capability indication indicates if the transaction can
pre-empt another transaction
pvi: The pre-emption vulnerability indication indicates if the transaction

can be pre-empted
prec: The pre-emption recommendation. This is needed in order to defer

pre-emption until a suitable non-congested cell is found in the preferred
cell list. The pre-emption recommendation is used when the old BSS
recommends that another connection be pre-empted.
Pre-emption is applied to the TCH only. The pre-emption feature is optional

and controlled by the O&M parameter (EN_TCH_PREEMPT) on a per-BSC
basis. The BSC provides pre-emption of TCH radio resources. This takes into
account the priority of the call. The lowest lower priority call with the pvi bit
set is pre-empted and thus released. Directed retry and/or forced handover in
order to avoid pre-emption is not supported.
3.5.3.1 eMLPP
Enhanced Multi Level Priority and Pre-emption (eMLPP) is a supplementary
service that allows a subscriber in the fixed or mobile network to initiate calls
that have a priority and pre-emption attribute known to all the network elements.
The eMLPP standardization provides the transportation of the subscription
information for priority and pre-emption on MAP. This subscription information is
stored in the HLR and the GCR and is transported to the VLR.
This information is used for the following procedures:
Paging
TCH Assignment
TCH Handover.
Only TCH pre-emption is supported (i.e., only for circuit-switched services).

Pre-emption for VGCS is possible for both the VGCH, in transmit and receive
modes, and for the dedicated channel, in dedicated transmit mode.
158 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.5.3.2 Pre-emption Rules

An Assignment Request message with pci=1 and priority level=p1 will
pre-empt an ongoing call with pvi=1 and priority level=p2 (p2 is lower than p1).
A Handover Request message with pci=1 and priority level=p1 will pre-empt
an ongoing call with pvi=1 and priority level=p2, except if the prec bit is present
and set to 0 (i.e., the old BSS does not recommend the pre-emption of an
ongoing call to be performed by the target BSS).
In both cases, the call with the lowest priority level=p2 value is selected first,
and if several calls have the same lowest priority level=p2 value, one of them
with the pci bit set to 0 is preferred.
3.6 Classmark Handling

The mobile station classmark contains information about the mobile station
type and capabilities. This information is used by the BSS when implementing
procedures that affect a mobile station, such as:
Handover
Power Control
Ciphering
Overload Control
Location Updating.
Mobile stations of different types have different capabilities within the network.
It is essential that the network recognizes the mobile station classmark when
initiating procedures for a specific mobile station.
There are three entities that provide classmark handling, as shown in the
following table.
Entity Classmark Handling
BSS Performed by the BSC, which is responsible for collecting

the classmark data needed to perform procedures on the
mobile station.
MSC Indicates the mobile station classmark data to the BSC for
MSC-initiated procedures.
Mobile station The BSS is informed of any classmark changes and

information is sent on request from the BSS.
Note: The BSS can receive mobile station classmark information from both the MSC
and the mobile station. The information from the mobile station overrides
information from the MSC.
3BK 21222 AAAA TQZZA Ed.08 159 / 304

3 Call Set Up
3.6.1 Classmark IE
The Alcatel-Lucent 900/1800 BSS supports classmark 1, classmark 2 and
classmark 3 IEs. Classmark 1 IE is always sent to the BSS when the mobile
station tries to establish communication.
Classmark 1
The Classmark 1 IE contains:
The revision Level
The RF Power Level
Support of A5/1 Encryption.
Classmark 2
The Classmark 2 IE is defined in GSM to allow the coding of phase 2
capabilities such as the A5/2 ciphering algorithm and VGCS capability. The
classmark contains the same elements as Classmark 1 IE, plus support
of A5/2 encryption.
Classmark 3
The Classmark 3 IE is defined in GSM to allow multiband mobile stations to
indicate their capabilities. The classmark specifies the supported bands
and the respective power classes.
160 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.6.1.1 Classmark IE Fields

The following tables describes the fields contained in a classmark IE.
This field... Indicates...
Revision Level Either a phase 1 or phase 2 mobile station. It does not distinguish
between phase 1 and phase 1 extended mobile stations. If there is an
error in this field, then a default phase 1 is assumed.
RF Power Level the mobile station power capability.

For Alcatel-Lucent 900:
Class 1 = 20 W
Class 2 = 8 W
Class 3 = 5 W
Class 4 = 2 W
Class 5 = 0.8 W
For Alcatel-Lucent 1800:
Class 1 = 1 W
Class 2 = 0.25 W
The value is not permitted if there is an error in this field. The result of
this is that the mobile station power capability is assumed to be the same
as the maximum transmit power allowed in the cell.
Support of A5/1 Encryption Whether the mobile station supports the A5/1 encryption algorithm. If
the A5/1 encryption algorithm is not supported, there is no indication of
other algorithms being supported.
Support of A5/2 Encryption Whether the mobile station supports the A5/2 encryption algorithm. If
the A5/2 encryption algorithm is not supported, there is no indication of
other algorithms being supported.
3BK 21222 AAAA TQZZA Ed.08 161 / 304

3 Call Set Up
3.6.1.2 Impact on BSS and MSC

The main difference between classmarks 1 and 2 for the BSS or MSC is the
support of the encryption algorithm. For procedures that require ciphering,
the BSS and MSC cannot recognize the mobile station ciphering capability if
only Classmark 1 IE was received. Therefore, there is a classmark updating
procedure.
Similarly, for classmark 3, the BSS and MSC do not recognize the mobile
stations multiband capabilities if only a Classmark 1 IE was received.
Therefore, a classmark updating procedure is required.
3.6.2 Classmark Updating

Further classmark information may be required by the BSS or MSC when
initiating a procedure which needs to encrypt information. The mobile station
can also send updated information if, for example, its power capability changes.
Therefore, updating of classmark information can be initiated from the:
Mobile station by sending a classmark_change message to the BSC which
sends a classmark_update message to the MSC.
BSC by sending a classmark_enquiry message through the BTS to the

mobile station. The mobile station responds with a classmark_change
message.
MSC by sending a classmark_request message to the BSC. This prompts

the BSC to send a classmark_enquiry message to the mobile station
which responds with a classmark_change message.
The classmark_change message from the mobile station is passed through

the BTS to the BSC. The BSC stores the information for its own use and
forwards the information to the MSC. Depending on the network type and
configuration, the classmark update is not always required. Therefore, the BSS
has a parameter in the BSC (parameter Send_CM_Enquiry) which can be
configured. The following table shows the possible configurations.
Parameter
Value Action
0 The classmark_enquiry message is never initiated by the

BSC.
1 The BSC always initiates a classmark update when it receives

a location update request.
2 The BSC only initiates a classmark update on reception of a

location update request if A5/1 is not available. This is worked
out from the classmark 1 IE.
If the system requests a classmark update to a phase 1 mobile station, the

mobile station is not able to respond. It considers the message an error and
sends an RR_status message. This message is ignored by the BSS and
is not passed to the MSC.
162 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.6.3 Location Updating with Classmark Procedure

If the mobile station is a phase 1 extended or phase 2 mobile station, it can
send classmark update information on request from the BSS or MSC. Because
the BSS does not know the mobile station ciphering capability from the
classmark 1 IE, updating is required. This is received when the mobile station
establishes the LAPDm connection, as shown in the following figure.
MS BTS BSC MSC
channel re
quest
(RACH)
channel re
quired
switch to
SDCCH SABM +
rn + fn +
cm
establish in
dication
SCCP conn
ection
ction
conne
H /SACC
H) SCCP
(FACC &6
fo 5 confirm
A+ sys in quiry
r+T ark en
powe classm
classmark change
classmark 2IE
classmark update
classmark 2IE
location update
(SDCCH)
cm : Classmark
IE : Information Element
MS : Mobile Station
RACH : Random Access Channel
SACCH : Slow Associated Control Channel
TA : Timing advance
3BK 21222 AAAA TQZZA Ed.08 163 / 304

3 Call Set Up
For location updates with classmark updates:

1. The mobile station initiates a location update procedure by sending a
Channel_Request message on the RACH.
2. The BSS performs the immediate assign procedure, as described in
Mobile-Originated Call (Section 3.2).
3. The mobile station establishes the LAPDm link and sends the location update
request and classmark 1 IE. The BTS sends an Establish_Indication
message to the BSC, containing the location update request and classmark
1 IE.
4. The BSC uses the classmark to send mobile station power control
information to the BTS to start power control. It stores the classmark
information and requests an SCCP connection with the MSC.
5. When the BSC receives an SCCP_Connection_Confirm message, it sends a
classmark_enquiry message to the mobile station.
6. The mobile station responds with a classmark_change message
containing the classmark 2 IE. This information is passed to the MSC in a
classmark_updating message. If the mobile station is a phase 1 mobile
station, it responds with an RR_status message which is ignored by the
BSS. In this case, the BSS sets ciphering with the information available
from the classmark 1 IE.
7. The MSC initiates the authentication procedure and on receipt of the
authentication response message, initiates the ciphering procedure. Refer
to Ciphering (Section 3.8) for more information about ciphering.
8. When ciphering is set, the MSC can accept the location update.
164 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.7 Authentication
The authentication procedure ensures that the subscriber identification (IMSI,
TMSI) and the IMEI are valid. The system behavior for non-valid identifications
is at the discretion of the Network Operator. The procedure also validates
the Ki value in the mobile station, and sends the RAND which is used to
calculate the ciphering key.
3.7.1 IMSI/TMSI
When the subscriber accesses the network for the first time, the subscription
is identified by the IMSI sent in the Location_Updating_Request message.
When the NSS has performed authentication and set the ciphering mode, the
VLR assigns a TMSI, in an encrypted format over the Air Interface.
The next time the subscriber connects to the system, it uses the TMSI as its
identification. If the mobile station has changed location area, it includes the
old Location Area Identity. The new VLR interrogates the old VLR for the
authentication information (IMSI and Ki value). The new VLR then assigns a
new TMSI. This is shown in the figure below.
New TMSIs can be assigned by the serving VLR at any time. The subscriber
identity is secure because the TMSI is always ciphered and changed regularly.
BTS BSC MSC VLR

Mobile
Station
info IMSI +
Mobile Station moving and connecting request
in a new location area Ki
service request + TMSI + old LAI

new TMSI MSC VLR
BTS BSC
Mobile
Station

Ki : Individual Subscriber Authentication Key
LAI : Location Area Identity
Figure 18: Location Update with Mobile Station Sending Location Area Identity of Previous VLR
3BK 21222 AAAA TQZZA Ed.08 165 / 304

3 Call Set Up
3.7.2 Authentication Procedure

The following steps describe the authentication procedure:
1. The authentication procedure is initiated by the NSS.
It sends an Authentication_Request message
to the mobile station and sets a guard timer.
This message contains:
Parameters for the mobile station to calculate the response
A ciphering key sequence number.
The ciphering key is calculated from the authentication Key value assigned
to the IMSI or TMSI and the value RAND.
2. The mobile station responds using the RAND and the
value authentication Key assigned to its TMSI or IMSI.
For mobile-originated calls, the mobile station uses:
The TMSI, if available
The IMSI, if no TMSI is assigned.
For mobile-terminated calls, the mobile station uses the TMSI

or IMSI as requested in the Paging message from the network.
For emergency calls, the mobile station uses:
The TMSI, if available
The IMSI, if no TMSI is assigned
The IMEI, if there is no TMSI or IMSI. This can happen when there
is no SIM in the mobile station.
3. When the mobile station sends the Authentication_Response message,

the NSS stops its guard timer and validates the response.If the mobile
station response is not valid, the network response depends on whether the
TMSI or IMSI was used:
If the TMSI was used, the network can request that the mobile station
sends its IMSI
If this is a valid IMSI, but is different from the IMSI that the network
associated with the TMSI, the authentication procedure is restarted with
the correct parameters
If the IMSI is invalid, the network sends an Authentication_Reject

message to the mobile station.
166 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.8 Ciphering
Ciphering is supported in the Alcatel-Lucent 900/1800 BSS to protect
information transmitted on the Air Interface.
This includes:
Subscriber information such as the IMSI
User data
SMS and SS data
Information such as called and calling party numbers.
Ciphering protects the information by using encryption. There are three

different ciphering modes, the use of which depends on the mobile station
classmark and the capability of the BTS.
These modes are:
Encryption using algorithm A5/1
Encryption using algorithm A5/2
No encryption.
The two encryption algorithms are defined in GSM. If either is to be used, both
the mobile station and BTS must have the same encryption capability.
3.8.1 Mobile Station Ciphering Capability

The mobile station ciphering capability depends on whether it is a phase 1
mobile station, a phase 1 extended mobile station, or a phase 2 mobile station.
The following table shows the different mobile station ciphering capabilities.
Mobile Station Type Capability
Phase 1 No encryption and A5/1
Phase 1 Extended No encryption and A5/1 and A5/2
Phase 2 No encryption
No encryption and A5/1
No encryption and A5/2
No encryption and A5/1 and A5/2
Only phase 2 mobile stations can turn off ciphering or change the ciphering
mode during a channel change procedure such as a handover.
The ciphering capability of a mobile station is signalled to the BSS in the
mobile station classmark.
3BK 21222 AAAA TQZZA Ed.08 167 / 304

3 Call Set Up
3.8.2 BSS Ciphering Capability

The Alcatel-Lucent 900/1800 BSS supports both uniform ciphering network
configurations and mixed ciphering network configurations.
A cell can be configured to support one of the following:
No encryption
No encryption and the A5/1 algorithm
No encryption and the A5/2 algorithm.
A uniform ciphering network configuration is where all cells have the same
ciphering capability.
A mixed ciphering network configuration is where the cells have different
ciphering capabilities.
3.8.3 Ciphering Keys

The encryption used on the Air Interface is provided by the physical layer
hardware. This means that it does not distinguish between signaling and user
traffic; therefore, the entire bit stream is encrypted.
The encryption pattern added to the bit stream is calculated by the algorithm
A5/1 or A5/2, using a ciphering key.
For maximum security, the value of the Ciphering Key is not a fixed value. It is
calculated separately by the HLR, BSC and the mobile station for each call.
This means that the value Kc is never transmitted on the Air Interface.
The value Kc must be the same in the HLR, BSC and the mobile station.
It is calculated using:
A value Ki, which is assigned to the IMSI when the user subscribed
to the service
A RAND, sent from the MSC during the authentication procedure.
The resulting value Kc is used to decipher the encrypted bit stream on the
downlink, by the mobile station, and on the uplink, by the BTS.
3.8.4 Ciphering Process

3.8.4.1 Choosing the Ciphering Mode
The ciphering chosen by the BSC for a call depends on:
The algorithms that the Network Operator allows in the network. This
information is sent in the Permitted_Algorithm message from the MSC
during ciphering or external handover procedures.
The ciphering capability of the mobile station. This information is sent to the
BSC in the mobile station classmark
The ciphering capability of the BTS being used to set up the call.
If the mobile station capability is not compatible with that of the BTS or is
not allowed by the Network Operator, then the BSC sets ciphering with
no encryption.
168 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.8.4.2 Setting the Ciphering Mode

The ciphering mode is set as follows:
1. Ciphering is initiated by the MSC by sending a cipher_mode command to
the BSC. This command contains the Permitted_Algorithm message.
2. The BSC compares the permitted algorithms with the mobile station
classmark and the BTS capability. If they match, the BSC sends an
encryption_command message to the BTS containing the value Kc and
the algorithm to be used. If there is no match and ’no encryption’ is
permitted, the BSC sends the encryption_command to the BTS indicating
’no encryption’.
3. If the BTS and mobile station capabilities are not compatible and the
MSC does not allow the ’no encryption’ option, then the BSC sends a
cipher_mode_reject message to the MSC.
4. The BTS sends the ciphering_mode command on the SDCCH to the
mobile station indicating the algorithm or ’no encryption’. If encryption is
to be used the BTS sets its decryption mode ready to receive encrypted
frames from the mobile station.
5. The mobile station either:
Starts the encryption and sends an encrypted Layer 2 acknowledgment
message to the BTS. This prompts the BTS to start encryption mode for
frames sent to the mobile station
Sends an unencrypted level 2 acknowledgment to the BTS.
6. The mobile station sends a ciphering_mode_complete message to

the BTS which is passed transparently to the BSC. The BSC sends a
cipher_mode_complete message to the MSC.
3BK 21222 AAAA TQZZA Ed.08 169 / 304

3 Call Set Up
The following figure shows this process.

MS BTS BSC MSC
d
man
ode com
r ing m
ciphe
s + Kc
nd orithm
omma ermitte
d alg
encryption c p
nd Kc or
mma hm +
de c
o algoreitncryption
ring mo no
ciphe
H)
(SDCC
algorithm or
no encryption
cipher
ing mo
de com
plete
cipher
mode
comple
te
MS : Mobile Station
3.8.4.3 Ciphering During Handover

Only phase 2 mobile stations can change ciphering mode during a handover.
If a phase 2 mobile station using the A5/1 algorithm is handed over to a cell
which supports A5/2 and ’no encryption’, the BSC instructs the target BTS to
set the new ciphering algorithm and sends the value Kc.
If a phase 1 mobile station using the A5/1 algorithm needs to be handed over,
the target cell must support A5/1, as the phase 1 mobile station cannot change
ciphering mode. For mixed ciphering networks, it is normal that the initial
cipher_mode command from the MSC only allows a phase 1 mobile station to
use the ’no encryption’ option, as this is supported by all cells.
170 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
3.9 Tandem Free Operation

Tandem Free Operation (TFO) provides better voice quality by avoiding
unnecessary successive coding and decoding operations in the case of
mobile-to-mobile calls. The importance of TFO is always increasing, as the
percentage of mobile-to-mobile calls increases with the number of subscribers.
Take the example of a call involving two mobile stations, MS 1 and MS 2.
With the TFO feature, the same codec will be used on both BSS.
This improves the speech quality of mobile-to-mobile calls, and particularly
when using the half-rate codec.
Without TFO
One GSM coding and decoding scheme (codec), is used between MS 1
and Transcoder 1, then A/law coding is used (at 64 kbit/s) between the two
transcoders and finally one GSM codec is used between Transcoder 2 and
MS 2. This means a loss of quality for the speech call.
With TFO.
The intermediate transcoding realized by the two involved transcoders is
avoided. The same codec is used on both BSS. This improves the speech
quality of mobile-to-mobile calls, particularly when using the half-rate codec.
This allows a wide use of the half-rate codec, with a good level of speech
quality, in order to save resources in BSS.
Note: As VGCS is point to multipoint on the downlink, it is not compatible with TFO.
3BK 21222 AAAA TQZZA Ed.08 171 / 304

3 Call Set Up
3.9.1 TFO Process

TFO can be applied whenever the two mobile stations use the same codec.
To satisfy this condition, after TCH allocation, the two BSS negotiate at each
side a common codec (full-rate, half-rate or enhanced full-rate), by using an
in-band protocol in the speech frame. The following figure shows an example
of TFO call establishment.
BTS A BSC A TC A TC B BSC B BTS B
Channel activation Channel activation

TFO enabled PCM samples TFO enabled 1
TRAU frames TRAU frames
CON_REQ CON_REQ
DL_ACK
DL_ACK 2
TFO_REQ
TFO_REQ TRAU frames
TRAU frames 3
TFO_ACK
TFO_ACK
Codecs match
4
TFO frames TFO_ON
TFO_ON
5
TFO REPORT (TFO STATUS= ON)
TFO REPORT (TFO STATUS= ON)
PCM : Pulse Code Modulation

TC : Transcoder
TFO : Tandem Free Operation
TRAU : Transcoder Rate Adaptation Unit
Figure 19: Example of TFO Establishment
Referring to the figure above, the call establishment is as follows:

1. At call establishment, the BSC sends the Channel_Activation message to
the BTS, containing information related to TFO.
2. TRAU frames are exchanged between the BTS and the Transcoder. PCM
samples are exchanged between the TRAUs. One TRAU frame is stolen
from the BTS by the Transcoder, to send TFO configuration information (in
the con_req message).
3. As soon as the TRAUs receive the information that TFO is enabled in the
con_req message, (and also the TFO configuration information), they send
the tfo_req message, within PCM speech samples, to indicate that the
TRAUs are TFO capable. Meanwhile, the TRAUs acknowledge the con_req
message to the BTS with the dl_ack indication.
4. The TRAUs acknowledge that the tfo_req message is received by sending
a tfo_ack indication.
5. The same codecs are then used on both sides. The TRAUs can exchange
TFO frames.
6. The BTS are made aware of the exchange of TFO frames by tfo_on. The
BSC is informed via a tfo_report message on the Abis Interface.
172 / 304 3BK 21222 AAAA TQZZA Ed.08

3 Call Set Up
The Alcatel-Lucent TFO implementation is fully compliant with the GSM

standard and additionally provides:
As an operator choice, the Alcatel-Lucent BSS is able to force the distant

BSS (Alcatel-Lucent or not) to overcome ETSI codec choice rules, in
order to optimize voice quality and load management. This mechanism is
patented by Alcatel-Lucent.
Codec optimization, to take into account that the two mobile stations may
use the same codec, but a better codec is available on both parts.
3.9.2 TFO Functional Architecture

The TFO procedure is defined between two TRAUs. When TFO is possible
between two mobile stations, TFO frames (similar to TRAU frames) are
transferred between the two TRAUs on the A Interface. These frames contain
coded speech streams, and may also contain embedded TFO messages. They
are supported by a 0.5 kbit/s signaling channel between two Transcoders,
emulated during the TFO negotiation phase. This channel uses one bit (Least
Significant Bit) every 16 PCM samples, regularly stolen on the 64 kbit/s circuit.
Note that when TFO frames are transmitted, speech is nevertheless coded to
G.711 law and sent to the A Interface on the remaining MSB bits of the PCM
samples. This allows a faster reversion to normal operation mode if required.
Moreover, lawful interception in the MSCs is still possible. The Alcatel-Lucent
solution avoids any Ater supplementary links, because the BSC-Transcoder
TFO messages are exchanged through the BTS and the Abis Layer 3 protocol.
When the same codec is used on both sides, no TFO negotiation is needed
between the TRAUs.
When the same codec is not used on both sides, TFO negotiation is needed
between the TRAUs. In this case, TFO communication is possible between the
two BSS, but the TRAUs do not use the same speech codec. TFO negotiation
and resolution by the BSS are needed. When detecting the mismatch, each
TRAU sends to the other (using TFO messages) the codec locally used, and the
list of possible codecs. At each side, the BSS determines the matching codec.
On each BSS, the same algorithm is implemented. This algorithm attempts to
find a matching codec using the information given by the TRAU. If a common
codec can be found, an internal intracell handover is performed to change the
speech codec used locally, and TFO exchange of the speech stream begins. A
logical parameter, configurable at the OMC-R, allows the BSC to ignore the
load in the cell and to force the handover in order to solve codec mismatch
situations. If no common codec can be found, or internal intracell handover is
not possible, TFO mode is given up, and the system reverts to normal mode.
3BK 21222 AAAA TQZZA Ed.08 173 / 304

3 Call Set Up
3.9.3 TFO Optimization and Management

TFO is managed by the OMC-R operator, on a per cell basis. Several functions
are introduced to provide full control of TFO optimization, load regulation,
speech quality, or Adaptive Multiple Rate (Section 6.2.8) codec support.
3.9.3.1 TFO Optimization

For a better speech quality, TFO optimization allows a new TFO negotiation
on an ongoing TFO mobile-to-mobile call, to find a better common codec, in
terms of speech quality. Therefore, enhanced full-rate coding is considered
better than full-rate coding which is considered to be better than half-rate
coding. The Enable TFO Optimization feature can be enabled or disabled per
cell at the OMC-R.
In some cases, both sides may use the same codec, but a better codec is
available at each side and may be used (e.g., half-rate is used at both sides,
but full-rate is possible). The procedure is then the same as the modification of
speech codec in mismatch status, except that it takes place only when TFO
frames are already exchanged. The TFO messages exchanged between both
TRAUs are then embedded in TFO frames.
3.9.3.2 TFO Negotiation Control

For better traffic load regulation, Alcatel-Lucent defined the function "Force
TFO half-rate when loaded" to give control of load regulation precedence over
TFO to the operator. This function can be enabled or disabled, per cell, at the
OMC-R, and allows the BSC to take into account the load in the cell while
building the list of supported codec types. If the cell is loaded, only half-rate (if
possible) will be included in the list. If the distant BSS supports TFO but not
half-rate, the function "Force TFO half-rate when loaded" allows the BSC in
this case to recompute the list of supported codec types by inserting full-rate
and enhanced full-rate in the list.
Therefore, the function "Force TFO half-rate when loaded" leads to three
different behaviors, depending on three possible values of the corresponding
flag:
TFO half-rate not forced. No filtering on the load is done. The load is not
tested and all the codec types supported by the call and by the cell are listed
in the supported codec type list
TFO half-rate only. Filtering is done on the load, half-rate is forced if the cell
is loaded and the mobile station supports half-rate, and if this codec type
is authorized in the cell. The list of supported codec types is restricted to
the half-rate codec type. As a consequence, if the distant side supports
half-rate, then the distant side will do an intracell handover to use half-rate,
and TFO will go on with half-rate. If the distant side does not support
half-rate, TFO will not be possible
TFO half-rate preferred. Filtering is done on the load, but TFO is preferred
to half-rate. In the case of a load situation, only half-rate is sent in the list of
preferred codecs. But if the distant BSS does not support half-rate, a new
list is computed, without taking into account the load in the cell.
174 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4 Call Handling
This section provides an overview of Call Handling and describes the

supervision of a call in progress.
3BK 21222 AAAA TQZZA Ed.08 175 / 304

4 Call Handling
4.1 Overview
In order to provide effective management of calls in the BSS, it is necessary
to ensure:
Maximum perceived signal quality with minimum perceived interference
Call continuity regardless of changes in propagation conditions or change

of location of the mobile station.
Given that spectrum is limited, this must be accomplished with maximum

resource reuse. Another important factor for the customer (and the operator as
well) is power efficiency to reduce overall power consumption and prolong the
autonomy of the mobile station under battery operation.
The supervision of calls in progress is provided by the Call Handling function.
Call Handling, with associated features, implements needed changes in the
required teleservice to maintain call quality and continuity.
Call Handling functions and features include:
In-Call Modification
Frequency Hopping
Discontinuous Transmission
Radio Power Control
Handover
Overload Control
Call re-establishment by the mobile station.
Note: A VGCS call uses the same general call handling procedures as a standard
call; any exceptions are described in the relevant procedure descriptions below.
176 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.2 In-Call Modification

In-call modification allows the teleservice to be changed during a call. This
means that a call does not have to be cleared, and a new call established, if
more than one teleservice is to be used.
The different types of in-call modification are:
Alternate between speech and a transparent data service

Alternate between speech and a non-transparent data service
Change from speech to a transparent data service
Change from speech to a non-transparent data service
Alternate between speech and transparent fax group 3

Alternate between speech and non-transparent fax group 3
Data rate change for transparent fax group 3
Data rate change for non-transparent fax group 3.
Calls requiring a change of service have to negotiate a ’dual-service’ before the

normal assignment procedure. This is indicated in the Set_Up message, which
is described in Call Set Up (Section 3).
Note: Changing the data rate of a fax call is not a true in-call modification procedure,
as the teleservice is not changed (no dual-service negotiation).
The main difference between the in-call modification procedure and a change
of data rate for fax are as follows:
The in-call modification procedure is triggered by a message from the

mobile station
The data rate change for fax is triggered by in-band signaling from the
fax machine to the MSC.
Both procedures use existing resources, therefore no new resources need to

be allocated. All full-rate traffic channels can be used for speech or data at any
of the defined data rates.
Both procedures use the mode ’modify procedure’ to change the transmission
mode. This is basically a normal assignment procedure but instead of a new
channel being assigned, a new mode is assigned.
3BK 21222 AAAA TQZZA Ed.08 177 / 304

4 Call Handling
4.2.1 In-Call Modification Procedure

In-call modification is initiated from a mobile station. This can occur during a
call to a correspondent on the public telephone network or to a mobile station.
For a mobile-station-to-mobile station call, both mobile stations must negotiate
a dual service during call establishment.
The process is as follows:
1. The mobile station initiates the procedure by sending a Layer 3 Call Control
modify message to the MSC, indicating the new mode. If the data call
direction is different from the original call set up, then this message contains
an indicator to reverse the call direction. The mobile station starts a guard
timer for the procedure.
2. The MSC checks the modify message. If it can accept the mode
change, it starts the normal assignment procedure by sending an
Assignment_Request message and starting a guard timer. This message
contains a channel type (speech or data plus data rate).
3. The BSS handles the normal assignment procedure as if assigning a traffic
channel during call set up (described in Call Set Up (Section 3)), with
the following exceptions:
When the BSC has checked and accepted the Assignment_Request

message, it does not assign a new traffic channel. This is because
it already has a traffic channel assigned for the transaction. The
transaction is identified by the SCCP connection on which the
Assignment_Request message was received
The Channel_Activation and Channel_Activation_Acknowledge

messages are replaced by the mode_modify and mode_modify
acknowledge messages.
4. When the MSC receives the Assignment_Complete message from the BSC,
it sends a Layer 3 CC modify_complete message to the mobile station.
This informs the mobile station that the procedure is successfully completed,
and the mobile station can start transmitting in the new mode.
178 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.2.2 Circuit-Switched Group 3 Fax Data Rate Change

Group 3 facsimile equipment can change the data transmission speed to
reduce the error rate.
Fax data rates can be:
9600 bit/s
4800 bit/s
2400 bit/s
1200 bit/s.
The Alcatel-Lucent 900/1800 BSS supports both transparent and

non-transparent fax transmission.
The BSS supports the Group 3 fax data rate change by:
In-band signaling for non-transparent fax

For non-transparent fax transmission, the data rate change is handled
within the BSS, using in-band signaling. This means that the frame size is
signalled in the frame by a "frame delimiter" field. The Radio Link Protocol in
the BTS uses this information to control the data flow on the Air Interface.
The BSS does not need to change the channel mode
The mode modify procedure for transparent fax.

Transparent fax frames are passed transparently through the BSS.
Therefore, in-band signaling cannot be used within the BSS. The Group
3 fax equipment informs the MSC of a data rate change using in-band
signaling. The MSC then initiates a mode modify procedure using the
Assignment_Request message.
This procedure is the same as the mode modify procedure for in-call
modification, except that the MSC does not send a Layer 3 Call Control
mode_modify_complete message. This is because the procedure was not
triggered by a Layer 3 CC modify message from the mobile station. When
the MSC receives the Assignment_Complete message from the BSC, it
sets the new data rate to the correspondent.
4.2.3 Error Handling

The Alcatel-Lucent 900/1800 BSS tries to provide the highest level of service at
all times. In general, if errors occur during an in-call modification, the BSS tries
to revert to the old mode to keep the call active.
For example, if the mobile station does not reply to the channel_mode_modify
message from the BSC, it is assumed that it is still active but in the old mode.
The BTS, however, has set the new mode. The BSC sends a mode_modify
message to the BTS indicating the old mode. If the BTS acknowledges that it
has reverted to the old mode, the call is kept active.
3BK 21222 AAAA TQZZA Ed.08 179 / 304

4 Call Handling
4.3 Frequency Hopping

Frequency Hopping is a method to increase frequency reuse and improve the
system’s ability to cope with adjacent channel interference.
The Frequency Hopping algorithm can be either random or cyclic. Associated
(i.e., paired) uplink and downlink frequencies are always +/-45 MHz.
There are two major types of frequency hopping:
Baseband Frequency Hopping (Section 4.3.1)
Synthesized Frequency Hopping (Section 4.3.2).
Frequency Hopping improves BSS-mobile station performance by providing

two types of diversity:
Frequency diversity
Frequency diversity averages the effects of signal fading by using several
frequencies to improve transmission performance. Obstacles such as
buildings produce fading by reflecting the signal out of phase with the main
signal. Each frequency is affected differently by fading.
After error correction information is added to the data, it is encoded so that
the data is split into packets and the information is repeated. This creates
redundant information which is transmitted in bursts on the Air Interface.
With Frequency Hopping, each redundant information burst is transmitted
on a different frequency. This enables the original data to be reconstructed
from the received flow, even if errors occur due to fading.
In this way Frequency Hopping improves transmission performance.
Interference diversity.
Interference diversity spreads the co-channel interference between several
mobile stations. In high traffic areas, the capacity of a cellular system is
limited by its own interference; that is, the interference caused by frequency
reuse. Interference Diversity minimizes the time during which a given user
on a given mobile station will experience the effects of such interference.
180 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.3.1 Baseband Frequency Hopping

A Mobile Allocation is a set of all the frequencies available for frequency
hopping. When the Frequency Hopping procedure is implemented, a group of
mobile stations is assigned to a Mobile Allocation.
When a traffic channel is set up in a cell where Frequency Hopping is active,
the traffic channel is assigned:
A particular timeslot
An FHS
An FHS is defined as the subset of frequencies within the MA to be used by
a given cell for Frequency Hopping.
A MAIO
The MAIO indicates the initial hopping frequency of the traffic channel within
the FHS. Use of the MAIO ensures that each traffic channel is assigned a
different frequency during hopping.
An HSN
The HSN supplies the identifying number of an algorithm which is used
to calculate the next frequency in the FHS on which the traffic channel
transmits. There can be up to 63 different HSN algorithms, all of which are
pseudo random. Within a given FHS, only one algorithm is used to avoid
collisions. An HSN of zero means a cyclic use of the frequencies.
An example of Frequency Hopping is shown in the figure below. Because HSN

= 0, hopping occurs in a sequential manner. With a non-zero HSN, each of
the three traffic channels would hop in a random fashion determined by the
algorithm corresponding to the HSN.
Within this FHS
the HSN=0
Frame Frame Frame Frame
n n+1 n+2 n+3
Assignment
for TCH 1:
TS=1 TCH1 on TS1 f1 f2 f3 f1
MAIO=0
MAIO=0
HSN=0
TCH2 on TS2
f2 f3 f1 f2
MAIO=1
TCH3 on TS3
f3 f1 f2 f3
MAIO=2
f : Frequency
FHS : Frequency Hopping System
MAIO : Mobile Allocation Index Offset
HSN : Hopping Sequence Number
TS : Timeslot
3BK 21222 AAAA TQZZA Ed.08 181 / 304

4 Call Handling
4.3.2 Synthesized Frequency Hopping

Synthesized Frequency Hopping functions in a similar fashion to Baseband
Frequency Hopping, but is performed at a different location. Instead of
switching each timeslot between traffic channels, the channel assigned to a
timeslot is assigned to a fixed Carrier Unit (or TRE).
The Carrier Unit/TRE changes frequency with each TDMA frame in accordance
with the HSN algorithm selected, in the same manner as above. Therefore,
instead of the channel hopping from one fixed transceiver to another, the
transceiver itself hops from one frequency to another, in both cases, according
to the algorithm and parameters selected.
Synthesized Frequency Hopping has the advantage of allowing an FHS to
contain one more frequency than the number of Carrier Units/TREs in the
system. This is particularly useful in some microcellular applications where only
one transceiver is available for Frequency Hopping.
Note: Normally, in both Frequency Hopping schemes (Baseband and Synthesized),

timeslot 0 (TS0) is not available for Frequency Hopping. This is because
it carries the BCCH, which must always be at maximum power and on a
frequency known to mobile stations in Idle mode in the cell.
4.4 Speech Transmission

Speech is transmitted over the air in the following ways:
Continuous transmission
Discontinuous transmission.
The system also uses Voice Activity Detection (VAD) when transmitting.
The two transmission types and VAD are described separately. In addition,
discontinuous transmission from the BSS to the MS and from the MS to the
BSS is explained in detail.
4.4.1 Continuous Transmission

Sound is continuously encoded into digital information, even when no one
is talking.
In normal conversation, only one participant at a time talks. This is used by the
system to its advantage, by transmitting only when someone is speaking.
182 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.4.2 Discontinuous Transmission

Discontinuous Transmission and VAD work together to decrease the average
transmission time on a channel. By transmitting only when actual speech is
present, the system reduces the interference level generated by the network in
both the uplink and downlink directions and saves power.
In tandem with Frequency Hopping, this improves spectrum efficiency without
jeopardizing the quality of the telephony service.
Only actual speech is digitally encoded and transmitted. During the non-speech
phase (silent periods), noise/comfort mode information is sent once every 480
ms instead of once every 20 ms for speech.
In this way the system:
Improves spectral interference
Increases power savings.
By transmitting at a reduced rate of 1 in 24 during the silent phases, the power

autonomy of the mobile station improves.
Discontinuous Transmission does not occur during half-rate speech or data
modes. It can be activated for either the uplink or the downlink or both.
The receivers of Discontinuous Transmission information can automatically
detect that the transmitter is in Discontinuous Transmission mode by the
reception of Silence Indication (SID) messages.
During quiet periods SID messages are sent instead of speech bursts. SIDs
carry noise information about background noise. This information is used to:
Let the receiver know that the link is still open
Provide comfort noise. Users of telephones prefer to hear background noise

rather than silence. Complete silence disturbs the listener.
Provide measurements of the link quality and timing advance. If there are
no bursts of data over the Air Interface for a particular channel, no power
level control and quality can be performed.
To eliminate the noise side effects generally known as banjo noise, the operator
can ban Discontinuous Transmission on the downlink for all calls that are
established on the BCCH TRX, without hopping, for all types of BTS. This is
achieved using the FORBID_DTXD_NH_BCCH parameter. The parameter can
be set to one of two values:
0. This is the default value, and allows Discontinuous Transmission on the

downlink for all calls that are established on the BCCH TRX
1. This bans Discontinuous Transmission on the downlink for all calls that
are established on the BCCH TRX.
4.4.3 Voice Activity Detection

Voice Activity Detection (VAD) is used to detect when there is speech, silence
or just background noise. The VAD device is located in the Transcoder. Once
the VAD detects speech, it starts transmitting speech bursts. After four bursts
of detected silence, the VAD goes back into silent mode, and SID information
frames are transmitted (i.e., the comfort noise generation is activated).
3BK 21222 AAAA TQZZA Ed.08 183 / 304

4 Call Handling
4.4.4 BSS Discontinuous Transmission Towards Mobile Station

Downlink Discontinuous Transmission is activated on a per call basis by
combining information from the MSC and the OMC-R.
The MSC informs the BSC about its downlink Discontinuous Transmission
preference. It does this via the Downlink Discontinuous Transmission flag in the
Assignment_Request or Handover_Request messages on a per call basis.
The OMC-R can enable or disable the possibility of downlink
Discontinuous Transmission per BSC via the Discontinuous
Transmission_DOWNLINK_ENABLE parameter. This is a static parameter which
can be set via the CMISE command M_ LOGICAL_PARAM_MODIFY. The overall
system reaction is shown in the following table.
MSC Downlink_ Result

OMC-R Discontinuous Discontinuous Discontinuous
Transmission_ DOWNLINK_ Transmission Flag Transmission
ENABLE (per BSC basis) (per call basis) Flag
True Allowed ON
True Unavailable/not OFF

allowed
False Allowed OFF
False Unavailable/not OFF

allowed
Table 5: Downlink Discontinuous Transmission Status in Channel Activation
The MSC requests no downlink Discontinuous Transmission during mobile

station-to-mobile station calls, where double clipping can occur if both ends
perform Discontinuous Transmission. This can have a staccato-like effect
on speech.
The BTS tells the Transcoder to perform Discontinuous Transmission by setting
the Discontinuous Transmission bit in the speech frame.
In the BSS, the Transcoder is responsible for Discontinuous Transmission
operation.
184 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
In the BTS, the information is processed in the FU in the following way:

1. When the Transcoder detects voice activity it informs the FU, using in-band
signaling. The speech signaling flag is set in the speech frame.
2. Every 20 ms the FU receives either speech frames or SID frames containing
background noise characteristics.
3. At the end of the speech period (four bursts of detected silence) the FU
sends a SID frame over the Air Interface.
4. During speech inactivity, the last received SID frame is sent at regular 480
ms intervals rather than at 20 ms. Otherwise dummy bursts are sent.
These dummy bursts are:
Transmitted for traffic channels on the BCCH frequency, due to the need
for constant transmission on the BCCH frequency
Not transmitted for traffic channels on other frequencies.
Note: The BTS uses the measurement_result message to inform the BSC
that Discontinuous Transmission is operating. The BSC compensates for
Discontinuous Transmission when calculating power control and handover.
4.4.5 Mobile Station Discontinuous Transmission Towards BSS

The OMC-R operator controls whether a mobile station can perform
Discontinuous Transmission towards the BSS per cell. This information is sent
in cell options information (sys_info 3 , and sys_info 6 on the Air Interface).
The following table shows the available operator options.
Option Description
Will perform This forces the mobile station to use Discontinuous

Discontinuous Transmission. It reduces the call quality but also
Transmission reduces interference in the cell and saves mobile
station battery power. During silent phases only
1 in 24 bursts are sent, which greatly reduces
interference.
Can perform This allows the mobile station to choose either quality
Discontinuous by not using uplink Discontinuous Transmission,
Transmission or power-saving by using uplink Discontinuous
Transmission.
Cannot perform The OMC-R operator has decided, due to low

Discontinuous interference, to have improved speech and
Transmission measurement control on the uplink side.
Table 6: Operator Discontinuous Transmission Options
The Transcoder detects that the mobile station is in Discontinuous Transmission

mode by the reception of SIDs.
Note: There is a small quality reduction due to the fact that VAD only starts sending
speech when a user starts to talk. This can cut the start of each speech activity.
Power control and handover are also affected, as the BTS has fewer incoming
messages with which to calculate power and interference.
3BK 21222 AAAA TQZZA Ed.08 185 / 304

4 Call Handling
The following figure shows the different forms of transmission.
Sound continuously encoded DTX during ’Silence’ in uplink
DTX during ’Silence’ in downlink DTX during ’Silence’ in up and downlink
Continuous Transmission
Discontinuous Transmission
DTX : Discontinuous Transmission
Figure 20: Different Forms of Discontinuous Transmission
4.5 Radio Power Control

Radio Power Control operates independently, but in a co-ordinated manner with
the handover to provide reliable service to the user.
Both directions of the radio link between the mobile station and the BTS
are subject to continuous power adjustments. The power adjustment of the
BTS and the mobile station are under the control of the BSC (see Radio
Measurements (Section 4.6.2)). RPC improves spectrum efficiency by limiting
intra-system interference. It also increases the autonomy of the mobile station
by saving battery power.
The reasons for changing the mobile station power level are:
Uplink power level too high or too low
Uplink link quality too low, or using power resources beyond quality
requirements of the call.
Similarly, the reasons for changing the BTS power control are:
Downlink power level too high or too low
Downlink link quality too low, or using power resources beyond quality
requirements of the call.
186 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.5.1 BTS Radio Power Control

The mobile station performs power measurements of radio signals being
transmitted by the BTS. The mobile station, via the SACCH, regularly sends a
measurement_report message to the BTS indicating the quality and strength
of the downlink plus measurements of neighboring cells. This information is
combined with uplink measurements taken by the BTS and sent to the BSC in
the measurement_result message.
The BSC then alters the BTS power, based on the measurement information it
receives from the mobile station. The maximum power level is limited by the
maximum power of the BTS, and also by the maximum power allowed in the cell.
The BTS power can be adjusted further than Unbalanced Output Power or
Cell Shared.
The BTS power can be reduced by the operator due to the following parameters:
BS_TXPWR_MAX
T3106-D
T3106-F
PWR_ADJUSTMENT.
The first 3 parameters on one side and the last one on other side are computed
separately. If one or the other is changed by the operator, the left one is
changed by the OMC.
4.5.2 Mobile Station Radio Power Control

The BTS measures the signal power transmitted by the mobile station. The
resulting measurements are combined with the measurement_report message
from the mobile station and are sent to the BSC in the measurement_result
message. The BSC sends commands to change the power level of the mobile
station as needed. The maximum power level is limited by the maximum power
of the mobile station, and also by the maximum power allowed in the cell.
Power control can be applied to traffic channels and Stand-Alone Dedicated
Control Channels.
3BK 21222 AAAA TQZZA Ed.08 187 / 304

4 Call Handling
4.5.3 Radio Link Measurements

Due to interference and signal quality problems on the Air Interface, the uplink
and the downlink transmissions are constantly measured to maintain maximum
efficiency of the air waves. A balance is maintained between the transmission
power, which can interfere with other cells using the same frequency, and
the quality of the actual link.
The following table shows the measurements used to achieve this balance.
Measurement Description
Signal strength Signal strength is calculated on both active and

inactive channels.
On active channels, this measurement is used to
provide the actual strength of the signal received
from the transmitter.
Inactive channel strength provides measurement of
interference levels.
Signal quality The signal quality of a channel is calculated on

the average Bit Error Rate on a particular channel.
BER is a standard quality calculation in radio
transmission.
Absolute mobile This is estimated by measuring the Time Of

station-BS distance Arrival (TOA) of the received burst at the BTS for
each allocated timeslot. The TOA is based on
transmission distance and not the actual ground
distance travelled. The calculation of one bit period
(3.69 µs) corresponds to 550m.
The statistical parameters of signal level and quality are obtained over a
measurement period. This period is called the ’Reporting Period’. The reporting
period for a traffic channel is 104 TDMA frames (480 ms). The information is
transmitted in the SACCH frames.
188 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.5.4 Power Control Decision and Handover

At every measurement interval, the BSC receives:
Pre-processed power measurement information (uplink and downlink)
Timing advance (distance information)
Power level information about neighboring cells (only the best six are
transmitted).
The BSC uses this information to perform power control by:
Lowering the power level in the uplink or downlink, as this has little effect
on the quality of the link
Increasing the power on the uplink or downlink if the link quality/level is low
Producing a handover alarm (refer to Handover Detection (Section 4.6.3) for

more information)
Taking no action, if the quality/level balance is acceptable.
The following figure illustrates the measurements described previously, as

well as power-control flow. Figure 21 shows how power control maintains
optimum quality and power levels.
MS BTS BSC MSC
Interruption of SACCH frames
start counter conn

failu ection
re in
dica
caus tion
e va
lue
e clear
releas requ
an nel est
RF ch
and
c omm e
clear valu
use
din g ca
inclu
MIE
MS : Mobile Station
TX : Transmitter
3BK 21222 AAAA TQZZA Ed.08 189 / 304

4 Call Handling
Note: The signal and quality levels are converted into the ranges Received Signal
Level and Received Signal Quality respectively. Each range is classed from
0-63 (Received Signal Level where 63 is high) and 7-0 (Received Signal
Quality where 7 is poor).
High Quality
Signal level low

Desired
Increase power Signal level too high
balance
R output Decrease power output
no
X change
Q
U
A
L
Signal level too high
Quality bad Quality bad
Increase power output Handover desired
Low Quality High Signal Level

Low Signal Level RXLEV
RXQUAL : Received Signal Quality

RXLEV : Received Signal Level
Figure 21: Power Output Balancing Based on Received Quality and Signal
Levels
190 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.5.5 Change Power Levels

The BSC controls the power levels of the BTS and the mobile station.
The BTS power level can be altered down from its maximum power. This is done
in 2 dBm steps to a minimum of -30 dBm from the maximum level. The BSC
informs the BTS of the new power level via a BS_power_control message.
The mobile station power level can be altered in steps of 2 dBm. The following
table shows the maximum and minimum power ranges of mobile stations.
Mobile Station Phase GSM

850/900/1800/1900 Max Power Min Power
Mobile station phase 1, GSM 900 43 dBm (20 W) 13 dBm
Mobile station GSM 850 39 dBm (8 W) 13 dBm
Mobile station GSM 1900 33 dBm (2 W) 0 dBm
Table 7: Mobile Station Maximum and Minimum Power Ranges
The maximum power setting of a mobile station is based on two factors: its
classmark (its physical maximum power rating), and the maximum mobile
station power setting for the cell.
Each cell can limit the maximum power level for all mobile stations in the cell.
For example, a 20 W mobile station can be limited to 5 W maximum power if
that is the maximum mobile station power level allowed in the cell. However, a 1
W mobile station can never exceed 1 W, and can therefore never reach the
5 W maximum allowed in the cell.
The BSC informs the BTS of the new power levels via the BS_power_control
message. The BTS in turn transmits a power_command to the mobile station
over the SACCH.
Changing power from one power level to another happens gradually. The power
level changes by 2 dB every 60 ms, until the desired level is reached.
3BK 21222 AAAA TQZZA Ed.08 191 / 304

4 Call Handling
4.6 Handover
A handover changes an active call from one channel to another channel. The
new channel can be in the same cell or another cell.
The types of handover are:
Internal
External
Directed retry
Incoming emergency
Fast traffic
UMTS to GSM.
Handovers ensure a high level of call quality. They are performed when the
BSS detects that the call quality has dropped below a defined level, and the
call can be better supported by a different channel.
The call quality can drop due to problems in the cell, such as an interface or
an equipment problem. Call quality can also be affected simply because the
mobile station has moved to an area where the radio coverage from another
cell is better.
The BSS detects the need for a handover by:
Measuring the Air Interface channel quality, mobile station and BTS power
outputs and the timing advance
Using an algorithm to see if the received information conforms to the criteria

for handover
Selecting a more suitable channel from a list of target cells and their
available channels.
If the BSS decides that a handover is required, the exact sequence of events
depends on the type of handover to be performed.
In all cases:
A new channel is assigned, ready to support the call
The mobile station moves over to the new channel

On successful completion of the handover, the system clears the resources
for the old channel.
192 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.6.1 Principal Handover Types

The following sections describe the principal types of handover.
4.6.1.1 Internal Handover

Internal handovers take place between cells controlled by the same BSC. This
can include channel changes within the same cell. For more information about
these handover cases, refer to Target Cell Evaluation (Section 4.6.4).
4.6.1.2 External Handover

External handovers take place between cells controlled by different BSCs.
These can be under the control of the same MSC or of different MSCs. For
more information about these handover cases, refer to Target Cell Evaluation
(Section 4.6.4).
4.6.1.3 Directed Retry Handover

Handovers can also be performed when there is congestion in a cell. If
congestion exists, the traffic channel assignment can be queued. For more
information about congestion management, refer to Congestion (Section 3.5).
If there is no available traffic channel for the normal assignment procedure, a
Directed Retry can be performed. A Directed Retry is an attempt to assign a
mobile station to a traffic channel in a cell other than the serving cell.
There are two types of Directed Retry:
An Internal Directed Retry without queueing attempts to hand over the call
to a traffic channel of a neighbor cell controlled by the same BSC.
An External Directed Retry attempts to hand over the queued call to a traffic
channel of a neighbor cell which is controlled by a different BSC.
4.6.1.4 Secured Incoming Handover

The ability to keep free resources in a cell for incoming emergency and power
budget handovers is provided on a cell basis. When the resource threshold is
reached, assignments and other handover types are handled as if the cell was
completely congested. Once such a request is queued, a directed retry can be
performed as usual. The free resources can also be accessed in the case of a
full-rate to half-rate handover for AMR calls, because it allows half a resource
(full-rate to half-rate) to be freed from the cell point of view. The feature
improves the quality of service, as it helps to limit the number of lost calls.
4.6.1.5 Fast Traffic Handover
The fast traffic handover searches in the whole cell for a mobile which can
perform a handover to a not-loaded neighbor cell if the received signal level of
the BCCH is good enough. It is much more efficient than the forced directed
retry when the overlap of adjacent cells is reduced, e.g., in the case of single
layer networks, or for deep indoor coverage (if the umbrella cell does not
totally overlap the microcells).
3BK 21222 AAAA TQZZA Ed.08 193 / 304

4 Call Handling
4.6.1.6 UMTS-to-GSM Handover

For circuit-switched services, the BSS supports handover from UMTS to GSM.
The handover from GSM to UMTS is not supported in this release of the BSS.
A hard handover is performed from the UTRAN to the GSM BSS between a
UMTS core network and a 2G MSC. This handover is regarded by the BSS as
a GSM inter-BSS handover. The signaling procedures, from the BSS point of
view, rely almost on the normal GSM procedures.
For packet-switched services, the current 3GPP standard does not allow
handover with channel preparation. Therefore, the UMTS mobile station
receives the 2G radio resource cell change order Information Element from the
UTRAN in the Inter System handover message. The UMTS mobile station then
performs an access request in the GPRS cell. From a BSS point of view, the
UMTS mobile station is regarded as a 2G mobile station when it indicates that it
has selected a GSM cell.
4.6.1.7 Load-Based 3G Handover Filtering

Load-Based 3G Handover Filtering lets the BSS reject an incoming 3G
handover when the G2 target cell is loaded and the MS is still within UTRAN
coverage. The feature can be activated and de-activated. Load-based
handover filtering only applies to service or traffic handovers. That is, handover
requests with the cause "better cell", "traffic" or "directed retry". A handover
cause indicating a problem in uplink or downlink signal quality or signal strength
is considered an emergency handover request and is accepted.
When load-based handover filtering is enabled, the BSC regularly calculates
the cell load of the 2G cells to assess their 3G_HOReject_Load_State. The
BSC compares the last averages of the traffic load with an O&M threshold to
determine cell load state. The BSC uses the THR_CELL_LOAD_3G_REJECT
parameter to set the load threshold determining whether a 3G-to-2G handover
request is rejected or accepted. If THR_CELL_LOAD_3G_REJECT is set to 100 %,
the feature is de-activated. Note that even if this feature is not activated, the
BSC still calculates cell load, which is used for other handover procedures as
well.
Upon receipt of a 3G to 2G handover request:
1. The BSC checks the target cell traffic load by comparing the current load
to the threshold in THR_CELL_LOAD_3G_REJECT.
2. If the target cell is in 3G_HOReject_Load High State , the BSC checks the
handover cause IE given in the BSSAP handover request message.
3. If the handover cause IE does not indicate an emergency handover, the BSC
rejects the HO request. Otherwise the request is accepted.
4. After rejecting the HO request, the BSC send a Handover_Failure
message with the cause indicating "no Radio resource available" and
the Cell Load Information.
194 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.6.2 Radio Measurements

The BTS constantly monitors the radio link by:
Measuring the received signal strength for active channels
Measuring the received signal quality for active and inactive channels
Measuring the received signal timing for active channels

Collecting signal strength and quality measurements from the mobile
station for the active channel
Collecting adjacent cell BCCH signal strength measurements from the

mobile station (adjacent cell BCCH frequencies are sent to the mobile
station in the sys_info 5 message on the SACCH).
The mobile station sends its measurements to the BTS in a Layer 3 Radio
Resource measurement_report message on the SACCH. The mobile
station and BTS measurements are passed to the BSC in a Layer 3 RR
measurement_result message. These messages are sent once per
multiframe and are processed by the BSC.
The BSC uses this information to:
Perform power control for the BTS and mobile station
Calculate whether a handover is needed
Make traffic channel quality tables
Make the target cell list

Make a handover decision.
4.6.2.1 Power Control

For more information about BTS and mobile station power control, refer to
Power Control Decision and Handover (Section 4.5.4).
From a handover point of view, no handover decision is made due to signal
quality until the power levels have been set to maximum.
4.6.2.2 Need for Handover

The BSC calculates the need for a handover using an algorithm, the use of
which is described in Handover Detection (Section 4.6.3).
4.6.2.3 Target Cell List
A target cell list can be made by the BSC using the neighbor cell BCCH
measurements sent by the mobile station. This is used to evaluate whether a
neighbor cell can provide a better channel than the existing one.
4.6.2.4 Handover Decision
Handover decision is based on averaged measurements and the results are
averaged over a period of time. For example, the BSC detects the need for
a handover, based on one measurement that may have been caused by
freak conditions changing the signal propagation for a short period. This
measurement is averaged with other measurements and a handover decision
may or may not result, depending on the other measurements.
3BK 21222 AAAA TQZZA Ed.08 195 / 304

4 Call Handling
4.6.2.5 Traffic Channel Quality Tables

The BSC uses the uplink idle channel measurements made by the BTS to make
a table of traffic channels, classified by interference levels. This table is used
to select a channel for assignment.
4.6.3 Handover Detection

Each time the BSC processes a set of Air Interface measurements, it checks
whether a handover is needed. If the need for a handover is detected, it
triggers the target cell evaluation process. See Target Cell Evaluation (Section
4.6.4) for more information.
If the handover algorithm in the BSC detects the need for a handover, it
produces a handover alarm. As the target cell evaluation is handled by the
BSC, this alarm is also handled internally by the BSC. The alarm includes a
cause value used by the BSC to evaluate which type of handover is required.
The basic types of handover are:
Quality and level
Better zone
Better cell (power budget)
Distance
Mobile velocity dependent

Preferred band.
4.6.3.1 Quality and Level Handover

These handovers are used to keep an active call connected when the signal
quality falls below a defined threshold. If a handover is not performed, a radio
link failure may be detected and the call cleared.
This type of handover can be caused by the following events:
Quality level too low on the uplink or downlink
Signal level too low on the uplink or downlink
Interference level too high on the uplink or downlink
Signal level too low on the uplink or downlink compared to low threshold
(microcells only)
Signal level too low on the uplink or downlink compared to high threshold
(microcells only)
Several consecutive bad SACCH frames received (microcells only)
Signal level too low on the uplink or downlink inner cell (concentric cells
only).
For more information about microcell handovers, refer to Microcell (Section

7.5.2). For more information about concentric cells, refer to Concentric Cell
(Section 7.2).
If the received signal level or the received signal quality is too low, the BSC
performs BTS and mobile station power control to try and achieve the optimum
level/quality ratio; seePower Control Decision and Handover (Section 4.5.4).
196 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
The figure below shows a graph of received signal level and received signal
quality. The hatched areas show where power control is successful. The solid
gray shaded areas show where power control fails to achieve the desired
level/quality ratio. These areas are where the BSC detects the need for a
handover.
High Quality
123456 123456789
123456
123456 123456789
123456789
Level 123456 123456789
Intercell 123456 123456789
Power Desired Power
Handover123456 and Level 123456789

Increase Quality Decrease to
Received
Signal
123456
to
123456
Improve 123456789
Conserve
(no action 123456789

Balance Resources
123456 needed) 123456789

Level and Minimize
Quality
123456 123456789
Interference
123456
123456 123456789
12345678901234
123456789
123456 12345678901234
123456
123456 12345678901234
Power Increase to
12345678901234
improve quality
123456 12345678901234
Quality Intercell Quality Intracell
Handover Handover
Low Quality High
Level
Low Level
Received Signal Level
4.6.3.2 Level Intercell Handover

The Level Intercell Handover area represents the range of measurements
where the received signal quality is acceptable, but the received signal level is
too low. If the power output levels are already set to the maximum allowed in
the cell, the BSC generates a handover alarm with a cause value indicating
the reason for handover. Although the quality of the signal is acceptable (and
may be very good), the call is in danger of being lost if the signal level drops
rapidly, causing a radio link failure.
The handover is an intercell handover, as the serving cell cannot support the
call at the required power level. The call is handed over to a channel in a cell
which can support the call at the required level and quality.
4.6.3.3 Quality Intercell Handover

The Quality Intercell Handover area represents the range of measurements
where both the receive signal quality and the received signal level are too
low. If the power output levels are already set to the maximum allowed in
the cell, the BSC generates a handover alarm with a cause value indicating
the reason for the handover.
The handover is an intercell handover, as the serving cell cannot support the
call at the required quality and power level. The call is handed over to a channel
in a cell which can support the call at the required quality and level.
3BK 21222 AAAA TQZZA Ed.08 197 / 304

4 Call Handling
4.6.3.4 Quality Intracell Handover

The Quality Intracell Handover area represents the range of measurements
where the received signal quality is too low, but the received signal level is
acceptable. This situation is caused by interference on the channel, so the call
is handed over to another channel in the same cell.
4.6.3.5 Better Zone Handover

This is used in concentric cell configurations when the mobile station moves
into the inner zone. If the inner zone has a free channel, an interzone
handover is triggered. This enables the mobile station to be supported on a
channel requiring a lower power level, therefore creating less interference in
the cell. The detection of this type of handover is performed on signal level
measurements only (SACCH of serving cell, BCCH of adjacent cells), as shown
in the following figure. This type of handover can be caused by the signal level
being too high on the uplink and downlink outer zone (concentric cells only).
High Power
Outer Zone
Low Power
Inner Zone
MS Handed
Over to
Low Power
Zone
MS : Mobile Station
198 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.6.3.6 Better Cell Handover

This feature is used to handover the mobile station to a cell that can support the
call using lower BTS and mobile station power levels. The algorithm in the BSC
calculates the power levels for the current cell, and the power levels required by
adjacent cells from the adjacent cell information sent by the mobile station.
This is shown in the figure below.
This type of handover is often referred to as a power budget handover, as it
uses the Power Budget parameter to detect whether an adjacent cell can be
used (see also Multiband Power Budget Handover in Multiband Handover
(Section 4.6.3.9)). If the power budget for an adjacent cell gives a ’better’
reading for a certain amount of time (a defined number of SACCH frames),
then a handover alarm is produced.
This type of handover can be caused by the following events:
Power budget is greater than handover margin threshold

High signal level in neighbor microcell (macrocell to microcell handover).
BSS 1 = Best Cell BSS 2 = Best Cell
Serving Cell Target Cell

BSS 1 BSS 2
Zone for Power Budget Handover

from BSS 1 to BSS 2
3BK 21222 AAAA TQZZA Ed.08 199 / 304

4 Call Handling
4.6.3.7 Distance Handover

This handover occurs when the propagation delay between the BTS and the
mobile station is considered excessive. The mobile station is considered to
be too far from the BTS and needs to be served by a closer BTS. This is
shown in the figure below.
Under normal circumstances, as the mobile station moves away from a BTS, a
Quality and Level or Better Cell handover takes place. However, under certain
conditions which change the propagation qualities of a signal, a cell can
provide a very high quality signal outside of the normal operating range of the
serving cell. These propagation qualities are often due to climactic conditions
which can change suddenly. If the high quality signal ’disappears’ due to a
change in the weather, the call would be lost. The distance handover ensures
that this does not happen by handing the mobile station over to a ’closer’ cell
once a distance limit is exceeded. This type of handover is caused by too great
a distance between the mobile station and the Base Station.
123456789
123456789
123456789
123456789
123456789
123456789
123456789
BSS 1 123456789
123456789
BSS 2
123456789
123456789
123456789
123456789
123456789
123456789
Area of Normal Distance Handover

Cell Boundaries Area from BSS1 to BSS2
200 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.6.3.8 Mobile Velocity Dependent Handover

In a hierarchical cell structure, where mini or microcells are overlaid by
an umbrella cell (macrocell), fast moving mobile stations are handled by
the upper layer cell.
Discrimination of the speed of a mobile station is based on the dwell time of
that mobile station in a lower layer cell. Depending on the time elapsed in the
serving cell, the call is transferred to the lower layer cell or the umbrella cell.
If the dwell time in the serving cell is above the threshold, the mobile station
is considered slow moving and is sent to the lower layer cell that triggered
the handover.
If the dwell time is below the threshold, the mobile station is considered fast
moving. To prevent a high number of handovers between the smaller lower
layer cells, the call is sent to the umbrella cell.
Dwell time is only calculated if there is a power budget handover from another
lower layer cell.
This is to avoid sending a call to the umbrella cell in the following cases:
A call initiated at the limit of the lower layer cell
A call transferred from the umbrella cell to the lower layer cell, just before
reaching the limit of that cell
After an external handover, when there is no information on the preceding
cell and handover cause.
Whatever the dwell time, any emergency handover sends the call to the
umbrella cell, which acts as the rescue cell.
The load on the umbrella cell is taken into consideration when determining
the threshold at which handovers are performed. Saturation of the umbrella
cell can cause the loss of calls, when a handover is required from another
umbrella cell or a lower layer cell.
As the load on the umbrella cell increases, the dwell time threshold is
increased, keeping some mobile stations in the lower layer cells. When the
load on the umbrella cell is very high, speed discrimination is disabled, and
priority is given to the load in the umbrella cell. The following figure shows a
graph of umbrella cell load and minimum dwell time.
Load in Umbrella Cell
Speed
Macrocell discrimination
saturated disabled
High load
Traffic
regulation
Low load
Max speed Macrocell with
discrimination little traffic
in force
Minimum
Dwell Time
Low minimum High minimum

dwell time dwell time
Figure 22: Umbrella Cell Load in Mobile Velocity Dependent Handover
3BK 21222 AAAA TQZZA Ed.08 201 / 304

4 Call Handling
4.6.3.9 Multiband Handover

There are two types of multiband handover: Preferred-band handover and
Multiband Power Budget handover. They are described below.
Preferred-Band Handover
Network capacity can be expanded by introducing multiband operation. This
means that an existing network (for example, GSM 900) is expanded by
adding cells in a different band (for example, GSM 1800). In such a network,
the original band (GSM 900) is referred to as the first band. The new band
(GSM 1800) is referred to as the preferred band.
The existing monoband mobile stations, which use the first band, continue to
do so. However, multiband mobile stations are handed over to the preferred
band, where possible. This is done to free resources in the first band for use
by monoband mobile stations. Normal handovers (for example, better cell
handover), hand over multiband mobile stations to the preferred band.
A new handover type, called preferred-band handover, hands over multiband
mobile stations immediately when a first-band cell reaches a specified
congestion threshold. This frees up resources for the monoband mobile
stations in the cell.
For a preferred-band handover to occur, the following conditions must be
met:
The first band cell’s traffic load reaches a high threshold
Suitable neighboring cells in the preferred band are available
The preferred band handover facility is enabled.
Multiband Power Budget Handover

In certain networks, two different frequency bands can exist. For example,
one frequency band uses the GSM 900 frequencies, the other frequency
band uses the GSM 1800 frequencies. In this case, multiband power budget
handovers can be enabled between the two frequency bands using the
EN_MULTIBAND_PBGT_HO parameter:
Setting the EN_MULTIBAND_PBGT_HO parameter to ’True’ enables
multiband power budget handovers between two frequency bands
Setting the EN_MULTIBAND_PBGT_HO parameter to ’False’ disables
multiband power budget handovers between two frequency bands.
This parameter must be defined for each cell where multiband power
budget handovers are required.
4.6.4 Target Cell Evaluation

Cell evaluation is performed by the BSC. Once a handover alarm is detected
within the BSC, it evaluates the neighbor cells and compiles a list of possible
target cells. The serving cell can be on the target cell list.
The cells are evaluated and ranked by preference, calculated by one of the
two algorithms, ORDER or GRADE. The Network Operator chooses which
algorithm is to be used on a cell-by-cell basis.
The BSC tries to hand over to the most suitable cell. If this cell is controlled
by the BSC, the BSC handles the handover procedure. If the target cell is
controlled by another BSC, the serving BSC sends a Handover_Request
message to the MSC.
202 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.6.4.1 Target Cell

The exact calculation performed to choose the target cell depends on the
algorithm used and the cause of the handover alarm.
The target cell is selected, taking into account the following criteria:
Received signal level

Power budget
Number of free channels
Relative load on the traffic channel of the cell
Maximum power allowed in cell
HO_MARGIN parameter
Mobile station distance from target BTS
Handover cause.
The HO_MARGIN parameter is an O&M parameter set by the Network Operator.

It is used to prevent a call being continually handed over between two cells. For
example, following a power budget handover, the new cell immediately starts
power budget calculations for its neighbor cells. It may find that the original cell
is giving a better power budget reading and try to hand back immediately. This
effect can be caused by slight climactic changes which affect the propagation of
signals. It is known as the ’ping-pong’ effect. The HO_MARGIN parameter stops a
call being handed back to a cell from which it has just been handed over.
There is also an O&M parameter, W_PBGT_HO which can be set by the OMC-R
operator, to add a weighting for the power budget parameters of cells controlled
by another BSC. Refer to the 9153 OMC-R Configuration Handbook for more
information.
The target cell chosen also depends on the mobile station classmark (see
Classmark Handling (Section 3.6)) and its compatibility with the BTS’s ciphering
capabilities (see Ciphering (Section 3.8)).
The procedures initiated to hand over a call depend on which cell is chosen as
the target cell.
3BK 21222 AAAA TQZZA Ed.08 203 / 304

4 Call Handling
4.6.4.2 Target Cell Handovers

Depending on which cell is chosen as the target cell, one of the following
handovers takes place.
This handover occurs... If the target and serving cell are...
Internal: Intracell The same, the call is handed over to a channel in the same cell. This
is an intracell handover. This type of handover is most commonly due
to interference in the cell. It is controlled by the BSC
Internal (IntraBSS): Intercell Not the same but are controlled by the same BSC, this is called an
intercell intraBSS handover. This handover is normally controlled by
the BSC. However, the Network Operator can specify that this type of
handover be controlled by the MSC
External (InterBSS): IntraMSC Not controlled by the same BSC, but the two BSC are controlled by
the same MSC, this is called an interBSS intraMSC handover. This
handover is controlled by the MSC.
External (InterBSS): InterMSC Controlled by different BSCs and the two BSCs are controlled by
different MSCs, this is called an interBSS interMSC handover. The
control of this handover is shared between the MSCs.
Handovers controlled by the BSC are called internal handovers.
Handovers controlled by the MSC are called external handovers.
204 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.6.5 Synchronous and Asynchronous Handover

The handover to the target cell can be synchronous or asynchronous. A
synchronous handover can be performed if the master clocks of the serving cell
and the target cell are synchronized.
This is the case when:
The serving cell and the target cell are the same cell
The BTS of the serving cell and the target cell are in a collocated
configuration.
BTS in a collocated configuration take the clock pulse from one BTS in the
configuration.
For a synchronous handover, the mobile station does not have to resynchronize
with the target BTS. Therefore, the physical context procedure for power levels
and timing advance does not have to be performed after the mobile station
accesses the target cell.
For an asynchronous handover, the mobile station has to synchronize with
the target cell before transmitting any user traffic.
3BK 21222 AAAA TQZZA Ed.08 205 / 304

4 Call Handling
4.6.5.1 Asynchronous External Handover - Message Flow

This section describes the message flow for an asynchronous external
handover. The example in the figure below is for a handover of a traffic channel
between two separate cells controlled by two different BSCs.
Target Serving Target Serving
MS BTS BTS BSC BSC MSC
measurement rep
orts (SACCH) 1
measurement res
ults
HO detect
2 HO alarm
handover required
3 handover reque
st
on
channel activati DTX+cause+cm
cipher+cell IDs+
channel type+
SACCH/FACCH
hanover request
channel activation ack
ack
+ handover comm
and
4 handover command
and
handover comm
and ch+cell+HOref+cipher
handover comm
release with
serving BTS
Synchronization
handover detect
(FCCH + SCH)
access burst (SA

CCH) 5
handover detect
HO ref + TA handover detect
set up switching
path between Abis
& A interfaces
physical info
(FACCH)
physical info
6
establish indication
ack
(FACCH)
handover comple
te
handover performe
d
clear command
DTX : Discontinuous Transmission

HO : Handover
MS : Mobile Station
TA : Timing advance
206 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.6.5.2 Asynchronous External Handover Process

For Asynchronous External Handovers, the following process applies:
1. The mobile station and BTS take measurements on the Air Interface
as described in the previous procedure. The mobile station sends
measurement information to the BTS in a measurement_report message.
The BTS sends mobile station and BTS measurements to the BSC in a
measurement_results message.
2. The BSC detects the need for a handover and creates a handover alarm
indicating the reason for the handover. The BSC evaluates possible target
cells and creates a candidate cell list.
To initiate the external handover procedure, the BSC sends a
Handover_Required message to the MSC including the candidate cell
list. It also starts a timer to prevent it sending the same cell list. It can
only re-send the cell list when the timer times out, or if it receives a
Handover_Request_Reject message from the MSC.
The MSC chooses the target cell from the cell list. It sends a
Handover_Request to the target BSC to inform it that a mobile station is
going to be handed over. This message contains:
Channel type required
Cipher mode information
Mobile station classmark information

Serving cell identification
Target cell identification
Downlink Discontinuous Transmission flag
Handover cause.
3. The target BSC initiates the channel activation for the new channel with the
Channel_Activation message.
The target BTS sets its resources to support the new channel, starts sending
the SACCH/FACCH and sends a Channel_Activation_Acknowledgment
message to the target BSC.
4. The target BSC builds a handover command. This command is sent to the
MSC in the Handover_Request_Acknowledgment message. The handover
command contains:
The new channel and its associated control channel
The target cell description
A handover reference
Any cipher mode information (phase 2 mobile stations can change cipher
mode during a handover procedure).
The MSC forwards the Handover_Command message to the serving BSC.

The serving BSC sends the Handover_Command message to the mobile
station.
3BK 21222 AAAA TQZZA Ed.08 207 / 304

4 Call Handling
5. The mobile station releases its connection to the serving BTS. It

synchronizes with the target BTS using the FCCH and SCH information.
Once synchronized, the mobile station continually sends access burst on
the uplink SACCH until it receives the Physical_Information message on
the FACCH from the target BSC.
When the target BTS receives an access burst, it checks the handover
reference and calculates the timing advance. This is sent to the target BSC
in the Handover_Detect message.
The target BSC informs the MSC of the handover detection and establishes
a switching path between the allocated Abis and A Interface resources.
6. When the mobile station receives the Physical_Information message, it
sends its first frame on the new channel using the timing advance sent in the
Physical_Information message.
The target BTS acknowledges the mobile station’s first frame and
sends an Establish_Indication message to the target BSC, and an
acknowledgment to the mobile station. On receipt of the acknowledgment,
the mobile station sends a Handover_Complete message on the uplink
FACCH to the target BSC.
The target BSC informs the MSC that the handover is performed.
The MSC initiates the call clearing procedure towards the serving BSC.
208 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.6.6 Circuit-Switched Telecom Handovers

In order to optimize the regulation of circuit-switched traffic load, specific
handovers may be triggered, as described below.
Specific Handover Description
Capture A capture handover refers to a handover triggered only on the signal level
received from the neighbor cell, independently of the signal received from
the serving cell.
Power Budget A power budget handover refers to a handover triggered on a power budget
criterion.
The power budget is a measure of the difference between the signal level
received from a neighbor cell and the signal level received from the serving
cell. The higher is the power budget, the more likely a power budget handover
is triggered.
Cause 14 Handover Cause 14 is used in hierarchical networks to unload the umbrella

cells by directing slow mobile station towards a lower or indoor layer cell.
Mobile station speed is estimated by measuring the residence time of the
mobile station in the indoor and lower layer cells. If this residence time is
below a certain threshold, the mobile station is deemed to move rapidly. If the
residence time is above another threshold, the mobile station is deemed to
move slowly.
Cause 21 In multiband networks, the operator defines a preferred band where multiband
mobile station are directed. Handover Cause 21 is triggered when a mobile
station in the non-preferred band receives a good signal level from a neighbor
cell where the traffic load is not high and which belongs to the preferred band.
Cause 23 Handover Cause 23 reduces the serving cell size when it is high loaded
relative to a low loaded neighbor cell. The traffic handover enables better
distribution of traffic in the serving cell neighborhood. When the mobile station
moves away from the BTS, as the path loss increases, the power budget
increases and a traffic handover is triggered sooner. The power budget is
used to evaluate the difference between the signal levels received from the
neighbor cell and from the serving cell.
Cause 24 In hierarchical networks where cells use different frequency bands, a general
capture handover Cause 24 is required to manage, on a per cell adjacency
basis, the ability of the mobile station to be captured by a neighbor cell. This
allows capture from a macrocell to a microcell or from the same macrocell to
another cell in the preferred band. This general capture handover takes into
account the load in the serving cell and in the target cell.
3BK 21222 AAAA TQZZA Ed.08 209 / 304

4 Call Handling
4.6.6.1 Traffic Handovers in Multiband Mono-layer Networks

In some multiband networks, the radio coverage is ensured by GSM 1800 cells
in one geographical area and by GSM 900 cells in another geographical area.
As these cells form a multiband mono-layer network, the capture handovers
between cells of different bands are inefficient in regulating circuit-switched
traffic load in the serving cell neighborhood. The solution consists of allowing
intra-layer traffic handovers (Cause 23) based on a power budget evaluation
between cells of different bands.
4.6.6.2 Inhibition of Capture Handovers for "Single Layer" Serving Cell

To avoid the ping-pong effect in multilayer or multiband networks, capture
handovers are inhibited. The T_INHIBIT_CPT timer controls the time during
which the capture handover Causes 14, 21, and 24 are inhibited. This timer
starts when an emergency handover is performed towards the serving cell, and
the preceding cell does not belong to the same layer or to the same frequency
band as the serving cell. The timer T_INHIBIT_CPT starts if the serving cell is
in the upper or lower layer, but not if the serving cell is in the single layer. This
improvement extends the capture handover inhibition mechanism.
4.7 Overload Control

A lot of telecommunications signaling is required for the BSS to support
communication between mobile stations in the cells under its control and
the MSC. Telecommunication processors in the BTS or BSC can become
overloaded.
To avoid a sudden loss of communication when a processor becomes
saturated, the BSS controls the load on these processors as follows:
1. Taking local action to reduce the load.
2. Taking global BSS action to further reduce the load.
Note: The telecommunications processors of the MSC can also become overloaded.
However, MSC overload control is not the domain of the BSS.
4.7.1 BTS Overload

The BTS Frame Unit (TRE for a BTS 9100 or BTS 9110) handles all the
telecommunications signaling on the Air Interface. If the FU or TRE becomes
saturated, this can result in the loss of calls. Therefore, the BTS monitors the
load and takes action where appropriate. On initial detection of the overload
condition, the BTS takes local action to reduce the load. If the BTS local action
does not reduce the load, the BTS sends overload messages to the BSC,
which can decide to take global action.
The different stages of BTS overload, from detection to resolution, are
described below.
The BTS monitors the load on the FU or TRE by measuring the free time on
the FU or TRE’s Signaling Control Processor and the free message space on
the associated buffers. If either of these passes a set threshold, a counter is
incremented. If a threshold is not passed again within a given time, the counter
is decremented. The counter has two thresholds. If the first of these is passed,
the BTS takes local overload action. If the second of these is passed, the BTS
sends overload messages to the BSC.
When local action is triggered in the BTS, it discards low priority messages
such as the Establish_Indication message to reduce the load on the SCP.
210 / 304 3BK 21222 AAAA TQZZA Ed.08

4 Call Handling
4.7.2 BSC Overload

The BSC provides two entities for handling telecommunications signaling:
The TCU handles telecommunications signaling for the Abis Interface
The DTC handles telecommunications signaling for the A Interface.
The following sections describe the different stages of BSC overload, from
detection to resolution.
4.7.2.1 BSC Overload Detection
For the BTS, overload is calculated on the processor free time and the free
message space of the associated buffers. As the BSC handles more signaling
traffic than the BTS, the detection of an overload, and whether to trigger local or
global defense actions, is more complicated. The BSC uses an algorithm that
takes into account which processors are affected, the level of overload, and
which buffers are affected. Each processor has a local overload controller.
The BSC’s centralized overload controller is responsible for global overload
defense actions.
4.7.2.2 BSC Local Overload Action
Local action in the BSC is taken by the local overload controller on each
processor. Local actions reduce the load on an individual board.
The local actions are:
TCU Action
The TCU discards a percentage of the measurement_result messages
received from the BTS. The percentage of discarded messages is increased
and decreased in steps, under the control of the local overload control. This
only affects the handover and power control algorithms, which still function
but with less information.
DTC Action
When the DTC detects an overload, its state is set to congested on the
BSC database. This means that it cannot be selected by the resource
management software to provide a new SCCP connection. Also, the DTC
cannot send connectionless messages to the MSC.
BSC Global Overload Action

The BSC controls global actions for the whole BSS. Global action reduces
the amount of telecommunications signaling traffic in the BSS by inhibiting
new calls. The BSC bars mobile station access classes either in one cell
if the global action is requested by a BTS or TCU, or in several cells if
a DTC or MSC are overloaded.
3BK 21222 AAAA TQZZA Ed.08 211 / 304

4 Call Handling
4.7.2.3 Mobile Station Access Class Barring

When the BSC receives a request for global overload action from a BTS,
from the MSC, or from one of its local overload control processors, it checks
the message for errors. If it can accept the request, it builds new system
information messages (1 to 4). These messages are sent on the BCCH. They
bar certain mobile station classes from sending Channel_Request messages
on the RACH.
If the overload condition persists, the BSC can change the system information
messages to bar more mobile station access classes from using the RACH.
When the BTS is barring access classes, its behavior can be modified from
the OMC-R by modifying the following parameters:
AUTO_BAR_CELL enables/disables the automatic barring of cells after all
access classes have been barred. This forces the mobile station to camp
on another cell
AUTO_BAR_EC enables/disables the automatic barring of emergency calls
EN_BSS_OVRL_CLASS_BARR enables/disables the ability of the BSC to

perform global action for BTS-to-BSC overload conditions.
It is also possible to configure the number of access classes that can be barred
and unbarred in one step from the OMC-R.
4.7.2.4 Mobile Station Access Class Unbarring

When an overload message is received from the BTS or when an overload is
detected in the BSC, a timer is set. If no overload message is received from the
BTS, or no overload detected in the BSC during the period of the timer, the
timer expires. When the timer expires, the BSC unbars some access classes
according to a defined algorithm.
4.8 Call Re-establishment by the Mobile Station

The mobile station initiates call re-establishment when there is already a
speech or data call in a stable state (traffic channel path connected) and
the mobile station detects a radio link failure. The mobile station waits a
predetermined time for a response from the network. If there is no response,
the mobile station performs a cell reselection procedure.
If the new cell allows the re-establishment procedure to be performed, the
mobile station initiates the channel request procedure RACH and awaits the
Immediate_Assignment message. The mobile station then performs the
contention resolution procedure using the cm re-establishment request
message.
The radio and link establishment procedure continues as described in
Mobile-Originated Call (Section 3.2).
The network can block the mobile station from performing the channel request
procedure, due to inhibition of the mobile station access class broadcast in
the sys_info 1 to 4 messages. If this is the case, the mobile station radio
resource entity reports the failure of the radio and link establishment procedure
to the higher layer entities in the mobile station.
When the MSC receives the cm re-establishment request message, it
initiates the procedures necessary to establish a new radio resource connection
and continue the call management connection.
212 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
5 Call Release
This section provides an overview of the Call Release process and describes
the procedures which ensure resource allocation to a call.
It also describes Remote Transcoder Alarms, and the processes used to
break a connection and disconnect the resources, depending on the nature of
radio transmission.
3BK 21222 AAAA TQZZA Ed.08 213 / 304

5 Call Release
5.1 Overview
The Call Release procedures ensure that resources allocated to a call are free
for reuse when they are no longer required by the current call.
Call Release procedures are required when:
A call is finished and either the called or calling party hang up
A mobile station is turned off

A call is handed over and the resources for the original call are released
A call is modified and the resources for the original channel are released
There is operator intervention, such as a channel being blocked
There is a failure
There is a radio link failure

The system detects an LAPDm failure.
If a call is terminated normally, the Call Release procedures are triggered

automatically. If the call is terminated abnormally, the system has to detect that
the resources are no longer required and release them.
For a complete Call Release, the following resources must be released:
A Interface resources
Abis Interface resources
Air Interface resources
MSC resources:
Layer 3 for the A Interface
SS7 signaling for the A Interface
Layer 1 physical resources for the A Interface.
BSC resources:
Layer 3 for the A, Abis and Air Interface
Layer 2 SS7 for the A Interface and LAPD for the Abis Interface
Layer 1 physical resource for the A and Abis Interface.
BTS resources:
Layer 3 for the A, Abis and Air Interface
Layer 2 LAPD for the Abis Interface and LAPDm for the Air Interface
Layer 1 physical resources for the Abis and Air Interface.
Mobile station resources:

Layer 3 for the Air Interface
Layer 2 LAPDm for the Air Interface
Layer 1 for the Air Interface.
214 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
5.2 Call Release Procedures in Normal Service

The Call Release procedures, and the order in which they are triggered,
depend on the reason for the release.
This section describes the following Call Release scenarios, which occur
during normal service:
Normal Release (calls terminated by Call Management)

Calls terminated following a channel change.
Note: A VGCS call uses the same general call release procedures as a standard call;
any exceptions are described in the relevant procedure descriptions below.
For more information about special cases, including detailed behavior of the
MSC, BSC, BTS and mobile station, refer to Call Release - Special Cases
(Section 5.3).
5.2.1 Normal Release

Call termination initiated by Call Management is considered to be a normal
reason for Call Release. In this type of Call Release, the MSC initiates the
release. Before this can happen, the mobile station must inform the MSC that
it has disconnected the call. This is done with Layer 3 messages passed
transparently through the BSS between the mobile station and MSC, as shown
in the following figure.
MS BSS MSC
disconn
ect (la
yer 3 CC)
3 CC)
(layer
requ est
release
release
complete
(layer 3
CC)
MS : Mobile Station
Figure 23: Mobile Station Disconnecting a Call
When a mobile station disconnects a call:

1. Once the MSC has confirmation that the mobile station wants to disconnect
and no longer requires the connection, it initiates the release procedure
towards the BSC. This procedure:
Releases the circuit (if applicable)

Releases the SCCP connection.
2. The BSC responds to the MSC to clear the connection on the A Interface,
and initiates the Call Release procedure toward the BTS and mobile station.
This procedure releases the radio resources.
3BK 21222 AAAA TQZZA Ed.08 215 / 304

5 Call Release
3. This action triggers the mobile station to release the LAPDm connection
(disc message) and the BSC to release physical resources allocated to
the call.
MS BTS BSC MSC
nd
omma
clear c e
e valu
din g caus
MIE inclu
se
el relea
chann CC
H release of A
te SA interface resources
ctiva
dea Timer start (SCCP release)
clear c
om plete
disc disable remote
(to re Timer start (release indication)
lease TC alarm detect
LAP ed
Dm)
relea releas
se in SCCP
UA dicat
ion
SCCP
releas
e com
t plete
eques
al co ntext r
physic
physic Timer
al con
text co
nfirm
ase
an nel rele
RF ch
RF ch Timer
annel
releas
e ack

MIE : Mandatory Information Element
MS : Mobile Station
TC : Transcoder
Figure 24: Normal Call Release
216 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
5.2.1.1 MSC Actions

The MSC initiates Call Release at the end of the mobile station transaction.
The MSC can be informed of the end of the mobile station transaction:
By a level 3 disconnection message from the mobile station (Figure 23)
By a disconnection message from the Network Operator if the

correspondent terminates the call
At the end of a service call (i.e., SMS or location updating).
The normal release procedure of the MSC releases both the A Interface
resources used for the call, if any, and the SCCP connection used for the
signaling which controls the connection.
MS BTS BSC MSC
1
nd
omma
clear c
e
e valu
g caus
cludin
MIE in
ase
el rele
chann release of A
interface resources
CH
AC
te S Timer start (SCCP release)
ctiva
dea clear co
mplete 2
Timer start (release indication)
3
ed
releas
SCCP
4 SCCP
release
complet
e

MS : Mobile Station
Figure 25: Initiation of Normal Release by MSC
When the MSC initiates a normal release procedure:

1. The MSC initiates the release procedure by sending a Clear_Command
message to the BSC. This command can include a cause value in the
Mandatory Information Element.
2. The BSC accepts the command even if no cause value is included. It
immediately releases the A Interface resources for the call and replies to the
MSC with a Clear_Complete message.
3. The BSC initiates the release of the Abis and Air Interface resources. It
also sets a timer to ensure that the MSC releases the SCCP signaling
resources. On receipt of the Clear_Complete message from the BSC, the
MSC releases the resources associated with the A Interface and initiates the
release of the SCCP signaling resources by sending the SCCP_released
message to the BSC.
4. The BSC stops its timer and sends the SCCP_release_complete message.
The SCCP resources are now released and can be used for another call. If
the BSC timer expires before the SCCP_released message is received, then
the BSC force releases the SCCP connection.
3BK 21222 AAAA TQZZA Ed.08 217 / 304

5 Call Release
The MSC also initiates two types of call release for VGCS calls:
Uplink release requested by the BSS
When the BSS detects that the mobile station is no longer connected, it
sends the MSC an Uplink_Release_Indication message containing
the Radio_Interface_Failure message. When the MSC receives this
message, it initiates the release of the radio and terrestrial resources
associated with the call.
Uplink release requested by the MSC

The MSC initiates the release of the radio and terrestrial resources
associated with the call when it detects that the previous talking service
subscriber is no longer talking, or that the talker has left the group call area.
When a mobile station belonging to another BSC area has successfully sized
the VGCH, the MSC informs the BSC. The BSS then notifies the other mobile
stations that the channel is busy.
5.2.1.2 BSC/BTS/Mobile Station Interactions
The normal Call Release procedure towards the mobile station/BTS releases
the:
Radio resources associated with the call

Radio Frequency channel.
The call release procedure is as follows:

1. The BSC initiates the release of the radio resource by sending:
A Channel_Release message to the mobile station via the BTS
A Deactivate_SACCH message to the BTS.
2. The Channel_Release message prompts the mobile station to send

a disc message to the BTS to release the LAPDm resource. When
this is received, the BTS acknowledges this with a ua message to
the mobile station and sends a Release_Indication message
to the BSC. This procedure is supervised by a timer in the BSC.
The BSC considers the mobile station to be disconnected and starts the
RF channel release when:
The timer expires

The BSC receives the Release_Indication message and stops the
timer.
218 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
3. When the BTS receives the Deactivate_SACCH message, it stops

sending SACCH information and disables the remote Transcoder alarm
detection. This stops the sending of Transcoder alarms to the BSC when
the Transcoder detects inactivity on the channel. This is shown in the
figure below. If the mobile station does not receive the Channel_Release
message, it considers the stopping of SACCH information as a radio link
failure and performs a local release.
MS BTS BSC MSC
nd
omma
1 clear c
lue
use va
clud ing ca
MIE in
ase
el rele
chann CH release of A
te SAC interface resources
c tiva
dea 3 Timer start (SCCP release)
clear c
om plete
2 disable remote
disc TC alarm detect Timer start (release indication)
(to re
lease ed
LAP releas
Dm) SCCP
relea
se in
UA dicat
ion
SCCP
releas
e com
plete

MS : Mobile Station
TC : Transcoder
Figure 26: BSC/BTS/Mobile Station Interactions in Normal Call Release
Once the BSC considers the mobile station disconnected, it initiates release
of the RF channel from the BTS. In a normal Call Release procedure, this
occurs following the release of the mobile station from the Air Interface (as
described earlier in this section).
3BK 21222 AAAA TQZZA Ed.08 219 / 304

5 Call Release
4. Before releasing the RF channel, the BSC sends a physical_context

message to the BTS and starts a timer to supervise the response. The
response from the BTS is a physical_context_confirm message which
contains the last LAPDm performance measurements for the RF channel.
5. On receipt of the physical_context_confirm message, or after the
timer has timed out, the BSC sends an RF_Channel_Release message
to the BTS and starts a timer to supervise the release. The BTS
releases the level 1 and 2 resources for the channel and replies with an
RF_Channel_Release_ack message.
On receipt of the acknowledgment, the BSC releases all resources for the
RF channel. This is shown in the following figure.
MS BTS BSC MSC
3
relea
se in
dicati
UA on
4
uest
conte xt req
physical
physic
al con
text co
Timer
nfirm
5
ase
an nel rele
RF ch
RF ch
annel Timer
release
ack
MS : Mobile Station
Figure 27: Normal Release Final Steps
If the timer supervising the release times out, the BSC sends the
RF_Channel_Release message again and restarts the timer. If the timer
times out again, the BSC releases all resources locally. It also sends an
O&M error report to the OMC-R with a cause value indicating that the RF
channel release procedure has failed.
Note: The RF channel can be released locally by the BTS and still be active. If the
RF channel is still active, it is released when the BSC attempts to assign it to
another call with a Channel_Activation message. The BTS replies with a
Channel_Activation_Nack and the BSC releases the channel (refer to Call
Set Up (Section 3) for more information).
For VGCS calls, when the mobile station terminates the call, the VGCH is
released and other mobile stations can attempt to seize the VGCH in order to
become the subsequent talking mobile station in the VGCS call.
220 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
5.2.2 Calls Terminated Following a Channel Change

This section describes the Call Release procedure following a successful
channel change procedure. The case presented is an external intercell
handover. For an internal channel change, the serving and target BSCs are the
same, and in some cases, the serving and target BTS are the same.
For calls terminated following a channel change:
1. The target BSC receives confirmation of the successful handover from the
mobile station when the mobile station sends the Handover_Complete
message. This message is passed transparently through the target BTS.
See Call Handling (Section 4) for more information about handovers.
2. The target BSC informs the MSC of the handover and initiates the Call
Release procedure towards the serving BSC, by issuing a Clear_Command
message.
3. The serving BSC issues a Channel_Release message to the mobile station
and a Deactivate_SACCH message to the serving BTS.
The normal Call Release procedure described in Normal Release (Section
5.2.1) continues between the serving BSC, the serving BTS, the MSC and the
mobile station. This is shown in the following figure.
Target Serving Target Serving
MS BTS BTS BSC BSC MSC
(FACC
H)
handover complet
e
handover perform
ed
and
comm
clear
ding
inclu
MIE value
ase caus
e
ne l rele
chan
CH
ate SAC
de activ

MS : Mobile Station
3BK 21222 AAAA TQZZA Ed.08 221 / 304

5 Call Release
5.3 Call Release - Special Cases

Call Release can occur for reasons outside normal service.
This section treats the following special cases in which Call Release happens:
Call Release following Reset
BSC-initiated Call Release
BTS-initiated Call Release
Mobile station-initiated Call Release

Remote Transcoder alarms.
5.3.1 Call Release Following Reset

Resets are used in software/hardware failure situations, or when the database
is corrupted and recovery procedures have failed. The MSC can reset all calls
within a BSC or an individual circuit. For example, if the MSC loses dynamic
information regarding calls (i.e., preventing it from providing such services as
accounting), it can send a reset or a reset_circuit message to the BSC.
5.3.1.1 Reset
The MSC initiates Call Release when it has to release all calls associated
with the BSS (Reset).
The MSC sends a reset message containing a cause value to the BSC.
The BSC then:
Sends an alarm to the OMC-R
Sends a block message to the MSC to block circuits
Starts to clear all calls in the BSS. For each call, the procedure in Normal
Release (Section 5.2.1) is repeated.
For each SCCP connection on the A Interface, the BSC can send an
SCCP_release message and release any A Interface resources associated
with the SCCP.
A timer allocates a certain amount of time for the calls to clear. When the timer
expires, the BSC sends a reset_ack message to the MSC. Figure 28 shows
the Call Release process after a reset is initiated.
5.3.1.2 Reset Circuit

The reset circuit procedure is initiated from the MSC. The procedure informs
the BSC that an individual circuit is no longer active in the MSC. This triggers
the call clearing procedure if the circuit has an active SCCP connection.
The MSC sends a reset_circuit message to the BSC for each circuit to be
reset. Depending on the resources allocated, this can trigger the BSC to:
Release the A Interface resources
Initiate the release of the SCCP
Initiate Call Release towards the BTS and mobile station.
222 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
MS BTS BSC MSC
reset
send alarm to OMC−R block
e SCCP
l releas releas
channe e circuits blocked
ple te
e com
releas
disc SCCP
e SCCP re
to relea l releas lease
se LAP
Dm channe
release
in dication
st lete
reque comp
al co ntext re lease
physic SCCP
disc
physic
to rele al con
ase L text co
APDm rele nfirm
indi a s e
cati
on RF chan el n
release
RF chann
el
release a
ck
l
physica quest
re
context
physic
al con
text confir
m
ase
nnel rele
RF cha
RF chan
nel relea
se ack
timer
reset a
ck

MS : Mobile Station
Figure 28: Call Release Following Reset
Note: If this procedure is invoked due to SCCP problems, then messages on the A
Interface may not be passed. The MSC and BSC locally release resources
for the A Interface connections. Refer to BSC-Initiated Release (Section
5.3.2) for more details.
3BK 21222 AAAA TQZZA Ed.08 223 / 304

5 Call Release
5.3.2 BSC-Initiated Release

The BSC is involved in Call Release for both the A Interface and Abis/Air
interfaces.
The BSC initiates Call Release on the A Interface when events internal to the
BSS terminate communication with the mobile station.
The Call Release towards the mobile station can already be in progress or
have finished when the BSC initiates a release on the A Interface. If the
mobile station is still connected when the BSC initiates a release on the A
Interface, the release towards the MSC is triggered by the Clear message
from the MSC to the BSC.
5.3.2.1 Towards the MSC

The BSC initiates the release towards the MSC by sending a Clear_Request
message. It also starts a timer to supervise the procedure. The MSC releases
resources for the A channel and sends the Clear_Command message to the
BSC. This command contains a cause value indicating that the BSC initiated
the release.
From this point, the Call Release follows the procedure described for normal
Call Release (refer to Normal Release (Section 5.2.1)). The procedure starts
with the BSC releasing A channel resources. It initiates the release procedure
towards the mobile station (if still attached), and returns a Clear_Complete
message to the MSC. This sequence is shown in the following figure.
MS BTS BSC MSC
clea
r re
que
st
nd
ma
rc om alue
clea u se v
din g ca
inclu
MIE

MS : Mobile Station
Figure 29: BSC-initiated Call Release Toward the MSC
224 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
5.3.2.2 Towards the Mobile Station/BTS

The Call Release procedure towards the mobile station/BTS releases:
The radio resources associated with the call
The RF channel.
The BSC initiates the release of the radio resource by sending:
A Channel_Release message to the mobile station via the BTS
A Deactivate_SACCH message to the BTS.
This is the Normal Release procedure described in Normal Release (Section

5.2.1).
Note: In this process, once the BSC considers the mobile station disconnected, it
initiates release of the RF channel from the BTS.
This can occur following:
The release of the mobile station from the Air Interface (as in the Normal
Release procedure)
A handover, when the BSC is sure that the mobile station has successfully
changed to the new channel. Refer to Calls Terminated Following a Channel
Change (Section 5.2.2).
An immediate assign procedure failure. This ensures that the SDCCH is

available for reuse as quickly as possible
A normal assignment failure or handover failure. This ensures that the traffic
channel is available for reuse as quickly as possible.
3BK 21222 AAAA TQZZA Ed.08 225 / 304

5 Call Release
5.3.3 BSC-Initiated SCCP Release

The BSC initiates an SCCP release when a release procedure has failed or
inactivity is detected in the BSC SCCP entity.
Failed Release Procedure

If there are no resources allocated to a call and the normal release of the
SCCP connection has failed, the BSC forces the release of the SCCP
connection:
Internally by sending a level 3 command to its SCCP entity
Externally by sending an SCCP_released message to the MSC.
The BSC does not wait for a reply from the MSC before releasing the
SCCP connection.
If the original failure is due to a problem on the SCCP connection or in
the BSC SCCP entity, the SCCP_released message may not be sent. If
the message is sent, the MSC replies with an SCCP_release_complete
message and releases any allocated resources.
Inactivity Procedure
The BSC performs an inactivity procedure for each SCCP connection. If
the BSC detects inactivity, it assumes that the associated transaction
is no longer active and therefore:
Performs Call Release on the Air and Abis interfaces
Initiates a reset circuit procedure if an A channel is active
Initiates the release of the SCCP connection.
5.3.4 BTS-Initiated Call Release

The BTS initiates a Call Release only if it detects a LAPD failure or when
O&M requests a restart of the BTS.
Otherwise the role of the BTS in Call Release is to:
Relay channel release messages to the mobile station
Deactivate the SACCH under control of the BSC
Send a release_indication message to the BSC when the mobile station

releases the LAPDm connection.
226 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
5.3.4.1 LAPD Failure

When the BTS detects a LAPD failure on a link between one of its frame units
and the BSC, it forces the release of all mobile stations on active channels
associated with that Frame Unit (TRE for a BTS 9100 or BTS 9110).
The BTS stops SACCH frames and sends a Layer 2 disconnect message to
each affected mobile station. It also starts a timer to supervise each LAPDm
disconnection. The LAPD connection cannot be re-established until the BTS
receives an acknowledgment, or the timer expires for each LAPDm connection.
If a mobile station sends an acknowledgment, the BTS releases the RF
resources.
If a mobile station does not respond, the BTS continues to send Layer 2
disconnect messages up to a predefined number. It then waits for the timer to
expire and the BTS releases the RF resources.
Note: If the maximum number of disconnect retries is reached, the BTS LAPDm entity
sends an error report to the BSC. This does not stop the timer supervising
the disconnection.
When all mobile stations are disconnected, the BTS attempts to re-establish
the LAPD connection. The BTS then sends an error report to the BSC with
a cause value indicating O&M intervention. This cause value indicates that
the FU or TRE has cleared all calls.
3BK 21222 AAAA TQZZA Ed.08 227 / 304

5 Call Release
The BSC re-initializes the link with the frame unit and starts Call Release for the
affected calls with the MSC. This sequence is shown in the following figure.
MS BTS BSC MSC
Detection of LAPD
failure. BTS stops
sending SACCH frames.
disc timer
disc timer
disc timer
UA
UA
release RF resources
UA
Re−establish LAPD connection
error
report
cause
value
Re−initialize FU or TRE link

clear re
quest
nd
omma
clear c
value
cause
cluding
MIE in
clear com
plete
FU : Frame Unit
LAPD : Link Access Protocol on the D Channel
MS : Mobile Station
TRE : Transmitter/Receiver Equipment
Figure 30: BTS-initiated Call Release following LAPD Failure
228 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
5.3.4.2 O&M Intervention

The BTS initiates a Call Release if its O&M entity requests a restart of a Frame
Unit (TRE for a BTS 9100 or BTS 9110).
The FU or TRE’s response to a restart request is to stop sending frames
on the Air Interface. The BTS starts a timer to supervise the disconnection
of the mobile stations. The timer allows enough time for the mobile stations
to detect a radio link failure due to the lack of SACCH frames. The BTS RF
performs a local release.
The BTS resets the FU or TRE and waits for the timer to expire. When the
timer expires, the FU or TRE attempts to re-establish the LAPD link with the
BSC. The BTS sends an error report to the BSC with a cause value indicating
O&M intervention.
The BSC releases the RF resources and initiates a Call Release with the MSC.
3BK 21222 AAAA TQZZA Ed.08 229 / 304

5 Call Release
5.3.5 Mobile Station-Initiated Call Release

The mobile station can initiate a Call Release by:
Initiating a radio link failure
Disconnecting the LAPDm connection.
5.3.5.1 Mobile Station-Initiated Radio Link Failure

If SACCH frames are no longer received from the mobile station, the BTS starts
to count the number of missing frames. When the BTS has counted a certain
number of missing SACCH frames, it considers that the radio link has failed.
This happens when the mobile station ’disappears’ from the Air Interface
(caused by adverse radio conditions, the mobile station is switched off, fatal
error, etc.).
Note: There is an optional feature where, after a number of missing SACCH frames,
the BSC sets both mobile station and BTS power to maximum in an attempt to
regain the Air Interface. If the BTS continues to register missing frames, the
radio link fails as described below.
The BTS sends a connection_failure_indication message to the BSC with
a cause value indicating that the radio link has failed. The BSC initiates Normal
Call Release procedures to the BTS by sending an RF_Channel_Release
message to the BTS and a Clear_Request message to the MSC. This is
shown in the following figure.
MS BTS BSC MSC
Interruption of SACCH frames
start counter
conn
ectio
n fail
ure in
dicati
on
caus
e valu
e
clear
requ
ase est
ele
el r
h ann
RFc
nd
ma
com
clea
r alue
se v
cau
ing
includ
MIE

MS : Mobile Station
Figure 31: Call Release due to Mobile Station-Initiated Radio Link Failure
230 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
5.3.5.2 Mobile Station-Initiated LAPDm Disconnection

If the mobile station has an error which unexpectedly terminates the call,
it sends a disconnect message to the BTS. The system reaction to the
disconnect message in this instance is the same as when the disconnect
message from the mobile station is prompted by a Channel_Release message
from the BSC (as explained in BSC-Initiated Release (Section 5.3.2)).
5.3.6 Remote Transcoder Alarms

If the Transcoder detects a break in communication with the BTS, it sets a
timer. This timer is defined by GSM standards. On expiration of this timer, the
Transcoder sends an alarm to the BTS. If the BTS remote Transcoder alarm
detection is active, a connection_failure_indication message is sent to
the BSC with a cause value indicating a remote Transcoder alarm.
If the BTS detects a break in communication with the Transcoder, it sends a
connection_failure_indication message to the BSC with a cause value
indicating a remote Transcoder alarm. See the figure below.
During an internal handover, this can cause remote Transcoder alarms to
arrive at the BSC, as the connection is still active but the call is handed over.
The BSC ignores these alarms for a guard period on new and old channels
during handover.
MS BTS BSC MSC
TC detects a communication
break and times out
Alarm
con
nec
tion
failu
re in
caus dica
e va tion
lue
clea
e r req
eas ues
l rel t
anne
RF ch
d
man
r com e
clea valu
ca use
u ding
incl
MIE

MS : Mobile Station
TC : Transcoder
Figure 32: Call Release Due to Communication Failure Detected by Transcoder
3BK 21222 AAAA TQZZA Ed.08 231 / 304

5 Call Release
5.4 Preserve Call Feature

The Preserve Call feature avoids locking the cell before modifying its logical
configuration. The OMC-R marks the TRXs that are impacted by the
modification and the BSC shuts down traffic only on those TRXs, preserving
the ongoing calls on other TRXs.
The OMC-R provides the WTC in the Cell-Frequencies-Type group. This WTC
is the one which applies by default to cell shutdown.
Modifying a TRX means changing its baseband definition and/or its radio
definition. The radio definition of a TRX is the allocation of a frequency or of an
FHS/MAIO. If the definition of an FHS is changed, the TRXs which use this
FHS must also be considered as modified.
5.4.1 Normal Release

In Normal Release, Preserve Call is set to ’False’ if one of the following
parameters is modified:
attached-sector (PC=False on modified TRX)

ARFN (TRX-TS) (PC=False on modified TRX)
ARFN-Set (FHS) (PC=False on TRX using the concerned FHS)
MAIO (PC=False on modified TRX)
HSN (PC=False on modified TRX)
Channel-Type (PC=False on modified TRX)

Zone_Type (PC=False on modified TRX)
The OMC-R considers that the Zone_Type value for a single cell is Not
Relevant.
When the transition from Not Relevant to another value is not triggered on
the concerned TRX, it remains set to ’False’.
If the TS0 of the TRX which is carrying the BCCH frequency is impacted,
all calls must be shut down on the cell. In this case, the OMC-R marks all
TRXs as impacted.
This is the case when there is a modification of the:
BCCH frequency
CBCH channel : combined <-> non-combined.
232 / 304 3BK 21222 AAAA TQZZA Ed.08

5 Call Release
5.4.2 Abnormal Release

In the following cases, even if the Preserve Call flag is not set to ’False’ by the
OMC-R, calls are released at TRX or at cell level:
Add TRX in a cell and the BSC TCH-RM Entity managing this cell (Traffic
Channel Resource Manager) is full
Inside the BSC software, the TCH-RM entities manage the radio timeslot
allocation on a cell basis. A cell, mapped on a sector, is mapped on a
TCH-RM entity. A TCH-RM entity can manage several cells with a maximum
capacity based on the total number of TRX that is limited to 90.
If a cell is extended with one or several TRX, the TCH-RM entity managing
the cell takes into account the new TRX. If, adding the TRX, the limit of 90 is
exceeded, the concerned cell can no longer be managed by this entity.
This cell is mapped automatically by the BSC on another TCH-RM. In this
specific case, all calls are released on this cell
Due to the "adjust" algorithm, TRX(s) with Preserve Call set to true are
disturbed in remapping
Once the BSC has unmapped and remapped all TRX(s) with Preserve Call
set to ’False’ , the BSC can be in one of the following situations:
There are more TRX than TRE configured
There are enough TRE configured but some are not available
In both cases, the BSC checks whether a recovery is performed to ensure
the availability of the TRX with the highest priority. The application of the
recovery also leads to the release of some TRE.
The OMC-R facility "Check Telecom Impact" related to PRCs is based on the
"preserve calls" parameter value. Consequently, in the three cases mentioned
above, the result of the check is not accurate.
3BK 21222 AAAA TQZZA Ed.08 233 / 304

5 Call Release
234 / 304 3BK 21222 AAAA TQZZA Ed.08

6 Handling User Traffic Across the BSS
This section describes the flow of speech and data traffic across the BSS.
3BK 21222 AAAA TQZZA Ed.08 235 / 304

6.1 Overview
The BSS performs traffic handling in the uplink and downlink directions
for speech and data.
The BSS uses the BSC and BTS to perform the required radio transmission,
control and baseband functions of a cell and to control the BTS in its domain.
Transmission provides the efficient use of the terrestrial links between the
BSS components.
Together, these components perform the required encoding and rate adaptation
procedures.
6.2 Speech
Speech is passed from the mobile station to the PSTN and from the PSTN to
the mobile station. This section describes how speech is encoded from the
mobile station to the PSTN, as shown in the following figure. Speech in the
opposite direction follows the reverse process and so is not described.
Full Rate Speech TCH
A 13 kbit/s CIM 13 kbit/s 64 kbit/s A/D
BTS BIE BIE BSC SM SM TC MSC PSTN
Mobile
Station
A 6.5 kbit/s CIM 6.5 kbit/s 13 kbit/s 64 kbit/s A/D
Half Rate Speech TCH

A : Analog
A/D : Analog/Digital
CIM : Channel Encoded, Interleaved, and Modulated
SM : Submultiplexer
TC : Transcoder
Figure 33: Encoded Speech Transmission Across the BSS with 9120 BSC
The scheme is similar in the BSS with an 9130 BSC, excepting the BIE and
SM 9120 BSC transmission components, which are supported by virtual
processors.
236 / 304 3BK 21222 AAAA TQZZA Ed.08

6.2.1 Analog
The microphone converts speech to an analog signal.
The analog signal is encoded into a digital signal depending on the type of
traffic channel used:
13 kbit/s for a full-rate traffic channel (or enhanced full-rate)

6.5 kbit/s for a half-rate traffic channel.
It is then transmitted on a 16 kbit/s (8 kbit/s for half-rate) radio timeslot. 3

kbit/s and 1.5 kbit/s are used for signaling on full-rate and half-rate channels
respectively.
6.2.2 Interleaving and Forward Error Correction

To pass speech over the Air Interface, error checking and redundancy are
included to make sure speech information is correctly transmitted. This ensures
that valid continuous speech is passed through the BSS.
Error correction is based on high redundancy with complicated parity and cyclic
redundancy methods. This is done to ensure that many types of parasitic and
sporadic errors are detected and to some degree, corrected. In the case of
speech, there is cyclic coding, convolutional and parity error encoding of the
data. The speech data starts as 260 bits (112 bits) and, after forward error
checking, is encoded as a 456 bit block (228 bit block).
These blocks are then split into eight (four for half-rate), and interleaved with
adjacent blocks into TDMA frames to be transmitted as radio wave bursts.
This means that if some of the blocks are lost during transmission, there is
a high chance that the other blocks hold enough redundancy to still have a
valid speech block.
6.2.3 Speech Data Bursts

The interleaved blocks are transmitted over the Air Interface and are then
reassembled in the BTS. As described above, when the interleaved blocks are
reassembled and checked for parity errors, there is a high chance that the data
can be recovered. In speech data the most significant bits are heavily protected
and are always transmitted at the start of a TDMA frame. This ensures that
even if the speech block cannot be reassembled, at least the most significant
speech data can be used to provide a close approximation.
3BK 21222 AAAA TQZZA Ed.08 237 / 304

6.2.4 Digital Speech

Speech bursts are returned to digital speech blocks in the BTS. They are sent
to the Transcoder as 13 kbit/s digital speech, plus 3 kbit/s for in-band signaling
if they are full-rate speech. The channels on the Abis and Ater interfaces are
64 kbit/s. The speech blocks have to be multiplexed on to these links. This is
shown in the figure below.
Half-rate speech is sent to the BSC on the Abis Interface as 6.5 kbit/s, plus
1.5 kbit/s signaling. Two half-rate 8 kbit/s channels are associated together
into a 16 kbit/s channel. On the Ater Interface a 16 kbit/s submultiplexing
scheme is used for all types of traffic. The two paired 8 kbit/s Abis channels are
independently switched by the BSC onto two 16 kbit/s Ater channels.
Ater Interface Ater−mux Interface Ater Interface A Interface
BSC SM SM TC MSC
30 x 16 kbit/s user 90 x 16 kbit/s user 30 x 16 kbit/s user 30 x 64 kbit/s user

traffic channels traffic channels traffic channels traffic channels
per link per link per link per link
SM : Submultiplexer
TC : Transcoder
Figure 34: Multiplexed Ater Interface
This scheme corresponds to the 9120 BSC. For 9130 BSC, there is no SM
or Ater interface beside the BSC.
6.2.5 Digital 64 kbit/s A-law Encoded Speech

The Transcoder converts the 13 kbit/s digital speech to the 64 kbit/s A-law
encoding. This is a standard digital speech interface for ISDN and PSTN
exchanges. The information passes through the MSC and is sent to the PSTN.
The Transcoder performs rate adaptation in both directions.
238 / 304 3BK 21222 AAAA TQZZA Ed.08

6.2.6 Enhanced Full-Rate

Enhanced full-rate provides advanced speech encoding on a full-rate traffic
channel, for improved voice quality and user comfort. The feature uses a
codec with ACELP coding.
Enhanced full-rate is enabled in the BSC, on a cell-by-cell basis, by the O&M
parameter EFR_ENABLED. When an enhanced full-rate call is set up, the
following process occurs:
1. The mobile station makes a call requiring speech, in which it announces its
codec preferences to the MSC in the Set_Up message.
2. The MSC passes appropriate Assignment_Request and Handover_Request
messages to the BSC.
3. The BSC uses the codec list supplied by the MSC to choose the correct
codec, based on the support for the codec in the BTS and A Interface
TRAU equipment.
4. The BSC activates the selected channel in the BTS, giving the indication
of codec type.
5. The BTS configures itself to handle the correct channel coding, and starts
sending TRAU frames to the TRAU, in order to configure the TRAU.
6. The BSC builds either an Assignment_Command message or a
Handover_Command message, indicating to the mobile station which codec it
should use when accessing the new channel.
7. Once the mobile station is attached, the BSC reports the selected codec
type to the MSC.
8. In case of subsequent handover, if the BSC has had to change the codec,
the BSC informs the MSC of the change.
For more information concerning enhanced full-rate, refer to the 9153 OMC-R
Configuration Handbook.
3BK 21222 AAAA TQZZA Ed.08 239 / 304

6.2.7 Half-Rate
Half-rate speech channels allow the operator to save timeslots on the Air
Interface when the number of available frequencies is very limited. Half-rate
uses a different encoding algorithm than full-rate, in order to minimize any
perceived loss of comfort by the subscriber. Use of the half-rate feature does
create extra overhead on the A Interface.
Half-rate is activated on a per-cell basis. In effect, the cell is capable of
operating in Dual Rate mode, permitting either half-rate or full-rate traffic
channels to be allocated. VGCS calls can be use either standard full-rate or
half-rate channels.
Half-rate can be applied to BSSs with the following equipment:
BSC 9120
BSC 9130
G2 Transcoder
9125 Transcoder
One of the following BTS:
G1 BTS equipped with Dual Rate Frame Unit
G2 BTS equipped with DRFU
Alcatel-Lucent BTS.
6.2.8 Adaptive Multiple Rate

Adaptive Multiple Rate (AMR) increases the quality of speech during
conversations and also increases the offered capacity due to the provision of
half-rate channels.
When looking at current GSM codecs (full-rate, half-rate, and enhanced
full-rate), each of them answers only one facet of capacity and quality
requirements:
Enhanced full-rate brings a higher speech quality than full-rate but with
no noticeable impact on capacity
Half-rate provides an answer to capacity requirement, but suffers from poor

speech quality in bad radio conditions, or mobile station-to-mobile station
calls when TFO (see Tandem Free Operation (Section 3.9)) cannot be used
AMR is a new technology defined by 3GPP which relies on two extensive sets
of codec modes. One is defined for full-rate and one for half-rate.
When used in combined full-rate and half-rate mode, AMR brings new answers
to the trade-off between capacity and quality:
Speech quality is improved, both in full-rate and half-rate

Offered capacity is increased due to the provision of half-rate channels.
This allows the density of calls in the network to be increased, with only
a low impact on speech quality.
240 / 304 3BK 21222 AAAA TQZZA Ed.08

The AMR technology also provides the advantage of a consistent set of codecs,
instead of the one-by-one introduction of new codecs.
Alcatel-Lucent offers two versions of AMR:
Full-rate mode only, for operators who do not face capacity issues and want
to benefit from the optimized quality of speech
Combined full-rate/half-rate mode, for operators who want to benefit from

the above defined trade-off between quality of speech and capacity.
Through these codec mode adaptations, AMR is able to adapt the sharing of
speech information and speech protection to current radio conditions, which
can vary greatly, depending on location, speed, and interference. Therefore, for
any radio conditions, the Alcatel-Lucent BSS is able to offer the best existing
codec, thus the best existing voice quality.
AMR functionality can be activated by configuration of the cells and the BTS
radio resources in all the network elements (OMC-R, BSC, BTS). The relevant
algorithms are activated on a call-by-call basis. On the radio interface, the AMR
can only be used with AMR mobiles. On the A Interface , the AMR can only
be used if the NSS implements it.
The AMR capability is available on a cell-by-cell basis.
This feature is compatible with VGCS.
The AMR Wideband (AMR-WB) codec is developed as a multi-rate codec with
several codec modes like the AMR codec. Like in AMR, the codec mode is
chosen based on the radio conditions. This feature is not compatible with TFO.
The following table refers to supported software versions versus hardware
boards and features.
HW Board/Feature AMR NB without TFO NB TFO FR, HR, AMR WB incl

TFO NB EFR TFO WB
Legacy MT120 yes no yes no
MT120-NB yes no yes no
MT120-WB yes no yes yes
Table 8: Software Version versus Hardware Board/Feature
3BK 21222 AAAA TQZZA Ed.08 241 / 304

6.2.8.1 AMR Normal Assignment

AMR is controlled on a per call basis by the MSC.
1. The MSC sends an Assignment_Request message to the BSC.
In the Assignment_Request message, the MSC gives the Channel type
IE, which indicates:
In octet 4, if full-rate or half-rate is to be used and if the BSS is allowed to
change
In octet 5 and above, octets indicate that AMR is allowed in half-rate or

full-rate.
2. The BSC activates the channel in the BTS by sending a

Channel_Activation message, containing the IE Multirate configuration. It
indicates the subset of codecs used for full-rate (or half-rate, respectively)
link adaptation, the threshold and hysteresis sent to the mobile station for
full-rate (or half-rate, respectively) link adaptation and, optionally, the start
mode (i.e., the initial codec mode).
3. If the initial codec mode is not given, the BTS chooses the default start mode
depending on the number of codec modes contained in the subset.
4. Once the channel is activated within the BTS, the BSC sends all AMR
relevant parameters to the mobile station in the Assignment_Command
message.
5. When the speech path is established and synchronization is performed
between the Transcoder and the BTS, the BTS checks if the Request
or Indication Flag (RIF) given in the TRAU frame is coherent with the
type of codec mode (Indication or Command) that should be sent on the
radio interface. If necessary, a CMI_CMR alignment command is sent
to the Transcoder.
6. Once the BTS detects that downlink CMI/CMR is synchronized between the
TRAU frames and the radio interface, it starts codec mode adaptation.
242 / 304 3BK 21222 AAAA TQZZA Ed.08

6.2.8.2 AMR O&M Management

The table below summarizes the main O&M configuration parameters that can
be changed by the operator from the OMC-R.
Parameter Description
AMR_SUBSET_FR Bitmap of 8 bits defining the codec subset for AMR full-rate
(1 to 4 codecs out of 8), on a per BSS basis.
AMR_SUBSET_HR Bitmap of 6 bits defining the codec subset for AMR half-rate
(1 to 4 codecs out of 6), on a per BSS basis.
EN_AMR_CHANNEL_ADAPTATION Flag on a per cell basis, used only for AMR calls, to enable
or disable intracell handovers for channel adaptation.
EN_AMR_HR Flag on a per cell basis to enable or disable AMR. This flag
is used for AMR half-rate.
EN_AMR_FR Flag on a per cell basis to enable or disable AMR. This flag
is used for AMR full-rate.
OFFSET_CA_NORMAL Offset for the channel mode adaptation hysteresis under

normal load. It can take a value from 0.0 to 7.0 (step = 0.1)
on a per cell basis.
OFFSET_CA_HIGH Offset for the channel mode adaptation hysteresis under

high load. It can take a value from 0.0 to 7.0 (step = 0.1) on
a per cell basis.
RXQUAL_CA_NORMAL Threshold for channel mode adaptation under normal load.

It can take a value 0.0 to 7.0 (step = 0.1) on a per cell basis.
RXQUAL_CA_HIGH Threshold for channel mode adaptation under high load. It

can take a value from 0.0 to 7.0 (step = 0.1) on a per cell
basis.
AMR_THR_3, Definition of thresholds on a per BSS basis.

AMR_THR_2,
AMR_THR_1
AMR_HYST_3, Definition of thresholds and hysteresis, on a per BSS basis

AMR_HYST_2,
AMR_HYST_1
3BK 21222 AAAA TQZZA Ed.08 243 / 304

6.2.9 Channel Mode Adaptation

Channel mode adaptation is the change from one full-rate channel to an
half-rate channel and vice-versa. This adaptation is independent from the
codec mode currently used.
This feature is available when the AMR half-rate option is installed.
The operator has direct operational control of it through the parameter
EN_AMR_CHANNEL_ADAPTATION used for both changes from full-rate to half-rate
and from half-rate to full-rate.
Full-Rate Channel Adaptation Due to High Radio Quality

This channel adaptation involves ongoing AMR full-rate communications
within cells where half-rate is enabled. During any AMR call, the downlink
radio quality is reported by the mobile station through the RX_QUAL. At
the same time, the uplink radio quality is evaluated by the BTS through the
RX_QUAL, and both are compared to a load-dependent threshold. Indeed,
in a cell heavily loaded, a half-rate channel will be preferred, even if the
quality is not optimal. Whenever both uplink and downlink radio quality are
higher than this threshold, then an intracell handover takes place from a
full-rate to a half-rate channel. To take into account the load, two different
threshold values are used. The change will also only be performed if the
current channel type is dual rate and it authorizes changes.
Half-Rate Channel Adaptation Due to Low Radio Quality

This channel adaptation involves ongoing AMR half-rate communications,
using a dual-rate channel type authorizing changes. During any such
AMR call, the downlink and uplink radio quality are evaluated with the
same metrics as stated for the full-rate channel adaptation, and the same
threshold comparison is performed. If either uplink or downlink radio quality
are lower than this threshold, then an intracell handover takes place from a
half-rate to a full-rate channel. To take into account the load, two different
thresholds are also used but they differ from the ones used in full-rate
adaptation by an offset value which is also cell load dependent. This offset
allows a hysteresis to be introduced between full-rate and half-rate channels.
244 / 304 3BK 21222 AAAA TQZZA Ed.08

6.2.10 VGCS
Voice Group Call Service (VGCS) is a BSS feature that allows speech
conversation for a predefined group of up to 6 mobile stations in half duplex
mode on the Air Interface.
VGCS enables a calling mobile station to establish a voice group call to
destination mobile stations belonging to a predefined group call area and
group ID. VGCS typically involves multiple group members in a small group
call area, which is comprised of one cell or a cluster of cells. Group call areas
are predefined in the network by the service provider, and co-ordinated by
the network operator.
The calling and destination mobile stations are any mobile stations that have
subscribed to the related group ID or any dispatcher whose ID is pre-registered
with the network.
Destination mobile stations are all mobile stations or groups of mobile stations
identified by the group ID which are currently located in the group call area, and
pre-registered dispatchers.
When a mobile station initiates a VGCS call, the group call area is uniquely
identified by the actual cell in which the mobile station resides at the moment
of VGCS call initialization, and by the group ID it sends. When a dispatcher
initiates a VGCS call, the dispatcher is connected to a related predefined group
call area. The entitlement of the dispatcher is checked by the MSC to verify the
calling identity. Since a dispatcher may be registered to more than one group
call area and group ID, an indication of the wanted group call area and group ID
is given in form of a dedicated address called by the dispatcher.
The service permits only one calling mobile station to talk at any moment, while
up to five dispatchers can be talking simultaneously at one time. Dispatchers
will hear all combinations of voices other than their own. Listening mobile
stations will hear the combination of all voices.
For more information about VGCS call set up, call management and call
release, refer to:
Call Set Up (Section 3)
Call Handling (Section 4)
Call Release Procedures in Normal Service (Section 5.2).
3BK 21222 AAAA TQZZA Ed.08 245 / 304

6.3 Circuit-Switched Data Modes

There are two types of circuit-switched data modes:
Transparent
Non-transparent.
Transparent Mode (Section 6.3.1)
Non-Transparent Mode (Section 6.3.2).
The following figure illustrates data transmission across the BSS.
BTS BIE BIE BSC SM SM TC MSC PSTN
Mobile
Station
V.110 data blocks ISDN
/Analog
A 13 kbit/s CIM 13 kbit/s 64 kbit/s A/D
A : Analog
A/D : Analog/Digital
CIM : Channel Encoded, Interleaved, and Modulated
SM : Submultiplexer
TC : Transcoder
Figure 35: Data Transmission Across the BSS
6.3.1 Transparent Mode

Transparent data mode is based on the V.110 protocol. V.110 is an ITU
recommendation. It specifies how ISDN supports DTE. It also specifies the
transport of synchronous/asynchronous data over a synchronous link.
Data is packaged and sent to the Transcoder in the same way as speech. It is
converted to the 64 kbit/s ISDN format for data transmission. Error handling is
dealt with by the Air Interface.
Transparent mode implies that the following functions are performed by the
BSS:
Interleaving and Channel Coding

Rate adaptation.
246 / 304 3BK 21222 AAAA TQZZA Ed.08

6.3.1.1 Interleaving and Channel Coding

Interleaving for data is more complicated than for speech. The data block is split
into 22 parts for interleaving 9.6 kbit/s and 4.8 kbit/s data rates. For 2.4 kbit/s,
the interleaving is the same as speech. The lower the data rate, the more space
can be used for redundancy and error detection. This lowers the error rate.
The Air Interface performs the error handling. The V.110 data packets are
grouped together and transmitted across the Air Interface exactly like speech.
The table below shows the data rate and error rate. A low data rate provides
more space for a better forward error correction scheme, in turn reducing
the number of errors.
6.3.1.2 Rate Adaptation
Data is packaged differently in V.110 for different data rates. The bandwidth is
reduced and therefore the rate is lower. See the table below for the rate
conversions. The Transcoder plays the final role in the rate adaptation when
the data stream is adapted to 64 kbit/s packets.
There is a difference between data and speech rate adaptation. Speech is
encoded to A-law, while data is transposed to the first bit and, if required, the
second bit of a Pulse Code Modulation (PCM) byte. PCM transmission is at 8
000 bytes (64 kbit/s). The 8 kbit/s and 16 kbit/s intermediate rates (before the
Transcoder) are transposed as 1 or 2 bits per byte respectively.
Error Rate (at

User Rate Intermediate Rate Radio Interface Full-Rate)
9600 16 kbit/s 12 kbit/s 0.3%
4800 8 kbit/s 6 kbit/s 0.01%
<=2400 8 kbit/s 3.6 kbit/s 0.001%
Table 9: Circuit-Switched Data Rate Conversions Across the Air Interface
3BK 21222 AAAA TQZZA Ed.08 247 / 304

6.3.2 Non-Transparent Mode

Non-transparent data mode is similar to transparent data mode, although data
is transmitted as packets from the modem on the mobile station to the modem
in the PSTN. Error handling is handled end-to-end.
Non-transparent data mode is a data transmission protocol. It is based on
sending RLP packets as four V.110 frames. This is the same process used
in transparent mode. Interleaving and channel coding are still used, as they
are in the transparent mode. The RLP adds extra protection and also allows
the retransmission. Packing RLPs in four V.110 frames ensures transparency
over the network. RLP packet size is the same as a radio block size, so it
is transmitted as one radio block.
Non-transparent data mode uses a 12 kbit/s radio interface rate. Interleaving
and channel coding are at 9.6 kbit/s (the same as in transparent mode). The
only difference between transparent and non-transparent modes for the BSS is
the processing of the four V.110 frames of an RLP packet.
Error handling and rate adaptation are handled as follows:
Error Handling
Non-transparent data mode has a better error rate as there is no forward
error checking or interleaving. Therefore, the size of packets remains small
and less prone to errors. There are however, some cyclic redundancy bytes
and the protocol is very similar in principle to LAPD.
Rate Adaptation
There is no rate adaptation in non-transparent mode. The rate can only be
adapted by physically transmitting less than the full bandwidth available.
The data rate is also limited by the number of errors, as packets have to be
retransmitted. The difference between transparent and non-transparent
mode data links is transparent to the Transcoder, but not to the BTS.
The Transcoder, as described in transparent mode, puts the data in the
first bits of a PCM byte.
The BTS must ensure that an RLP packet maps into four V.110 frames
numbered 0, 1, 2, 3. These must be sent in one block on the Air Interface.
248 / 304 3BK 21222 AAAA TQZZA Ed.08

6.4 Short Message Service - Cell Broadcast

There are two types of SMS:
Point-to-point SMS allows a short message to be sent to, or received
from, a mobile station
SMS-CB allows messages to be broadcast to the mobile stations (i.e.,

one way).
SMS-CB can be used for a number of reasons, for example, to transmit

emergency information, road traffic information, etc. An SMS-CB message
can be transmitted to all the cells connected to the BSC, or to selected cells
only, as required.
The following figure shows the SMS-CB components.
Broadcast Message set

up by OMC−R Operator
OMC−R HMI
Broadcast
Message to
Selected SMS−CB
Cell(s) commands
and signaling
BTS BSC
Message
broadcast to all SMS−CB
Transmission commands
Mobile Stations Request and signaling
CBC
Broadcast Message set

up by CBC Operator
CBC : Cell Broadcast Center
HMI : Human Machine Interface
SMS-CB : Short Message Service - Cell Broadcast
6.4.1 SMS-CB Operation

The SMS-CB is managed and operated from a separate CBC. The CBC is
connected to the BSC and the data needed to connect the BSC to the CBC is
sent from the OMC-R.
The operator at the CBC inputs the cell broadcast message identifying the
broadcast text and the selected cell identities. Only one broadcast message
per cell, or cells, is allowed. Any subsequent message simply replaces the
message being broadcast.
The message is sent from the CBC to the BSCs handling the selected cells.
The BSCs then send the message to the individual BTS of the selected cells.
On receipt of the transmission request message from the BSC, the BTS
broadcasts the message to the mobile stations in the cell over the Cell
Broadcast Channel of the Air Interface.
For SMS-CB, the BSC supports only the connection to an external CBC
platform. The SMS-CB implements all of the improvements of the phase 2+
recommendations.
3BK 21222 AAAA TQZZA Ed.08 249 / 304

6.4.2 Phase 2+ Enhancements

An external CBC can be connected directly to the BSC. This allows the BSC to
send information to the CBC, e.g., billing information.
Two types of connection can be used to connect the CBC to the BSC:
CBC-to-BSC via PSDN

This is the default connection. A BSC can be connected to one CBC.
CBC-to-BSC via MSC

The CBC and OMC-R must be connected to the same MSC.
In addition to the SMS-CB feature managed from CBC, the phase 2+ GSM
recommendation defines the following enhancements:
Greater throughput with a second CBCH channel (extended CBCH)
Better responsiveness when urgent data is to be broadcast due to the use

of high priority messages. Messages can be allocated a priority of high,
normal, or background.
Better service availability through the restart with recovery indication feature.
The feature also offers greater convenience with the support of multipage
messages.
250 / 304 3BK 21222 AAAA TQZZA Ed.08

6.5 Support of Localized Service Area

The aim of Support of Localized Service Area (SoLSA) is to link radio resources
(cells) with services such as specific billing or differentiated access rights.
These services are associated with LSAs (Localized Service Area). An LSA
can be defined over several cells, and a cell can belong to several LSAs. One
possible use of this feature is to enable the efficient deployment of dedicated
corporate applications. The following description uses this example.
In order to efficiently manage corporate LSAs, the Alcatel-Lucent BSS SoLSA
implementation:
Favors the camping of SoLSA mobiles on cells belonging to an LSA where

they have a subscription. These mobile stations will likely camp on the
corporate cells, even if they are not the best ones.
Informs the end user that he is camping on a cell belonging to a subscribed

LSA and thus that he can benefit from the LSA services. This is achieved
through the Localized Service Area Indication SoLSA service.
The localized service area concept gives the operator the basis to offer
subscribers or groups of subscribers different service features, different tariffs
and different access rights depending on the location of the subscriber.
It is up to the operator to decide which services features are required for
a specific service.
The LSA can be considered as a logical subnetwork of the operator‘s PLMN.
This subnetwork can be configured by the operator. A subscriber can have
LSAs at several PLMNs.
The following list shows examples of different types of localized service area:
Office indoors. The office cells are those that are provided by indoor base
stations.
Home or office and its neighborhood. The localized service area can be
broadened outdoors. The neighborhood cells outdoors can be included
in the local service area.
Industry area. A company with several office buildings may want to have a
localized service area that covers all its buildings and outdoor environments.
A part of a city or several locations.
3BK 21222 AAAA TQZZA Ed.08 251 / 304

6.6 PLMN Interworking

A foreign PLMN is a PLMN different from the own PLMN to which the cells
internal to the OMC-R belong. Only cells external to the OMC-R can belong to
a foreign PLMN. All internal cells belong to the own PLMN.
Both OMC-R own cells and cells external to the OMC-R can belong to an
own PLMN.
The Alcatel-Lucent BSS supports:
Incoming inter-PLMN 2G-to-2G handovers

Outgoing inter-PLMN 2G-to-2G handovers (optional feature).
The operators are allowed to define handover adjacency links towards
external cells belonging to a foreign PLMN, i.e., handovers from a serving
cell belonging to the own PLMN towards a target cell belonging to a
foreign PLMN.
Inter-PLMN 2G-to-2G cell reselection

The Alcatel-Lucent BSS allows the operator to define cell reselection
adjacency between two cells belonging to different own PLMN (which must
therefore be owned by two different BSCs).
Multi-PLMN (optional feature).
The Multi-PLMN feature allows operators to define several own PLMN
in order to support network sharing (Tool Chain, OMC-R, MFS, Abis
transmissions - and also BTS, via rack sharing). Inter-PLMN handovers and
cell reselection between two different own PLMN are supported. The BSC
itself cannot be shared and thus remains mono-PLMN (i.e., all BSC own
cells belong to the same own PLMN).
The Alcatel-Lucent BSS supports several own PLMN (up to four, at least
one). An OMC-R thus manage at least one (own) PLMN and up to eight
PLMN (four own + four foreign). Both cell reselection and handover are
allowed between two cells belonging to different own PLMN.
The operator is allowed to define handover adjacency between two cells
belonging to different own PLMN (which must thus be owned by two
different BSCs).
The OMC-R (and the Tool Chain) is by definition of the feature itself always
shared between the different own PLMN. On the other hand:
The MFS can be shared
The BSC cannot be shared
The BTS can be shared up to the rack sharing level (no radio part
sharing)
The Abis transmission can be shared
The transcoder can be shared.
The outgoing inter-PLMN handover feature is a prerequisite for the
multi-PLMN feature.
252 / 304 3BK 21222 AAAA TQZZA Ed.08

7 Cell Environments
7 Cell Environments
This section describes the cell environments available in the Alcatel-Lucent

900/1800 BSS.
3BK 21222 AAAA TQZZA Ed.08 253 / 304

7 Cell Environments
7.1 Overview
The Alcatel-Lucent BSS provides coverage suited to the needs of urban, rural
and coastal areas by offering a variety of possible cell environments. The BSS
supports a set of cell configurations to optimize the reuse of frequencies.
The operator may choose to deploy a network using both GSM 900 and
GSM 1800 bands.
The parameters to define cells are grouped into five types:
Cell dimension
This consists of:
Macro up to 35 km (can be up to 70 km with extended cell), and
Micro up to 300 meters.
Cell Coverage
There are four types of coverage:
Single
Lower
Upper, and
Indoor.
Cell Partition
There are two types of frequency partition:
Normal
Concentric.
Cell Range
The cell range can be:
Normal
Extended.
Cell Band Type. A cell belongs to either the GSM 900 or GSM 1800 bands,
or both in case of a multiband cell.
For the cell name, it is possible to use any combination of the following
characters in the ’Name’ and ’Location Name’ fields: a-z, A-Z, 0 - 9, -, _
(hyphen, underscore).
Blank spaces are permitted. Use the rules fromO&M Parameters Dictionary.
The ’LAC’ and ’CI’ fields accept up to five numeric characters.
254 / 304 3BK 21222 AAAA TQZZA Ed.08

7 Cell Environments
The following figure shows various configurations of the normal GSM 900 or
GSM 1800 cell type. Each of the following sections explains the functional
differences between the cell described and the single cell configuration.
Inner Zone
Outer Zone
Single Cell Concentric
Cell
Sectored Site
Umbrella Cell
Microcell
Microcell
Umbrella &
Microcell Concentric
Cell
Inner Cell Outer
Limit Microcell
Microcell
Microcell
Extended Cell
Inner Cell
Outer Cell
Overlap Zone Outer Cell Inner

Limit
Figure 36: Example: Cell Configurations
3BK 21222 AAAA TQZZA Ed.08 255 / 304

7 Cell Environments
7.1.1 Rural and Coastal Coverage

In a rural and coastal environment, coverage is principally a function of cell
planning. Standard cell layouts provide coverage of up to 35 km. Extended
cells, which have two collocated antennae, provide options covering traffic
density and ranges up to 70 km.
7.1.2 Urban Coverage

In an urban environment the coverage is determined by the location of the
BTS antennae.
Two types of cells are normally used:
Macrocells, where the antenna is located above the roof tops and
propagation occurs in all directions. These cells can be sectored by using
specific antenna patterns.
Microcells, where the antenna is located below roof top level, on building
facades or street lights. Propagation occurs mainly as line of sight along the
street, with strong attenuation at street corners.
Indoor cells.
These three cell types can be used in a hierarchical cell environment where
continuous coverage is provided by the macrocell (umbrella cell) and locations
of increased traffic density are covered by dedicated microcells and indoor
cells. See Umbrella Cell (Section 7.5) for more information.
7.2 Concentric Cell

The goal of concentric cells is to increase the frequency economy of the
network. This is done by reducing the interference levels of some BTS carriers.
These carrier frequencies can be reused for smaller distances.
The inner zone serves a high concentration of mobile station calls in a small
area, with a reduced maximum power output limit. The outer zone performs call
handling for a greater radius with a normal maximum power output limit.
The BCCH, CCCH and SDCCH in concentric cells are put on the outer
zone frequencies. Traffic channel assignment during call connection can be
allocated to either the outer or inner zones. It depends on the location of the
mobile station at that time.
The inner and outer zones are part of the same cell, and a frequency carrier is
assigned either to the inner or outer zone. This is signalled by the zone_type
flag of 1 or 0, (1=inner, 0=outer).
The outer zone maximum power limit is the same as normal zones. The
inner zone is controlled by two maximum power limit values: one maximum
power limit value for the mobile station and one maximum power limit value for
the BTS.
The micro concentric, mini concentric, indoor concentric cells must be
multiband (the allowed FREQUENCY_RANGE is PGSM-DCS1800 or
EGSM-DCS1800). This restriction does not apply to the external cells.
256 / 304 3BK 21222 AAAA TQZZA Ed.08

7 Cell Environments
7.3 Sectored Site

A sectored site consists of one or more BTS. Each BTS hosts up to six
antennae illuminating up to six sectors, each sector covering a separate single
macrocell. The figure below shows a three-sector arrangement.
The BTS in a sectored site contains up to three transceivers which are each
allocated to different given sectors. Each sector and its associated cell are
managed independently and are seen functionally, by the OMC-R and BSC, as
separate BTS connected in chain mode.
Within the physical BTS site, there is a master BTS and up to two slave BTS
(for G2 BTS and Alcatel-Lucent 9100 BTS, each BTS can have three slaves
using the Shared Cell feature; see Cell Shared by Two BTS (Section 7.6) for
more information). Each BTS generates its own clock locally, but the slave BTS
are synchronized to the master BTS.
Sector
1
Cell 1
BTS
Cell 2 Sector
2
Cell 3
Sector
3 Antenna
Figure 37: Sectored Site Configuration
3BK 21222 AAAA TQZZA Ed.08 257 / 304

7 Cell Environments
7.4 Extended Cell

An extended cell is made up of two cells, an inner and an outer, as shown in
the figure below. The inner cell handles calls up to a distance of 35 km (the
same as a normal cell), while the outer cell handles traffic from 33 km up to a
maximum range of 70 km.
There are 3 extended cells allowed on BTS.
Inner Cell
Highway
Urban Area
70 km
max
Outer Cell
35 km
max
Figure 38: Example of Extended Cell Topology
There are two types of extended cell:
Standard Extended Cell (Section 7.4.1)
Enlarged Extended Cell (Section 7.4.2).
258 / 304 3BK 21222 AAAA TQZZA Ed.08

7 Cell Environments
7.4.1 Standard Extended Cell

The inner and outer cells are covered by two synchronized, collocated G2 BTS
or by only one Alcatel-Lucent BTS.
The reception (uplink) of the outer cell is delayed to correspond to a 33 km shift
in range. Radio continuity between the two cells is ensured by the overlap zone.
The inner cell uses two carrier units:
Carrier Unit BCCH Inner: at the inner cell BCCH frequency
Carrier Unit RACH Catcher: at the outer cell BCCH frequency, but with
transmission switched off.
Because the outer cell can have areas of strong signal within the inner cell’s
coverage area, it is necessary to prevent a mobile station in such a region
from camping on the outer cell frequency. This could lead to sudden signal
degradation as conditions change, and eventual loss of the call.
The RACH Catcher receives Channel_Request messages from mobile stations
which are synchronized on the outer cell BCCH frequency, but are within 33
km of the BTS. The BTS knows, from the timing advance sent by the mobile
station, that it is actually in the inner cell, and assigns the mobile station
to an inner cell SDCCH frequency.
The outer cell uses one Carrier Unit with reception delayed by 60 bits. This
effectively shifts the logical position of a mobile station 33 km nearer than
its actual position and allows it to be handled in the standard GSM 0-63 bit
timing advance range.
The handover procedure is controlled normally, with the settings ensuring that
the necessary distance is reached before handing a call over to the outer or
inner cell.
Different types of coverage are possible depending on the type of antenna
used for the inner and outer cells. The example in the figure above shows an
extended cell with an omnidirectional inner cell and directional outer cell.
7.4.2 Enlarged Extended Cell

The enlarged extended cell is an extended cell designed to provide enlarged
capacity for areas where sustained traffic is high. It is especially well-suited for
rural areas and dense highways where more than one TRX is necessary to
handle traffic.
The enlarged extended cell relies on the general principles of the extended
cell: it is made up of two sub-cells to handle calls up to a distance of 70 km.
However, with the enlarged extended cell, the two sub-cells are covered by
one BTS, assuring a higher synchronization rate.
The following telecom features are supported:
The TDMA frame timeslots can be used independently, providing any
TRX with full capacity
Inner cell mobile station access requests use the outer cell BCCH frequency
Handover between the two sub-cells

BCCH TRX recovery.
3BK 21222 AAAA TQZZA Ed.08 259 / 304

7 Cell Environments
7.4.3 PS in Extended Cell

(E)GPRS is supported in extended cell:
NC2 mode is not offered in the extended cell
The Network Assisted Cell Change is not allowed in the extended cell
The (Packet) PSI status procedure is not allowed in the extended cell.
7.5 Umbrella Cell

In much denser traffic areas, depending on the required traffic capacity, a
hierarchical network is used, where continuous coverage is provided by an
umbrella cell (macrocell), and traffic hotspots are covered with dedicated lower
layer cells of limited range. Fast moving mobiles are kept in the upper layer cell
to avoid a high rate of handovers.
For medium density areas small macrocells (called mini cells) are overlaid with
one umbrella macrocell. See Mini Cell (Section 7.5.1) for more information.
For higher traffic densities microcells are installed in all the streets where very
dense traffic occurs. Umbrella macrocells provide continuous coverage for level
and quality handovers, and saturated overlaid cells.
Refer to Microcell (Section 7.5.2) for more information about the relationship
between umbrella cells and microcells.
7.5.1 Mini Cell

Mini cells are used for dense urban areas where traffic hotspots are covered
by very small macrocells (500 m to 1 km radius) and continuous coverage is
provided by an overlaid macrocell (5 to 10 km radius). The lower layer mini
cells handle pedestrian traffic while the umbrella cell handles the faster moving
mobiles. As only macrocells are used there is no street corner effect.
The following figure shows the application of the two-layer hierarchical network,
with macrocells for both layers, in a small town.
Umbrella Cell
Pedestrian area
Mini Cells
Urban area
Figure 39: Umbrella Cell with Mini Cells
260 / 304 3BK 21222 AAAA TQZZA Ed.08

7 Cell Environments
7.5.2 Microcell
Microcells have a small coverage area (less than 300 m radius). These cells
are usually situated indoors or along streets in built-up areas. Microcells
have an umbrella cell (1 to 2 km radius) to minimize the risk of losing calls
by providing maximum coverage.
The microcell’s small radius is created by limiting the maximum power output
strategically to cover a pre-defined microcell area.
Handover occurs more frequently in a microcell environment due to the
small radius sizes.
Microcell handovers occur:
To handle stationary mobile stations (especially mobile stations used

indoors)
When a mobile station moves in a street covered by microcells
To avoid losing calls. Whenever there is a risk of losing a call, a handover

is triggered to the umbrella cell.
Fast moving mobiles are handled by the umbrella cell. A mobile handled by a
microcell is sent to the umbrella cell if the delay between handovers becomes
too small. Conversely a mobile is sent to a microcell if it receives a high
level of signal for a sufficient time.
Call quality/control is achieved by providing four thresholds for microcell
handover and one handover threshold for macrocell handover.
7.5.2.1 Micro-to-Micro Handover

Microcell to microcell handover occurs due to the proximity of the two cells.
When the power budget is better in another cell, the mobile station is handed
over to the cell which will serve the call more efficiently. This normally occurs in
microcells serving in the same street.
3BK 21222 AAAA TQZZA Ed.08 261 / 304

7 Cell Environments
7.5.2.2 Micro-to-Macro Handover

The following table describes the three types of micro-to-macro threshold
handovers.
This Handover Type... Occurs when...
High Threshold Handover The signal strength has dropped below the theoretical signal level at the
radius of the cell. This would normally mean that the mobile station has
turned a street corner.
Low Threshold Handover The mobile station level is under the high threshold and the signal level has
dropped below the low threshold. The handover is to the umbrella/macrocell,
which supports the call until the mobile station moves into another cell.
When the macro to micro threshold is exceeded in the umbrella/macrocell,
the mobile station is passed to a new microcell.
Rescue Handover The mobile station is forced to handover to the umbrella cell when no
measurement reports are transmitted. This occurs after a number of
consecutive SACCH reporting periods.
7.5.2.3 Macro-to-Micro Handover

This occurs when the mobile station signal level in a microcell is above the
M_to_m threshold for a certain period. This threshold value must always
be higher than the low threshold value of the cell. Otherwise, a handover
ping-pong effect can occur between the umbrella and the microcell.
Note: If the low threshold is not used, the M_to_m Threshold value must be above the
high threshold value.
262 / 304 3BK 21222 AAAA TQZZA Ed.08

7 Cell Environments
7.5.2.4 Threshold Handover Example

The example in the figure below shows two typical cases of handover in
microcells:
Micro-micro handover along a street (Case 1 in the figure below)
Signal levels rising and dropping, causing macro-micro handover (Case

2 in the figure below). This example shows the use of the two levels
of macro-micro handover (strong to weak signal, and weak to weaker
signal). This is represented by the high and low threshold handovers. This
example also shows the macrocell handing back to a microcell once a
stronger signal level is received.
High Signal Level
1
Micro−Micro
Handover
2
High Threshold
d 3 4 6
B M_to_m Threshold
m
Low Threshold
5
Low Signal Level
Micro-Micro Handover (Case 1)

A mobile station is moving along a street.
As it moves along a street, the mobile station is handed over from microcell to
microcell (1).
Macro-Micro Handover (Case 2)
A mobile station turns a corner then moves indoors.
1. Call starts at (2). The signal level is normal.
2. The mobile station signal level drops below the high threshold level (3), e.g.,
when turning a corner. To protect the call, it is handed over to the macrocell
until a better microcell is found. The call remains with the macrocell until a
strong signal from another microcell is received (normal case).
3. If a strong signal from a microcell cannot be found, a weaker signal from a
microcell with enough strength to be above M_to_m threshold level, but that
remains below the high threshold is found (4).
In this case, as long as the signal strength remains above the low threshold
and there is not a better microcell, the call remains with that microcell
(e.g., the mobile station is indoors).
4. The signal level drops below the low threshold (5). The mobile station is
again passed to the macrocell (e.g., the mobile station moves further inside
a building). The macrocell is used to ensure call quality.
5. The mobile station moves into a position where the mobile station reports a
microcell signal level above the M_to_m threshold (6). The call is handed
over to that microcell, e.g., the mobile station is still indoors, but has a
stronger signal from a microcell.
3BK 21222 AAAA TQZZA Ed.08 263 / 304

7 Cell Environments
7.5.3 Indoor Cell

The aim of indoor layer support is twofold:
Firstly, to enable a better radio coverage inside large buildings (hotels,

shopping malls, corporate centers) by the public network
Secondly, to unloaded the cells provided for outdoor coverage but which are
accessible from these buildings.
Indoor cells can be deployed in all types of network, even in very dense
networks which already have two layers (upper and lower). The feature eases
the optimization of multilayer networks which include cells dedicated to indoor
coverage. Indoor coverage is performed mostly from outdoor BTS. Although
already satisfactory in many cases, the indoor quality of service can be
improved by using dedicated in-building equipment. Together with this improved
quality, an increase in the indoor capacity can be achieved, particularly in high
density public areas such as airports, train stations, shopping malls, business
parks, etc. A three layer per band management is introduced and a new type
of cell is defined (the indoor cell) that maximizes traffic in these indoor cells
while preserving quality. In idle mode, classical criteria (C2) allows mobiles to
be forced to camp on indoor cells.
For example, when entering a building covered by an indoor cell, calls are
automatically transferred from outdoor cells, whatever their type. When moving
inside the building, calls are transferred from one indoor cell to another one,
even if the received power from outdoor cells is higher. It is only when the
mobile leaves the indoor coverage that it is transferred to an outdoor cell.
It is important for the Operator to minimize interference from indoor to
outdoor. Therefore, indoor cells will often be used with very low radiated
power (picocells). In this context, the feature also provides enhanced Power
Control algorithms.
The cells added to the network for indoor coverage are referred to as indoor
cells and form a new layer referred to as the indoor layer. The following figure
gives an example of network structure with three layers and two bands.
Umbrella cell 1800

Upper layer
Umbrella cell 900
Micro−cell 1800 Micro−cell 1800 Micro−cell 1800 Lower layer

Micro−cell 900 Micro−cell 900 Micro−cell 900
Indoor cell 1800

Indoor layer
Indoor cell 900
Figure 40: Indoor Cell Example Network Hierarchy with Three Layers and Two Bands
264 / 304 3BK 21222 AAAA TQZZA Ed.08

7 Cell Environments
The already deployed network hierarchy has to be adapted as follows:

If there were already two layers, cells belonging to the upper layer will
remain unchanged. Outdoor cells belonging to the lower layer will also
remain in the lower layer. New cells introduced for the indoor layer will
belong to the indoor layer
If there was only one layer, cells having the cell_layer_type "single" will
become upper. New cells introduced for the indoor layer will belong to the
indoor layer. There is no lower layer.
7.6 Cell Shared by Two BTS

The system is able to handle cells whose TRXs are located in two different BTS.
This feature brings important flexibility by allowing:
An existing site to be extended by only adding TRXs in a new BTS, not

changing the arrangement of the existing BTS
Existing cells to be combined into one, e.g., combine one 900 cell and one
1800 cell in order to create a multiband cell
The support of 3x8 TRX configurations in two racks (instead of three)
The support of 16 TRX per cell.
Note: This feature only applies to BTS 9100.

Each set of TRX in a certain BTS must have its own coupling. It is possible to
combine the coupling output towards the same antenna through an additional
duplexer, although this is a special installation. The fact that part of the sector is
in another BTS does not increase the number of necessary antennae. For BTS
9100, each BTS can have one slave, but each slave can in turn have another
slave, up to a maximum of three linked slaves for one master BTS. If linked BTS
support part of the same cell, the linked BTS must be clock synchronized with
each other (master/slave).
With this feature, the operator can associate two physical sectors from different
BTS into one shared sector. This shared sector can be mono or dual-band
and it can support one cell as a normal sector. It takes the identity of one of
the physical sectors, called the primary sector. The other physical sector is
the secondary sector.
3BK 21222 AAAA TQZZA Ed.08 265 / 304

7 Cell Environments
7.7 Unbalancing TRX Output Power per BTS Sector

The feature allows unbalanced configurations on the same antenna network.
This configuration behaves as a concentric cell, where the output power
balancing is performed on a zone basis instead of on the sector basis.
Furthermore, for 3 TRXs per ANc configuration, 2 TRXs are used in combining
mode on the first antenna path and 1 TRX is connected in by-pass mode
on the second antenna path. This leads to the same sort of concentric cell
configuration as in the case TREs with different output power are used.
When the feature is activated, the BSC maps, on the HP TRE, the TRX
configured by the operator on the outer zone and maps the TRX of the inner
zone on the others. A new mapping algorithm takes the place of the adjust
when the feature is activated on a concentric cell.
The BTS informs the BSC, for each TRE, about the GMSK and 8PSK output
power (after coupling). The BTS informs the OMC-R through a hardware audit
about the output power of each TRE for GMSK and 8PSK modulation.
The feature can be activated at the OMC-R through one of the Power Control
parameters (EN-Unbalanced-Output-Power). It is not an optional feature.
266 / 304 3BK 21222 AAAA TQZZA Ed.08

8 Operations & Maintenance
This section provides an overview of O&M and describes O&M functions in the
context of an operational network.
For more information about O&M, refer to the Operations & Maintenance
Principles.
3BK 21222 AAAA TQZZA Ed.08 267 / 304

8.1 Overview
To ensure that the BSS operates correctly, O&M actions are implemented at
all levels within the BSS.
The O&M functions in the BSS are grouped into three categories:
Configuration Management
The main benefit of configuration management is the reduced time needed
to perform operations and reduce telecom outages. This is achieved by
having fewer operator commands and providing smooth migration and
equipment configuration. The main functions of configuration management
include radio configuration management and equipment management.
Fault Management
Fault Management is used to supervise and to repair the network when
anomalies occur. This is done through a sequence of steps from detection to
report and recovery. These are carried out by all the BSS/MFS subsystems,
and are reported to the operator at the OMC-R.
Performance Management.
Performance Management is used to monitor the efficiency of the system
and the telecom services. It is controlled entirely from the OMC-R and
provides measurements and statistics about various traffic events and
resource use in the BSS.
268 / 304 3BK 21222 AAAA TQZZA Ed.08

8.1.1 Subsystem O&M Functions

The table below provides a brief description of the O&M functions at the
subsystem level.
This O&M function... Is used...
Configuration To view and control network resources. Configuration Management allows the
Management operator to:
Configure the BSS/MFS hardware and software when it is first installed
Change the network by adding, deleting, or moving network entities
Upgrade to new hardware or software
Change equipment and telecom parameters to improve system performance.

For more information, see Configuration Management (Section 8.4).
Fault Management By the BTS to monitor the condition of the hardware modules it manages, and
report any change in status to the BSC.
By the BSC to supervise its own hardware modules and report changes in status
to the OMC-R.
By the BSC and Transcoder together to provide a set of transmission O&M
functions to ensure a high level of fault tolerance and reliability. The functions also
provides efficient use of the terrestrial links between the equipment of the BSS.
By the MFS to supervise its own hardware modules and report changes in status
to the OMC-R.
For more information, see Fault Management - Alarms (Section 8.5).
Performance By the BSC and the MFS to:

Management
Collect raw measurement data from network elements
Transfer the raw measurement data to the OMC-R, where the results are
processed and displayed.
For more information, see Performance Management (Section 8.6).
3BK 21222 AAAA TQZZA Ed.08 269 / 304

8.1.2 System O&M Functions

The OMC-R is responsible for O&M functions at the system level.
Its principal operations are:
Network configuration
It provides the operator with an interface to the system to:
Perform software configuration management (files, version downloading)
Perform hardware configuration management (e.g., update the
configuration according to extension/reduction operations, configure
certain BSS parameters such as Abis link characteristics and some
BTS characteristics)
Provide configuration functions for logical parameters.
Network supervision
Display alarm status and history
Display equipment and resource states
Monitor and display performance measurement results
Provide Usage State on Demand observations
Define and supervise counter thresholds (Quality of Service alarms).
Network maintenance
Access equipment management functions (test)
Access resource equipment state management.
Lock and unlock equipment and resources
Keep track of hardware and software configurations in the system and

managing software versions
Provide mediation between the BSS and one or more NMCs. This uses the
Q3 interface.
Provide an interface to the electronic documentation collection.
For more information about the OMC-R and its functions, refer to the Operations
& Maintenance Principles and the Getting Started document.
270 / 304 3BK 21222 AAAA TQZZA Ed.08

8.2 O&M Control - Subsystems

O&M functions are controlled either at subsystem level using the LMTs and the
IMT (for the MFS) or by the OMC-R at BSS/MFS level. This section provides a
brief overview of subsystem control.
8.2.1 LMTs and IMT

Local Maintenance Terminals are used when performing maintenance tasks at
the BSC, BTS, and Transcoder. LMTs are connected directly to the equipment.
The operations available at the LMTs act only on the local hardware, not
on logical resources.
The IMT performs maintenance tasks at the MFS, using a Mozilla browser.
All these tasks (except for three tasks associated with alarms, enable/disable
sound, view history file, and enable/disable external alarm management) can
also be accessed from the OMC-R terminal. The IMT alarm tasks are not
provided when the IMT is accessed from the OMC-R because the OMC-R
already has its own alarm management tasks.
The IMT software can be accessed from either the IMT or the OMC-R. It has
three different user profiles: administrator, operational, basic.
If the IMT software is accessed from the IMT, two administrator sessions at a
time can be run. Two instances of the IMT can be in use at the same time.
The IMT is integrated into the OMC-R and, as a result, provides:
Multiple entry points to the IMT (from MFSUSM, RNUSM and DCN)
Centralized user management: at the OMC-R (the OMC-R operator no

longer has to log on to the IMT)
Parallel access to a given MFS, with up to eight users per session
A separate time out is used for every administrative user. The time out delay
proposed is 15 minutes.
N basic users and (8-N) GPU users at most (8 > = N always) are supported
Better performance on the OMC-R, due to IMT Fast Start.
With the exception of multiple entry points to the IMT, the above features are
only available when both the OMC-R and the IMT are in B10.
For more information about LMTs, refer to one of the following:
BSC Terminal User Guide
Transmission Terminal User Guide
BTS Terminal User Guide
Alcatel-Lucent 9125 Compact TC Terminal User Guide

Alcatel-Lucent 9135 MFS IMT User Guide
9130 MFS Evolution IMT User Guide.
3BK 21222 AAAA TQZZA Ed.08 271 / 304

8.2.2 OML Auto-Detection

An OML auto-detection feature exists to take full advantage of the transmission
configuration via OML feature (which is more reliable and more robust than
configuration via the Qmux channel). The OML auto-detection feature provides
the following benefits:
Transmission configuration via OML on all Alcatel-Lucent BTS
No LMT configuration necessary during Move BTS

Secure recovery after OML breakdown
Simplification of BTS installation (for Plug and Play BTS).
See OML Auto-Detection (Section 8.4.6) for more information.
8.2.3 Managed Objects

Managed Objects are used to represent elements of the Telecommunication
TMN environment on the Q3 Interface in terms of system resources. This
concept is also used to represent the activities of management function blocks
performed on these resources.
In Alcatel-Lucent’s network management model, Managed Objects can be
physical entities, such as a BSS, BTS, BSC, or a hardware module within one of
these entities. They can also be a logical entity, such as programs or program
routines which implement communication protocols.
8.2.4 Security Blocks

Alcatel-Lucent has an internal object model structure, based on objects called
Security Blocks. Security Blocks are only used for the BSC, the BTS, and the
Transcoder. Security Blocks are only visible to an operator performing local
maintenance using certain LMTs, such as the BSC terminal, BTS terminal,
or Transmission terminal. The SBL model is not used by the OMC-R or the
IMT. The OMC-R can display SBLs in certain circumstances, for example, in
BSSUSM.
272 / 304 3BK 21222 AAAA TQZZA Ed.08

8.3 O&M Control via OMC-R

The OMC-R is the primary control station for the BSS/MFS and manages the
majority of O&M functions. The OMC-R provides the operator interface used
to perform Configuration Management, Fault Management and Performance
Management actions. The following features help the OMC-R to manage
O&M activities.
8.3.1 Multiple Human-Machine Interface

This feature permits one OMC-R operator to perform actions normally done by
several OMC-Rs, typically during off-duty hours. The connection between the
multiple access workstation and the other OMC-R hosts is via an X.25 network.
The following figure illustrates the operation principles.
Central Site
Additional
Printer
Workstation
HMI Multiple Access

Server Workstation
X.25 Network
OMC−R
OMC−R Host n
Host 1
OMC−R
Host 2
HMI : Human Machine Interface

Figure 41: Multiple HMI Access to OMC-Rs
The implementation of this feature takes advantage of the distributed

configuration of the OMC-R which usually consists of a host machine and
distinct local or remote HMI servers.
3BK 21222 AAAA TQZZA Ed.08 273 / 304

The site used for multiple access contains the following:

Printing facilities
Additional workstations which connect to the multiple access workstation,

but only connect to the same OMC-R
Configuration of each OMC-R is specific to the multiple access workstation
and its peripherals.
8.3.2 ACO
Alarm Call Out (ACO) is a process within the HMI server used to perform alarm
management tasks for a complete network. Alarms from the BSSs controlled
by other OMC-Rs are directed to one OMC-R. These links are used to transfer
alarm notifications from the controlled OMC-Rs to the ACO OMC-R, as shown
in the figure below.
The ACO OMC-R:
Collects alarms from these OMC-Rs
Applies filters defined by the on-duty operator
Sends the filtered results to a dedicated printer

Sends e-mail to support technicians.
It is possible to start and stop ACO from any OMC-R.

ACO OMC−R
Workstation
OMC−R 3
OMC−R 1 Area 3
Area 1
OMC−R 2
Area 2
ACO : Alarm Call Out

Figure 42: ACO Links
274 / 304 3BK 21222 AAAA TQZZA Ed.08

8.3.3 Connection from BSC to OMC-R

8.3.3.1 Secured X.25 Connection From 9120 BSC to OMC-R
The Secured X.25 Connection feature provides redundant links in the event of a
link failure on either the OMC-R or BSC side. When a link failure occurs, the
initiator system involved must process the changeover.
The configuration for the X.25 links consists of two physical links, one for
CMISE, and one for FTAM. The following figure illustrates the configuration
without redundancy.
OMC−R
X.25 Network
BSC A
CMISE BSC A CMISE
HSI 0 OSI CPRA 1
BOARD
1
2 FTAM BSC A FTAM
3 OSI CPRA 2
CMISE : Common Management Information Service Element

CPRA : Common Processor Type A
FTAM : File Transfer Access and Management
HSI : High Speed Interface
OSI : Open System Interconnection
Figure 43: X.25 Without Redundancy
Definition of the primary and the secondary links based on their hardware
configuration can achieve various types of redundancy, such as:
OMC-R-side redundancy
BSC-side redundancy
Complete redundancy.
3BK 21222 AAAA TQZZA Ed.08 275 / 304

The following figure illustrates these redundancy types.
OMC−R
X.25 BSC
Network Primary Link
HSI 0 OSI CPRA 1
Board
1 1
2 2
OSI CPRA 2
3 3 Secondary
Link
Secondary Link Configurations

1. OMC−R side redundancy
2. BSC side redundancy
3. Complete redundancy
CPRA : Common Processor Type A
HSI : High Speed Interface
OSI : Open System Interconnection
Figure 44: X.25 With Redundancy
When the OMC-R or the BSC sets up a CMISE or FTAM association, the
subsystem chooses the active link. The active link is the primary link if it is in
traffic, otherwise it is the secondary link.
The following events occur:
The transfer is performed on the primary link if the association is successful.
The association is attempted three times.
The primary link is set out of service if the association is unsuccessful

after the third try
If the secondary link is in traffic, it becomes the active link and the
association is tried on this link.
If the secondary link is out of service, the application is impossible.

Links are periodically tested for availability. When the primary link is recovered,
it becomes active and in traffic. Loss of one link (i.e., primary or secondary)
triggers an alarm and the recovery triggers the end of alarm.
8.3.3.2 Secured IP Connection From 9130 BSC to OMC-R

Note: For the 9130 BSC, the X25 links are replaced by IP. As with the 9120 BSC, the
9130 BSC can support both routes to connect to the OMC-R, namely over a
direct IP network or over an Ater and IP network.
In order to maintain stable ISO services and decrease development costs
and risks, TS is used on the TCP which is specified by RFC1006 for the IP
interface between the 9130 BSC and OMC-R. TSAP and TS are maintained,
and original NS primitives are replaced with TCP primitives. FTAM is replaced
with FTP for file transfers.
276 / 304 3BK 21222 AAAA TQZZA Ed.08

8.3.4 Electronic Documentation

Installation and use of the electronic documentation collection depends on the
configuration.
Small Configurations
The documentation collection is installed on each OMC-R. To search the
documentation collection, install the documentation collection CD-ROM on a
single PC, and use the search function provided on the CD-ROM.
Standard, Large, and XLarge Configurations.
The license for the documentation collection is installed on one OMC-R. All
other OMC-Rs on the same site are connected to this OMC-R. The maximum
number of users that can be managed for each search engine license is 75.
This corresponds to a site with five Large configuration OMC-Rs.
Refer to 9153 OMC-R Capacity per BSS Category for more information about
the various OMC-R configurations.
3BK 21222 AAAA TQZZA Ed.08 277 / 304

8.4 Configuration Management

Configuration Management is the process of putting in place the essential
hardware and software components of the network, and determining their
operating capabilities. The table below shows the configuration management
functions of each network element.
Network Configuration Management Functions

Element
BSC Software and database replacement
Reading and modifying logical parameters.
BTS Supervision of the BTS equipment. This includes initializing and configuring the BTS.
Transfer of software and data files to the FUs (G1/G2 BTS) or TREs (BTS 9100/9110)
Software and database replacement

Auto Identification (BTS 9100/9110 only). See Auto-Identification (Section 8.4.5) for
more information.
Application of the logical configuration of the BTS.
Transcoder Communication through the Q1 Interface with the Transcoder, SM and BIE modules
Permission for configuration and reconfiguration of the Transcoder, SM and BIE modules.
TSC Communication through the LAPD link with the BSC
MFS Reading and modifying parameters
Control station and GPU configuration
Framer configuration for Gb Interface messages
GPU switch configuration for circuit-switched connections.
For detailed information about configuration management, refer to Configuration

Management in the Operations & Maintenance Principles or the descriptive
documentation.
278 / 304 3BK 21222 AAAA TQZZA Ed.08

8.4.1 Hardware Configuration

Hardware Configuration enables the operator to:
Control the placement in service of both BSS and MFS hardware
Control the manner in which deployed hardware elements will act and
interact within the BSS and MFS
Modify the parameters that control these elements.
It also permits the operator to view the current hardware configuration status
of the network.
8.4.2 Logical Configuration

There are three types of Logical Configuration:
Radio Logical Configuration allows the operator to change the parameters

that control the Air Interface. This includes channel definitions, manipulating
and reconfiguring the Carrier Units or TREs and defining the Frequency
Hopping System.
Cell Logical Configuration displays and modifies BSS logical parameters

and threshold values which influence a cell’s operational behavior. These
are divided into several classes which simplify searches.
GPRS Logical Configuration allows the management of the following:

The telecommunications application, including bearer channels, Gb
Interface, Ater Mux Interface towards the BSC, and cell management
domains
Synchronization of the logical GPU resource states after a server
changeover
Configuration of a logical GPU when requested by the GPU (after a
start, reset or changeover)
Network service configuration and the supervision of the Gb Interface
domain.
3BK 21222 AAAA TQZZA Ed.08 279 / 304

8.4.3 Default Parameter Customization

Customers receive a standard set of default telecom parameters. It is not
possible for these default parameters to fit each customer’s specific network
configuration. Until recently, customers had to manually modify certain default
parameters for their network. The default parameter customization feature
makes it easier to perform this task.
This feature allows access to the list of customizable parameters via a
dedicated menu, Default Values Customization. This menu display a window
with a parameter list containing all relevant information about each modifiable
parameter. From this window, the user can edit the default values for each
listed parameters as necessary. A filter mechanism allows users to search for
specific parameters by name and/or by object type.
The allowed parameter object types are:
BSC parameters
CELL parameters
ADJACENCY parameters
TRX parameters.
For detailed information about this feature, refer to the 9153 OMC-R
Administration Handbook.
8.4.4 Software Configuration

Software Configuration enables new versions of the BSS software to be
installed in the BSS. This feature also allows the operator to display current
software versions of the BSS. BSC and BTS software is managed from the
OMC-R, while MFS software is managed from the IMT.
8.4.5 Auto-Identification
Auto-Identification provides the BTS 9100 and the BTS 9110 with the capacity
to recognize their own hardware configuration, and to provide this information
to the OMU and the BTS Terminal.
The auto-identification procedure is triggered by the OMU in the following
situations:
BTS/SUM power up
BTS reset
OMU reset/auto reset
Module initialization (on maintenance operator command, or during a Local

Recovery Action or Hardware Extension; the auto identification takes place
only for the module(s) concerned by the operation).
The BTS 9100 and the BTS 9110 capabilities received by the OMU at
auto-identification are stored and can be used internally by the OMU software
or sent to the BSC at Hardware audit.
280 / 304 3BK 21222 AAAA TQZZA Ed.08

8.4.5.1 Auto-Identification Components

Auto-identification has the following two components:
Remote Inventory
Remote inventory identifies the following:
RIT type of each managed module
Hardware capabilities of each RIT.
RF Cable Identification
RF Cable Identification provides the following information:
Location of each RIT (subrack and slot)
Sector to antenna network x mapping
TRE to antenna network x mapping.
For more information, refer to the BTS Functional Description and the BTS
Terminal User Guide.
8.4.5.2 Consistency Checks

When a new Configuration Data Message is received from the BSC, the BTS
9100 and/or the BTS 9110 perform a consistency check of capabilities against
the Configuration Data Message. They also do this at module initialization due
to maintenance operator command or to a Hardware Extension operation. The
BTS 9100 and/or BTS 9110 also check that the received OMU Configuration
Parameter Data File is valid for this generation of BTS. Consistency checks are
also performed by G1 and G2 BTS.
For more information, refer to the following:
Alcatel-Lucent BTS 9100/9110 Functional Description
Alcatel-Lucent BTS 9100 Hardware Description

BTS Terminal User Guide.
3BK 21222 AAAA TQZZA Ed.08 281 / 304

8.4.6 OML Auto-Detection

The OML auto-detection feature was introduced in order to take full advantage
of the transmission configuration via OML feature (which is more reliable and
more robust than configuration via the Qmux channel).
The OML auto-detection feature provides the following benefits:
The feature allows one extra timeslot to be used for signaling (if no G1/G2
BTS are present on the Abis Interface). This provides an increase of telecom
traffic on one Abis (because there are no timeslots dedicated to the Qmux).
There is no need for onsite BTS reconfiguration during a move BTS scenario
(using the LMT to reconfigure the BTS). Also, the Qmux address for the
Alcatel-Lucent BTS can be modified remotely from the OMC-R.
There is no need for onsite BTS reconfiguration during an OML multiplexing

change (from 16k to 64k)
Secure recovery after OML breakdown
Simplification of the commissioning procedure: Synchronization between

OMC-R and commissioning personnel is no longer required. The BTS can
be installed before or after the BTS is created at the OMC-R.
The OMC-R operator no longer needs to know on which timeslot the OML is
located, and no longer needs to configure it manually
Transmission configuration via OML for all Alcatel-Lucent BTS.
282 / 304 3BK 21222 AAAA TQZZA Ed.08

8.4.7 Network Element Provisioning

Network element provisioning allows equipment that is not yet in commercial
use to be distinguished from equipment that is under maintenance. This
is not important for network monitoring. The feature introduces the status
"commercial use" that is associated with the BTS. This status is changeable
online from the OMC-R. It is also available at the radio configuration
export/import interface of the OMC-R for co-ordination with the operators’
information systems. For the BTS marked as "not in commercial use", potential
alarms are raised with a "warning" severity and the performance measurement
results are not taken into account. BTS marked as "not in commercial use"
are not reported in the topology files sent to the 9159 NPO. They can also be
filtered from the supervision view.
Previously, as soon as a BTS was declared, it was supervised, but this raised
permanent alarms when the BTS was not physically connected. If cells were
created on this BTS and PM cell measurements ran on it, this led to very poor
PM results as the BTS was not in commercial service.
An attribute (commercialUse = On or Off) is associated with each BTS. The
attribute can be changed at both the SC and the PRC radio network level to
mark the BTS as out of commercial use, or in commercial use. When this
attribute is set (i.e., the BTS is out of commercial use), all alarms related to the
BTS have a maximum severity equal to a warning (except for the alarms from
the MFS). At the OMC-R, the operator still sees all of the alarms and alarm
states, and is able to trigger all O&M commands. This allows the operator to be
aware of the fault situation of the BTS, but does not give a false status of the
network. There is no PM handling and storage for BTS that are marked out
of commercial use (except for the PM counters that are relative to RSL/OML
traffic which are not filtered).
To avoid any impact of cells not in commercial use on 9159 NPO indicators, the
operator follows the sequence below:
1. Create the BTS.
2. Set it in ’no commercial use’.
3. Map the cell onto the BTS.
In the scenario above, none of the PM observed by the BSC on this cell are
taken into account by MPM/9159 NPO. If the operator maps the cell before
putting the BTS in commercial use, the BSC starts reporting PM on it. As soon
as PM results are collected by MPM/9159 NPO, indicators are computed. Due
to the extrapolation function of 9159 NPO, these indicators are computed
for a long period. At this point, it is essential to prevent any reporting so
as to avoid misleading indicators.
8.5 Fault Management - Alarms

The BSS generates alarms to signal a change in the behavior of a particular
function within the system, such as a potential problem or a confirmed failure
in the system.
This section describes the alarm generation process. It describes the alarms
and their effects on the system.
3BK 21222 AAAA TQZZA Ed.08 283 / 304

The following table shows the fault management functions of each network
element.
Network Fault Management Functions

Element
BSC BSC
Fault detection, fault correlation and fault localization on all devices controlled by
the processor
BSC reconfiguration in case of loss of the BCCH, Terminal Control Unit/FU or a

Carrier Unit (G1 or G2 BTS)
BSC reconfiguration in case of loss of the BCCH, TCU/TRE (BTS 9100/9110).

Through the TSC, the BSC also performs the following functions:
Monitors the status of the Transcoder, SM and BIE modules
Provides local access to configure the Transcoder, SM and BIE modules via an
RS-232 connection to the BSC terminal
Gives access to the fault localizing features of the TSC (for example, the ability to
set up loop-back tests).
BTS BTS
Testing the equipment. This includes collecting alarms and reporting to the BSC.
Fault detection, fault correlation and fault localization for the BTS
Management of equipment states. This includes triggering BTS channel configuration
in case of a failure.
Provides access for local diagnostics and configuration of the BTS

BTS power supply control
Event report management. See Alarm Generation (Section 8.5.1) for further
information concerning events.
MFS MFS
Collects all fault information for telecom and external alarms, the telecommunications
hardware and the active server
Records the fault information in a table
Allows the IMT and the OMC-R access to the fault information
Generates the ending alarm for pending alarms
Manages the communications with the IMT.
For additional information about fault management, refer to the descriptive

documentation and Fault Management in the Operations & Maintenance
Principles document.
284 / 304 3BK 21222 AAAA TQZZA Ed.08

8.5.1 Alarm Generation

When an Alarm is generated, it is indicated as either:
Fault (begin or end)

If a fault arises, the related alarm is stored in the relevant BSS unit, and also
in the OMC-R. The alarm begin message signals that a particular system
activity has stopped due to an error. When the error is corrected, an alarm
end message is sent to indicate that the condition no longer exists, and the
alarm is taken out of the Alarms-in-Force list.
Event
An Event occurs when an unexpected situation arises during system
operation.
Alarms can be generated as a result of previous alarms or events which

influence other parts of the system. For example, when the Carrier Unit
produces an alarm to signal an internal fault, the FU and the Radio Signaling
Link produce alarms to signal that no information is being received from the
Carrier Unit. Fault correlation and filtering actions are performed by the O&M
modules in each unit, so that a single fault is sent as an alarm. In the case of
the faulty Carrier Unit, an alarm is sent signaling a Carrier Unit fault. In this
example, the loss of the RSL link is signalled from the BSC but is not correlated.
For more information, refer to Alarm Handling in the Operations & Maintenance
8.5.2 Alarm Functions

The following alarm functions help the operators monitor and correct fault
conditions in the system.
8.5.2.1 Correlation
Correlation refers to the collection and analysis of all available fault indications
for a particular problem. Fault correlation is performed to define where and why
the fault occurred.
An example of correlation is when:
1. Several boards in the BTS report clock problems, and these reports are
correlated by the OMU.
2. The ’clock generator is faulty’ alarm is sent to the OMC-R via the BSC.
8.5.2.2 Filtering
Alarms are filtered to minimize the number of fault alarms reported and
displayed to the operator and are displayed in order of severity.
To reduce the number of alarms in the OMC-R, short end alarms are filtered.
For these alarms a BEGIN is raised soon after the previous END.
These END /BEGINs are not considered significant and are filtered. The
operator sees fewer alarms and is informed that alarms are filtered, because
the number of filtered alarms, if any, is indicated in AS.
For more information, refer to Alarm Handling in the Operations & Maintenance
3BK 21222 AAAA TQZZA Ed.08 285 / 304

8.5.2.3 Persistency
A fault is signaled only if there is no recovery after the timer expires. For
example, for a LAPD failure of an RSL link, an alarm is only sent if the LAPD
link has not recovered before the persistency timer has expired.
8.5.2.4 Alarm Surveillance
AS is an OMC-R application that supports fault management integration in
TMN functions. It collects alarms issued by applications residing in the various
Management Layers and processes them.
To improve operator action visibility on alarms in RNUSM, the displayed
information is reshuffled, as RNUSM was not designed to support supervision.
The operator can see whether unacknowledged alarms are still present.
Use of alarm acknowledge status, alarm status, and alarm synthesis are
computed on all active alarms. The operator is, as yet, unaware of new alarms.
It is presumed that an operator is aware of each alarm he acknowledges and
unaware of alarms that he has not acknowledged.
8.5.2.5 Alarms-in-Force List
Each BSS component keeps an Alarms-in-Force list, so that the system
knows that an alarm has begun. This list ensures synchronization of alarms
throughout the BSS components. This makes the alarm situation visible
at all times. The OMC-R also keeps track of all the Alarms-in-Force lists
for each BSS component.
286 / 304 3BK 21222 AAAA TQZZA Ed.08

8.5.3 BSC Alarms

The BSC detects alarms on the Abis and A trunk via the TCU and the DTC. It
also detects alarms from each functional unit of the BSC.
For more information, refer to Alarm Handling in Operations & Maintenance
Principles.
8.5.3.1 Processor Failure

The active S-CPRA creates a daisy-chain map of all the processors in the
BSC. Every ten seconds, the S-CPRA sends the map to the next processor.
This processor sends the information to the next processor in line, until the
S-CPRA receives the daisy-chain map.
The daisy-chain map can be modified by an intermediary processor when that
processor cannot send the map to the next processor in line. In this case, the
intermediary processor skips the processor and removes that processor
from the daisy-chain map. When the S-CPRA receives the map with the
same processor missing twice in a row, it tries to recover the processor. If
the processor cannot be recovered, the S-CPRA places the processor in
the FLT state.
The S-CPRA signals the processor failure to the OMC-R as follows:
If the processor failure is in the TCU, recovery only takes place to ensure
BCCH functionality
If a DTC processor fails, the BSC tries to inform the MSC, so that the MSC
is aware the SS7 link is out of service. This implies:
The loss and, if possible, the changeover of the SS7
The blocking of circuits.
3BK 21222 AAAA TQZZA Ed.08 287 / 304

8.5.3.2 Telecom Link or Trunk Failure

The TSC supervises its trunks between the Transcoder, BTS, and MSC.
Failure of the Abis Interface is signaled to the BSC by all of the RSLs of the
associated BTS. A single RSL failure reflects the status of the corresponding
LAPD and FU.
All A Interface faults are controlled by the Transcoder and the MSC. However
they are also monitored by the BSC, in order to define the status of each
"end-to-end" A-trunk. The following figure shows RSL fault correlation on
the Abis Interface.
Note: The BTS_TEL SBL describes the status of the GSM-defined BTS telecom
functions. Its state is defined by operator commands, and correlation of the
LAPD RSL states or of the different Carrier Units.
Fault Start CPR Informed RSL State Change
RSL−1 Alarm begin BTS_TEL
ACTIVE
Persistency Correlation
INACTIVE
Fault Start
RSL−2
Fault Start
RSL−N (last RSL)
CPR : Common Processor

RSL : Radio Signaling Link
Figure 45: RSL Correlation on the Abis Interface
288 / 304 3BK 21222 AAAA TQZZA Ed.08

8.5.3.3 Abis Interface Fault Monitoring

The BSC monitors the Abis Interface faults as follows:
1. The BSC detects the first LAPD RSL link failure
of the BTS. The BSC starts a persistency timer.
It puts the SBL of the RSL into a Maintenance Seized-Auto state while the
following actions occur:
The RITs are now in the SOS state. This is because the RIT belonging to
the RSL still functions, but cannot communicate with the BSC
Telecoms resources are blocked to prevent new activity at the BSC
end of this link
The RSL SBL is put into the FLT state, reflecting the loss of the RSL.
2. The persistency timer expires and the CPR is informed of the fault. If the
link recovers during the persistency period, nothing is reported. Otherwise
a correlation timer starts and waits for further RSL link failures belonging
to the same BTS.
3. Once the correlation timer expires, the BSC sends a state-change-report
message to the OMC-R. The message contains a list of all RSL that are in
the FLT state.
4. The OMC-R is then informed about the state of the BTS_TEL. If all the RSLs
belonging to the BTS have failed, then an alarm is sent to the OMC-R
signaling the loss of the cell. When an SBL is put in to the FLT state, it is
shown in the Alarms-In-Force list.
8.5.3.4 A Interface Fault Monitoring

When the BSC detects a DTC failure, the BSC puts the DTC SBL in the
MSD-Auto state, then into the FLT state. Through TS0 signaling, the MSC is
informed that the trunk is no longer operational and prevents all transactions
requiring the A channel (including new mobile-originated calls) from using the
failed link of the DTC. The failure is also signalled to the OMC-R. The TSC also
detects a failure of the Ater link and signals the failure to the OMC-R.
Note: The A channel is allocated only by the MSC.
3BK 21222 AAAA TQZZA Ed.08 289 / 304

8.5.3.5 Failures Detected by Software

Software throughout the BSC detects error and alarm conditions. It reports
these conditions to the alarm handling software. The alarm handling software
performs persistency, filtering and correlation actions on the received alarm
indicators, and determines the required action (e.g., to isolate a faulty SBL).
The figure below shows an example alarm report.
If one or more RSL links remain for the failed BTS, an event change is sent. The
BTS_TEL is put in a FIT state, as some channels for that cell are in operation.
The AIFL shows the new alarm. The BSC marks the cell as degraded in
service and reconfigures the BTS.
Figure 46: Example Alarm Report
290 / 304 3BK 21222 AAAA TQZZA Ed.08

8.5.4 BTS Alarms

Alarms in the BTS are tracked by the OMU. The following sections describe the
OMU hardware and alarm functions, and also BTS alarm collection.
8.5.4.1 BTS Alarm Hardware
Alarm Hardware OMU Function
G1/G2 Alarm Buses The OMU has a Q1 Interface to the Carrier Units, MCLU, EACB, and FHU modules
in the system, as well as a Token Bus Interface with all of the FU modules.
BTS 9100/9110 The BSII provides the OMU with an interface to the TRE functional unit, and to the
Alarm Buses antenna network x and TRANS & CLOCK functional entities, which have their own
on-board controllers. The BCB provides an interface to all the functional entities in
the BTS.
8.5.4.2 BTS Alarm Functions
Alarm OMU Function
Q1 Interface (G1/G2 On the Q1 Interface, a system of double polling takes place. The OMU polls each
BTS) subsystem individually to find out if there is an error. If there is an error, the OMU
demands an error report from that board. Normally, the information from the error
report is used as an alarm or an event notification.
Token Bus Interface The OMU is informed by the FU about the type of error that has occurred. The OMU
(G1/G2 BTS) sends the alarm information to the BSC.
BSSI (BTS Each module spontaneously reports errors to the OMU, which processes the report
9100/9110) as an alarm or an event notification.
BCB (BTS The Base Station Control Bus operates in a master/slave configuration where the
9100/9110) SUM functions as Pilot (master) and the functional entities function as Terminals
(slaves) in normal conditions. The OMU collects alarm information on the BCB
and sends it to the BSC.
3BK 21222 AAAA TQZZA Ed.08 291 / 304

8.5.4.3 Alarm Collection

The mechanism for BTS alarm collection on all buses is as follows:
1. The alarm is added to the AIFL.
2. The OMU enters alarm information in a queued buffer. In this way, alarms are
queued even if the link between the BTS and the BSC is temporarily unusable.
If the buffer becomes full (over 100 messages):
All fault/state change messages are deleted
No more messages are sent until a state and alarm audit takes place
to synchronize the BSC and the OMC-R. An audit BTS request is
transmitted on a regular basis until an audit occurs.
3. The alarm messages containing the alarm information are transmitted to the
BSC. For specific information about the alarm messages, refer to the BTS
Alarm Dictionary and the BSC/TC Alarm Dictionary.
4. The message is sent to the CPRA, where it is date and time stamped.
5. The BSC performs one of two activities:
If possible, it converts the alarm into a CMISE message, performs

an action and sends a different alarm/event to the OMC-R, via the
alarm queue
Otherwise, it retransmits the message to the OMC-R, via the alarm

queue.
6. The message is put in the alarm queue for BTS alarms. If the queue
overflows, the BSC performs an Alarms-in-Force audit on all the modules
in the BTS. This signals that information was received and lost when the
queue overflowed, and that resynchronization is required.
7. The OMC-R receives the alarm over the CMISE link. The alarm is put into
the AS component where it is logged.
292 / 304 3BK 21222 AAAA TQZZA Ed.08

8.5.5 Alarms Detected by the TSC

TSC O&M activities are similar to those performed by the BTS. The TSC has
a Q1 Interface to the transmission equipment. A system of double polling
occurs on the Q1 Interface:
The first poll checks if there is a change in states.
The second poll occurs only if the state has changed, in order to obtain
more information about the changes.
The Transcoder supervises PCM links. The loss of a link between the BSC and
Transcoder is reported by the Transcoder to the TSC.
8.5.6 MFS Alarms

The MFS generates alarms to signal a change in the behavior of a particular
function within the system, such as a potential problem or a confirmed failure in
the system. The Global Alarm Manager manages the MFS alarms.
It processes all hardware and telecom alarms and is responsible for:
Collecting all fault information relating to GPUs, the active server, and
telecom and external alarms
Recording alarms in a table
Allowing the IMT and the OMC-R to access the alarms
Generating ending alarms when a fault is cleared (for example, when a

GPU is replaced)
Managing a communication session with the IMT.
3BK 21222 AAAA TQZZA Ed.08 293 / 304

8.5.7 Recovery Example: Carrier Unit Failures with BCCH

This recovery example is based on a BTS with two Carrier Units. One Carrier
Unit is used for BCCH channel handling, the other is used for normal traffic.
If the Carrier Unit holding the BCCH fails, it is switched out and the second
Carrier Unit takes the place of the first.
As an example, this section describes the system’s reactions when a Carrier
Unit (TRE for a BTS 9100 or a BTS 9110) which has the BCCH channel fails.
Note: In the BTS 9100 or the BTS 9110, the SBLs FU and Carrier Unit have been
merged into one indivisible SBL, called the TRE. At the BSC, however, all BTS
9100 and BTS 9110 TRE faults are mapped to the Carrier Unit to provide
compatibility with G1 and G2 BTS. Therefore, at the BSC, all such errors are
displayed as Carrier Unit faults. That is how they are presented in this example.
FU faults in G1 and G2 BTS continue to be reported as such.
8.5.7.1 Fault Recovery Mechanism

The recovery mechanism in the BSS allows a failed unit to switch to a
replacement unit, such as:
Redundant hardware
A similar unit which had lower priority active use than the failed unit. For
example, the BCCH has to exist for the cell to function, so another Carrier
Unit/FU pair (TRE for a BTS 9100 or a BTS 9110) is expendable to replace
the failed Carrier Unit.
The recovery mechanism of the BSS recognizes that the Carrier Unit can
change to its twin Carrier Unit.
Refer to Carrier Unit Recovery Scenario (Section 8.5.7.2) for a step-by-step
scenario of Carrier Unit recovery.
294 / 304 3BK 21222 AAAA TQZZA Ed.08

8.5.7.2 Carrier Unit Recovery Scenario

The Carrier Unit recovery process is as follows:
1. The Carrier Unit holding the BCCH fails.
2. The BTS sends the BSC a recovery request, reporting that the Carrier Unit
is faulty and is out of service, and that a recovery is required.
The BTS also suggests a new Carrier Unit to the BSC, to be used to carry
the BCCH. When the recovery request is received, the BSC temporarily
blocks the resources while it checks if reconfiguration is available. If
reconfiguration is available, the BTS_TEL SBL becomes FIT, all calls on the
Carrier Unit are immediately released, and the RSL is blocked.
3. The BSC sends an alarm to the OMC-R, signaling the loss of BCCH.
4. The BSC attempts a recovery. The recovery command is
BTS-CONF-DATA(2).
5. The BTS receives and acknowledges the recovery message. It then
switches off the faulty Carrier Unit and switches on the second Carrier Unit.
The second Carrier Unit adjusts its frequency to the BCCH frequency.
6. If the configuration was successful, the BTS sends a confirmation to the
BSC. The BSC then sends the new sys_info (1-6).
7. The BCCH is now broadcasting on the same frequency as before, via
the newly configured Carrier Unit.
8. The BSC sets the BTS_TEL SBL to FIT and informs the OMC-R by sending
an end of alarm. The BTS_TEL remains FIT due to the loss of a channel.
9. If the new Carrier Unit was previously IT, its previously attached resources
are lost. An alarm is sent to the OMC-R to update the information on
lost channels.
3BK 21222 AAAA TQZZA Ed.08 295 / 304

The following figure shows the redundancy process for a failed Carrier Unit
with BCCH.
OMC BSC BTS
1
CU Fault
BTS_TEL=IT
2
OS)
Resources
req (CU, F
blocked, BCCH Reco_
reconfiguration
possible
3 BTS_TEL=FIT
gin)
H be 4
of BCC
loss BTS_C
m( cell, ONF_
DATA
Alar (2)
5
BTS_TEL=FIT BTS performs the reconfiguration
L
COMP
ONF_
BTS_C
6
8 SYS_IN
FO (1..6
)
d)
CH en
ss of BC
(cell, lo 9
Alarm
gin)
CH be
ll, los s of T BTS_TEL=FIT
Alarm (ce
BCCH : Broadcast Control Channel

CU : Carrier Unit
Figure 47: Example: Loss of Carrier Unit Holding BCCH.
Note: The BTS_TEL SBL describes the status of the GSM-defined BTS telecom
functions. Its state is driven by operator commands, or by correlation of the
LAPD RSL states or of the different Carrier Units.
296 / 304 3BK 21222 AAAA TQZZA Ed.08

8.5.8 Automatic Power-Down

This feature is available only on the BTS 9100. It is used typically in an outdoor
installation where the BTS has a backup battery power supply.
In the case of a main power-supply failure, the BTS 9100 is automatically
switched to battery power. This situation continues until the main power is
restored or the battery is drained, whichever happens first.
To extend the time during which the BTS 9100 can function under battery power,
the BTS is reduced to a minimum configuration to reduce power consumption.
Once a power-supply failure alarm arrives, the OMU starts a timer. If, once the
timer expires, the alarm is still active, the OMU switches off all TREs except
the BCCH TRE (one per sector for a sectored site), by placing the TREs to
be powered down in the FOS state.
If, in a given sector of a sectored site, the BCCH TRE is configured without a
traffic channel, another TRE (which carries the SDCCH) is kept powered on, so
that calls are still possible in this sector, though limited to one TRE.
When the power-supply failure alarm disappears, the OMU starts a timer. If the
alarm re-occurs before the timer expires, the OMU takes no further action. This
is to guard against a possible unstable restoration of power.
If the BTS power-supply remains stable until the timer expires, the OMU
performs an autonomous auto reset with BTS activation. This re-initializes
all available TREs.
For more information about this feature, refer to the following:
Alcatel-Lucent BTS 9100/9110 Functional Description
Alcatel-Lucent BTS 9110 Hardware Description.
8.5.9 BSC Alerter

The BSC Alerter is a telecom supervision function which generates an alarm
event when the system suspects abnormal behavior of a resource. This is
system defined and not dependent on site configuration or traffic conditions
in a particular cell.
An Alerter functions by monitoring and computing the levels of specific
Performance Management counters. If the count exceeds the operator-defined
parameters, the Alerter generates an alarm for the BSC resource. This alarm is
sent to the OMC-R operator.
Note: For performance reasons, each alerter type has a maximum limit of 16 alarms.
For more information about BSC Alerters, refer to BSC Alerters in the
Operations & Maintenance Principles document.
3BK 21222 AAAA TQZZA Ed.08 297 / 304

8.6 Performance Management

The following provides a brief overview of performance management facilities in
the BSS.
For detailed information about performance management, refer to Performance
Management in the Operations & Maintenance Principles document.
For a description of individual counters, refer to PM Counters and Indicators.
The following table shows the performance management functions of the
BSC and the MFS.
Network Performance Management Functions

Element
BSC BSC
Result collection and collation
X.25-related counters
Traffic measurements on radio channels

Performance Measurement result reporting
Trace invocation result reporting.
MFS MFS
Collects the performance management counters
associated with each logical GPU
Creates a file of counter values.
8.6.1 Traces
Trace management coordinates and triggers trace activities within the BSS.
Tracing is originated from the MSC. There are two types of tracing:
Call tracing
IMSI tracing.
Call tracing follows a specified transaction (subscriber call, location update,

short message, etc.) inside the BSC. When the specified transaction ends, or
the transaction changes to another BSC, the trace activity ends.
IMSI tracing is not restricted to speech. It includes information about the radio
resources set up for the mobile. This includes, for example, location updating,
supplementary services, short messages, etc.
For more information about trace management, refer to Trace Management in
the Operations & Maintenance Principles document.
298 / 304 3BK 21222 AAAA TQZZA Ed.08

8.6.2 Performance Monitoring

Monitoring system performance provides information that can be used to
improve the system performance, optimize traffic levels, perform network radio
planning and optimization, and plan network reconfiguration. The OMC-R
manages the gathering of data collected from all the network elements by
means of PM counters. PM counter values are collected into results files in
the BSC.
In the BSS, there are two types of raw counters: standard and detailed. These
two counter types are gathered in the following counter groups:
Cumulative counters
Status inspection counters

DER counters
RMS counters.
8.6.3 Radio Measurements Statistics

Radio Measurements Statistics (RMS) provides counters and indicators to
measure the performance of the Mobile Assisted Frequency Allocation (MAFA)
feature and the Adaptive MultiRate (AMR) feature. Other improvements to
Timing Advance statistics have also been added.
Radio Measurement Statistics for MAFA is available on G1 BTS Mk2, G2 BTS
equipped with DRFU and Alcatel-Lucent BTS. AMR Radio Measurement
Statistics are only available on Alcatel-Lucent BTS.
8.6.3.1 MAFA Radio Measurement Statistics

In order to help the operator find "clean" frequencies for better frequency
planning, RMS counters provide information based on the Mobile Assisted
Frequency Allocation (MAFA) feature. MAFA is a standardized GSM feature
that provides a way for the system to ask each mobile station to measure extra
frequencies (frequencies of non-neighbor cells). MAFA can also be used to
check interferences from non-neighbor cells. RMS is a BSC/BTS feature that
records measurements from the BTS and mobile stations. For MAFA, specific
mobiles supporting this standardized GSM feature are required. Every mobile
station supporting MAFA acts as a potential spectrum analyzer and provides
excellent information about the radio conditions for each single cell.
Using this feature, the operator can:
Detect interfered frequencies
Assess the quality of the cell coverage

Detect and quantify cell unexpected propagation
Assess the traffic distribution in the cell from statistics on reported neighbor
cells
Evaluate the voice quality in the cell.
3BK 21222 AAAA TQZZA Ed.08 299 / 304

During the observation period, the BTS/FU keeps track of all the RMS
statistics derived from the measurements reported by the mobile stations
or measured by the BTS/FU itself on the TCH (SDCCH are not used with
RMS). At the end of the observation period when the RMS data is collected
from the concerned BTS/FUs, the BSC builds a report (called the RMS
result file). The transfer towards the OMC-R occurs via FTAM. In addition,
it is possible during the observation period to apply MAFA (also called
Extended Measurement Reporting). This procedure consists of sending an
Extended Measurement Order (EMO) to the mobile stations. On receipt of
the command, the mobile stations take one SACCH multiframe to perform
measurements on specific frequencies. The measurements are reported via
the EXTENDED_MEASUREMENT_REPORT message. The EMO is sent only once per
call. The statistics related to MAFA are collected in the BTS and integrated in
the RMS results. The statistics are based on the measurements performed at
the BTS and the mobile station, on the TCH only.
The statistics can be classified as follows:
Radio related statistics. These can be classified as follows:

Statistics related to the whole serving cell
Statistics related to the TRXs.
Voice quality statistics. Nine counters and indicators provide an overview of

the communications quality (TCH only) for each TRX.
8.6.3.2 Detailed Radio Measurement Statistics

Several new improvements have been added to RMS, including the introduction
of Radio Measurement Statistics counters and indicators for AMR. New
counters reporting timing advance statistics were also added. These are all
reported within existing RMS jobs.
AMR codecs (both FR and HR) are monitored to find which codecs are used
the most often. Because FR and HR use different parameters and different
codecs are used in UL and DL, results are provided for:
AMR FR uplink
AMR FR downlink
AMR HR uplink
AMR HR downlink
Matrixes are used to show the total number of good speech frames per codec
gathered in RXLEV intervals. These results make it possible to deduce the
average frame erasure rate per AMR codec in the uplink. Results are provided
at TRX level.
Knowing the codec use and comparing it with the link level in the cell enables
the operator to monitor proper operation of AMR and the quality of radio
coverage in a cell. Statistics on the frame erasure rate in the uplink and
comparisons between codec distribution and RXLEV allows an assessment of
the voice quality and to adapt AMR thresholds to specific cell conditions.
Timing advance is a good indicator of the position of an MS relative to a cell.
The RMS counters provide statistics on timing advance in order to understand
the geographical distribution in a cell. These statistics can be used to identify
resurgences and hot spots.
300 / 304 3BK 21222 AAAA TQZZA Ed.08

To allow operators to obtain information about BTS output power on a TRX

basis, a new counter is implemented. This counter retrieves the GMSK TRX
power level applied at the BTS antenna output connector in dBm. This counter
reports on the BTS_MAX_OUTPUT_POWER variable, used for power control
and path balance statistics.
These RMS improvements help the operator to:
Optimize speech quality using AMR
Optimize network planning, through identification of resurgences and

hot spots.
8.6.4 Results Analysis

Using the OMC-R, an operator can view alarms from the OMC-R databases
and analyze the PM measurements.
Counter and indicator information is processed by an OMC-R tool. The results
can be used to generate QoS alarms to notify the operator of possible network
problems. The results, also can be sent to the 9159 NPO to produce reports.
9159 NPO is usually a standalone tool that runs on a separate Sun machine.
It can also run on the OMC-R machine:
As 9159 NPO embeded, if the number of managed cells is up to 200. In this

case the full 9159 NPO functionality is available.
A s MPM, if the OMC-R manages more than 200 cells. In this case only
QoS feature is available.
For more information about results analysis and the tools available to process
counter and indicators information, refer to the Results Analysis section of the
3BK 21222 AAAA TQZZA Ed.08 301 / 304

8.7 Audits
Audits can be automatic or initiated by an operator. They can be performed at
several levels:
From the OMC-R to the Transcoder, the BSC, or the MFS

From the BSC to the BTS.
For more information about Audits, refer to:

Configuration Management Audits in Configuration Management
Audits/Resynchronization
Fault Management Audits in Fault Management Audits.
Using the IMT, it is possible to perform a radio re-initialization, or a radio

resynchronization of the MFS.
8.7.1 Audit Types

The following table describes the various types of audits.
Type Description
Logical Audit A logical audit is performed on logical parameters. The logical parameters include
dynamic cell information, its power ratings, information about adjacent cells, the
radio configuration of the cell, and hopping and paging groups. No logical audit
is provided for the MFS side.
Software Version The software version audit controls the versions of software that exist on the
Audit subsystem.
Hardware Audit Hardware audits control the hardware on the subsystem. This audit provides a
physical list of all components in the subsystem, their SBLs, and their associated
RITs. The OMC-R updates the database with this information.
Alarm Audit The OMC-R requests the AIFL from a unit of the BSS. The OMC-R then compares
this with its own list and updates its database if there are any differences.
State Audit A state audit checks the state of SBLs on a particular subsystem, to ensure that SBL
databases are synchronized. All the SBLs and their states are compared with the
data in the OMC-R. If the SBL does not exist in the database, it is created and its
state is registered.
The BSC/BTS SBL audit does not line up BSC and BTS databases when the BTS
receives a state-update-request with different SBLs states. So in this case the BSC
lines-up completely itself on BTS view, without useless audits.
302 / 304 3BK 21222 AAAA TQZZA Ed.08

Two types of action are possible for the MFS:

Re-initialize GPRS configuration
Allows the OMC-R to force the logical configuration of the MFS, by deleting
the current one, and then recreating one from scratch, using the current
OMC-R configuration. This is roughly the equivalent of a Force configuration
at the BSS side. However, it always induces some outages.
Resynchronize GPRS configuration.

Allows the OMC-R to force the logical configuration of the MFS, by
computing the differences with the current OMC-R configuration. It is
the preferred synchronization action at the MFS side, as it minimizes the
MFS outage.
A suite of audits is automatically invoked by the OMC-R or the BSC to

resynchronize the system. This is done:
To perform a RESET/RESTART
When there is a loss of links between subsystems. This ensures that the
system databases are synchronized after autonomous operation while the
link was down (i.e., the BTS_O&M was disabled).
To make changes in the databases, without the possibility of aligning
both subsystems
To start a BSC Alarms-in-Force audit if the BSC alarm queue overflows

To perform software database replacement.
Audit information for the whole system is stored in the OMC-R.
8.7.2 Audit Flow

Audit flow is based on an action request from the OMC-R, or on an automatic
request.
The subsystem receiving the audit request performs an audit of its functional
units.
The reply can have one or several report messages to pass the information back
to the request originator. The request originator can generate more actions
based on the information received. For example, when the state of the Carrier
Unit and its pair FU do not match, the BSC disables the FU/Carrier Unit pairs.
The OMC-R, on reception of the audit report, updates its database. During
download the results of the software audit are used to provide the list of
modules the OMC-R needs to update the BSS subsystem. This is done by
comparing the OMC-R lists of modules to transfer, and their version numbers,
to see if they already exist in the subsystem. Only the newer versions are
transferred to the subsystem.
3BK 21222 AAAA TQZZA Ed.08 303 / 304

8.8 Remote Inventory

The Remote Inventory feature allows an operator to get hardware and firmware
information from the OMC-R. This information is used for retrofit, deployment or
maintenance. The main benefit is that the amount of site visits can be reduced
considerably. The Remote Inventory data is reported to the OMC-R by the
MFS, by Alcatel-Lucent BTS (9100/ 9110) which are numerous and spread out
in the field and by the 9125 STM-1 TC. The operator can get this data in two
ways, automatically or on-demand. The on-demand mode remains available
even when the automatic mode is selected. Among the reported data is
information that is very useful for retrofit or maintenance actions, e.g., the site
name, the exact location of the board, the serial number, the part number and
the variant. Sending the data to external tools is possible because the inventory
data files on the OMC-R can be consolidated into a single (tabular format)
csv file per BTS, per MFS and per 9125 STM-1 TC. Existing external tools
can therefore be re-used.
The Remote Inventory feature brings the following benefits:
Reliability
Inventory data is reported directly (periodically if requested) by the BTS
to the OMC-R (through the BSC, which is transparent), so the operator
always has the correct information. To keep the OMC-R at a high level
of performance, Alcatel-Lucent recommends using the automatic mode
with a seven-day acquisition period.
Cost cutting
It is no longer necessary to go onsite to get hardware and firmware
information before performing a retrofit or a maintenance action.
Remote Inventory can be performed at the MFS. Information can be displayed

for the selected subrack. For a BSC and MFS which share the same rack, each
network element will provide its own inventory files, which are managed by the
OMC-R. A remote inventory can be built and collected either automatically,
according to a defined schedule, or on demand, via IMT or OMC-R request.
For more information about the IMT, and the tasks that can be performed,
refer to the:
Online help provided for the 9130 MFS IMT
Alcatel-Lucent 9130 MFS IMT User Guide.
Online help provided for the 9135 MFS IMT
Alcatel-Lucent 9135 MFS IMT User Guide.
For more information about Remote Inventory, see Remote Inventory in the
304 / 304 3BK 21222 AAAA TQZZA Ed.08

Bss System Desc

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Bss System Desc

Hochgeladen von

Copyright:

Verfügbare Formate

Alcatel-Lucent GSM

BSS System Description

3BK 21222 AAAA TQZZA Ed.08

Short title System Description

2 / 304 3BK 21222 AAAA TQZZA Ed.08

3BK 21222 AAAA TQZZA Ed.08 3 / 304

2.2 GPRS Channels and System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

4 / 304 3BK 21222 AAAA TQZZA Ed.08

3.1.1 Call Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128

3BK 21222 AAAA TQZZA Ed.08 5 / 304

4.6.1 Principal Handover Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

6 / 304 3BK 21222 AAAA TQZZA Ed.08

7.5 Umbrella Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

3BK 21222 AAAA TQZZA Ed.08 7 / 304

8 / 304 3BK 21222 AAAA TQZZA Ed.08

3BK 21222 AAAA TQZZA Ed.08 9 / 304

10 / 304 3BK 21222 AAAA TQZZA Ed.08

Mobile Communications Support

Operations and Maintenance (O&M).

What’s New In Edition 08

3BK 21222 AAAA TQZZA Ed.08 11 / 304

Transcoder And Transmission Function (Section 1.3.3)

12 / 304 3BK 21222 AAAA TQZZA Ed.08

The following sections were modified:

Information concerning GboIP was introduced in Gb over IP (Section 2.10)

Information concerning EDA was introduced in Extended Dynamic

Information concerning AMR-WB and TFO was added in Adaptive Multiple

Information concerning TC IP supervision and STM-1 was added in

Extended GSM (Section 1.4)

GPRS Channels and System Information Messages (Section 2.2)

Results Analysis (Section 8.6.4).

Information concerning compressed messages in the call setup step was

Information concerning the TDSCDMA feature was added in 2G to 3G

Information concerning availability in the case of NC2 was added in 2G

Information concerning the NC2 related restriction was added in Cell

Information concerning the recommendation on IR activation was added in

Information concerning one GSL configured on GPU was added in

Information concerning MX capacity improvements was added in HSL

Information concerning MCCCH was added in Control Channels (Section

Information concerning DTM was added in Dual Transfer Mode (Section

3BK 21222 AAAA TQZZA Ed.08 13 / 304

Network decision makers who require an understanding of the underlying

Network Management concepts and terminology.

14 / 304 3BK 21222 AAAA TQZZA Ed.08

3BK 21222 AAAA TQZZA Ed.08 15 / 304

Mobile Network Fixed

MFS : Multi-BSS Fast Packet Server

16 / 304 3BK 21222 AAAA TQZZA Ed.08

1.1.1 Alcatel-Lucent Radio Solutions

Note: BTS G1 and BTS G2 are still supported by Alcatel-Lucent.

1.1.2 Extended GSM Band (E-GSM)

This corresponds to a total number of 174 addressable frequencies.

1.1.3 GSM 850

3BK 21222 AAAA TQZZA Ed.08 17 / 304

1.1.4 Frequency Band Configurations

BSS with a mix of GSM 850 and GSM 1900 cells

BSS with a mix of GSM 900 and GSM 1800 cells

BSS with a mix of GSM 900 and GSM 1900 cells.

For more information, refer to the Basic GSM System Specifications.

Circuit-switched transmission for voice

18 / 304 3BK 21222 AAAA TQZZA Ed.08

1.2 BSS Functions

Operations & Maintenance.