Professional Documents
Culture Documents
BSC Functional 20572e02
BSC Functional 20572e02
Descriptive Documentation
BSS Concepts
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.
2 / 252
Contents
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
BSS Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1
Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2
Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3
Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4
Operations & Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3
BSS Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1
Base Station Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.2
Base Transceiver Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3
Transcoder And Transmission Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.4
The Multi-BSS Fast Packet Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.5
Multi-GPU per BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4
Extended GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5
External Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.1
Network Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.2
Mobile Stations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.5.3
Phase 2 Mobile Support in a Phase 1 Infrastructure . . . . . . . . . . . . . . . . . . . . . . .
1.5.4
Operations and Maintenance Center-Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6
Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.1
Telecommunications Management Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.6.2
Q3 Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7
BSS Telecommunications Layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.1
Call Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.2
Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.3
Radio Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.4
The A Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.5
The Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.6
Satellite Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.7.7
The Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1
Packet Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2
GPRS Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2
GPRS Channels and System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1
Master Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2
Static Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3
Dynamic Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.4
Multiple PCCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.5
Logical Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.6
Virtual Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.7
System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3
GPRS Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1
The Gb Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.2
The BSCGP Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.3
The GCH Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4
GPRS Network Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1
Mobility Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2
Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.3
Radio Power Control and Radio Link Measurement . . . . . . . . . . . . . . . . . . . . . . . .
2.5
Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5.1
Time Slot Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
14
16
16
17
17
17
18
18
19
22
23
25
26
28
29
30
33
33
34
34
35
36
36
36
37
38
39
39
41
47
48
48
49
52
52
52
53
54
56
56
57
59
59
60
61
62
63
64
64
65
65
3 / 252
Contents
2.5.2
Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.5.3
PCM Link Sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.5.4
Resource Reallocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
2.6
Traffic Load Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.6.1
Congestion Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
2.6.2
Smooth PDCH Traffic Adaption to Cell Load Variation . . . . . . . . . . . . . . . . . . . . . . 70
2.6.3
GPRS Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
2.6.4
Delayed Downlink TBF Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.7
Data Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.7.1
GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
2.7.2
Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
2.7.3
Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
2.7.4
Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
2.7.5
GPRS Suspend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
2.7.6
GPRS Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
2.7.7
GPRS Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Call Set Up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.2
Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.2.1
Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.2.2
Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.2.3
Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.3
Mobile Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
3.3.1
Radio and Link Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.3.2
Authentication and Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.3.3
Normal Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.3.4
IMSI Attach-Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.4
Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.4.1
Paging Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.4.2
Discontinuous Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.5
Congestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.5.1
Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.5.2
In-queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.5.3
Pre-emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.6
Classmark Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3.6.1
Classmark IE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3.6.2
Classmark Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
3.6.3
Location Updating with Classmark Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.7
Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.8
Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.8.1
Ciphering Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.8.2
Ciphering Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.9
Tandem Free Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3.9.1
TFO Functional Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.9.2
TFO Optimization and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Call Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.2
In-Call Modification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.2.1
In-Call Modification Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.2.2
Circuit-switched Group 3 Fax Data Rate Change . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.2.3
Error Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
4.3
Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
4.3.1
Baseband Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
4.3.2
Synthesized Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.4
Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.4.1
Speech Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4 / 252
Contents
4.4.2
BSS Discontinuous Transmission Towards Mobile Station . . . . . . . . . . . . . . . . .
4.4.3
Mobile Station Discontinuous Transmission Towards BSS . . . . . . . . . . . . . . . . .
4.5
Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.1
BTS Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.2
Mobile Station Radio Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.3
Radio Link Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.4
Power Control Decision and Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.5.5
Change Power Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6
Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.1
Radio Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2
Handover Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.3
Target Cell Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.4
Synchronous and Asynchronous Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7
Overload Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.1
BTS Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.7.2
BSC Overload . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8
Call Re-establishment by the Mobile Station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2
Call Release Procedures in Normal Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1
Normal Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2
Calls Terminated Following a Channel Change . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3
Call Release - Special Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1
Call Release Following Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2
BSC-Initiated Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3
BSC-Initiated SCCP Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.4
BTS-Initiated Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.5
Mobile Station-Initiated Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.6
Remote Transcoder Alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Handling User Traffic Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2
Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1
Enhanced Full-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.2
Half-Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3
Adaptive Multiple Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.4
Channel Mode Adaption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3
Circuit-Switched Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1
Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2
Non-Transparent Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4
Short Message Service - Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.5
Support of Localized Service Area . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cell Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2
Concentric Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3
Sectored Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.4
Extended Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5
Umbrella Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.1
Mini Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.5.2
Microcell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.6
Cell Shared by Two BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operations & Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2
O&M Architecture and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.1
O&M Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2.2
O&M Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
141
142
144
144
144
145
146
148
149
151
152
159
161
168
168
169
171
173
174
175
175
180
181
181
183
185
186
189
190
191
192
192
194
195
196
198
199
200
201
202
204
205
206
208
209
210
212
212
213
217
219
220
220
221
222
5 / 252
Contents
8.3
8.4
8.5
8.6
8.7
8.8
6 / 252
223
224
225
226
228
229
230
230
230
231
232
233
234
236
236
237
240
242
242
243
245
245
246
246
247
248
249
250
252
Figures
Figures
Figure 1: BSS in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Figure 2: Antenna Diversity on G1 and G2 BTSs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 3: Antenna Diversity on the BTS A9100 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Figure 4: Transmission Components in the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Figure 5: Cell Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Figure 6: Logical Position of External Components Associated with BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 7: Location Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Figure 8: TMN System Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 9: General Telecommunication Layers within GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Figure 10: BSS Application, Transmission Layers and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Figure 11: Time Slot 4 of a Time Division Multiple Access Frame Supporting Access Grant Channels . . . 41
Figure 12: Model LLC Packet Data Unit used in GPRS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 13: The Alcatel GPRS solution in the PLMN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Figure 14: GPRS Traffic Load Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figure 15: GPRS Attach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figure 16: Mobile Station-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . 74
Figure 17: GGSN-Originating Packet Data Protocol Context Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Figure 18: Mobile-Originated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 19: Mobile-Terminated Data Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 20: Mobile Station Originating Packet Data Protocol Context De-activation . . . . . . . . . . . . . . . . . . . . . 78
Figure 21: Network-Originating Packet Data Protocol Context De-activation Processes . . . . . . . . . . . . . . . . 79
Figure 22: GPRS Suspend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Figure 23: GPRS Resume . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Figure 24: Mobile Station-Originating GPRS Detach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Figure 25: Network-Originating GPRS Detach Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Figure 26: Radio and Link Establishment for Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Figure 27: SDCCH Channel Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 28: Immediate Assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figure 29: Connection for Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Figure 30: Normal Assignment for Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 31: Channel Activation Process for the Traffic Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Figure 32: Channel Assignment Process for the Traffic Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Figure 33: Call Connection for Mobile Originated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figure 34: Radio and Link Establishment for Mobile Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Figure 35: Normal Assignment for Mobile Terminated Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Figure 36: CCCH with Three Blocks Reserved for AGCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Figure 37: Four TDMA Frame Cycles Providing 24 Paging Sub-channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
Figure 38: Paging Message Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Figure 39: Location Update with Classmark Update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
7 / 252
Figures
Figure 40: Location Update with Mobile Station Sending Location Area Identity of Previous VLR . . . . . . . 123
Figure 41: Ciphering Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Figure 42: Example of TFO Establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 43: Frequency Hopping within an FHS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
Figure 44: Different Forms of Discontinuous Transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Figure 45: Power Control Flow of Measurement and Decision Action . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Figure 46: Power Output Balancing Based on Received Quality and Signal Levels . . . . . . . . . . . . . . . . . . . . 147
Figure 47: Quality and Level Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Figure 48: Better Zone Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Figure 49: Better Cell Handover (Power Budget) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Figure 50: Distance Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Figure 51: Umbrella Cell Load in Mobile Velocity Dependent Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Figure 52: Synchronous Internal Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Figure 53: Asynchronous External Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Figure 54: Mobile Station Disconnecting a Call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Figure 55: Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Figure 56: Initiation of Normal Release by MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
Figure 57: BSC/BTS/Mobile Station interactions in Normal Call Release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
Figure 58: Normal Release Final Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Figure 59: Call Release Following a Channel Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
Figure 60: Call Release Following Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Figure 61: BSC-initiated Call Release toward the MSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
Figure 62: BTS-initiated Call Release following LAPD failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Figure 63: Call Release due to Mobile Station initiated Radio Link Failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Figure 64: Call Release due to Communication Failure detected by Transcoder . . . . . . . . . . . . . . . . . . . . . . 190
Figure 65: Encoded Speech Transmission Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Figure 66: Multiplexed Ater Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Figure 67: Data Transmission Across the BSS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Figure 68: Short Message Service - Cell Broadcast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Figure 69: Example: Cell Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Figure 70: Sectored site configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Figure 71: Example of Extended Cell Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Figure 72: Umbrella Cell with Mini Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Figure 73: Example: Handovers due to Threshold Triggering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
Figure 74: Indoor cell example network hierarchy with three layers and two bands . . . . . . . . . . . . . . . . . . . . 215
Figure 75: Multiple HMI Access to OMC-Rs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Figure 76: ACO Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
Figure 77: X.25 Without Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
Figure 78: X.25 With Redundancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
Figure 79: RSL Correlation on the Abis Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
8 / 252
Figures
9 / 252
Tables
Tables
Table 1: System Information Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Table 2: GPRS System Information Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Table 3: GPRS System Information Messages Used with MPDCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Table 4: Gb Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Table 5: BSCGP Interface Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Table 6: Network Operation Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Table 7: Time Slot Allocation Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Table 8: PDCH Traffic Load States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Table 9: Types of Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Table 10: Call Set Up Phases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Table 11: Cell List Identifier and Paging Performed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Table 12: Paging Request Message and Mobile Station Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Table 13: Classmark Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Table 14: Classmark Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Table 15: Mobile Station Ciphering Capabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Table 16: Downlink Discontinuous Transmission Status in Channel_activation . . . . . . . . . . . . . . . . . . . . . . . . 141
Table 17: Operator Discontinuous Transmission Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Table 18: Radio Link Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Table 19: Mobile Station Maximum and Minimum Power Ranges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Table 20: Circuit-Switched Data Rate Conversions Across the Air Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 200
Table 21: Configuration Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
Table 22: Fault Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Table 23: BTS Alarm Hardware Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Table 24: BTS Alarms Functional Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
Table 25: Performance Management Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Table 26: Audit Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
10 / 252
Preface
Preface
Purpose
Audience
11 / 252
Preface
Assumed Knowledge
12 / 252
1 Introduction
1 Introduction
This chapter gives a brief overview of the Alcatel BSS, its functions and
features. It describes:
Overview
BSS functions
Internal and external components and interfaces
BSS Network Management
The distribution of telecommunications software in the BSS.
13 / 252
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 signalling 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
Stations
Network
Subsystem
Fixed
Network
MSC
PSTN
SGSN
PSDN
TC
BTS
BSC
MFS
OMCR
NMC
GGSN
HLR
MFS
NMC
PSDN
PSTN
SGSN
EVOLIUM Radio
Solutions
To respond to the swiftly evolving needs in BSSs, Alcatel offers the EVOLIUM
Radio Solutions.
The Alcatel EVOLIUM Radio Solutions includes the following BSS equipment
described in this document:
G2 BSC
G2 Transcoder
G2.5 Transcoder
BTS A9100
BTS A910
A935 MFS.
Note:
14 / 252
1 Introduction
The Alcatel 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.
GSM 850
Frequency Band
Configurations
The GSM 850 MHz band has been introduced in the Release 1999 of the 3GPP
Standard in 1999 to allow operators to replace progressively 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 in their network the GSM system
with the GSM 1900 MHz to extend or replace their D-AMPS existing network.
The term GSM 850 is used for any GSM system which operates in 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.
The Alcatel BSS supports the following multiband network configurations:
BSS with a mix of GSM 850 and GSM 1900 cells
BSS with a mix of GSM 850 and GSM 1800 cells
BSS with a mix of GSM 900 and GSM 1800 cells.
Refer also to Basic GSM System Specifications.
GPRS
15 / 252
1 Introduction
Mobility Management
Calls
Mobility Management calls, such as location update, are used by the system
to gather mobile station information. The exchanges are protocol messages
only. Therefore, only a signalling channel is used.
Supplementary Service
Calls
Supplementary service calls, such as SMS, allows the mobile station to send
and receive messages to and from the BTS. These calls pass small amounts of
information. Therefore, only a signalling channel is used.
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
signalling channel. These calls use traffic channels.
Call set up processes include:
Radio and Link Establishment to assign a signalling 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.
See Call Set Up (Chapter 3) for more information.
16 / 252
1 Introduction
17 / 252
1 Introduction
18 / 252
1 Introduction
19 / 252
1 Introduction
TX
B
I
E
F
H
U
FU
C
O
U
P
L
I
N
G
CU
a
ab
U
N
I
T
RX
best of a&b
RX
(option)
OMU
CONTROL
BASEBAND
BASEBAND
RADIO
COUPLING
CONTROL
BIE
CU
: Carrier Unit
FHU
FU
: Frame Unit
OMU
RX
: Receiver
TX
: Transmitter
20 / 252
1 Introduction
TRE 1
best of
a&b
ab
ANT a
Tx / Rx
TRE 2
ab
S
U
M
best of
a&b
a
b
TRE 3
ab
best of
a&b
ab
b
a
TRE 4
best of
a&b
ab
b
ANT b
Tx / Rx
ANy
ANx
ANC
BASEBAND
BASEBAND
RADIO
COMBINING
CONTROL
ANT
: Antenna
ANx
ANy
SUM
TRE
: Transmitter/Receiver Equipment
RADIO
DUPLEXING
Note:
21 / 252
1 Introduction
Submultiplexers
BTS
BIE
BIE
BSC
SM
TC
SM
MSC
BTS
BIE
BIE
BSC
TC
TSC
BTS
BIE
SM
: Submultiplexer
TSC
TC
: Transcoder
22 / 252
1 Introduction
23 / 252
1 Introduction
Telecom functions:
Radio and transmission resources control
Radiolink 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
Signalling management on the GSL interface.
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 (see The GCH
Interface (Section 2.3.3) for more information).
Protocols handled by the PMU:
Gb interface protocols (BSSGP, Network Service, and FR)
BSC interface protocols (BSCGP, L2-GSL, and L1-GSL)
RRM protocol.
The PMU manages the corresponding Gb and GSL interfaces.
24 / 252
1 Introduction
Cell Mapping
GPU1
Cell 2
Cell 3
Cell 5
Cell 6
BSC
Cell 7
GPU2
Cell 8
Cell 12
Cell 9
GPU3
Cell 11
Cell 10
Cell 14
GPU4
Cell 13
GPU
25 / 252
1 Introduction
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 the Classmark 2 is set to 1 (regardless of the value of the
Band 2 bit of the Classmark 3) or
The FC bit of the Classmark 2 is set to 0, and the Band 2 bit of the
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.
E-GSM Management
After Initial
Determination
E-GSM Determination
at Handover
Once the E-GSM ability has been initially determined as described above, it
may happen that the mobile station radio characteristics 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.
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 the 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 the 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 the Classmark 2 is set to 1 (whatever the value of the band
2 bit of the Classmark 3)
If the FC bit of the Classmark 2 is set to 0 and the band 2 bit of the
Classmark 3 is set to 1.
26 / 252
1 Introduction
TCH Allocation
27 / 252
1 Introduction
Network
Subsystem
Ater Interface
BTS
MSC
Fixed
Network
PSTN
Transcoder
BTS
BSC
MFS
BTS
Gb Interface
SGSN
GGSN
PSDN
Abis
Interface
OMCR
HLR
NMC
GGSN
HLR
MFS
NMC
PSDN
PSTN
SGSN
28 / 252
1 Introduction
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.
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.
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
Equipment Identity
Register
The AuC manages the security data used for subscriber authentication.
The EIR contains the lists of mobile station equipment identities.
29 / 252
1 Introduction
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 three
idle mode functions:
Cell selection and cell reselection
Location updating
Overload control.
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.
30 / 252
1 Introduction
GSM/GPRS to UMTS
Cell Reselection
Location Updating
31 / 252
1 Introduction
interrogates the old VLR for authentication and subscriber information. For
further information see Location Updating with Classmark Procedure (Section
3.6.3) and Authentication (Section 3.7).
The Location Area Identity is made up of:
Mobile Country Code
Mobile Network Code
Location Area Code.
The BSS adds the cell identity of the mobile station 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 in either its HLR or its VLR. Following a location update procedure,
the VLR can assign a new Temporary Mobile Subscriber Identity to the mobile
station. See Authentication (Section 3.7) for more information about the TMSI.
The following figure shows a mobile station as it moves to a new location area.
BTS
Mobile
Station
BSC
BSC
MSC
VLR
MSC
VLR
Mobile
Station
VLR
Protocol Messages
BTS
BSC
BSC
Overload Control
32 / 252
To protect the system 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 further information, see GPRS Overload
Control (Section 2.6.3) and Overload Control (Section 4.7).
1 Introduction
33 / 252
1 Introduction
Network Management
OSS
NMC
Q3
OMCR Operator
(Resource and Equipment
Management)
OMCR
Mediation Function
Network Element
MFS
BSC
BTS
OSS
MFS
NMC
BTS
&
Network Element
Management
BSS
BTS
34 / 252
1 Introduction
1.6.2 Q3 Interface
Communication between the NMC and the OMC-R takes place across the Q3
Interface (see Figure 8). The Q3 protocols can be divided into the following
main areas:
Association connection and disconnection mechanisms
Message format and structure
Command types.
For further information on Network Management and the Q3 Interface see the
Operations & Maintenance Principles document.
35 / 252
1 Introduction
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
36 / 252
1 Introduction
BTS
BSC
MSC
CM
MM
GSM
Application
Layers
RRM
BSSAP
BSSAP
LAPDm
LAPDm
Layer 1
Layer 1
LAPD
Layer 1
LAPD
Layer 1
BSSAP
SCCP
SCCP
SS7
SS7
Layer 1
Layer 1
08.60
Air Interface
Abis Interface
BSSAP
CM
: Call Management
LAPD
LAPDm
MM
: Mobility Management
RRM
SCCP
SS7
TC
: Transcoder
Layer 2
TC
A Interface
37 / 252
1 Introduction
Physical Layer 1
Application Sub-layer
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.
Ater Interface
The part of the A Interface between the Transcoder and BSC is known as the
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.
This feature improves efficiency on the Ater Mux PCM connection between
the G2 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 G2 BSC and G2 Transcoder allows up to 116 traffic
channels.
38 / 252
1 Introduction
Physical Layer 1
The data link layer provides frame handling and signalling functions using
the LAPD.
This layer supports three types of signalling links:
The Radio Signalling Link for signalling 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.5))
allows the time slot reserved for the O&M Link to be used for signalling
(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 Sub-layer
BTS
The BTS management layer is used for 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 RR management sub-layer
3 on the Air Interface. Non-transparent messages include messages for radio
link layer control and channel management.
39 / 252
1 Introduction
Modification of parameters is done from the OMC and propagated to the BSC
and the concerned BTSs. A new connection type parameter is associated to
each Abis link. The operator can set the parameter at Abis creation time. If
the satellite link is to be made using the Ater interface, the new connection
type parameter associated to 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 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.
40 / 252
1 Introduction
Physical Layer 1
The physical layer is a radio link where channels are divided by time and
frequency.
The data link layer provides frame handling and signalling 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. This procedure is explained
in detail in Ciphering (Section 3.8).
A
G
C
H
A
G
C
H
Frame 1
AGCH
A
G
C
H
Frame 2
Frame 3
A
G
C
H
Frame 4
A
G
C
H
Frame 5
Figure 11: Time Slot 4 of a Time Division Multiple Access Frame Supporting Access Grant Channels
Channels can be divided into traffic channels and control channels.
41 / 252
1 Introduction
Traffic Channels
A traffic channel can be used for speech or data. The Alcatel BSS supports the
following types of traffic channels:
Speech:
Full-rate speech traffic channel
Enhanced full-rate speech traffic channel
Half-rate speech traffic channel.
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).
Control Channels
CCHs control communications between the BSS and the mobile stations.
There are three types of CCH:
The BCCH broadcast cell information to any mobile station in range. Three
channels use the BCCH time slot:
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.
The CCCH communicate with mobile stations in the cell before a dedicated
signalling channel is established. Three channels use the CCCH time slot:
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 DCCH and ACCH pass signalling information for a specific mobile
station transaction. Two channels use the DCCH time slot:
SDCCH: used for signalling and short message information
CBCH: uses an SDCCH channel for Short Message Service Cell
Broadcasts.
42 / 252
1 Introduction
System Information
Messages
System information messages transmit information about the cell to the mobile
station. There are six system information messages. Four are sent on the
BCCH as a general broadcast to any mobile stations in the cells, and two sent
on the SACCH to mobile stations in communication with the BSS. 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
Channel
Information
Sys_info 1
BCCH
Sys_info 2
BCCH
Sys_info 2bis
(multiband
systems only)
BCCH
Sys_info 2ter
(multiband
systems only)
BCCH
43 / 252
1 Introduction
Message
Channel
Information
Sys_info 3
BCCH
Cell Identity
Location Area Identity
Control channel description
Cell options:
Power central information
Discontinuous Transmission (mechanism) information
Radio link timeout.
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.
RACH control information
Spare bits setting flags and timers.
Sys_info 4
BCCH
Sys_info 5
SACCH
Sys_info 5bis
(multiband
systems only)
SACCH
44 / 252
1 Introduction
Message
Channel
Information
Sys_info 5ter
(multiband
systems and
phase 2 mobile
stations only)
SACCH
Sys_info 6
SACCH
CI
Location Area Identity
Cell options:
Power control information
Discontinuous Transmission information
Radio link timeout
Indication of which Network Color Code it is allowed to monitor.
45 / 252
1 Introduction
46 / 252
47 / 252
2.1 Overview
The success of GSM has taken place in parallel with 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 graphics-intensive services
such as the World Wide Web and personal video conferencing. 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 European Telecommunication Standards Institute for
the double challenge of increased demand for data service and pressure
on radio resources is called General Packet Radio Service. The European
Telecommunication Standards Institute recommendations establish a standard
for inserting an alternative transmission method for data in the PLMN: packet
switching instead of circuit switching.
The Alcatel GPRS solution follows the ETSI GSM phase 2+ recommendations
closely.
48 / 252
4. At the destination, another PAD reads the envelope information, strips it off,
and reassembles the data in the proper order.
Header
Address Control
Field
Field
DATA
Footer
Information Field
FCS
ENVELOPE
FCS
SAPI
OMCR
MS
Gb
FRDN
Gb
SGSN
Packet
Switched
Traffic
GGSN
BSS
MFS
BTS
GCH
BSCGP
Abis
BTS
Transcoder
BSC
GCH
Ater
GCH
BSCGP
FRDN
GCH
: GPRS Channel
GGSN
MFS
PSTN
SGSN
VLR
MSC/
VLR
Circuit
Switched
Traffic
To PSTN
49 / 252
In the Alcatel solution, the Multi-BSS Fast packet Server with its associated
interfaces is the BSS element. All other components are external to the BSS.
The following internal and external components are described in this chapter:
GPRS mobiles
The Serving GPRS Support Node
The Gateway GPRS Support Node
The Multi-BSS Fast packet Server.
GPRS Mobiles
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 GPRS) 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
The Serving GPRS
Support Node
Class C mobile stations an be either IMSI attached or GPRS but not both, and
can use circuit-switched or GPRS services alternately.
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.
50 / 252
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.
See The Multi-BSS Fast Packet Server (Section 1.3.4) for details of the MFS
51 / 252
52 / 252
53 / 252
54 / 252
The following table describes the parameters that can be defined by the
operator.
Parameter Name
BS_PBCCH_BLKS
Definition
Coded on 2 bits:
00=Block
B0 used for
PBCCH
01=Block B0
and B6 used
for PBCCH
Type
Mandatory Rules
Number if:
BS_PBCCH_BLKS=1
then
PSI_REPEAT_PERIOD >
3.
if:
BS_PBCC
H_BLKS > 1 then
PSI_REPEAT_PERIOD >
4/BS_PBCC H_BLKS.
10=Block
B0, B6, and
B3 used for
PBCCH
11=Block B0,
B6, B3, and
B9 used for
PBCCH
BS_PAG_BLKS
_RES
Number of blocks
allocated to
the PAGCH or
PDTCH or PACCH
per 52 multiframe.
Number None.
BS_PRACH_
BLKS
Number of static
prach blocks.
BS_PRACK_
BLKS_MAX
Number of
dynamic prach
blocks.
Number BS_PRACH_BLKS_MAX
>= BS_PRACH_BLKS
S/(16 * BS_PRAC
H_BLKS_ MAX) >
round_trip_delay.
55 / 252
56 / 252
Channel
Information
SI 13
BCCH
Channel
Information
PSI 1
PBCCH
57 / 252
PSI 2
PBCCH
PSI 3/3bis
PBCCH
PSI 8
PBCCH
58 / 252
Description
Network services
BSS-GPRS Protocol
services
59 / 252
Description
Note:
60 / 252
The common radio signaling functions of the BSCGP are handled on the GPRS
Signaling Link, which is carried inside the Ater interface.
61 / 252
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 function.
The MAC function operates between the MFS and the mobile station, and
works in conjunction with the Radio Link Control function. Radio Link Control
defines the procedures for retransmission of unsuccessfully delivered data
blocks (error correction) and for the disassembly and reassembly of PDUs.
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.
A Temporary Block Flow is maintained only for the duration of the data transfer.
The Temporary Block Flow 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 Temporary Block Flow in each direction, and the path
of each Temporary Block Flow can be different.
62 / 252
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 re-selection is equivalent to
circuit-switched call re-establishment. Refer to Call Re-establishment by the
Mobile Station (Section 4.8) for more information.
63 / 252
2.4.2 Paging
Paging is the procedure by which the network contacts a mobile station.
The network can coordinate 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
Network
Operation Mode
2
Network
Operation Mode
3
64 / 252
Is used to:
MAX_UL_TBF_
SPDCH
MAX_DL_TBF_
SPDCH
N_TBF_PER_
PDCH
65 / 252
If MAX_UL_TBF_SPDCH is set to five, the minimum raw bit rate per user will be
increased from 1.9 kbit/s to 2.68 kbit/s (13.4/5). When the PDCH reaches five,
it is declared full and will not accept a sixth shared user.
However, setting the N_TBF_PER_PDCH parameter will affect 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 kbits/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.
66 / 252
67 / 252
Explanation
Empty
No established TBFs.
Active
Busy
Full
68 / 252
Maximum number of
PDCHs is reached
Allocated PDCHs
2
MAX_PDCH_GROUP
3
MAX_PDCH_HIGH_LOAD
1
MIN_PDCH_GROUP
GPRS MS requests time slots
Cell activated
GPRS
MS
: Mobile Station
PDCH
Time
69 / 252
70 / 252
of a network server as seen from this MFS. The timer range is 0-5000 ms
(in 100 ms steps). The default value is 700 ms.
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 MS, the network maintains the downlink
TBF by occasionally sending dummy downlink RLC data blocks to the MS,
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 MS,
beginning with the next available BSN.
When the network wishes to poll the MS 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 CS-1 downlink RLC data block. The LLC Dummy UI
Command is an invalid LLC PDU and is discarded by the LLC entity in the MS.
Unacknowledged Mode
In RLC unacknowledged mode the MS detects the end of the TBF by detecting
the Final Block Indicator (FBI) bit set to 1. The MS 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.
71 / 252
BTS
BSC
GPRS
Attach
MFS
SGSN
HLR
Reque
st
Update
Locati
on
er
scrib
Sub ta
Da
on
nticati
Authe
Subs
c
Data riber
ACK
ate
Upd ACK
n
o
i
t
a
Loc
GPRS
Attach
Accep
GPRS
Attach
Comp
lete
HLR
MFS
MS
: Mobile station
GPRS
SGSN
72 / 252
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.
73 / 252
BTS
Activat
e PDP
BSC
MFS
GGSN
SGSN
Context
Reque
st
Create
PDP
Context
Reque
st
DP
te P
Crea sponse
t Re
tex
Con
te PDP
Activa
ept
xt Acc
Conte
GGSN
MFS
MS
: Mobile station
PDP
SGSN
Mobile
Station-Originating
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 bidirectional 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 can begin.
74 / 252
GGSN-Originating
Activation
MS
BTS
BSC
MFS
HLR
SGSN
GGSN
PDU
PDP
Info
ting
Rou
uest
Req
Routin
g Info
ACK
eques
tion R
otifica
PDU N
PDU N
otificatio
n Resp
onse
n
itvatio
text Ac
P Con
D
P
t
s
Reque
PDP C
GGSN
HLR
MFS
MS
: Mobile station
PDP
PDU
SGSN
ontext
Activatio
75 / 252
BSS
Pack
et Ch
Requ annel
est
F
L TB
et U
t
Pack ignmen
Ass
RLC
SGSN
PDU
PDU
RLC ACK
N
/
K
AC
UL L
LC P
DU
5
PDU
RLC ACK
N
/
ACK
LLC
MS
: Mobile station
PDU
RLC
SGSN
TBF
UL
: Uplink
76 / 252
Mobile-Terminated Data
Transfer
BSS
SGSN
STAND BY
g PS
in
Pag
2
3
PCH
H or
PPC
Pack
et Ch
Requ annel
est
F
L TB
et U ent
k
c
a
P
gnm
Assi
LLC
PDU
UL
LLC
PDU
READY
F
L TB
et D ent
k
c
a
P
gnm
Assi
DL
LLC
PDU
DL
: Downlink
MS
: Mobile station
LLC
PCH
: Paging Channel
PDU
PPCH
PS
: Packet Switched
SGSN
TBF
UL
: Uplink
77 / 252
Mobile
Station-Originating
De-activation
MS
BTS
DeAc
tivate
BSC
PDP C
ontext
MFS
GGSN
SGSN
Reque
st
Delete
PDP
Conte
xt Req
uest
P
te PD
Dele esponse
R
t
tex
Con
PDP
ctivate
ept
xt Acc
Conte
DeA
GGSN
MFS
MS
: Mobile station
PDP
SGSN
Figure 20: Mobile Station 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.
78 / 252
SGSN-Originating
De-activation
MS
BTS
BSC
MFS
GGSN
SGSN
Delete
PDP
Conte
xt Req
uest
SGSNOriginating
DP
te P
Dele sponse
e
xt R
onte
st
Reque
ontext
PDP C
te
a
v
ti
DeAc
DeAc
tivate
PDP C
ontext
Accep
GGSNOriginating
PDP
tivate
DeAc
DeAc
tivate
PDP C
ontext
DP
te P
Dele equest
R
text
Con
uest
xt Req
Conte
Accep
Delete
PDP
Conte
xt Res
ponse
GGSN
MFS
MS
: Mobile station
PDP
SGSN
79 / 252
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.
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.
80 / 252
BTS
RR Su
BSC
MFS
SGSN
spend
Susp
end
Susp
end
T3
Suspe
Suspe
MFS
SGSN
nd Ack
nd Ack
81 / 252
BTS
BSC
MFS
SGSN
Resu
me
Resu
me
T_GPRS_Resume
T4
ck
me A
Resu
ck
me A
Resu
se
Relea
annel
RR Ch
Routing Area
Update Reque
st
MFS
MS
: Mobile station
RR
: Radio Resource
SGSN
82 / 252
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 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
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.
83 / 252
Mobile
Station-Originating
Detach
MS
BTS
BSC
Detac
MFS
GGSN
SGSN
h Req
uest
Delete
PDP
Conte
xt Req
uest
P
te PD
Dele esponse
R
text
Con
GPRS
pt
h Acce
Detac
GGSN
MFS
MS
: Mobile station
PDP
SGSN
84 / 252
Network-Originating
Detach
MS
BTS
BSC
MFS
GGSN
SGSN
HLR
ion
ocat
cel L
Can
Delete
PDP
Conte
xt Req
uest
GPRS
uest
h Req
Detac
DP
te P
Dele sponse
e
R
t
ntex
Co
Detac
h Acce
pt
Cance
l Loca
GGSN
HLR
MFS
MS
: Mobile station
PDP
SGSN
tion AC
85 / 252
86 / 252
3 Call Set Up
3 Call Set Up
This chapter 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.
The type of teleservice and bearer service required are also described.
This chapter also describes the following parts of the Call Set Up procedure:
Overview
Mobile Originated Call
Mobile Terminated Call
Paging
Congestion
Classmark Handing
Authentication
Ciphering.
87 / 252
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.
Call Types
Description
Service Calls
88 / 252
3 Call Set Up
The following table shows the phases involved in call set up:
Phase
Composition
Authentication and
Ciphering
Classmark handling
Authentication
Ciphering.
Normal assignment
89 / 252
3 Call Set Up
Channel Request
90 / 252
3 Call Set Up
MS
BTS
BSC
MSC
Channe
l Reque
st (RAC
H)
REF
Chann
el Requ
REF+R
ired
FN+TA
REF stored
in MS
memory
SDCCH
Allocation
vation
el Acti
Chann
er
+pow
DCCH
TA+S
Chann
el Activ
ation A
ck
MS compares
message with
REF in memory
Switch to
SDCCH
iate
Immed
REF+
GCH)
ment (A
assign
RF
+SD
N+TA
d
mman
ign co
te ass
ia
d
e
Imm
REF
RFN+
wer+
H+po
C
C
A+SD
CCH
SABM
+ cm +
Service
Request
UA
Establis
h Indic
ation
cm + Se
rvice Re
quest
uest
e Req
Servic
SCCP
Conne
ction R
equest
cm + Se
rvice Re
quest
SCCP
cm
: Classmark
ID
power
REF
RFN
SDCCH
Service
Request
TA
: Timing advance
UA
: Un-numbered acknowledgment
onfirm
ction C
Conne
Figure 26: Radio and Link Establishment for Mobile Originated Call
The mobile station continues to transmit channel_request messages until it
receives a response. 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.
91 / 252
3 Call Set Up
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:
SDCCH Channel
Activation
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.
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.
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:
BTS
BSC
SDCCH
Allocation
Chann
el Acti
vation
er
+pow
DCCH
TA+S
Chann
el Activ
ation A
ck
power
SDCCH
TA
: Timing advance
92 / 252
MSC
3 Call Set Up
Immediate Assignment
BTS
Im
Switch to
SDCCH
te as
media
signm
ent (A
GCH)
BSC
nd
omma
sign c
iate as
d
e
m
FN
Im
EF+R
er+R
+pow
H
C
DC
TA+S
DCCH
TA+S
RFN+
+
F
E
R
REF
RFN
SDCCH
TA
: Timing advance
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.
93 / 252
3 Call Set Up
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 is user setable.
If an immediate_assign_command message is received before expiration
of the timer, it has priority and the mobile station will respond to it, thus
connecting the call.
Note:
Immediate Assignment
Extended
This message can not be used when the mobile station is responding to
paging, i.e. in the case of a Mobile-terminated call.
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 has been 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.
Set Asynchronous
Balanced Mode
94 / 252
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.
3 Call Set Up
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 +
Service
Reques
t
UA
Serv
ice Re
Establi
sh Indic
cm + Se
ation
rvice Re
quest
quest
SCCP
Conne
cm + Se
ction R
rvice Re
equest
quest
nfirm
on Co
nnecti
Co
SCCP
cm
: Classmark
Service
Request
: Initial layer 3 message including the mobile station identity and classmark
UA
: Un-numbered acknowledgment
Establish Indication
SCCP Connection
95 / 252
3 Call Set Up
Authentication
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 correctIndividual Subscriber
Authentication Key value on the SIM for the ciphering procedure
Sends the Random Number for the ciphering and authentication procedures.
This procedure is described in Authentication (Section 3.7).
Ciphering
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).
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 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.
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.
96 / 252
3 Call Set Up
MS
BTS
BSC
MSC
set up (S
DCCH)
layer 3 CC
tele/bearer
service
called party
no.
layer 3 CC
call proceeding
layer 3 CC
layer 3 CC
quest
ment re
assign
TCH
allocation
physica
xt confi
power +
ates
r upd
powe
e6
TA +
5
fo
in
+ sys
pe+c
quest
l conte
H)
nel ty
text re
al con
physic
(SACC
chan
rm
TA
vation
el acti
chann
her
+ cip
+ TA
er
w
TCH
o
p
X+
+ DT
channe
l activa
tion ac
knowle
dge
and
comm
ment
assign
H)
(SDCC
mand
nt com
e
m
n
assig
release
SDCCH
SABM
(FACC
H)
estab
UA
H)
(FACC
lish in
Set
transcoder
dicatio
assign
ment c
omple
te (FA
CCH)
Set switching
path
assign
ment c
o
layer 3 CC
layer 3 CC
connect acknowledgement
layer 3 CC
initiate SDCCH
release
alerting
layer 3 CC
connect
mplete
layer 3 CC
cipher
cm
: Classmark
DTX
TA
: Timing advance
97 / 252
3 Call Set Up
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 station 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.
Traffic Channel
Activation
98 / 252
3 Call Set Up
The following figure shows the channel activation process for the traffic channel.
MS
BTS
BSC
MSC
TCH
allocation
quest
text re
al con
physic
physical
context
confirm
power +
TA
ation
el activ
chann
(SACC
er
+ ciph
+ TA
TCH
ower
p
+
X
+ DT
H)
ates
r upd
powe
TA +
5&6
fo
in
+ sys
channe
l activa
tion ack
nowled
ge
mand
com
nment
assig
CH)
d (SDC
mman
o
ment c
assign
cipher
DTX
MS
: Mobile station
TA
: Timing advance
TCH
: Traffic Channel
99 / 252
3 Call Set Up
The following figure shows the channel assignment process for the traffic
channel.
MS
release
SDCCH
BTS
SABM
BSC
MSC
(FACC
H)
establi
sh ind
UA (FA
assign
ment c
Set
transcoder
CCH)
omple
te (FA
CCH)
ication
Set switching
path
assign
ment c
FACCH
MS
: Mobile station
SABM
UA
: Unnumbered Acknowledgment
omple
te
100 / 252
3 Call Set Up
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
layer 3 CC
layer 3 CC
connect acknowledgement
BSC
layer 3 CC
initiate SDCCH
release
layer 3 CC
MSC
alerting
connect
layer 3 CC
MS
: Mobile station
SDCCH
OACSU is a method available in the BSS where 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.
Practically speaking, the way this happens is 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 has the effect on the system of increasing 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.
101 / 252
3 Call Set Up
BTS
BSC
MSC
paging
IMSI +
paging
paging
reques
TMSI/IM
chann
el requ
(PCH)
com
mand
TMSI/
cell lis
up +
ing gro
SI pag
IM
r
I/
e
b
S
TM
el num
chann
SI
est
(RACH
)
chann
el requ
ired
IMSI
MS
: Mobile station
PCH
: Paging Channel
RACH
TMSI
Figure 34: Radio and Link Establishment for Mobile Terminated Call
102 / 252
3 Call Set Up
Before the BSS sets up a signalling 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 time slot 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).
103 / 252
3 Call Set Up
BTS
BSC
MSC
set up
r service
layer 3 CC
tele/beare
layer 3 CC
call confirmed
(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
knowledg
connect ac
layer 3 CC
layer 3 CC
MS
: Mobile station
SDCCH
104 / 252
If 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
3 Call Set Up
to the answering user, so that the user does not hang up before the Normal
Assignment procedure completes.
105 / 252
3 Call Set Up
106 / 252
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
assign 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 are for
the PCH. The parameter to reserve these blocks is set to BS_AG_BLKS_RES = 3.
TDMA Frame Cycle
CCCH0
CCCH1
CCCH2
CCCH3
CCCH
PCH
: Paging Channel
TDMA
CCCH4
CCCH5
CCCH6
CCCH7
CCCH8
107 / 252
3 Call Set Up
AGCH
AGCH
AGCH
PGR0
PGR1
PGR2
PGR3
PGR4
PGR5
PGR9
PGR10
PGR11
PGR15
PGR16
PGR17
PGR21
PGR22
PGR23
AGCH
AGCH
AGCH
PGR6
PGR7
PGR8
AGCH
AGCH
AGCH
PGR12
PGR13
PGR14
AGCH
AGCH
AGCH
PGR18
PGR19
PGR20
AGCH
PGR
: Paging Group
PCH
: Paging Channel
TDMA
108 / 252
3 Call Set Up
Paging Performance
No IE present
Error in IE
109 / 252
3 Call Set Up
Paging Request
Message
BTS
BSC
MSC
paging
+ cell
paging
paging
reques
S
TMSI/IM
channe
list IE
nd
omma
up
ing gro
t + pag
meslo
ti
H
C
+ CC
l reque
st
channe
l requir
REF +
RFN +
ed
TA
SABM
+ serv
ice req
uest (p
aging
respon
se)
establis
h indic
ation
CCCH
IE
: Information Element
IMSI
MS
: Mobile station
REF
RFN
SABM
TA
: Timing advance
TMSI
110 / 252
3 Call Set Up
111 / 252
3 Call Set Up
3.5 Congestion
To prevent an assignment_request or an external handover_request
message 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_Q_LENGTH parameter to 0 disables the 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.
112 / 252
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_Q_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
Forced Directed Retry.
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.
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.
113 / 252
3 Call Set Up
Queue Preemption
Timer Expires
Reshuffling Half-Rate
Calls
Half-rate calls use only a half time slot. If two half-rate calls are alone on
separate time slots they are gathered on to a single time slot. This frees a
whole time slot to serve a queued full-rate request. Reshuffling half-rate calls
is enabled on a per cell basis, by setting the EN_HR_RESHUFFLING parameter
to TRUE. Setting the EN_HR_RESHUFFLING parameter to FALSE disables
reshuffling half-rate calls 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
There are at least two half-rate resources in the half-rate pool
The parameter EN_HR_RESHUFFLING is set to TRUE.
If the request is a half-rate request, it is not queued but served, because at least
two half-rate resources in the half-rate pool are required to trigger the algorithm.
If there is only one resource in the half-rate pool, it means there is an odd
number of half-rate calls in the cell, so it is not possible to pair the last one. The
queued request may be an assignment, or an incoming external emergency
handover. If the algorithm has been triggered once and the queued request
served (or rejected by expiry of the timer), if at least another request still
remains in the queue, and if the trigger condition is still fulfilled for the top
queued request (assignment or external emergency handover), then the
algorithm is triggered again. If a half-rate request is queued behind a full-rate
request, the half-rate request is served on a remaining half-rate resource of the
half-rate pool (if any) without triggering the algorithm again.
Half-rate calls are paired using an intracell handover. In the case of concentric
cells, mobile stations are queued in the outer zone only. The check for two
free half-rate resources applies to the outer zone only (to free a resource in
the outer zone). The mobile station selected will make its handover into the
outer zone (i.e. this handover does not allow handover from the outer zone
to the inner zone).
114 / 252
3 Call Set Up
115 / 252
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 signalling 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 & Phase 2 GSM the signalling 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 that
pre-emption can be deferred while 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 is to be pre-empted.
Pre-emption isapplied to 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.
eMLPP
116 / 252
3 Call Set Up
Pre-emption Rules
117 / 252
3 Call Set Up
Classmark Handling
BSS
MSC
Mobile station
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.
3.6.1 Classmark IE
The Alcatel 900/1800 BSS supports classmark 1, classmark 2 and classmark 3
IEs. The classmark 1 IE is always sent to the BSS when the mobile station
tries to establish communication.
Classmark 1
Classmark 2
118 / 252
3 Call Set Up
Classmark 3
Revision Level
RF Power Level
Support of A5/1
Encryption
This field indicates 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
This field indicates 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.
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 the classmark 1 Information Element 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 classmark 1 Information Element was
received. Therefore, a classmark updating procedure is required.
119 / 252
3 Call Set Up
Action
120 / 252
3 Call Set Up
MS
BSC
MSC
channel re
quest
(RACH)
channel
switch to
SDCCH
SABM +
rn +
required
fn + cm
establish
indication
SCCP co
nnection
SCCP
CCH)
H/SA
(FACC
pow
+s
er + TA
ys info
5&6
ark
classm
enauiry
ion
connect
confirm
classmark change
classmark 2IE
classmark update
classmark 2IE
location update
(SDCCH)
cm
: Classmark
FACCH
IE
: Information Element
MS
: Mobile station
RACH
SABM
SACCH
SCCP
SDCCH
TA
: Timing advance
121 / 252
3 Call Set Up
122 / 252
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.
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
request
MSC
IMSI +
Ki
VLR
BSC
Mobile
Station
IMSI
Ki
LAI
TMSI
VLR
Figure 40: Location Update with Mobile Station Sending Location Area Identity of Previous VLR
123 / 252
3 Call Set Up
Authentication
Procedure
124 / 252
3 Call Set Up
3.8 Ciphering
Ciphering is supported in the Alcatel 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.
Capability
Phase 1
Phase 1 Extended
Phase 2
No encryption
No encryption and A5/1
No encryption and A5/2
No encryption and A5/1 and A5/2
125 / 252
3 Call Set Up
BSS Capability
126 / 252
3 Call Set Up
127 / 252
3 Call Set Up
BTS
BSC
MSC
e com
g mod
n
cipheri
tion
encryp
mm
ode co
s + Kc
orithm
ted alg
permit
c or
m+K
algorith
tion
p
ry
c
n
no e
and
ng m
cipheri
and
comm
mand
H)
(SDCC
algorithm or
no encryption
cipheri
ng mo
de com
plete
cipher
mode
MS
: Mobile station
SDCCH
comple
te
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.
128 / 252
3 Call Set Up
129 / 252
3 Call Set Up
The TFO procedure 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.
TC A
BSC A
BTS A
TC B
Channel activation
TFO enabled
BSC B
BTS B
Channel activation
TFO enabled
PCM samples
TRAU frames
TRAU frames
CON_REQ
CON_REQ
DL_ACK
DL_ACK
2
3
TFO_REQ
TFO_REQ
TRAU frames
TFO_ACK
TRAU frames
TFO_ACK
Codecs match
4
TFO frames
TFO_ON
TFO_ON
5
TFO REPORT (TFO STATUS= ON)
PCM
TC
: Transcoder
TFO
TRAU
130 / 252
3 Call Set Up
The Alcatel TFO implementation is fully compliant with the GSM standard
and additionally provides:
As an operator s choice, the Alcatel BSS is able to force the distant BSS
(Alcatel or not) to overcome ETSI codec choice rules, in order to optimize
voice quality and load management. This mechanism is patented by Alcatel.
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.
As the same codec is used on both sides, there is no TFO negotiation needed
between the TRAU.
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 intra-cell handover is performed to change the speech codec
locally used, and TFO exchange of speech stream begins. A logical parameter,
configurable at OMC-R level, 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 intra-cell handover is not possible,
TFO mode is given up, and the system reverts to normal mode.
131 / 252
3 Call Set Up
TFO Optimization
For a better speech quality, TFO Optimization allows a new TFO negotiation
on an on-going TFO mobile-to-mobile call, to find a better common codec, in
terms of speech quality. Therefore, enhanced full-rate coding is considered to
be 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 parts 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.
For a better traffic load regulation Alcatel has defined the function "Force
TFO half-rate when loaded" to give control to the operator of load regulation
precedence over TFO. 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 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 part supports
half-rate, then the distant part will do an intra-cell handover to use half-rate,
and TFO will go on with half-rate. If the distant part 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.
132 / 252
4 Call Handling
4 Call Handling
This chapter provides an overview of Call Handling and describes the
supervision of a call in progress. The following specific areas are described:
Overview
In-call modification
Frequency hopping
Discontinuous Transmission
Radio Power Control
Handover procedures
Overload conditions
Call re-establishment by the mobile station.
133 / 252
4 Call Handling
4.1 Overview
An obvious requirement for the effective management of calls in the BSS
is to provide the following:
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.
134 / 252
4 Call Handling
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 signalling 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.
For a mobile station to mobile station call, both mobile stations must negotiate a
dual service during call establishment.
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 to 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.
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).
The BSS handles the normal assignment procedure as if assigning a traffic
channel during call set up (described in Call Set Up (Chapter 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.
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
135 / 252
4 Call Handling
informs the mobile station that the procedure is successfully completed, and
the mobile station can start transmitting in the new mode.
Non-Transparent Group
3 Fax
For non-transparent fax transmission, the data rate change is handled within
the BSS, using in-band signalling. 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.
Transparent fax frames are passed transparently through the BSS. Therefore,
in-band signalling cannot be used within the BSS. The Group 3 fax equipment
informs the MSC of a data rate change using in-band signalling. 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.
In-Call Modification
Example
136 / 252
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.
4 Call Handling
Frequency Diversity
Interference Diversity
137 / 252
4 Call Handling
Assignment
for TCH 1:
TS=1
MAIO=0
HSN=0
TCH1 on TS1
MAIO=0
Frame
n+1
Frame
n+2
Frame
n+3
f1
f2
f3
f1
TCH2 on TS2
MAIO=1
f2
f3
f1
f2
TCH3 on TS3
MAIO=2
f3
f1
f2
f3
: Frequency
FHS
TCH
: Traffic Channel
MAIO
HSN
TS
: Time slot
138 / 252
4 Call Handling
Note:
139 / 252
4 Call Handling
Continuous
Transmission
Discontinuous
Transmission
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 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.
140 / 252
4 Call Handling
1. This bans Discontinuous Transmission on the downlink for all calls that
are established on the BCCH TRX.
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).
MSC Downlink_
Discontinuous
Transmission flag
(per call basis)
Result
Discontinuous
Transmission
flag
True
Allowed
ON
True
Unavailable/not
allowed
OFF
False
Allowed
OFF
False
Unavailable/not
allowed
OFF
141 / 252
4 Call Handling
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:
Description
Will perform
Discontinuous
Transmission
Can perform
Discontinuous
Transmission
Cannot perform
Discontinuous
Transmission
Note:
142 / 252
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.
4 Call Handling
Continuous Transmission
Discontinuous Transmission
DTX
: Discontinuous Transmission
143 / 252
4 Call Handling
144 / 252
4 Call Handling
Description
Signal strength
Signal quality
Absolute mobile
station-BS distance
Reporting Period
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.
145 / 252
4 Call Handling
BTS
BSC
MSC
start counter
conn
ectio
n fail
ure in
caus
dicati
on
e va
lue
clear
e
leas
requ
est
el re
RF
n
han
and
mm
r co
clea
alue
se v
cau
g
in
clud
IE in
MS
: Mobile station
TX
: Transmitter
146 / 252
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
R
X
Q
U
A
L
Desired
balance
no
change
Quality bad
Increase power output
Low Quality
Low Signal Level
RXLEV
RXQUAL
RXLEV
Figure 46: Power Output Balancing Based on Received Quality and Signal
Levels
147 / 252
4 Call Handling
Max Power
Min Power
43 dBm (20 W)
13 dBm
30 dBm (1 W)
10 dBm
39 dBm (8 W)
13 dBm
39 dBm (8 W)
13 dBm
30 dBm (1 W)
4 dBm
33 dBm (2 W)
0 dBm
148 / 252
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
Internal
External.
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.
Internal
Internal handovers take place between cells controlled by the same BSC. This
can include channel changes within the same cell. More details about these
handover cases is given in Target Cell Evaluation (Section 4.6.3).
External
149 / 252
4 Call Handling
Directed Retry
Secured Incoming
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 in the case of 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.
Fast Traffic
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
overlap totally the microcells).
UMTS to GSM
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 hand over. The signalling 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. Therefore, 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.
150 / 252
4 Call Handling
Power Control
BTS and mobile station power control is described in 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.
The BSC calculates the need for a handover using an algorithm, the use of
which is described in Handover Detection (Section 4.6.2).
The BSC uses the uplink idle channel measurements made by the BTS to
make a table of traffic channel channels, classified by interference levels. This
table is used to select a channel for assignment.
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.
Handover Decision
151 / 252
4 Call Handling
152 / 252
4 Call Handling
High Quality
Received
Signal
Quality
123456
123456789
123456
123456789
123456
123456789
123456789
Level 123456
Power
Desired
Power
123456789
Intercell 123456
Increase
Quality
Decrease to
Handover123456
to
and Level 123456789
Conserve
Improve
Balance
Resources
123456
123456789
Level
(no action 123456789
and Minimize
123456
needed) 123456789
Interference
123456
123456
123456789
123456
123456789
123456789
123456
12345612345678901234
12345678901234
Power Increase to
12345612345678901234
improve quality
123456
12345678901234
123456
12345678901234
Quality Intercell
Handover
Quality Intracell
Handover
High
Level
Low Quality
Low Level
Quality Intercell
Handover
Quality Intracell
Handover
153 / 252
4 Call Handling
High Power
Outer Zone
Low Power
Inner Zone
MS Handed
Over to
Low Power
Zone
MS
: Mobile station
154 / 252
4 Call Handling
Serving Cell
BSS 1
Target Cell
BSS 2
155 / 252
4 Call Handling
BSS 1
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
1234567890
Area of Normal
Cell Boundaries
Distance Handover
Area from BSS1 to BSS2
156 / 252
BSS 2
4 Call Handling
Macrocell
saturated
High load
Traffic
regulation
Low load
Max speed
discrimination
in force
Macrocell with
little traffic
High minimum
dwell time
157 / 252
4 Call Handling
Preferred-Band
Handover
In certain networks, two different frequency bands can exist, for example, one
frequency band uses the GSM frequencies, the other frequency band uses
the DCS 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.
158 / 252
4 Call Handling
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 chosen 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
Internal: Intracell
If the target cell and the serving cell are 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.
159 / 252
4 Call Handling
Internal (IntraBSS):
Intercell
If the target cell is not the same as the serving cell but is 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 is controlled by the MSC.
External (InterBSS):
IntraMSC
If the target cell and the serving cell are 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
If the target cell and the serving cell are 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.
160 / 252
4 Call Handling
161 / 252
4 Call Handling
Target
BTS
MS
measu
remen
Serving
BTS
BSC
MSC
t report
s (S
ACC
H)
measu
re
ment re
s
ults
HO detect
HO alarm
cell evaluation
quest
text re
al con
physic
physic
confirm
al con
text
TA + p
ower
vation
el
chann
ower +
p
+
X
DT
ipher +
TA + c
el acti
chann
chann
el acti
ell
er + c
+ pow
ack
mman
ver co
hando
f
HO re
vation
TA +
desc +
cipher
nel
+ chan
release with
serving BTS
acces
s burs
t (SAC
CH)
hando
ver de
tection
SABM
establi
sh ind
ication
hando
ver co
mplete
hando
ver pe
DTX
: Discontinuous Transmission
HO
: Handover
MS
: Mobile station
SABM
SACCH
TA
: Timing advance
rforme
162 / 252
4 Call Handling
Measurement Reporting
Handover Detection
The mobile station and BTS take measurements on the Air interface as
described above. 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.
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 cell list. For this example, the first cell on the list (target cell)
is a cell controlled by this BSC and the BTSs of both serving and target cell
are collocated. Once this cell is chosen, the BSC initiates the synchronous
internal handover procedure.
The BSC sends a physical_context_request message to the serving BTS,
requesting current timing advance and power level information. This information
is passed to the target BTS.
The serving BTS responds with a physical_context_confirm message.
Channel Activation
Handover Command
163 / 252
4 Call Handling
The Handover
The mobile station releases its connection with the serving BTS and sends
four consecutive access bursts to the target BTS on the uplink SACCH. These
bursts include the handover reference and use a timing advance of 0.
The BTS calculates the timing advance (it may have changed since the physical
context procedure). It sends a handover_detection message to the BSC
indicating the timing advance measured for the access burst. If the mobile
station timing advance needs to be updated, the BSC sends this information in
the physical_information message on the FACCH channel associated with
the traffic channel.
The mobile station then sets ciphering (as required). It sends its first
frame, SABM, using the timing advance information either as sent in the
handover_command message, or as updated in the FACCH frames.
When the BTS receives the frame from the mobile station, it sends an
acknowledgment frame to the mobile station and an establish_indication
message to the BSC. This informs the BSC that the radio link has been
established. The BSC starts BTS and mobile station power control.
On receipt of the acknowledgment frame, the mobile station sends a
handover_complete message to the BSC. The mobile station can now start
transmitting on the new channel.
The BSC informs the MSC of the handover in a handover_performed
message and initiates the release of the old channel.
164 / 252
4 Call Handling
MS
measurement repo
Serving
BTS
rts
Target
BSC
Serving
BSC
MSC
(SACCH)
measurement resu
lts
HO detect
HO alarm
handover required
est
handover requ
channel activati
on
X+cause+cm
her+cell IDs+DT
channel type+cip
SACCH/FACCH
channel activation
ack
hanover request
ack
+ handover com
mand
handover command
mand
handover com
d
handover comman
ch+cell+HOref+cipher
release with
serving BTS
handover detect
Synchronization
(FCCH + SCH)
handover detect
handover detect
HO ref + TA
set up switching
path between Abis
& A interfaces
physical info
physical info
(FACCH)
establish indication
ack
(FACCH)
handover complete
handover performed
clear comman
DTX
: Discontinuous Transmission
FACCH
HO
: Handover
MS
: Mobile station
SABM
SACCH
TA
: Timing advance
165 / 252
4 Call Handling
Measurement Reporting
Handover Detection
The mobile station and BTS take measurements on the Air interface as
described above. 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.
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.
Channel Activation
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.
Handover Command
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.
The Handover
166 / 252
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.
4 Call Handling
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.
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 stations 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 has been performed.
The MSC initiates the call clearing procedure towards the serving BSC.
167 / 252
4 Call Handling
Note:
168 / 252
The BTS monitors the load on the FU or TRE by measuring the free time on
the FU or TREs Signalling 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.
4 Call Handling
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 signalling
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 BSCs centralized overload controller is responsible for global overload
defence actions.
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 signalling 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 MSC are overloaded.
169 / 252
4 Call Handling
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:
AUT_BAR enables/disables the automatic banning of cells after all access
classes have been barred. This forces the mobile station to camp on
another cell.
EC_BAR 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.
The number of access classes that can be barred and unbarred in one step can
also be configured from the OMC-R.
170 / 252
4 Call Handling
171 / 252
4 Call Handling
172 / 252
5 Call Release
5 Call Release
This chapter provides an overview of Call Release and describes the
procedures which ensure resource allocation to a call. It specifically describes
Call Release procedures in normal service plus the following special cases:
Overview
Following Reset
BSC initiated
BTS initiated
Mobile station initiated
This chapter also describes Remote Transcoder Alarms, and the processes
used to break a connection and disconnect the resources, depending on the
nature of radio transmission.
173 / 252
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 signalling for the A interface
Layer 1 physical resources for the A interface.
BSC:
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:
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:
Layer 3 for the Air interface
Layer 2 LAPDm for the Air interface
Layer 1 for the Air interface.
174 / 252
5 Call Release
BSS
MSC
discon
nect (la
yer 3
uest
se req
(layer
CC)
3 CC)
relea
release
MS
comple
te
(layer 3
CC)
: Mobile station
175 / 252
5 Call Release
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.
This action triggers the mobile station to release the LAPDm connection (disc
message) and the BSC to release physical resources allocated to the call.
This is shown in the following figure.
MS
BTS
BSC
MSC
clear c
nd
omma
alue
ause v
ding c
clu
MIE in
ase
el rele
chann
release of A
interface resources
Timer start (SCCP release)
CH
AC
eS
vat
acti
de
disc
(to re
lease
LAPD
m)
clear c
omplete
disable remote
TC alarm detect
relea
se in
UA
ed
releas
SCCP
dicati
on
SCCP
ontext
t
reques
c
ysical
ph
physic
al con
release
comple
te
Timer
text co
nfirm
lease
nnel re
RF cha
RF ch
annel
Timer
releas
e ack
LAPDm
LAPDm
MIE
MS
: Mobile station
SACCH
SCCP
TC
: Transcoder
UA
: Unnumbered Acknowledgment
176 / 252
5 Call Release
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 54)
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
signalling which controls the connection.
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.
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. This is shown in the following figure.
MS
BTS
BSC
MSC
omma
clear c
MIE in
ase
el rele
chann
dea
ctiv
ate
C
SA
CH
cludin
nd
g caus
e valu
release of A
interface resources
Timer start (SCCP release)
clear c
omplete
SCCP
MIE
MS
: Mobile station
SACCH
SCCP
ed
releas
release
comple
te
177 / 252
5 Call Release
BSC/BTS/Mobile Station
Interactions
The normal Call Release procedure towards the mobile station/BTS releases:
The radio resources associated with the call
The Radio Frequency 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.
Thechannel_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 disconnected and
starts the RF channel release when:
The timer expires
The BSC receives the release_indication message and stops the timer.
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
clear c
alue
ause v
ding c
clu
MIE in
chann
el rele
ase
dea
lease
release of A
interface resources
Timer start (SCCP release)
CH
SAC
clear c
omplete
disable remote
TC alarm detect
disc
(to re
te
tiva
LAPD
m)
UA
SCCP
relea
se in
releas
ed
dicati
on
LAPDm
MIE
MS
: Mobile station
SACCH
SCCP
TC
: Transcoder
UA
: Unnumbered Acknowledgment
SCCP
release
comple
te
178 / 252
5 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).
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.
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
UA
BSC
relea
se in
MSC
dicati
on
quest
text re
al con
physic
physic
al con
text co
nfirm
Timer
e
releas
annel
RF ch
RF ch
annel
MS
: Mobile station
UA
: Unnumbered Acknowledgment
Timer
releas
e ack
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 chapter
3 for more information).
179 / 252
5 Call Release
MS
Serving
BTS
Target
BSC
Serving
BSC
MSC
(FACCH)
handover comple
te
handover perform
ed
and
comm
clear
lue
se va
MIE
ding
inclu
cau
ase
el rele
chann
ct
dea
FACCH
MIE
MS
: Mobile station
SACCH
iva
te S
AC
CH
180 / 252
5 Call Release
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. The figure below
shows the Call Release process after a reset is initiated.
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.
181 / 252
5 Call Release
MS
BTS
BSC
MSC
reset
l releas
channe
SCCP
disc
to relea
se LAP
Dm
e
l releas
release
indicatio
leas
phys
e LA
PDm
te
comple
quest
t re
to re
release
circuits blocked
SCCP re
lease
channe
ntex
ical co
disc
block
SCCP
releas
e
rele
CCP
ase c
omp
lete
physic
al con
text co
nfirm
rele
indic ase
atio
n
nnel
RF cha
release
RF channe
l release
ack
l
physica request
context
physical
context
RF cha
nnel re
confirm
lease
RF chan
nel relea
se
ack
timer
reset a
LAPDm
MS
: Mobile station
SCCP
ck
Note:
182 / 252
5 Call Release
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
clear
requ
est
MIE
MIE
MS
: Mobile station
and
mm
r co
clea
ing
clud
alue
se v
cau
in
183 / 252
5 Call Release
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.
184 / 252
5 Call Release
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
185 / 252
5 Call Release
LAPD Failure
When the BTS detects an 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 A9100 or BTS A910).
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.
The BSC reinitializes 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.
186 / 252
5 Call Release
MS
BTS
BSC
MSC
Detection of LAPD
failure. BTS stops
sending SACCH frames.
disc
timer
disc
timer
disc
timer
UA
UA
UA
release RF resources
release RF resources
release RF resources
Reestablish LAPD connection
error
caus
repo
rt
e valu
quest
clear co
mman
se va
ing cau
lue
clud
MIE in cl
ear compl
ete
FU
: Frame Unit
LAPD
MIE
MS
: Mobile station
SACCH
TRE
: Transmitter/Receiver Equipment
UA
: Unnumbered Acknowledgment
187 / 252
5 Call Release
O&M Intervention
The BTS initiates a Call Release if its O&M entity requests a restart of an
Frame Unit (TRE for a BTS A9100 or BTS A910).
The FU or TREs 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 reestablish 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.
188 / 252
5 Call Release
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:
MS
BTS
BSC
MSC
start counter
conn
ectio
n fail
ure in
caus
dicati
on
e va
lue
clear
e
as
l rele
RF
MS
: Mobile station
SACCH
est
ch
MIE
MIE
requ
e
ann
and
mm
r co
clea
alue
se v
cau
ing
d
lu
inc
Figure 63: Call Release due to Mobile Station initiated Radio Link Failure
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)).
189 / 252
5 Call Release
BTS
BSC
MSC
TC detects a communication
break and times out
Alarm
conn
ectio
n fail
ure in
dicati
on
caus
e valu
e
clear
requ
est
e
leas
el re
ann
h
c
RF
MIE
MIE
MS
: Mobile station
TC
: Transcoder
inc
and
mm
r co
clea
g
ludin
cau
se v
alue
190 / 252
191 / 252
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 BTSs in its domain.
The TSS 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
64 kbit/s
13 kbit/s
BTS
BIE
BIE
BSC
SM
SM
TC
MSC
A/D
PSTN
Mobile
Station
A
6.5 kbit/s
CIM
6.5 kbit/s
13 kbit/s
64 kbit/s
A/D
: Analog
A/D
: Analog/Digital
BIE
CIM
PSTN
SM
: Submultiplexer
TC
: Transcoder
TCH
: Traffic Channel
Analog
192 / 252
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.
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.
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 signalling
if they are full-rate speech. The channels on the Abis and Ater interfaces are
64 kbit/s. The speech blocks 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 signalling. 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 mated 8 kbit/s Abis channels are
independently switched by the BSC onto two 16 kbit/s Ater channels.
Ater Interface
Atermux Interface
SM
BSC
30 x 16 kbit/s user
traffic channels
per link
SM
: Submultiplexer
TC
: Transcoder
Ater Interface
SM
90 x 16 kbit/s user
traffic channels
per link
30 x 16 kbit/s user
traffic channels
per link
A Interface
TC
MSC
30 x 64 kbit/s user
traffic channels
per link
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.
193 / 252
Enhanced Full-Rate
Process
194 / 252
6.2.2 Half-Rate
Half-rate speech channels allow the operator to save time slots 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.
Half-rate can be applied to BSSs with the following equipment:
G2 BSC
G2 Transcoder
One of the following BTSs:
G1 BTS equipped with Dual Rate Frame Unit
EVOLIUM BTS.
195 / 252
196 / 252
Normal Assignment
AMR is controlled on a per call basis by the MSC. In the assignment request
message, the MSC gives the Channel type IE, which indicates the following:
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 following octets indicate that AMR is allowed in half-rate or
full-rate.
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). 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. Once
the channel is activated within the BTS, the BSC sends all AMR relevant
parameters to the mobile station in the assignment command message.
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. Once
the BTS detects that downlink CMI/CMR is synchronized between the TRAU
frames and the radio interface, it starts codec mode adaptation.
O&M Management
This section summarizes the main O&M configuration parameters that can be
changed by the operator from the OMC-R:
AMR_SUBSET_FR Bitmap of 8 bits defining the codec subset for AMR full-rate
load. It can take the 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 the value from 0.0 to 7.0 (step = 0.1) on a per cell basis.
AMR_THR_3, AMR_THR_2, AMR_THR_1 Definition of thresholds on a per BSS
basis.
197 / 252
Full-Rate Channel
Adaptation Due to High
Radio Quality
Half-Rate Channel
Adaptation Due to Low
Radio Quality
198 / 252
Transparent
Non-Transparent
BTS
BIE
BIE
BSC
SM
SM
TC
MSC
PSTN
Mobile
Station
ISDN
/Analog
13 kbit/s
CIM
13 kbit/s
: Analog
A/D
: Analog/Digital
BIE
CIM
PSTN
SM
: Submultiplexer
TC
: Transcoder
64 kbit/s
A/D
199 / 252
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.
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 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.
User Rate
Intermediate Rate
Radio Interface
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 20: Circuit-Switched Data Rate Conversions Across the Air Interface
200 / 252
Error Handling
The 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
201 / 252
Broadcast
Message to
Selected
Cell(s)
BTS
HMI
SMSCB
commands
and signaling
BSC
Message
broadcast to all
Mobile Stations
Transmission
Request
SMSCB
commands
and signaling
CBC
Broadcast Message set
up by CBC Operator
CBC
HMI
SMS-CB
202 / 252
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 feature SMS-CB managed from CBC, the following
enhancements are defined in the phase 2+ GSM recommendation:
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 brings also better convenience with the support of multipage
messages.
203 / 252
204 / 252
7 Cell Environments
7 Cell Environments
This chapter describes the cell environments available in the Alcatel 900/1800
BSS. The following cell environments are described:
Overview
Single Cell
Concentric Cell
Sectored Site
Extended Cell
Umbrella Cell
Mini Cell
Microcell.
Indoor cell
205 / 252
7 Cell Environments
7.1 Overview
The Alcatel 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 DCS 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. Two types of frequency partition exist, normal or concentric.
Cell Range. The cell range can be normal or extended.
Cell Band Type. A cell belongs to either the GSM 900 or DCS 1800 bands,
or both in case of a multi-band cell.
Urban Coverage
206 / 252
7 Cell Environments
Inner Zone
Outer Zone
Single Cell
Concentric
Cell
Sectored Site
Umbrella Cell
Microcell
Microcell
Umbrella &
Concentric
Cell
Microcell
Inner Cell Outer
Limit
Microcell
Microcell
Microcell
Extended Cell
Inner Cell
Outer Cell
Overlap Zone
207 / 252
7 Cell Environments
208 / 252
7 Cell Environments
Cell 1
BTS
Cell 2
Sector
2
Cell 3
Sector
3
Antenna
209 / 252
7 Cell Environments
Inner Cell
Highway
Urban Area
70 km
max
Outer Cell
35 km
max
210 / 252
7 Cell Environments
211 / 252
7 Cell Environments
Pedestrian area
Mini Cells
Urban area
212 / 252
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 microcells 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.
This type of handover occurs when 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
This type of handover occurs when 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
Note:
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.
If the low threshold is not used, the M_to_m Threshold value must be above the
high threshold value.
213 / 252
7 Cell Environments
MicroMicro
Handover
High Threshold
d
B
m
M_to_m Threshold
Low Threshold
5
Micro-Micro Handover
(Case 1)
Macro-Micro Handover
(Case 2)
As it moves along a street, the mobile station is handed over from microcell to
microcell (1).
214 / 252
7 Cell Environments
Upper layer
Microcell 1800
Microcell 900
Microcell 1800
Microcell 900
Microcell 1800
Lower layer
Microcell 900
Indoor layer
Figure 74: Indoor cell example network hierarchy with three layers and two bands
215 / 252
7 Cell Environments
216 / 252
7 Cell Environments
Note:
217 / 252
7 Cell Environments
218 / 252
219 / 252
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
Fault Management
Performance Management.
These categories are described later.
220 / 252
OML Auto-detection
Managed Objects
221 / 252
Security Blocks
Configuration
Management
Fault Management
Performance
Management
222 / 252
Fault Management allows the operator to supervise and to repair the network
when anomalies occur. It does this through a sequence of steps from
detection to reporting and recovery. These are carried out by all the BSS/MFS
subsystems, and are reported to the operator at the OMC-R.
Performance Management allows the operator 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 usage in the BSS.
223 / 252
Printer
HMI
Server
Multiple Access
Workstation
X.25 Network
OMCR
Host n
OMCR
Host 1
OMCR
Host 2
HMI
Central Site
Configuration
224 / 252
8.3.2 ACO
Alarm Call Out (ACO) is a process within the HMI server 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 OMCs, applies
filters defined by the on duty operator, sends the filtered results to a dedicated
printer and sends e-mail to support technicians.
ACO can be started and stopped from any OMC-R.
ACO OMCR
Workstation
OMCR 3
Area 3
OMCR 1
Area 1
OMCR 2
Area 2
ACO
225 / 252
BSC A
CMISE
OSI CPRA 1
FTAM BSC A
CMISE
CPRA
FTAM
HSI
OSI
FTAM
OSI CPRA 2
226 / 252
BSC
Primary Link
OSI CPRA 1
0
1
2
OSI CPRA 2
Secondary
Link
HSI
OSI
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.
227 / 252
Small Configurations
228 / 252
BTS
Transcoder
TSC
MFS
229 / 252
230 / 252
Remote Inventory
RF Cable Identification
Consistency Checks
When a new Configuration Data Message is received from the BSC, the BTS
A9100 and the BTS A910 performs a consistency check of its capabilities
against the Configuration Data Message. It also does this at module
initialization due to maintenance operator command or to a Hardware Extension
operation. The BTS A9100 and the BTS A910 also checks 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:
231 / 252
232 / 252
8.4.6 NE Provisioning
Network element provisioning allows equipment that is not yet in commercial
use to be distinguished from equipment that is under maintenance. This is mot
important for network monitoring. The feature introduces the status "commercial
use" that can be associated to 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 coordination with the operators information systems. For the
BTS marked as "not in commercial use", potential alarms are raised with only a
"warning" severity and the performance measurement results are not taken
into account. The BTS marked as "not in commercial use" are not reported
in the topology files sent to the A985-NPA and A956-RNO. They can be also
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, PM cell measurements were running on the BTS, and this
lead to very poor PM results as the BTS was not in commercial service.
An attribute (commercialUse = On or Off) is associated to each BTS. The
attribute can be changed from 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 severity maximum 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, as usual. 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 the BTS that are
marked out of commercial use (except for the PM counters that are relative to
RSL/OML traffic which are not filtered).
233 / 252
234 / 252
BTS
MFS
235 / 252
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 as follows:
1. When several boards in the BTS report clock problems, these reports are
correlated by the OMU.
2. The clock generator is faulty alarm is sent to the OMC-R via the BSC.
Filtering
Alarms are filtered to minimize the number of fault alarms reported and
displayed to the operator. Alarms are displayed in order of severity.
Refer also to the Alarm Handling section of the Operations & Maintenance
Principles document.
Persistency
A fault is signalled only if there is no recovery after the timer expiration. For
example, in the case of an LAPD failure of an RSL link, an alarm is sent only if
the LAPD link has not recovered before the persistency timer has expired.
Alarm Surveillance
Alarms-in-Force List
236 / 252
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 change-over of the SS7
The blocking of circuits.
The TSC supervises its trunks between the Transcoder, BTS, and MSC.
Failure of the Abis interface is signalled 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.
237 / 252
Fault Start
CPR Informed
RSL1
Persistency
Correlation
ACTIVE
INACTIVE
Fault Start
RSL2
Fault Start
RSLN (last RSL)
CPR
: Common Processor
RSL
238 / 252
A Interface Fault
Monitoring
Note:
Failures Detected by
Software
When the BSC detects a DTC failure, the BSC puts the DTC SBL in the
MSD-Auto state, then into the FLT state. Through the TS0 signalling, the MSC
is informed that the trunk is no longer operational and prevents all transactions
requiring the A channel (includes new mobile station-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.
The A channel is allocated only by the MSC.
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.
239 / 252
OMU Function
Alarm
OMU Function
240 / 252
Alarm Collection
241 / 252
242 / 252
Note:
In the BTS A9100 or the BTS A910, the SBLs FU and Carrier Unit have been
merged into one indivisible SBL, called the TRE. At the BSC, however, all BTS
A9100 and BTS A910 TRE faults are mapped to the Carrier Unit to provide
compatibility with G1 and G2 BTSs. Thus, 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 BTSs continue to be reported as such.
Fault Recovery
Mechanism
243 / 252
BSC
BTS
CU Fault
BTS_TEL=IT
Resources
blocked, BCCH
reconfiguration
possible
Alarm
ss
(cell, lo
in)
H beg
of BCC
req
Reco_
BTS_TEL=FIT
4
BTS_CO
NF_DAT
A (2)
BTS_TEL=FIT
SYS_INF
8
nd)
ll, loss
O (1..6)
CCH e
ss of B
(ce
Alarm
5
BTS performs the reconfiguration
L
COMP
ONF_
BTS_C
ell, lo
larm (c
OS)
(CU, F
of TCH
begin)
BTS_TEL=FIT
BCCH
CU
: Carrier Unit
TCH
: Traffic Channel
Note:
244 / 252
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.
Power-Down Alarm
Processing
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 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 on this feature, refer to the following:
Note:
For performance reasons, each alerter type has a maximum limit of 16 alarms.
For further information concerning BSC Alerters, refer to the BSC Alerters
section of the Operations & Maintenance Principles document.
245 / 252
MFS
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 on trace management, refer to the Trace Management
section of the Operations & Maintenance Principles document.
246 / 252
247 / 252
248 / 252
249 / 252
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.
More information on Audits can be found as follows:
Configuration Management Audits in the Configuration Management
Audits/Resynchronization section of the Operations & Maintenance
Principles document.
Fault Management Audits in the Fault Management Audits section of the
Operations & Maintenance Principles document..
Using the IMT, it is possible to perform a radio re-initialization, or a radio
resynchronization of the MFS.
Audit Types
Description
Logical Audit
Software Version
Audit
Hardware Audit
Alarm Audit
State Audit
250 / 252
Audit Flow
251 / 252
252 / 252