Radio Network Management

GSM/EDGE RAN - BR line
Functional area description

Base station controller
Radio network management

A50016-G5100-B556-04-7620
The information in this document is subject to change without notice and describes only the
product defined in the introduction of this documentation. This documentation is intended for the
use of Nokia Siemens Networks customers only for the purposes of the agreement under which
the document is submitted, and no part of it may be used, reproduced, modified or transmitted
in any form or means without the prior written permission of Nokia Siemens Networks. The
documentation has been prepared to be used by professional and properly trained personnel,
and the customer assumes full responsibility when using it. Nokia Siemens Networks welcomes
customer comments as part of the process of continuous development and improvement of the
documentation.
The information or statements given in this documentation concerning the suitability, capacity,
or performance of the mentioned hardware or software products are given "as is" and all liability
arising in connection with such hardware or software products shall be defined conclusively and
finally in a separate agreement between Nokia Siemens Networks and the customer. However,
Nokia Siemens Networks has made all reasonable efforts to ensure that the instructions
contained in the document are adequate and free of material errors and omissions. Nokia
Siemens Networks will, if deemed necessary by Nokia Siemens Networks, explain issues which
may not be covered by the document.
Nokia Siemens Networks will correct errors in this documentation as soon as possible. IN NO
EVENT WILL Nokia Siemens Networks BE LIABLE FOR ERRORS IN THIS DOCUMENTA-
TION OR FOR ANY DAMAGES, INCLUDING BUT NOT LIMITED TO SPECIAL, DIRECT, INDI-
RECT, INCIDENTAL OR CONSEQUENTIAL OR ANY LOSSES, SUCH AS BUT NOT LIMITED
TO LOSS OF PROFIT, REVENUE, BUSINESS INTERRUPTION, BUSINESS OPPORTUNITY
OR DATA,THAT MAY ARISE FROM THE USE OF THIS DOCUMENT OR THE INFORMATION
IN IT.
This documentation and the product it describes are considered protected by copyrights and
other intellectual property rights according to the applicable laws.
The wave logo is a trademark of Nokia Siemens Networks Oy. Nokia is a registered trademark
of Nokia Corporation. Siemens is a registered trademark of Siemens AG.
Other product names mentioned in this document may be trademarks of their respective
owners, and they are mentioned for identification purposes only.
Copyright © Nokia Siemens Networks 2009. All rights reserved
f Important Notice on Product Safety

Elevated voltages are inevitably present at specific points in this electrical equipment.
Some of the parts may also have elevated operating temperatures.
Non-observance of these conditions and the safety instructions can result in personal
injury or in property damage.
Therefore, only trained and qualified personnel may install and maintain the system.
The system complies with the standard EN 60950 / IEC 60950. All equipment connected
has to comply with the applicable safety standards.
The same text in German:

Wichtiger Hinweis zur Produktsicherheit
In elektrischen Anlagen stehen zwangsläufig bestimmte Teile der Geräte unter Span-
nung. Einige Teile können auch eine hohe Betriebstemperatur aufweisen.
Eine Nichtbeachtung dieser Situation und der Warnungshinweise kann zu Körperverlet-
zungen und Sachschäden führen.
Deshalb wird vorausgesetzt, dass nur geschultes und qualifiziertes Personal die
Anlagen installiert und wartet.
Das System entspricht den Anforderungen der EN 60950 / IEC 60950. Angeschlossene
Geräte müssen die zutreffenden Sicherheitsbestimmungen erfüllen.
2 Id:0900d80580539dd9 A50016-G5100-B556-04-7620
Table of contents
This document has 456 pages.
Reason for update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1 Introduction to functional area descriptions . . . . . . . . . . . . . . . . . . . . . . 17

1.1 Functional area descriptions and related operating instructions . . . . . . 17
1.2 Scope and content of the functional area descriptions . . . . . . . . . . . . . 18
1.3 Symbols used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2 Overview: Radio network management . . . . . . . . . . . . . . . . . . . . . . . . . 20
3 Cells, frequency bands and transceivers . . . . . . . . . . . . . . . . . . . . . . . . 24

3.1 Cells and their addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Cell types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.4 Hierarchical cell structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5 Frequency bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6 Creation of a new cell and transceiver configuration . . . . . . . . . . . . . . . 36
3.7 TRX mode of operation (support of EGPRS or not). . . . . . . . . . . . . . . . 40
3.8 Enabling GPRS/EGPRS services on BSC and cell level. . . . . . . . . . . . 43
3.9 Adjacent cells. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.9.1 Adjacencies within a pure GSM network . . . . . . . . . . . . . . . . . . . . . . . . 45
3.9.1.1 Separate BCCH allocation lists for idle and active state . . . . . . . . . . . . 47
3.9.2 Adjacencies to UMTS cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.10 Barring a cell and barring access classes . . . . . . . . . . . . . . . . . . . . . . . 50
3.11 Sleeping cell and TRX detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4 Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Physical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 GSM logical channels and channel combinations . . . . . . . . . . . . . . . . . 56
4.2.1 Logical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
4.2.2 Channel combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2.3 Combined channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3 GPRS logical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4 Creation and configuration of radio channels . . . . . . . . . . . . . . . . . . . . 63
4.4.1 Configuring channels for (E)GPRS usage . . . . . . . . . . . . . . . . . . . . . . . 65
4.4.2 Multiframe configuration for PBCCH/PCCCH . . . . . . . . . . . . . . . . . . . . 67
5 Coding and transmission modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.1 GSM channel coding for speech, data and signalling channels . . . . . . 69
5.2 14.4 kbit/s data transmission on a single timeslot . . . . . . . . . . . . . . . . . 73
5.3 HSCSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4 Adaptive multi-rate coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4.1 Link adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.4.2 Configurations for narrowband AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.4.3 Configurations for wideband AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.4.4 Call setup with wideband AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.5 Tandem free operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.6 Ciphering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
A50016-G5100-B556-04-7620 Id:0900d80580539dd9 3
5.7 Discontinuous transmission and comfort noise insertion . . . . . . . . . . . . 92

5.8 GPRS channel coding. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.9 EGPRS channel coding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.10 Initial coding scheme for GPRS and EGPRS . . . . . . . . . . . . . . . . . . . . . 99
5.11 Link adaptation for GPRS and EGPRS. . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.11.1 Link adaptation enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.12 Temporary Block Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.12.1 Simultaneous data transfers for different (E)GPRS services . . . . . . . . 108
5.13 Uplink incremental redundancy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.14 Radio resource operating modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
5.15 Dual transfer mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6 Frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

6.1 Static MAIO allocation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.2 Dynamic MAIO allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
6.3 Configuring frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.1 ASCI services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.1.1 Voice group call service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.1.2 Voice broadcast service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
7.1.3 Release of ASCI VBS and VGCS channels . . . . . . . . . . . . . . . . . . . . . 134
7.1.4 CS data transmission during active voice group call . . . . . . . . . . . . . . 136
7.1.5 Reactivation of VGCS/VBS channels after service unavailability . . . . . 140
7.2 Location services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
7.2.1 Response timer for location services . . . . . . . . . . . . . . . . . . . . . . . . . . 150
7.3 Wireless priority service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
7.4 SMS cell broadcast service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
7.5 Service layer lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
8 Signalling and call establishment/release . . . . . . . . . . . . . . . . . . . . . . . 160

8.1 GSM connection establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
8.1.1 Mobile initiated call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
8.1.2 Mobile terminated call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
8.1.3 Discrimination of valid and invalid access bursts on RACH . . . . . . . . . 162
8.1.4 Acknowledgement control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
8.1.5 Retransmission of RACH messages. . . . . . . . . . . . . . . . . . . . . . . . . . . 165
8.2 Paging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
8.2.1 Hierarchical paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
8.2.2 Intelligent selective paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
8.2.3 Paging tasks and capacity of the BSC . . . . . . . . . . . . . . . . . . . . . . . . . 171
8.2.4 Paging blocks on CCCH and interplay between PCH and AGCH . . . . 175
8.2.5 (E)GPRS network mode of operation for paging . . . . . . . . . . . . . . . . . 179
8.3 Immediate downlink repetition of FACCH messages . . . . . . . . . . . . . . 180
8.4 Repetition and modified scheduling of SACCH messages . . . . . . . . . . 183
8.4.1 Modified scheduling of messages on SACCH . . . . . . . . . . . . . . . . . . . 183
8.4.2 Repetition of SACCH blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
8.4.3 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
8.5 GSM call release. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
4 Id:0900d80580539dd9 A50016-G5100-B556-04-7620
8.5.1 Radio link timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

8.5.2 Channel release in case of MS inactivity . . . . . . . . . . . . . . . . . . . . . . . 193
8.6 Call re-establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
8.7 CCCH and PCCCH for GPRS/EGPRS signalling . . . . . . . . . . . . . . . . 194
8.8 GPRS TBF establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
8.8.1 MS initiated TBF establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
8.8.1.1 Channel requests and access bursts with 8 or 11 information bits . . . 199
8.8.2 Network initiated TBF establishment . . . . . . . . . . . . . . . . . . . . . . . . . . 201
8.9 Messaging for TBF control. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
8.10 GPRS call release . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
8.11 Extended uplink Temporary Block Flow. . . . . . . . . . . . . . . . . . . . . . . . 208
8.12 Establishment of dual transfer mode . . . . . . . . . . . . . . . . . . . . . . . . . . 210
8.13 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
8.14 Classmark information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
9 Radio channel allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

9.1 Allocation due to radio channel quality . . . . . . . . . . . . . . . . . . . . . . . . 216
9.2 Layer and service oriented channel allocation. . . . . . . . . . . . . . . . . . . 217
9.2.1 Special priority rules. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
9.2.2 Direct TCH assignment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
9.3 Strategies for handling congestion situations . . . . . . . . . . . . . . . . . . . 221
9.3.1 Preemption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
9.3.2 Directed retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
9.3.3 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225
9.3.4 Downgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
9.3.5 Preemption and priority concept for packet switched calls . . . . . . . . . 228
9.3.6 Enhanced pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
9.3.7 Cell load dependent activation of half rate TCHs. . . . . . . . . . . . . . . . . 231
9.4 Request management, resource re-allocation and waiting list management
233
9.4.1 Request manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
9.4.2 Resource re-allocator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
9.4.3 Waiting list manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
9.5 DMA admission control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
10 GPRS radio channel management . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

10.1 Horizontal and vertical allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
10.1.1 Vertical allocation (VA). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
10.1.2 Horizontal allocation (HA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
10.1.3 Switching between vertical and horizontal allocation. . . . . . . . . . . . . . 245
10.2 Dual carrier in downlink direction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
10.3 (E)GPRS radio resource allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
10.3.1 Admission control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
10.3.2 Channel allocation algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
10.3.3 Background: Interplay between PCU and TDPC . . . . . . . . . . . . . . . . . 258
10.3.4 TBF scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
10.3.5 Mobile Station overheating management . . . . . . . . . . . . . . . . . . . . . . 261
10.3.6 Upgrade of radio resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
A50016-G5100-B556-04-7620 Id:0900d80580539dd9 5
10.3.7 Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

10.4 Control of the number of timeslots in case of peak throughput based chan-
nel allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
10.4.1 Improved downlink resources allocation . . . . . . . . . . . . . . . . . . . . . . . . 267
10.4.2 Uplink balancing/unbalancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
11 GSM power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

11.1 Basic functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
11.2 Functional sequence of the power control procedure . . . . . . . . . . . . . . 274
11.3 Classic power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
11.4 Adaptive power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
11.5 Attributes and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
11.6 Delayed power control for emergency calls . . . . . . . . . . . . . . . . . . . . . 288
11.7 Temporary overpower. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
11.8 Derived handover power management. . . . . . . . . . . . . . . . . . . . . . . . . 290
11.9 (E)GPRS power control (complement to GSM power control) . . . . . . . 293
12 Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
12.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
12.1.1 General procedure and overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
12.1.2 Classification of handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
12.1.3 Attributes enabling/disabling handover types . . . . . . . . . . . . . . . . . . . . 299
12.2 Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
12.3 Measurement preprocessing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304
12.4 Handover indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307
12.4.1 Extended cell handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
12.4.2 Concentric cell handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309
12.4.2.1 Inter-cell handover into a concentric cell. . . . . . . . . . . . . . . . . . . . . . . . 311
12.4.3 Quality and level handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
12.4.3.1 Quality handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
12.4.3.2 Level handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
12.4.4 Distance handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
12.4.5 Power budget handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
12.4.6 DTM power budget handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
12.4.7 Speed sensitive power budget handover . . . . . . . . . . . . . . . . . . . . . . . 321
12.4.8 Fast uplink handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
12.4.9 Forced handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323
12.4.10 Traffic handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
12.4.11 Compression/decompression handover . . . . . . . . . . . . . . . . . . . . . . . . 325
12.4.11.1 Attributes and configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327
12.4.12 Handovers between AMR-wideband and AMR-narrowband . . . . . . . . 334
12.5 Service dependent handover configuration . . . . . . . . . . . . . . . . . . . . . 337
12.6 Generation of the target cell list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
12.6.1 Sorting the target cell list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
12.7 Handover execution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
12.8 Handover prevention procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
12.9 Call release due to excessive distance. . . . . . . . . . . . . . . . . . . . . . . . . 357
12.10 GSM-UMTS intersystem handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
6 Id:0900d80580539dd9 A50016-G5100-B556-04-7620
12.10.1 Handover from GSM to UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

12.10.1.1 Attributes and configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362
12.10.2 Handover from UMTS to GSM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
13 Cell changing and cell reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

13.1 Criteria for cell selection and cell reselection. . . . . . . . . . . . . . . . . . . . 370
13.1.1 C1 criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
13.1.2 C2 criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
13.1.3 C31 criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
13.1.4 C32 criterion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374
13.2 Network assisted cell change (NACC). . . . . . . . . . . . . . . . . . . . . . . . . 375
13.3 External network assisted cell change (ENACC). . . . . . . . . . . . . . . . . 378
13.4 Network controlled cell reselection (NCCR). . . . . . . . . . . . . . . . . . . . . 378
13.5 GSM-UMTS cell reselection. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383
13.6 Network controlled reselection from GSM/GPRS to UMTS due to sufficient
UMTS coverage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386
14 Special radio network features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

14.1 Multi-Operator BSS – 2G network sharing. . . . . . . . . . . . . . . . . . . . . . 388
14.2 IMSI based handover. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
14.2.1 Adressing subscribers and PLMNs . . . . . . . . . . . . . . . . . . . . . . . . . . . 394
14.2.2 Management of subscriber groups and authorized networks lists . . . . 395
14.2.3 Information flow between network elements and MS . . . . . . . . . . . . . 397
14.2.4 Managed objects and parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402
14.3 TRX reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404
14.3.1 TRX reconfiguration in case a redundant TRX is available . . . . . . . . . 404
14.3.2 BCCH recovery in case no redundant TRX is available . . . . . . . . . . . 404
14.3.3 TRX reconfiguration in concentric cells (no redundant TRX). . . . . . . . 406
14.4 BSS overload control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
14.5 Antenna hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 410
15 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
15.1 Handover parameters overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 412
15.2 Power control parameters overview. . . . . . . . . . . . . . . . . . . . . . . . . . . 415
15.3 Functional object tree for radio network configuration . . . . . . . . . . . . . 416
15.4 Signalling for call processing on radio area and Abis area . . . . . . . . . 416
15.5 Example for SACCH messaging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 418
15.6 Protocol view on the GSM radio network. . . . . . . . . . . . . . . . . . . . . . . 419
15.6.1 Messages for radio resource management . . . . . . . . . . . . . . . . . . . . . 420
15.6.1.1 System information messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
15.6.1.2 Other selected messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
15.6.2 LAPDm messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
15.6.3 Messages for mobility management . . . . . . . . . . . . . . . . . . . . . . . . . . 430
15.7 Protocol view on GPRS and packet data/message flow . . . . . . . . . . . 433
15.8 RLC/MAC data blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
15.9 Mobile station power classes and power control levels . . . . . . . . . . . . 438
15.10 Frequency/channel conversion table . . . . . . . . . . . . . . . . . . . . . . . . . . 439
15.10.1 GSM 850-900 table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
15.10.2 GSM 1800 table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
A50016-G5100-B556-04-7620 Id:0900d80580539dd9 7
15.10.3 GSM 1900 table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
8 Id:0900d80580539dd9 A50016-G5100-B556-04-7620
List of figures
Figure 1 Symbols used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figure 2 GSM/EDGE RAN architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Figure 3 Integration of the radio access network with the core network . . . . . . . 21
Figure 4 Configuration with LMT, RC and OTS . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Figure 5 Omnicells and sector cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 6 3-cell sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Figure 7 Extended cell areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figure 8 Concentric cell areas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Figure 9 Shifting frame numbers at BTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Figure 10 Example for a network with hierarchical cell structure . . . . . . . . . . . . . . 32
Figure 11 GSM frequencies in the 850/900 MHz range. . . . . . . . . . . . . . . . . . . . . 33
Figure 12 GSM 900 frequency bands and ARFCNs . . . . . . . . . . . . . . . . . . . . . . . 34
Figure 13 GSM 900 extended band frequencies and ARFCNs . . . . . . . . . . . . . . . 34
Figure 14 GSM 1800 frequency bands and ARFCNs . . . . . . . . . . . . . . . . . . . . . . 35
Figure 15 Managed objects and parameters for cell and TRX configuration . . . . . 37
Figure 16 Reconfiguration of CU-to-TRX assignment . . . . . . . . . . . . . . . . . . . . . . 42
Figure 17 Managed objects and parameters for (E)GPRS configuration. . . . . . . . 44
Figure 18 TGTCELL attribute. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Figure 19 Illustration of adjacent cell administration . . . . . . . . . . . . . . . . . . . . . . . 47
Figure 20 Sleeping cell and TRX detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Figure 21 TDMA frame structure and radio channels . . . . . . . . . . . . . . . . . . . . . . 53
Figure 22 Radio blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Figure 23 Multiframes for GSM traffic with 26 TDMA frames. . . . . . . . . . . . . . . . . 54
Figure 24 Multiframe for GSM signalling with 51 TDMA frames . . . . . . . . . . . . . . 55
Figure 25 Multiframe for PS services with 52 TDMA frames . . . . . . . . . . . . . . . . . 55
Figure 26 Example configuration of control channels . . . . . . . . . . . . . . . . . . . . . . 58
Figure 27 Combined configuration of control channels . . . . . . . . . . . . . . . . . . . . . 59
Figure 28 Example of timeslot configuration and pool assignments . . . . . . . . . . . 60
Figure 29 Example of channel configuration in a concentric cell . . . . . . . . . . . . . . 64
Figure 30 Example of channel configuration in an extended cell. . . . . . . . . . . . . . 65
Figure 31 Example of channel configuration including PBCCH and PCCCH . . . . 65
Figure 32 Example for a PBCCH multiframe configuration . . . . . . . . . . . . . . . . . . 68
Figure 33 Net and gross data transmission rate for GSM full rate speech . . . . . . 69
Figure 34 Data frames and block types for full rate speech. . . . . . . . . . . . . . . . . . 70
Figure 35 Channel coding for full rate speech TCHs . . . . . . . . . . . . . . . . . . . . . . . 71
Figure 36 AMR principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Figure 37 Frequency spectrum of wideband AMR. . . . . . . . . . . . . . . . . . . . . . . . . 77
Figure 38 MultiRate configuration IE for a set of 4 codec modes . . . . . . . . . . . . . 78
Figure 39 Link adaptation thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Figure 40 Example for signalling for an AMR wideband codec downgrade. . . . . . 81
Figure 41 Signal path for an MS-MS connection . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Figure 42 Embedding of ciphering between coding and modulation . . . . . . . . . . . 89
Figure 43 Ciphering with Kc and A5/1 (simplified) . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figure 44 Discontinuous transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Figure 45 GPRS coding process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
A50016-G5100-B556-04-7620 Id:0900d80580539dd9 9
Figure 46 RLC/MAC block coding for CS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Figure 47 GMSK modulation and 8-PSK modulation . . . . . . . . . . . . . . . . . . . . . . . 97
Figure 48 EGPRS coding schemes and families . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Figure 49 Simulated throughputs depending on coding schemes and C/I (dB) . . 100
Figure 50 Simulated throughputs depending on MCSs for family A (+ MCS1) and C/I
(dB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Figure 51 BLER as function of C/I (dB) for the GPRS coding schemes . . . . . . . . 102
Figure 52 Multiplexing MSs on the same PDCH (downlink) . . . . . . . . . . . . . . . . . 107
Figure 53 Multiplexing MSs on the same PDCH (uplink) . . . . . . . . . . . . . . . . . . . 108
Figure 54 Scheduling several PFCs for one TBF . . . . . . . . . . . . . . . . . . . . . . . . . 109
Figure 55 Multiple Temporary Block Flow (mTBF) . . . . . . . . . . . . . . . . . . . . . . . . 110
Figure 56 RR operation modes (including dual transfer mode) and transitions . . 113
Figure 57 Baseband frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
Figure 58 Synthesizer frequency hopping. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Figure 59 Channel description information element . . . . . . . . . . . . . . . . . . . . . . . 119
Figure 60 Cell channel description IE and mobile allocation IE (example) . . . . . . 120
Figure 61 Example for static MAIO allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Figure 62 Managed objects and parameters for frequency hopping. . . . . . . . . . . 125
Figure 63 Voice group call service in a group call area . . . . . . . . . . . . . . . . . . . . 129
Figure 64 1.0 and 1.5 channel mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Figure 65 Message flow for listener’s data transmission during active VGCS call 138
Figure 66 ASCI call re-establishment after failure of the VGCS/VBS channel . . . 143
Figure 67 Network architecture for location services . . . . . . . . . . . . . . . . . . . . . . 148
Figure 68 NSS centric architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Figure 69 BSS centric architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Figure 70 WPS queues and public queues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Figure 71 SMS cell broadcast service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Figure 72 Message flow for SMS cell broadcast service . . . . . . . . . . . . . . . . . . . 155
Figure 73 Messaging during call setup (MS originated) . . . . . . . . . . . . . . . . . . . . 161
Figure 74 Retransmission of unsuccessful channel request on RACH. . . . . . . . . 167
Figure 75 Paging messages within mobile terminated call setup . . . . . . . . . . . . . 168
Figure 76 Hierarchical paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Figure 77 Principle of basic BSC queuing and distribution for pagings . . . . . . . . 172
Figure 78 Example for CCCH resource sharing between PCH and AGCH . . . . . 176
Figure 79 Example for scheduling of AGCH and PCH requests. . . . . . . . . . . . . . 177
Figure 80 FACCH block repetition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
Figure 81 Scheduling of SI and MI messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Figure 82 Downlink SACCH block repetition and related SACCH block decoding 188
Figure 83 SACCH block repetition and re-scheduling in case of SI messages . . 189
Figure 84 GPRS signalling message flow in the BSC1. . . . . . . . . . . . . . . . . . . . . 195
Figure 85 MS initiated TBF establishment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Figure 86 11 information bits access burst coding . . . . . . . . . . . . . . . . . . . . . . . . 200
Figure 87 Network initiated TBF establishment . . . . . . . . . . . . . . . . . . . . . . . . . . 201
Figure 88 Uplink TBF control (RLC acknowledged mode) . . . . . . . . . . . . . . . . . . 204
Figure 89 DTM establishment from dedicated mode with TCH reassignment . . . 211
Figure 90 Components for authentication and ciphering . . . . . . . . . . . . . . . . . . . 213
Figure 91 Message flow for authentication within the location registration procedure
10 Id:0900d80580539dd9 A50016-G5100-B556-04-7620
214
Figure 92 Example for resource allocation with service layer lists. . . . . . . . . . . . 218
Figure 93 Preemption procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Figure 94 Example for enhanced pairing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Figure 95 Algorithm for the cell load dependent activation of HR channels. . . . . 232
Figure 96 Management of 1 timeslot TCH requests . . . . . . . . . . . . . . . . . . . . . . 235
Figure 97 Management of multislot TCH requests. . . . . . . . . . . . . . . . . . . . . . . . 236
Figure 98 Capacity of GPRS PDCHs/timeslots . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Figure 99 Example of vertical allocation strategy. . . . . . . . . . . . . . . . . . . . . . . . . 244
Figure 100 Example of the horizontal allocation algorithm . . . . . . . . . . . . . . . . . . 245
Figure 101 Example of a cell configured with five TRXs . . . . . . . . . . . . . . . . . . . . 246
Figure 102 Dual carrier allocation in downlink direction (example) . . . . . . . . . . . . 249
Figure 103 Radio resource management entities and interplay with scheduler. . . 251
Figure 104 Flow diagram of the second part of the channel allocation algorithm . 257
Figure 105 PCU – TDPC interplay in case of PDCH allocation (simplified example) .
259
Figure 106 Example for TBF scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Figure 107 Improved downlink resources allocation . . . . . . . . . . . . . . . . . . . . . . . 268
Figure 108 Power control loop for MS power control and BTS power control . . . . 271
Figure 109 Flexible power control steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Figure 110 Progress of MS power control in time . . . . . . . . . . . . . . . . . . . . . . . . . 275
Figure 111 Classic power control decisions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
Figure 112 Adaptive power control decisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Figure 113 Relations between power control and handover threshold parameter val-
ues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Figure 114 Message flow for derived handover power management . . . . . . . . . . 291
Figure 115 Overview of the handover process . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
Figure 116 Handover categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Figure 117 Averaging RXLEV measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Figure 118 Single and double timeslots in an extended cell . . . . . . . . . . . . . . . . . 308
Figure 119 Inner-to-inner-area handover between colocated concentric cells . . . 311
Figure 120 Overview: quality and level handover . . . . . . . . . . . . . . . . . . . . . . . . . 313
Figure 121 “Better cell” with respect to power budget considerations . . . . . . . . . . 319
Figure 122 Handover margin for speed sensitive power budget handover . . . . . . 321
Figure 123 Traffic handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
Figure 124 Thresholds defining cell borders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Figure 125 Intra-cell handover messaging. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Figure 126 Inter-cell, inter-BSC handover messaging . . . . . . . . . . . . . . . . . . . . . . 350
Figure 127 Prevention of back handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354
Figure 128 Prevention of handover failure repetition . . . . . . . . . . . . . . . . . . . . . . . 355
Figure 129 Limitation of intra-cell handover repetition . . . . . . . . . . . . . . . . . . . . . . 356
Figure 130 Example for excessive distance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357
Figure 131 UMTS/GSM network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Figure 132 Handover from GSM to UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Figure 133 C2 graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Figure 134 Message flow for network assisted cell change. . . . . . . . . . . . . . . . . . 376
Figure 135 Message flow for network controlled cell reselection. . . . . . . . . . . . . . 381
A50016-G5100-B556-04-7620 Id:0900d80580539dd9 11
Figure 136 Cell reselection from GSM to UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . 384

Figure 137 Principle of radio access network sharing. . . . . . . . . . . . . . . . . . . . . . . 389
Figure 138 Example of radio access network sharing in the CS domain . . . . . . . . 390
Figure 139 Example of radio access network sharing in the PS domain . . . . . . . . 391
Figure 140 IMSI based handover in a shared network (example) . . . . . . . . . . . . . 396
Figure 141 Message flow related to “IMSI based handover” during a handover . . 399
Figure 142 Message flow related to “IMSI based handover” during call establishment
400
Figure 143 BCCH recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Figure 144 TRX reconfiguration in concentric cells. . . . . . . . . . . . . . . . . . . . . . . . . 407
Figure 145 Intercell handover parameters, part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . 412
Figure 146 Intercell handover parameters, part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . 413
Figure 147 Intracell handover parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
Figure 148 Power control parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Figure 149 Functional object tree for radio network configuration . . . . . . . . . . . . . 416
Figure 150 LAPD signalling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 417
Figure 151 Example for uplink SACCH messaging . . . . . . . . . . . . . . . . . . . . . . . . 418
Figure 152 GSM protocol structure for the radio access network . . . . . . . . . . . . . . 419
Figure 153 Channel description information element . . . . . . . . . . . . . . . . . . . . . . . 425
Figure 154 GPRS protocol structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Figure 155 GPRS data container units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
Figure 156 Downlink RCL/MAC data block (example) . . . . . . . . . . . . . . . . . . . . . . 435
Figure 157 Uplink RCL/MAC data block (example) . . . . . . . . . . . . . . . . . . . . . . . . 436
12 Id:0900d80580539dd9 A50016-G5100-B556-04-7620
List of tables
Table 1 Example for a priority configuration in a hierarchical cell structure . . . . 31
Table 2 GSM frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Table 3 Selection of frequency bands by the SYSID attribute . . . . . . . . . . . . . . 35
Table 4 Correspondence between NETWTYPE values and SYSID values . . . 36
Table 5 Combinations of TRXMD and TRX CAPABILITY values . . . . . . . . . . . 41
Table 6 GSM logical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Table 7 GPRS logical channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Table 8 Setting channel combinations with the CHTYPE attribute . . . . . . . . . . 64
Table 9 Capacity gain vs. half rate penetration . . . . . . . . . . . . . . . . . . . . . . . . . 72
Table 10 Characteristics of channel coding for data TCHs . . . . . . . . . . . . . . . . . 72
Table 11 Characteristics of channel coding for signalling channels . . . . . . . . . . 73
Table 12 AMR codecs and source codec bit rates . . . . . . . . . . . . . . . . . . . . . . . 77
Table 13 Codecs supported by different BTS families . . . . . . . . . . . . . . . . . . . . . 79
Table 14 Parameters for configuration of the Active Codec Set . . . . . . . . . . . . . 83
Table 15 Threshold parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Table 16 Link adaptation parameters for wideband AMR . . . . . . . . . . . . . . . . . . 85
Table 17 GPRS coding schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Table 18 EGPRS coding schemes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Table 19 Families of EGPRS modulation and coding schemes . . . . . . . . . . . . . 98
Table 20 Simulation results for CS switching points . . . . . . . . . . . . . . . . . . . . . 102
Table 21 Typical S/N frequency hopping gain in dB for different terrains . . . . . 116
Table 22 Parameters for enhanced pushed-to-talk . . . . . . . . . . . . . . . . . . . . . . 140
Table 23 Parameters for ASCI: reactivation of VGCS/VBS channels . . . . . . . . 146
Table 24 Attributes for the LCS response timer . . . . . . . . . . . . . . . . . . . . . . . . . 150
Table 25 Mapping of WPS priority levels and eMLPP priority levels to 3GPP/GSM
priority and queuing allowed levels . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Table 26 Service types and associated service layer lists . . . . . . . . . . . . . . . . . 157
Table 27 Mapping of NSLOTST to RACH timeslot number Nr . . . . . . . . . . . . . 167
Table 28 Mapping of RACH timeslot numbers Nr and Nd . . . . . . . . . . . . . . . . . 167
Table 29 Maximum rate: paging delivery rates and queue capacity . . . . . . . . . 173
Table 30 Medium 1 rate: paging delivery rates and queue capacity . . . . . . . . . 173
Table 31 Medium 2 rate: paging delivery rates and queue capacity . . . . . . . . . 173
Table 32 Normal rate: paging delivery rates and queue capacity . . . . . . . . . . . 174
Table 33 Maximum paging capacity of a BTS (messages per hour) . . . . . . . . . 175
Table 34 Paging channels used for PS and CS pagings . . . . . . . . . . . . . . . . . . 179
Table 35 Parameters for repeated SACCH and modified scheduling of SACCH
messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Table 36 Audit timer thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Table 37 Soft blocking decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Table 38 Transfer delays for selected BLER values and numbers of timeslots . 252
Table 39 Example of MS multislot class mask . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Table 40 Example of MS configuration list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Table 41 Minimum transmission rates for selected TBF weights . . . . . . . . . . . . 256
Table 42 Mapping of multislot classes 30-33 to lower classes . . . . . . . . . . . . . 263
Table 43 Scheduling: relations between priorities and weights . . . . . . . . . . . . . 265
Table 44 Mapping between RXQUAL and C/I values . . . . . . . . . . . . . . . . . . . . 272
A50016-G5100-B556-04-7620 Id:0900d80580539dd9 13
Table 45 Power control threshold attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Table 46 Time progression of measurement results, power control decisions and
power change results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Table 47 Service groups for power control purpose . . . . . . . . . . . . . . . . . . . . . . 285
Table 48 BTS power control correction: PWRC flag for AMR/non-AMR calls . . 288
Table 49 Handover types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Table 50 Handover priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
Table 51 Attributes enabling/disabling the handover types . . . . . . . . . . . . . . . . 300
Table 52 Example for PLMNP usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 302
Table 53 RXLEV mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Table 54 RXQUAL mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Table 55 Minimum number of samples dependent on the averaging period . . . 306
Table 56 Main criteria for handover indication . . . . . . . . . . . . . . . . . . . . . . . . . . 307
Table 57 Compression/decompression parameters overview . . . . . . . . . . . . . . 328
Table 58 Common and not-AMR related compression/decompression parameters
330
332
Table 60 Compression/decompression parameters related to wideband AMR . 333
Table 61 Parameters related to handovers between wideband and narrowband
AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Table 62 Service groups for handover purpose . . . . . . . . . . . . . . . . . . . . . . . . . 337
Table 63 Parameters for 2G radio access network sharing . . . . . . . . . . . . . . . . 392
Table 64 Authorized networks lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Table 65 Subscriber groups list . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
Table 66 Service groups and related authorized networks lists in a shared network
(example) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397
Table 67 Neigbour cells information in SI and MI messages for IMSI based
handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
Table 68 Parameters for IMSI based handover . . . . . . . . . . . . . . . . . . . . . . . . . 402
Table 69 Messages for radio resource management . . . . . . . . . . . . . . . . . . . . . 420
Table 70 Messages for mobility management . . . . . . . . . . . . . . . . . . . . . . . . . . 431
Table 71 Mobile station power classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Table 72 Power control levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
Table 73 Frequency/channel conversion table . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Table 74 GSM table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Table 75 DCS table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
Table 76 PCS table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
14 Id:0900d80580539dd9 A50016-G5100-B556-04-7620
Radio network management Reason for update
Reason for update

Issue history
Issue Date Summary

01 07/2008 First issue of this document
02 11/2008 Editorial changes and corrections
03 03/2009 Editorial changes and corrections
04 07/2009 Update, editorial changes and corrections
Details
Multi-operator BSS – 2G network sharing added.
Dual carrier in downlink direction added.
IMSI based handover added.
Security improvements for A5/1 ciphering added.
Changes related to interworking with 3G cells optimized for high speed packet services
added (no handover of CS calls to such cells, forced reselection to such cells).
A50016-G5100-B556-04-7620 Id:0900d8058052ced7 15
Reason for update Radio network management
16 Id:0900d8058052ced7 A50016-G5100-B556-04-7620
Radio network management Introduction to functional area descriptions
1 Introduction to functional area descriptions

g This document is prepared as a standard edition that may include descriptions not
applying to your system.
This chapter provides an overview of the functional area descriptions, of which the
present manual forms part.
1.1 Functional area descriptions and related operating

instructions
Functional area descriptions contain background information about the functional areas
of the product or system. They describe features or feature groups and provide
examples of configurations.
The related operating instructions provide the command sequences required to operate
the functional areas.
Functional area descriptions cover the following topics:
• RAN dimensioning guideline
• Air interface dimensioning
• SDCCH dimensioning
• Gb interface dimensioning
• Network configuration
• Equipment configuration
• Transmission & transport network management
• Radio network management
• Administration with the BSC
• Fault and test management
• Performance management
• Trace management
They provide links to the corresponding operating instructions and to reference docu-
ments such as “eBSC Commands”.
The related operating instructions are:
• Master procedures
• Configuring equipment
• Configuring the transport network
• Configuring the radio network
• Administering with the BSC
• Testing
• Monitoring BSC performance
• Tracing
They provide links to the to the related topics in the functional area descriptions and to
reference documents such as “eBSC Commands”.
Entry points for operation instructions are the corresponding task lists.
A50016-G5100-B556-04-7620 Id:0900d8058025cba7 17
Introduction to functional area descriptions Radio network management
1.2 Scope and content of the functional area descriptions

g Two main types of BSC are available: BSC1 and eBSC. The functional area
descriptions and related configuration manuals cover both types:
• If the behavior of the BSC types does not differ, the topic is described only once.
In this case the term "BSC" is used for both types.
• If their behavior differs, the term "BSC1" or "eBSC" is used in the description.
Scope
The functional area descriptions and related configuration manuals address persons
who administrate the GSM/EDGE RAN BR line network elements locally via the LMT.
Content
"Network configuration" describes:
• Different network configurations between MSC, BSC, TRAU and BTSE
• Nailed up connections
• Support of satellite links on A-, Asub and Abis interfaces
"Equipment configuration" describes:
• Enabling antenna hopping
• Handling of a remote object
• Creation of a nailed up connection
• Time management and synchronization
"Transmission & transport network management" describes:
• Configuration of the terrestrial interface (physical layer, layer 2, signaling)
"Radio network management" describes:
• Configuration of radio cells
• Management of radio resources
• Handover management
"Administration with the BSC" describes:
• Downloading of software to the BSC
• Handling of software within the BSC
• Handling of features on the LMT-BSC
"Fault and test management" describes:
• Automatic recovery procedure related to a set of faulty managed objects
• Management of BSS alarms on the LMT-BSC
• Management of test objects on the LMT-BSC supporting test management activities
"Performance management" describes:
• Measurement data processing
• Management of scanner jobs
• Management of RFLOOP jobs
• Management of SCA jobs and BTS/BSC procedures for performance issues
"Trace management" describes:
• Activation and deactivation of a cell traffic recording
• Activation and deactivation of history data on dropped calls
• Management of trace measurement reports
18 Id:0900d8058025cba7 A50016-G5100-B556-04-7620
Radio network management Introduction to functional area descriptions
"Master procedures" describes:

• Adding a BTSE to a BSC
• Adding a TRAU to a BSC
• Configuring GSM cells
• GPRS services
1.3 Symbols used

The following symbols are used in the manuals:
Safety note; the notes given here are to be followed with care. Non-
observance can lead to personal injury and property damage.
ESD (Electrostatic Sensitive Device) precautions to be taken
Reference to another procedure/procedure step
Reference to another procedure; return after having finished
PDF: HTML:
Note; important information
Use the LMT to enter commands
Figure 1 Symbols used
A50016-G5100-B556-04-7620 Id:0900d8058025cba7 19
Overview: Radio network management Radio network management
2 Overview: Radio network management

Scope of radio network management
This manual describes the resources, functions and configuration possibilities for radio
network management within the GSM/EDGE radio access network (RAN, see Figure 2)
– if necessary for comprehensibility also between the radio access network and the core
network. Related procedures are described in Configuring the radio network. Within this
manual, the focus lies on the means for managing the air interface (Um interface)
between MS ans BTS. Since it is the BSC which controls most of the radio network func-
tions, the descriptions are often based on the BSC´s view of the radio network. Connec-
tions and related functionalities between the BSC and other network nodes are
described in the Transmission and transport network management.
Network elements of the radio access network
TRAU
A Circuit-switched
GSM core
BTS network
Asub
BSC
BTS Lb SMLC
Abis
Air interface
(Um) BTS
PCU
Gb Packet-switched
UE
GPRS core
network
Base station system (BSS)
Figure 2 GSM/EDGE RAN architecture

The radio access network includes the following main components:
• Base transceiver station (BTS)
• Base station controller (BSC)
• Transcoding and rate adaptation unit (TRAU)
The BTS connects the user equipment (UE) or mobile station (MS) to the GSM/EDGE
RAN via the air interface (Um). Several BTSs are controlled by a single BSC via the
respective Abis interfaces. Each BTS fulfills routing, switching and maintenance tasks
in the GSM/EDGE RAN.
The PCU (packet control unit) is a functional unit providing GPRS and EDGE function-
ality and is integrated in the BSC.
20 Id:0900d8058053dfa2 A50016-G5100-B556-04-7620
Radio network management Overview: Radio network management
For completeness, Figure 3 shows the integration of the radio access network with the
core network.
BSS TRAU MSC/VLR GSM core network
A PSTN
HLR/AUC/(EIR)
Asub
BSC SS7 network
BTS
Air interface
(Um) Abis
Gr/Gd/Gs GGSN Gi
SGSN
PDN
Gb Gn
UE PCU
GPRS core network
Figure 3 Integration of the radio access network with the core network
The components connected with the radio access network are:
• Mobile switching center (MSC)
• Serving GPRS support node (SGSN)
Structure of the manual

This manual is structured according to practical considerations regarding radio network
management.
• Chap. 3 Cells, frequency bands and transceivers and 4 Channels describe the basis
of the radio network which is
– the cellular structure of the radio network,
– the radio frequencies/carriers,
– the physical and logical paths for transmitting signalling and user data via air
interface.
• Chap. 5 Coding and transmission modes shows how the transmission is done.
• Chap. 6 Frequency hopping describes a special transmission mode.
• Chap. 7 Services describes special services available in the GSM network.
• Chap. 8 – 10 deal with radio access topics:
– Chap. 8 Signalling and call establishment/release shows the signalling paths for
establishment (and release) of calls or data connections.
– Chap. 9 Radio channel allocation describes how incoming requests for circuit
switched (2G GSM) radio resources are handled and how available radio
resources are distributed.
– Chap. 10 GPRS radio channel management is the complement of chap. 9 for
packet switched services (GPRS)
• Chap 11 – 13 deal with concepts for managing MSs moving within the radio network.
– Chap. 11 Power Control describes the means to adjust the MS and BTS power
according to the distance between MS and BTS when an active MS moves
within a cell.
A50016-G5100-B556-04-7620 Id:0900d8058053dfa2 21
Overview: Radio network management Radio network management
– Chap. 12 Handover describes the strategies applied when an active MS with an

established CS call connection moves from one cell to another.
– Chap. 13 Cell changing and cell reselection describes the processes applied if
a MS in idle state or with a (E)GPRS connection established moves from one
cell to another.
• Chap. 14 BSS control and special radio network features describes additional func-
tions and features of the radio network management not fitting in the other chapters.
• The Appendix gives additional and useful background information.
Regarding the layered protocol structure of the GSM network (see Appendix), radio
network management tasks mainly refer to radio resource management (RRM, a sub-
layer of the network layer, layer 3) by far, sometimes a functionality affects or integrates
also other parts of the layer structure. So, the GSM layer structure is useful foremost for
background information and for comparing with GSM standard documents (e.g. 3GPP
recommendations). The structure of this manual does not match the GSM layered
protocol structure.
Evolution from GSM to GPRS to EDGE

GSM was originally designed for mobile speech services. In the basic form GSM
provides circuit switched (CS) call connections with fixed, moderate transmission rates.
Developments such as high speed circuit switched data services (HSCSD) or adaptive
multirate (AMR) increase data rates and quality of services.
GPRS offers packet switched (PS) services for data applications with higher transmis-
sion rates compared to speech and efficient distribution of radio resources. GPRS uses
the same radio resources as usual GSM (e.g. radio frequencies, radio channels, time
structure on radio interface, modulation scheme) and requires a modified network archi-
tecture (e.g. PCUs, SGSN).
EDGE or (E)GPRS is an evolution of GPRS. It fits well in the GPRS network structure
and offers about three times higher data rates than GPRS, mainly by applying 8PSK
modulation (3 bits per symbol transmitted via air interface) instead of GMSK modulation
(1 bit per symbol) for usual GSM and GPRS.
On-site and remote radio network management

On-site configuration of the network elements is supported by the Local Maintenance
Terminal (LMT) Evolution. Remote operation and maintenance support is provided by
both the Radio Commander (RC) and the Operation and Maintenance Tool Set (OTS).
22 Id:0900d8058053dfa2 A50016-G5100-B556-04-7620
Radio network management Overview: Radio network management
LMT RC OTS
T interface
BTS
O interface
BTS
BSC TRAU
BTS T interface
T interface
LMT LMT
LMT
LMT
Figure 4 Configuration with LMT, RC and OTS
A50016-G5100-B556-04-7620 Id:0900d8058053dfa2 23
Cells, frequency bands and transceivers Radio network management
3 Cells, frequency bands and transceivers
3.1 Cells and their addressing

Geographically, a GSM cell is a radio area covered by one antenna or a group of
antennas with the same coverage area. Accordingly a cell is related to a TRX or a group
of TRXs connected with a cell’s antenna group. The complete coverage area of a GSM
radio network is composed of a large amount of overlapping cells (cells can even form
a hierarchical structure, see chap. 3.4). Since a BTS can carry many TRXs covering dif-
ferent areas, the BTS can serve several cells. The group of cells served by one BTS is
called a site.
Cells with different shapes and sites

The basic form of a cell is a round cell covered with an omni-directional antenna in the
center; such a cell is called omnicell. Omnicells may be chosen in low traffic areas with
good radio propagation (open area), and are especially dedicated to isolated sites.
For modelling reasons when covering a large area with several or many cells, the cells
are assumed as hexagonal (though actually round).
Omnicell Shaped omnicell Sector cell
Figure 5 Omnicells and sector cells

In order to extend the capacity of a site (one place for antennas), the site can be sector-
ized by using appropriate antennas transmitting and receiving only in a certain sector of
a circle. Each sector forms one cell, a sector cell. Most common are 3-cell sites where
the cells can be hexagonal or rhomboidal depending on the antenna characteristics.
Cell 1 Cell 1
Cell 3 Cell 3
Cell 2 Cell 2
Hexagonal cells Rhomboidal cells
Figure 6 3-cell sites
24 Id:0900d8058052e632 A50016-G5100-B556-04-7620
Radio network management Cells, frequency bands and transceivers
Adressing cells and BTSs

GSM cells:
Cells are addressed with the help of a hierarchical addressing scheme composed of the
following elements (ordered from large to small entities):
• Mobile Country Code (MCC)
• Mobile Network Code (MNC)
• Location Area Code (LAC)
• Cell Identifier (CI)
The adress of a cell is formed by: MCC + MNC + LAC + CI.
A location area (LA) is a group of cells which cover a certain area, and LAs are the basis
of location updates and pagings:
– When a mobile station in idle mode leaves one location area and enters another
one, it reports the new location area to the BTS from where it is forwarded to MSC
and VLR.
– A paging request is sent to all cells of the location area where the mobile station is
registered.
With the help of location areas the number of location updates is kept small and the core
network has no effort with administering the mobile station’s exact location. A location
area is reported by the LAI (Location Area Identity) which is:
LAI = MCC + MNC + LAC
GSM cells for (E)GPRS:
In case of GPRS cells and communication with the SGSN there is an additional address-
ing level: the routing area (RA), identified with the Routing Area Code (RAC). A routing
area is formed by a group of cells and is a part of a location area. When a mobile station
changes its routing area, it reports the new routing area to the SGSN. The routing area
can influence the distribution of paging messages (but the usual entity for GPRS paging
is the location area). The messages containing routing area information use the RAI
(Routing Area ID) which is:
RAI = MCC + MNC + LAC + RAC
BTSs:
For distinguishing neigbouring BTSs each BTS is related to a Base Station Identity Code
(BSIC). The BSIC consists of the following two components:
• Network Color Code (NCC) by which neighbouring PLMNs or parts of PLMNs are
distinguished. Within one PLMN more than one NCC may be allowed. From the
point of view of network planning, care needs to be taken to ensure that the same
NCC is not used in adjacent PLMNs.
• Base Station Color Code (BCC) by which neigbouring BTSs of the same PLMN are
distinguished. It is used by the MS to correctly decode the BCCH: The BCC must
correspond to the Training Sequence Code (TSC) assigned to the BCCH of that cell.
In other words: From the BCC in the synchronization channel (SCH) the MS knows
the TSC of the BCCH it has to select. The BCC is selected by default as TSC for the
BCCH when it is created.
A50016-G5100-B556-04-7620 Id:0900d8058052e632 25
Attributes
GSM cells:
• BTS: A GSM cell is represented by the BTS managed object (MO) and is created by
applying the CREATE BTS command.
g “BTS” is used in two different ways:
– BTS as hardware or Network Element (NE). In this case the BTS represents
a machine providing radio equipment. Such a BTS can include the equip-
ment for several cells (e.g. the cells of one site).
– BTS as Managed Object. In this case the BTS represents one cell.
• CELLGLID (Cell Global Identity): This attribute, subordinate to the BTS object,
contains the Cell Identification (CI) and the Location Area ID (LAI) of the cell and it
is composed by the MCC, MNC, LAC, CI fields.
• BSIC (Base Station Identity Code): This attribute is composed by two fields, NCC
(Network Color Code, range: 0..7) and BCC (Base Station Color Code, range: 0..7).
Further attributes for (E)GPRS cells (working in packet switched mode):
Cells for GPRS usage are created as usual GSM cells; then they are configured for
GPRS mainly via the PTPPKF (Point To Point Packet Function) MO, subordinate to the
BTS MO. The PTPPKF object contains the RACOL (“routingAreaColour”) MO and the
RACODE (“routingAreaCode”) MO. For more information, see chap. 3.8.
In GSM 08.18, for point to point packet transfer, it is specified that a cell is identified by
a BVCI (BSSGP Virtual Connection Identifier), so there is a relation one to one from cell
and BVCI. The BVCI is allocated by the system to each PTPPKF according to the
creation position in the database: BVCI = 2 for the first PTPPKF, BVCI = 3 for the second
PTPPKF, etc.
Sites:
The operation & maintenance (O&M) functions common to all cells of a site are config-
ured via the BTSM (BTS site manager) MO (see the Transmission and transport network
management manual).
3.2 Cell types

The following cell types are distinguished:
– Standard cells
– Dual band standard cells
– Extended cells
– Concentric cells
Standard cell
The standard cell represents a normal cell with a maximum cell radius (i.e. max. MS-
BTS distance) of 35 km. This value is only valid for GSM900/GSM850; for
DCS1800/PCS1900 the cells have to be smaller due to the more adverse radio propa-
gation characteristics of the higher frequencies. Standard cells use ordinary single
timeslots for TCHs and do not distinguish different coverage areas within the cell.
Dual band standard cell

Dual band standard cells provide two frequency bands within the area of a standard cell.
The cell’s radius is assumed to be the same for the two frequency bands, i.e. both bands
have well-matching cell borders. The frequency band combinations GSM850/PCS1900,
26 Id:0900d8058052e632 A50016-G5100-B556-04-7620
GSM900/DCS1800 and GSM850/DCS1800 Mhz are supported. Dual band standard

cells are also called mixed cells and have cell identities as any single band GSM cell.
They have been introduced to increase the capacity of a cell.
One common BCCH is set up for both frequency bands which saves radio capacity and
avoids additional BCCH planning activities. The BCCH frequency can be chosen from
both frequency bands.
Both circuit switched, e.g. speech, and packet switched data, e.g. GPRS/EGPRS,
services can be allocated in both frequency bands (single band MSs have access only
to the TRXs on the frequency band that is used for the BCCH.).
Frequency hopping is not possible between the frequency bands.
Extended cell
An extended cell is a cell with a maximum MS-BTS distance of up to 100 km. In a normal
GSM cell the maximum MS-BTS distance is limited to 35 km. This is due to the max.
permissible transmission delay, which ensures that the BTS can receive information
from the MS in the assigned timeslot. In an extended cell two cell areas are defined:
– Near area (up to 35 km radius) where the transmission delay is not critical: Usual
single timeslots are used as in standard cells.
– Far area: Two adjacent timeslots are merged to a double size timeslot and the radio
transmission is done with the doubled timeslots and additionally with an extremely
extended guard period, thus allowing a much higher delay of the bursts.
The areas are discriminated by the user defined distance threshold parameter
HOMSTAM (“hoMsTaMax”) subordinate to the HAND object (because this threshold is
important for handover decisions mainly).
There is no fixed relation between an area (far or near) and TRX (as opposed to con-
centric cells); a TRX can transmit with single timeslots in the near area and with double
timeslots in the far area as well (dependent on the MS-BTS distance).
Extended cell
near area far area
up to 35 km up to 100 km
single timeslots
double timeslots
Figure 7 Extended cell areas

In an extended cell, all control channels (BCCH, CCCH, SDCCH, CBCH) have to be
configured as double timeslots (via the EXTMODE attribute, subordinate to the CHAN
attribute, see chap. Addition of a radio channel).
A50016-G5100-B556-04-7620 Id:0900d8058052e632 27
Within an extended cell, different TCH pools serve the different coverage areas. Traffic
channels can be configured as double or single timeslot channels. The BSC assigns
single timeslot TCHs to mobiles in the near area around the BTS (maximum 35 km) and
double timeslot TCHs for larger distances (up to 100 km). If the BSC tries to assign a
single timeslot channel, but all single timeslots are busy, the decision is revised to a
double timeslot channel.
Intra-cell handovers from a single timeslot traffic channel towards a double timeslot
traffic channel are provided, and vice versa (see chap. Extended cell handover).
Extended cells support half rate traffic channels and Frequency Hopping.
Concentric cell
A concentric cell is a cell in which different TRXs have different ranges. TRXs with the
smaller range serve the so-called inner area, TRXs with the wider range serve the so-
called complete area. Whether a TRX serves the inner or the complete area is defined
with the TRXAREA attribute of the TRX object (values: INNER, COMPLETE, NONE).
The different TRX ranges are determined by the values entered for the power reduction
in the PWRRED attribute (“txPwrMaxReduction”) of the TRX object.
All control channels of a concentric cell (BCCH, CCCH, SDCCH, CBCH) belong to the
complete area. As opposed to extended cells there is a fixed relation of concentric cell
areas and particular TRXs. Intra-cell handovers from the inner to the complete area and
vice versa are provided (see chap. Concentric cell handover).
Frequency hopping in a concentric cell is only allowed within the complete area or within
the inner area (frequency hopping is not shared between the two areas). Therefore two
Frequency Hopping Systems (FHSYs) have to be created: one for the complete area
and one for the inner area.
Concentric cell
Inner complete
area area
Figure 8 Concentric cell areas

Dual band operation:
Different frequency bands can be assigned to the inner and the complete area of a con-
centric cell (such concentric cells are also called mixed cells), again one common BCCH
is used for both areas. The different TRX coverage for dualband concentric cells are
determined by the different TX output powers of the used TRX hardware and different
propagation attenuations of the different used frequency bands. Considering the fre-
28 Id:0900d8058052e632 A50016-G5100-B556-04-7620
quency propagation characteristics and the band-specific maximum cell radius, the
most useful configuration is to use GSM900 or GSM850 frequencies for the complete
area (and thus for the BCCH and also the SDCCHs) and to assign DCS1800 or
PCS1900 frequencies to the inner area. However, also the opposite configuration is
technically possible.
Parameters and configuration

The cell type has to be defined when a cell is created (command: CREATE BTS).
Standard cells, Dual band standard cells and Extended cells are set up via the
CELLTYP (“cellType”) attribute and the values STDCELL, DBSTDCELL or EXTCELL.
A concentric cell is set up with CELLTYP = STDCELL and additionally with the
CONCELL (“concentricCell”) attribute set to TRUE (if the CELLTYP attribute is set to
EXTCELL or DBSTDCELL, the CONCELL attribute can not be set to TRUE, because
an extended or dual band standard cell can not be a concentric cell).
An additional attribute DUMMY, subordinate to the BTS object, is provided in order to
allow the operator entering additional cell information (e.g. for determining a group of
cells the current cell belongs to, or for specifying a certain cell identification such as
“city”) in the BSC database. The DUMMY attribute is an alphanumeric string (space
character allowed, size: 1 ... 64 characters), the default value of DUMMY is "NOTDEF".
For dual band configurations see 3.5 Frequency bands.
3.3 Synchronization
Intra-site synchronization
Synchronicity within a site (i.e. within the cells controlled by the BTS site manager,
BTSM) is necessary to achieve a controlled time decoupling of radio resources if the
cells of the site use the same frequencies. This situation occurs if e.g. the frequency
spectrum granted to the operator is so small, that frequencies have to be re-used in
neigbour cells in case of frequency hopping. In such cases co-channel and adjacent
channel interference is avoided by intelligent frequency distribution and synchronized
hopping of frequencies (see chap. Frequency hopping).
Synchronicity within a site is guaranteed as all cells within a BTSM are controlled by a
common master clock. In fact, all cells of the same BTSM have even the same frame
numbers, as all cells of a BTSM start their operation at exactly the same point of time.
Inter-site synchronization
Synchronicity between adjacent sites is recommended in case of tight reuse of frequen-
cies to allow time decoupling of radio resources between the sites and is achieved with
the help of GPS (Global Positioning System) technology as time reference. After inter-
site synchronization the cells of all affected sites are synchronized in time regarding the
timeslots and frames as well as the frame numbers (for information about timeslots,
frames and multiframes, see chap. Channel configuration).
For time decoupling of radio resources between sites (after having enabled the inter-site
synchronization) two facilities are offered:
• Shifting the frame numbers of the cells (BTSs Managed Objects) of one site in
relation to the cells of an adjacent site (see Figure 9). This is done by adding an
offset to the frame number on BTS basis.
The shift of frame numbers between cells has the following positive effects:
A50016-G5100-B556-04-7620 Id:0900d8058052e632 29
– The synchronization information carried on SCH is not sent simultaneously.

Thus the BSIC decoding is improved e.g. leading to a higher efficiency of the
handover algorithm.
– The SACCH messages of the cells are not sent simultaneously which decreases
the influence of interfering signals on SACCH decoding.
• Shifting the timeslot numbers of the cells of one site in relation to the cells of an
adjacent site. This is done by adding an offset to the timeslot number on BTS basis.
The shift of timeslot numbers influences the planning of the Training Sequence
Code (TSC): Some combinations of TSCs may degrade receiver performance when
the TSC values are not orthogonal (only four TSC pairs are orthogonal (0; 2), (0; 7),
(1; 3) and (3; 4)) and these TSCs are sent simultaneously.
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
"43
&2!./&&3 FRAMEX FRAMEX FRAMEX

43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
"43

43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
"43
"52./&&3FORALL"43S
Figure 9 Shifting frame numbers at BTS

The shift of frame numbers and timeslots needs not always be configured with the same
values for all BTSs of a site, individual solutions are possible.
Attributes for inter-site synchronization

For the configuration of the GPS synchronization source the object SYNCBTSE (avail-
able only in the BTSE via BTSE-LMT) must be used: the parameter SYNCSRC (SYNC
source) must be set to extGPS.
Then inter-site synchronization is enabled by setting the EINTSITSYN (“enableInterSite-
Sync”) attribute to TRUE.
The frame number offset is determined by the FRANOFFS (“frameNumberOffset“) attri-
bute which can assume integer values 0, 1, ..., 255. In case of signalling
FRANOFFS = 51 or a multiple of 51 means a shift of just one full multiframe and therefor
has the same effect as FRANOFFS = 0.
The timeslot offset is set by BURNOFFS (“burstNumberOffset“) which can assume
values 0 – 7, according to the possible numbers of timeslots within a TDMA frame.
g The FRANOFFS and BURNOFFS values are only considered by the BTSE system
if EINTSITSYN is set to TRUE.
30 Id:0900d8058052e632 A50016-G5100-B556-04-7620
If Dynamic MAIO Allocation (DMA) is enabled, the FRANOFFS and BURNOFFS

values must be equal in all cells (BTSs) within a site (BTSM).
3.4 Hierarchical cell structure

The total traffic in a radio network area can be distributed over several radio cell layers.
For example a triple level structure comprises:
– Large cells, so called umbrella cells, for overall coverage form the top layer.
– Normal cells with a lower range (typically greater than 1 km) are embedded in the
large cells and form the middle layer.
– Micro cells building up the lowest layer cover little areas of highest traffic density.
The layers are prioritized in order to provide an improved availability and traffic handling
capability. The priority indicates a preference of a certain cell layer (e.g. in case of han-
dover) relative to another cell layer. As a general rule a large part of the active Mobile
Stations not moving or moving slowly are kept in micro cells which are usually planned
for high traffic load – hot spots – (also avoiding congestion in the large cells). So, the
highest priority is related to micro cells and slow moving MSs. Fast moving MSs shall
not be served in micro cells (because too much handovers could occur), but in larger
cells. Thus the priority of a micro cell for a fast moving MS is lower than the priority of a
larger cell for such MSs. Moreover the hierarchical cell structure and the prioritization
can include different frequency bands, leading to more priority levels. Usually there are
3 or 4 sublayers for a cell layer (e.g. micro cell): 2 for different frequency bands, another
2 if the MS’s speed category (slow/high) is taken into account. Table 1 shows an
example for a prioritization in a dual band environment (see also Figure 10). The layer
with PL = 0 has the highest priority. Max. 16 priority levels are supported.
Priority layer (PL) Cell layer, frequency band, MS speed

0 Micro cell, GSM1800, slow MS
1 Micro cell, GSM900, slow MS
2 Normal cell, GSM1800, both MS speed categories
3 Normal cell, GSM900, both MS speed categories
4 Umbrella cell, GSM900, both MS speed categories
5 Micro cell, GSM1800, high speed MS
6 Micro cell, GSM900, high speed MS
Table 1 Example for a priority configuration in a hierarchical cell structure
The priority order implies preferences regarding cell layers in case of handovers: A pri-
oritized cell has a higher probability of being targeted for handover than a cell with low
priority.
A50016-G5100-B556-04-7620 Id:0900d8058052e632 31
Umbrella Cell
GSM900
PL = 4
Micro Cell
GSM900
PL = 1 / 6
Normal Cell
GSM900
Normal Cell PL = 3
GSM900
PL = 3
Normal Cell Micro Cell

GSM1800 GSM1800
PL = 2 PL = 0 / 5
Normal Cell
GSM900
PL = 3
PL : Priority Layer
0 / 5 : Priorities for slow/fast moving MS
(0 is highest priority)
Figure 10 Example for a network with hierarchical cell structure
Attributes
Since the hierarchical cell structure mainly affects target cell selection in case of han-
dover, and target cells are adjacent cells, the managed objects involved in the hierarchi-
cal cell structure handling are: ADJC and HAND. Within the HAND object the HIERC,
PL, HIERF attributes have to be set. For details concerning the ADJC and HAND objects
and the handover procedures as well please refer to chap 3.9 Adjacent cells and chap.
12.6 Generation of the target cell list (especially 12.6.1 Sorting the target cell list).
32 Id:0900d8058052e632 A50016-G5100-B556-04-7620
3.5 Frequency bands

Table 2 shows the GSM frequency bands all of which are supported by Nokia Siemens
Networks.
GSM Freq. band Long term Short Uplink Downlink

System term MHz MHz
GSM850 GSM850 GSM 850 MHz band 850 824 - 849 869 - 894
GSM900 P-GSM Primary GSM P 890 - 915 935 - 960
GSM900 E-GSM Extended GSM E 880 - 915 925 - 960
GSM900 R-GSM Railway GSM G 876 - 915 921 - 960
GSM900 GSM-RE GSM railway extension RE 876 - 901 921 - 946
GSM900 GSM-PS P-GSM shifted to E-GSM PS 880 - 905 925 - 950
GSM900 GSM-PS5 P-GSM 5 MHz shifted to E-GSM PS5 895 - 910 930 - 955
GSM1800 1800 MHz GSM 1800 MHz Band DCS 1710 - 1785 1805 - 1880
GSM1900 1900 MHz GSM 1900 MHz Band PCS 1850 - 1910 1930 - 1990
Table 2 GSM frequencies
Figure 11 gives a graphical representation of the GSM900 and GSM850 frequency

bands.
P-GSM
GSM-PS5
GSM-PS
E-GSM
R-GSM
GSM-RE
850 MHz
850 MHz 900 MHz 950 MHz
Figure 11 GSM frequencies in the 850/900 MHz range

Main frequency bands used in GSM are:
• GSM 900 Base Band operating with the following frequencies fup(n) and fdown(n) and
represented with Absolute Radio Frequency Channel Numbers (ARFCNs) n (see
Figure 12):
fup(n) = 890 MHz + 0.2 MHz · n with 1 ≤ n ≤ 124 (200 kHz channel spacing)
fdown(n) = fup(n) + 45 MHz (45 MHz duplex spacing)
A50016-G5100-B556-04-7620 Id:0900d8058052e632 33
!2&#.

'3-""

-(Z &REQUENCY;-(Z=
!2&#.
K(Z

&REQUENCY;-(Z=
Figure 12 GSM 900 frequency bands and ARFCNs

• GSM 900 Extended Band operating with the following frequencies fup(n) and
fdown(n) and represented with ARFCNs n (see Figure 13):
fup(n) = 890 MHz + 0.2 MHz · n with 0 ≤ n ≤ 124 and
fup(n) = 890 MHz + 0.2 MHz · (n – 1024) with 975 ≤ n ≤ 1023
!2&#.

%84

-(Z &REQUENCY;-(Z=
!2&#.
K(Z

&REQUENCY;-(Z=
Figure 13 GSM 900 extended band frequencies and ARFCNs

• GSM 1800 (DCS 1800) operating with the following frequencies fup(n) and fdown(n)
and represented with ARFCNs n (see Figure 14):
fup(n) = 1710.2 MHz + 0.2 MHz · (n – 512) with 512 ≤ n ≤ 885
(200 kHz channel spacing)
34 Id:0900d8058052e632 A50016-G5100-B556-04-7620
!2&#.

'3-$#3

-(Z &REQUENCY;-(Z=
!2&#.
K(Z

&REQUENCY;-(Z=
Figure 14 GSM 1800 frequency bands and ARFCNs

During cell creation the frequency band(s) to be used must be selected. For mixed cells
(dual band standard cells, or concentric cells operating with two frequency bands)
certain combinations of frequency bands are possible.
The frequency band or combination of two frequency bands for a cell is defined by the
SYSID (“systemIndicator“) attribute. Table 3 shows the possible SYSID values and the
related frequency bands. Additionally the frequency bands are characterized by the
absolute radio frequency channel numbers (ARFCNs).
SYSID value Frequency band(s) ARFCNs

BB900 GSM standard band (P-GSM) 1 – 124
DCS1800 DCS 1800 512 – 885
EXT900 GSM extended band (E-GSM) 0 – 124 and
975 – 1023
PCS1900 PCS 1900 band 512 – 810
GSMR Railway GSM (R-GSM) 955 – 974
GSMDCS GSM extended band 0 – 124 and
(for mixed cells only) and 975 – 1023 and
DCS 1800 band 512 – 885
GSM850 GSM 850 standard band 128 – 251
GSM850PCS GSM 850 band and 128 – 251 and
(for mixed cells only) PCS 1900 band 512 – 810
GSM850DCS GSM 850 band and 128 – 251 and
(for mixed cells only) DCS 1800 band 512 – 885
Table 3 Selection of frequency bands by the SYSID attribute
A50016-G5100-B556-04-7620 Id:0900d8058052e632 35
Depending on the setting of the NETWTYPE (“networkType“) attribute related to the

BSC object, the user can select only certain SYSID values. The table below shows the
correspondence between the NETWTYPE values and the possible SYSID values.
NETWTYPE value SYSID values

GSMDCS BB900, EXT900, DCS1800, GSMDCS
GSMPCS BB900, EXT900, PCS1900
GSMR R-GSM
GSM850PCS GSM850, PCS1900, GSM850PCS
GSM850DCS GSM850, DCS1800, GSM850DCS
GSMRAILPUB R-GSM, EXT900
Table 4 Correspondence between NETWTYPE values and SYSID values
g The BTS1s (BS-20/21/22/60/61) do not support Dual band operation with GSM850
and PCS1900/DCS1800.
g In order to inform the MSs about available frequencies (via SYSTEM INFORMA-
TION, ASSIGNMENT COMMAND, HANDOVER COMMAND and FREQUENCY
REDEFINITION messages), the BSC codes the available frequencies into one of
the following bitmap formats depending on the frequency range: bitmap0, variable
bitmap, range 128, range 256, range 512, range 1024 (an example of frequency
coding is given in chap. Frequency hopping). Some mobiles could have difficulties
to correctly decode certain bitmap formats in case the frequencies in the two ranges
0, 1...124 and 975...1023 are mixed in the same cell. Therefor, the DENC (“dis-
ableEncodings”) attribute, subordinate to the BSC object allows to disable the
variable bitmap format across ARFCN = 0 (DENC = noVarBMapAcr0) or to force the
range 1024 format (DENC = noEncodingAcr0) which is the oldest and most common
format.
For the different frequency band combinations different mobile maximum transmission
power settings apply, see the BSC commands and eBSC commands manual.
3.6 Creation of a new cell and transceiver configuration

Figure 15 shows the parameters involved in basic cell and TRX configuration.
A cell is represented by the BTS Managed Object (MO) and created by applying the
CREATE BTS command. The transeiver configuration is located in the TRX MO subor-
dinate to the BTS MO.
36 Id:0900d8058052e632 A50016-G5100-B556-04-7620
BTS
BSIC (NCC+BCC)
CELLGLID TRX:0 TRX:1

(MCC+MNC+LAC+CI)
LPDLMN LPDLMN
CELLTYP (e.g. STDCELL)
CHAN:0 CHAN:0...7
CONCELL (e.g. = TRUE)
TRXAREA CHANTYPE TRXAREA CHANTYPE
SYSID (e.g. BB900) = COMPLETE = MAINBCCH = INNER = TCHFULL
BCCHFREQ (e.g. = 1) TRXFREQ ... TRXFREQ ...

= BCCHFREQ = CALLF01
CALLF01 (e.g. = 2)
... ... ...
MSTXMAXGSM PWRRED PWRRED
...
SLLPRM LAYERID LAYERID

(e.g. LY_00 included) (e.g. = LY_00) (e.g. = LY_01)
CRTSWSPELLPRM
(e.g. LY_01 included)
In blue colour: Parameters related to frequency configuration
... In green colour: Parameters related to layers and service layer lists
Figure 15 Managed objects and parameters for cell and TRX configuration
Configurations on the BTS Managed object

In LMT representation, mandatory attributes are marked by a flag. Additional attributes
(optional) get their default value if no values are entered.
In general the attributes of the BTS MO are distributed in five groups:
– BASICS: This group describes the basic properties of a BTS
– CCCH: This group permits the configuration of the Common Control Channels
– INTERF: This group is related to the interference measurements
– OPTIONS: This group allows enabling services or specific features on the cell
– TIMER: This group is related to the timer settings
All the attributes requested for the creation of a new cell are described in detail in BSC
commands and eBSC commands.
The mandatory attributes related to the CREATE BTS command are the following:
1. NAME: The user must specify the instance of the Site Manager (in the range: 0..499)
to which the cell is related and the instance of the BTS Managed Object (the cell, in
the range: 0..11).
2. BSIC (Base Station Identity Code): This attribute is composed by two fields, NCC
(Network Color Code, range: 0..7) and BCC (Base Station Color Code, range: 0..7).
From the NCC the MS determines which cells are allowed for handover, i.e. only
cells with a permitted NCC may be included in the MEASUREMENT REPORTS.
The BCC must correspond to the Training Sequence Code (TSC) assigned to the
BCCH of that cell. The BCC is used by the MS to correctly decode the BCCH. In
other words: From the BCC in the synchronization channel (SCH) the MS knows the
A50016-G5100-B556-04-7620 Id:0900d8058052e632 37
TSC of the BCCH it has to select. The BCC is selected by default as TSC for the
BCCH when it is created. Within one PLMN more than one NCC may be allowed.
From the point of view of network planning, care needs to be taken to ensure that
the same NCC is not used in adjacent PLMNs which may use the same BCCH
carrier frequencies in neighbouring areas.
3. CELLGLID (Cell Global Identity): This attribute contains the Cell Identification (CI)
and the Location Area ID (LAI) of the cell and it is composed by the MCC, MNC,
LAC, CI fields.
This parameter is sent downlink on the BCCH (SYSTEM INFORMATION TYPE 3 or
4) or on the SACCH (SYSTEM INFORMATION TYPE 6). Within these messages
MCC-MNC-LAC make up the “Location Area Identification” Information Element
(LAI IE) and CI corresponds to the “Cell Identity” IE. SYSTEM INFORMATION TYPE
4 does not contain the CI but only the LAI.
4. CELLTYP: This attribute specifies the type of the cell, i.e. STDCELL for Standard
cells, EXTCELL for Extended cells or DBSTDCELL for Dual Band Standard cells.
5. BCCHFREQ: This attribute defines the absolute radio frequency channel number
(ARFCN) of the carrier which contains the FCH, SCH, BCCH and CCCH. The
ARFCN must belong to the range determined by the SYSID value.
6. SYSID: This attribute defines the frequency band used by the cell.
7. CONCELL: This attribute defines a cell as concentric (value TRUE) or not (FALSE).
Having defined the BCCH frequency (with BCCHFREQ), the other frequencies used by
the transceivers of the cell have to be specified. For this purpose the CALLF<nn> (“cel-
lAllocationF<nn>“) attributes are provided with <nn> = 01 ... 63 (so a cell has maximum
63 non-BCCH frequencies); each CALLF attribute value is a frequency number
(ARFCN) which must belong to the range determined by the SYSID value. Regarding
the CALLF<nn> attributes, from which the TRX frequencies are taken during the subor-
dinate TRX creation, it should be considered, that the number of TRXs per cell is limited
by the BTS equipment, actually the BTSs of the main line allow 24 TRXs.
g When the BTS object is created, the subordinate PWRC and HAND Managed
Object Instances are automatically created, too, and they assume their default
values. The user can modify the attributes of these objects entering the SET HAND
or SET PWRC commands.
Setup of the MS maximum transmit power

Several parameters are provided for configuring the maximum power the MS is allowed
to transmit with. Generally the parameter values should be adapted to the size of the
radio cell: The smaller the cell the lower the allowed transmit power should be in order
to minimize channel interference in adjacent cells and to save MS battery.
• MSTXPMAXCH (“msTxPwrMaxCcch”): This parameter indicates the maximum
transmit power level a MS is allowed to use when it accesses the cell on the Random
Access Channel (RACH) and the initial power the MS is allowed to use on the ded-
icated control channel (SDCCH or SACCH/FACCH on TCH) after an IMMEDIATE
ASSIGNMENT.
This power level remains valid until the MS receives the first power control order
(due to dynamic Power control). The MSTXPMAXCH value is sent on the BCCH
(SYSTEM INFORMATION TYPE 3 and TYPE 4) in the “Cell Selection Parameters”
IE. MSTXPMAXCH may be set to the same value as MSTXPMAXGSM (resp.
MSTXPMAXDCS or MSTXPMAXPCS, see below) to guarantee that a MS, which is
accepted on the RACH, is able to communicate with the network also on the dedi-
38 Id:0900d8058052e632 A50016-G5100-B556-04-7620
cated channel. Increasing the entered value decreases the allowed transmit power
on the RACH and thus the maximum allowed distance between MS and BTS for
RACH access.
This parameter is also used (together with other parameters) to define the path loss
criterion C1 (see chap. Cell changing and cell re-selection).
GMSTXPMAC (“gprsMsTxPwrMaxCch”) is the corresponding parameter for GPRS
mobiles in case a Packet Broadcast Control Channel (PBCCH) is configured.
In case of DCS 1800 cells PWROFS (“powerOffset”) defines an offset added to the
MSTXPMAXCH value to be used by DCS1800 Class 3 Mobile Stations for their
random access attempts (and for the calculation of C1 and C2).
• MSTXPMAXGSM (“msTxPwrMaxGsm”): This parameter defines the maximum
transmission level a MS is allowed to use on a dedicated channel (SDCCH and
TCH) in the serving cell. This parameter is relevant if the cell contains frequencies
of the GSM900 band.
• MSTXPMAXDCS (“msTxPwrMaxDcs”): This parameter defines the maximum trans-
mission level a MS is allowed to usefor DCS1800 on a dedicated channel (TCH and
SDCCH) in the serving cell.
• MSTXPMAXPCS (“msTxPwrMaxPcs”): This parameter defines the maximum power
level a MS can use for PCS1900 in the serving cell.
g If two different frequency bands are used in the cell (dual band concentric cells, or
dual band standard cells), the power parameters for both frequency bands must be
set, as both bands are used within the cell. This information is evaluated during call
setup and for the complete-to-inner intracell handover decision.
Further actions: Configurations on the TRX managed objects

Having created and configured the BTS as described above, the TRXs of the cell can
be created. The radio frequency of each TRX must be taken from the values of the
CALLF<nn> attributes. In case of dual band cells some TRXs have to be associated with
frequencies belonging to one band, and other TRXs with frequencies belonging to the
other band. Of course, the frequency associated to the TRX object has to be selected
according to the real values supported by the TRX (Quartz filters tuning).
The following attributes are mandatory for the creation of a TRX object:
1. TRXFREQ (“carrierFrequency“): This attribute specifies the frequency of the trans-
ceiver and assumes:
– The BCCHFREQ value, if the TRX is the BCCH one
– A CALLF<nn> value, among the values defined by the user, when creating the
superordinate BTS object
2. LPDLMN (“lapdmNumber“): The TRX shares a logical LAPD link with the superor-
dinate BTSM for the transmission of its radio resource management signalling data
and layer 2 control over the PCMB line (Abis interface to BSC); On BTSM level this
logical link is represented by the LPDLM managed object; the LPDLMN attribute of
the TRX relates the TRX to one LPDLM. For more information about the configura-
tion of LAPD links, please refer to chap. Signalling for call processing on radio area
and Abis area and the Transmission and transport network management manual.
Since the sending power determines the actual cell size, the PWRRED (“txPwrMaxRe-
duction”) parameter is used to adjust the sending power according to the desired trans-
mission range. PWRRED specifies the number of 2 dB steps the TX power should be
reduced from the maximum transmit power.
A50016-G5100-B556-04-7620 Id:0900d8058052e632 39
Further actions: enabling a TRX for a service (e.g. HSCSD)

The TRX has to be connected with a so called Layer which then has to be included in
the Service Layer List of the desired service (for information about the concept of Layers
and Service Layer Lists see chap. Service layer lists). If the Layer which the TRX is
related to is not included in the right Service Layer List, the TRX cannot provide the
service.
Examples
• Concentric cell with two frequency bands (GSM900 and DCS 1800) containing 16
frequencies belonging to different bands. The common BCCH shall be the first of the
GSM900 band.
Selected BTS parameters:
SYSID = GSMDCS
BCCHFREQ = 1
CONCELL = TRUE
CALLF01 = 2 (e.g.), CALLF02 = 10 (e.g.), ...,
CALLF08 = 513 (e.g.), CALLF09 = 521 (e.g.), ...
MSTXPMAXGSM = (as required), MSTXPMAXDCS = (as required)
Selected parameters for the BCCH-TRX:
TRXAREA = COMPLETE (the BCCH serves on the complete cell area)
TRXFREQ = BCCHFREQ
PWRRED (“txPwrMaxReduction”) = ... (determines the TRX range)
Selected parameters for a TRX of the inner area:
TRXAREA = INNER
TRXFREQ = CALLF08
• Extended Cell:
CELLTYP = EXTCELL
CONCELL = FALSE
TRXAREA = NONE (no concentric cell)
Additionally the EXTMODE (“extendedMode”) parameter of the CHAN object has to
be set accordingly. The HOMSTAM attribute subordinate to the HAND object deter-
mines the border between the two cell areas.
3.7 TRX mode of operation (support of EGPRS or not)

The TRXMD (“trxMode”) attribute indicates which GSM technologies the TRX supports:
– If the TRX shall just support circuit switched services (usual GSM) or GPRS, the
TRXMD attribute has to be set to GSM.
– If the TRX can support EGPRS and the user wants to enable this facility, the TRXMD
attribute has to be set to EDGE.
From the point of view of BTS equipment, the TRXMD attribute is the criterion used to
allocate one of the following Carrier Unit (CU) types to the transceiver:
– GCU: GSM Carrier Unit able to support GSM and GPRS services (not EGPRS)
– ECU: EDGE Carrier Unit able to support GSM, GPRS and EGPRS services
– FlexCU: Flexible Carrier Unit able to support GSM, GPRS and EGPRS services
The association between a TRX and the boards (GCU, ECU, FlexCU) of a mainline BTS
is performed automatically by the BTS equipment, taking into account the TRXMD
setting. The EDGE capability of a CU is modelled with the TRX CAPABILITY attribute
(which is “read only”). It reflects the real capabilities of the TRX independently of the
40 Id:0900d8058052e632 A50016-G5100-B556-04-7620
TRXMD parameter setting. The attribute is available for the operator by the GETINFO
TRX and GETINFO BTS commands, and the following values can be assumed:
– GSM: The TRX is associated to a Carrier Unit without EDGE capability.
– EDGE: The TRX is associated to a Carrier Unit with EDGE capability.
– UNKNOWN: The BSC has no knowledge about the Carrier Unit associated to TRX.
The following combinations of TRXMD and TRX CAPABILITY are possible (Table 5):
TRXMD TRX CAPABILITY Meaning

GSM GSM The TRX is working with GSM functionality
GSM EDGE The TRX is working with GSM functionality
GSM UNKNOWN No CU is related
EDGE GSM The TRX is working with GSM functionality
since no ECU or FlexCU is available
EDGE EDGE The TRX is working with EDGE functionality
EDGE UNKNOWN No CU is related
Table 5 Combinations of TRXMD and TRX CAPABILITY values
The configuration of a TRX for supporting EGPRS/GPRS services has to take into
account the multislot constraints for TSC (Training Sequence Code) and Frequency
Hopping parameters.
TRX-CU assignment procedure:
The BTSE shall try to find an optimal allocation between the required TRX operation
modes and the available CU types according to the following rules:
1. Try to allocate the BCCH-TRX to the appropriate CU type
2. Try to allocate all EDGE-TRXs to ECUs/FlexCUs
3. Try to allocate all GSM-TRXs to GCUs
4. Try to allocate all remaining GSM-TRXs to ECUs/FlexCUs
5. Try to allocate all remaining EDGE-TRXs to GCUs (the states of the TRXs change
to enabled-degraded).
Re-configuration of TRXs due to a change of functional configuration
When TRXs have to re-configured, the BTSE checks, if the allocation among TRXs and
CUs is still optimal. If necessary, an automatic re-configuration according to the rules
shown above is performed.
A change of the functional configuration may be caused by:
– Creation/deletion of a TRX
– Modification of the TRXMD attribute of a TRX
– Breakdown of the CU allocated to the BCCH-TRX
– Breakdown of a CU allocated to a complete area TRX in case of concentric cells
– Commissioning of a TRX after breakdown
In case of baseband frequency hopping all TRXs involved in the same hopping law must
be homogeneous, i.e. they must have the same TRXMD value. If a TRX with TRXMD =
EDGE gets TRX CAPABLITY = GSM (e.g. due to a re-configuration) the hopping for the
TRX related to this hopping law is stopped in the cell, and the operator is informed. Syn-
thesizer frequency hopping is not affected.
A50016-G5100-B556-04-7620 Id:0900d8058052e632 41
In some cases, changes of TRX’s configuration could lead to a loss of traffic for one or
two TRXs if the configuration procedure is not performed with the correct steps (e.g. a
shutdown of a TRX could be necessary, see the first example below).
Examples:
• The starting configuration comprises two TRXs (TRX:1, TRX:2) configured for GSM
services which are related to an ECU and to a GCU (see Figure 16). Now an addi-
tional GSM-CU is implemented and a third TRX (TRX:3) is created for EDGE ser-
vices. Since the additional GCU can not support EDGE, but there is an ECU related
to a TRX in GSM mode, an automatic reconfiguration takes place, relating the ECU
to TRX:3 and the free GCU to TRX:1.
Carrier Units TRX Objects

(BTS Equipment) (BSC Database)
EDGE-CU TRX:1
TRXMD = GSM
Automatic
a) Starting BTSE internal
Configuration Assignment
GSM-CU TRX:2
TRXMD = GSM
Automatic
Reconfiguration
EDGE-CU TRX:1
TRXMD = GSM
b) Configuration
after Upgrade
GSM-CU TRX:2
TRXMD = GSM
GSM-CU TRX:3
TRXMD = EDGE
(additional CU) (new TRX)
Figure 16 Reconfiguration of CU-to-TRX assignment

A potential loss of traffic is avoided by performing the following sequence:
1. Shutdown of TRX:1
2. Creation of TRX:3 with TRXMD = EDGE (causing the automatic reconfiguration)
3. Unlocking of TRX:1
g If the BCCH-TRX is involved in the TRX-CU assignment procedure (this can
happen, if an EDGE property of the BCCH-TRX itself is modified or if the BTSE-
internal optimization algorithm touches the BCCH-TRX), the whole cell is
affected. In this case, a shutdown/create/unlock procedure should be applied to
the whole cell and not only to the single TRX involved.
• Starting configuration:
– TRX:1 with TRXMD = GSM is related to a GCU.
42 Id:0900d8058052e632 A50016-G5100-B556-04-7620
– TRX:2 with TRXMD = GSM is related to an ECU.

– TRX:3 with TRXMD = EDGE is related to an ECU.
Now, if one TRX shall be enabled to support EGPRS, the best choice is TRX:2; in
fact it is already associated to an ECU, and no re-configuration is necessary. If the
TRX:1 was enabled to support EDGE, then a re-configuration would occur between
TRX:1 and TRX:2.
Considerations about output power regarding EDGE

An EDGE capable carrier unit (ECU or FlexCU) cannot generate the same maximum
output power for 8PSK as for GMSK. If no static power reduction (PWRRED parameter)
is applied, the maximum power values that can be provided on 8PSK timeslots in the
downlink is 2-3 dB smaller than the maximum power values on GMSK timeslots,
depending on the type (ECU, FlexCU), version and variant (850, 900, 1800, 1900 etc.)
of the used CU boards. If the TRX is operated with static power reduction (at least
PWRRED = 1 (= 2 dB), better PWRRED = 2), there is no power deviation as the (E)CU
board has enough reserves to support the 8PSK power requirement (in this case the
deviations remain within the tolerances specified by the 3GPP standard). Thus, with
PWRRED applied, the BTS correctly equalizes the output power levels on both 8PSK
and GMSK timeslots.
If EGPRS with 8PSK coding schemes is used on the BCCH TRX and PWRRED = 0 to
guarantee a stable DL level reference for neighbour cell measurements (all BCCH TRX
timeslots must transmit with equal maximum power), this leads to a slight falsification of
the BCCH transmit power depending on the number of timeslots busy with 8PSK coding
schemes.
3.8 Enabling GPRS/EGPRS services on BSC and cell level

Enabling of GPRS and EGPRS comprises configurations mainly on cell/BTS level, but
also on BSC level. Additionally the CPCU and PCU objects are involved, see Figure 17.
Generally enabling EGPRS on BSC level

The ESUP (“edgeSupport“) parameter of the BSC object allows to enable EGPRS
services in the BSC. If the user does not set the ESUP parameter to TRUE, EGPRS
services are not allowed in the BSC.
At least one CPCU (common packet control unit) object has to be created which gathers
attributes common for all PCUs (in case of one CPCU) or a pool of PCUs (several
CPCUs). The CPCU attributes include several parameters for TBF (temporary block
flow) control, to be found e.g. in chap. Signalling and call establishment/release. (The
PCU entity within the BSC mainly manages the packet functions.)
A50016-G5100-B556-04-7620 Id:0900d8058052e632 43
BSS FUNCTIONAL
BSC BTSM CPCU:1 PCU:0 PCU:1
ESUP PFCFCSUP CPCUN CPCUN

(e.g. = 1) (e.g. = 1)
...
BTS
TRX:0 PTPPKFK
GEXTS TRXMD RACOL

(e.g. = ALLFREQ) (e.g. = EDGE) CHAN:4
RACODE
GLLPRM LAYERID GDCH CPCUN

(e.g. LY_02 included) (e.g. = LY_02) (e.g. = PBCCH) (e.g. = 1)
ELLPRM EGPRS
(e.g. LY_02 included)
EEDGE
CSCH3CSCH4SUP
In blue colour: Parameters related EDGE EMFA1UL8PSK

In green colour: Parameters related to layers and service layer lists ...
Figure 17 Managed objects and parameters for (E)GPRS configuration
Configurations for (E)GPRS on cell/BTS level

• GEXTS (“gprsExtension“): This attribute determines if only the BCCH band is
allowed for GPRS/EGPRS services or all bands in case of dual band cells.
• PTPPKF (Point To Point Packet Function): This attribute controls the main proper-
ties and settings for packet switched functions of a cell (max. 1 PTPPKF object per
cell/BTS). The PTPPKF object is not automatically created with the BTS.
The creation of the PTPPKF object requires the setting of at least the following man-
datory attributes:
1. RACOL (“routingAreaColour”), range: 0..7
2. RACODE (“routingAreaCode”), range: 0..255
3. CPCUN (“commonPCUNumber”): The number of the common PCU the PCU
refers to, range: 0..11
• EGPRS (“enableGprs“): This attribute of the PTPPKF object allows to generally
enable/disable (EGPRS = TRUE/FALSE) packet data services in the cell. EGPRS
can be set to TRUE only if at least one TRX has been configured for GPRS.
• EEDGE (“enableEdge“): This attribute of the PTPPKF object allows to enable/dis-
able (EEDGE = TRUE/FALSE) the EGPRS service in the cell. The EEDGE attribute
can only be set to TRUE, if the following conditions are fulfilled:
– The EGPRS attribute has been set to TRUE.
– At least one TRX has been configured to support EGPRS.
– The CS3/CS4 coding scheme has been enabled (CSCH3CSCH4SUP = TRUE);
the EGPRS service can be made available without activation of CS3/CS4 coding
schemes by setting the ENOCS3CS4 attribute to TRUE, meaning that the max.
44 Id:0900d8058052e632 A50016-G5100-B556-04-7620
coding scheme usable is CS2, independently from the CSCH3CSCH4SUP

value.
Further configurations have to be made on TRX level (layers) and on Service layer lists.
g There is a certain interplay between the configurations of the objects in different
hierarchy levels. For example the (E)GPRS service can not be enabled by creating
the PTPPKF object only. Additionally, at least one TRX must have been configured
for (E)GPRS, before this service can be enabled at the PTPPKF object. Therefore
the user should configure the TRXs for (E)GPRS services before performing the
configurations related to the PTPPKF object.
3.9 Adjacent cells

To provide effective support for network management and call handover, the spatial
relationships between cells must be specified. A cell must “know” which cells are its
neighbors.
Therefore the adjacency concept is implemented: An adjacent cell is a cell that is a
physical neighbor of another cell in the network. Each cell keeps an adjacent cell list
containing so called ADJC Managed Object Instances, one for each adjacent cell (up to
64). Each ADJC (Adjacent Cell) MOI specifies an adjacent cell as handover target cell.
The target cell can belong to the same BSC area or to another BSC area, in the latter
case the ADJC is provided with basic information about the target cell via a subordinate
reference to a TGTBTS object related to the target cell (not necessary for intra-BSC
adjacencies). If a handover is indicated, the serving cell (where the affected call is estab-
lished) gets all information about the target cell (where the call is to be handed over to)
from its ADJC (and subordinate) objects.
Adjacencies between GSM cells and UMTS cells are managed by the ADJC3G objects
and the ADJC3G list.
3.9.1 Adjacencies within a pure GSM network

ADJC object
The ADJC object comprises the information about one target cell needed for handovers
in various parameters. The following mandatory parameters have to be specified
(including specifications for pure GSM or (E)GPRS supporting cells):
• NAME: The complete path related to the ADJC Managed Object Instance
• TGTCELL (“targetCell”):
For adjacencies between usual GSM cells (GPRS not applicable), two cases have
to be distinguished (see Figure 18):
)NTERNAL %XTERNAL
NEIGHBOURCELL NEIGHBOURCELL
!$*#
4'4#%,, 4'4#%,,
"43-N"43M 4'4"43N
Figure 18 TGTCELL attribute
A50016-G5100-B556-04-7620 Id:0900d8058052e632 45
– In case the target cell belongs to the same BSC area (internal target cell), the
TGTCELL attribute specifies the path to the target cell, i.e. the FDN (Full Distin-
guished Name) of the BTS related with the target cell (e.g. BTSM:x/BTS:n).
(E)GPRS related information of the target BTS – if applicable – is accessible via
the PTPPKF object subordinate to the target BTS.
– In case the target cell belongs to another BSC area (external target cell), the
TGTCELL attribute points to a TGTBTS object (e.g. TGTBTS:m) which contains
a copy of the attributes of the external cell.
For accessing (E)GPRS related information of the target BTS, the TGTBTS
object contains the subordinate TGTPTPPKF object which carries copies of the
attributes of the desired PTPPKF object.
This mechanism has two major benefits: First, viewed from the level of the
TGTCELL attribute, external adjacent cells are treated in the same way as internal
adjacent cells. Second, thanks to the referencing, the attributes of the external target
cell need not to be replicated in the ADJC object of the serving cell.
• USG (“usage“): This attribute indicates whether the adjacent cell must be sent over
SYSTEM INFORMATION TYPE 2 or 5 or both when active, or if it is used only for
measurement purposes (inactive); for more information see chap. 3.9.1.1).
The other attributes (e.g. RXLEVMIN, HOM, HOMSOFF, HOMDTIME, ...) are not man-
datory, but they are useful to configure each adjacency relationship (i.e. to manage han-
dovers from the serving cell to the neighbored one).
A maximum of 64 ADJC object instances can be created for each BTS object instance
(each cell); more detailed it is possible to specify:
– Up to 64 adjacent cells in total
– Up to 32 active adjacent cells for handover procedure (call processing)
– Up to 64 active adjacent cells used to measure extra BCCH frequencies
TGTBTS object
The TGTBTS (Target BTS) object is necessary for adjacencies to external cells and
contains all parameters which the target cell is characterized with, like:
– CELLGLID (Cell Global Identity): contains the Cell Identification (CI) and the
Location Area Id of the external target cell;
– BSIC (Base Station Identity Code): composed by two fields, NCC (Network Color
Code) and BCC (Base Station Color Code);
– SYSID: indicates the frequency band used by the external target cell;
– BCCHFREQ: defines the absolute radio frequency channel number of the BCCH.
In case of external adjacent cells the parameters listed above must be specified during
the creation of the TGTBTS instance.
The ADJC objects access the TGTBTS parameters via the path given by the subordi-
nate TGTCELL object.
Addition of an adjacent cell

The creation of the objects involved in the adjacency relations has to be done by several
steps in the following order (due to hierarchical dependencies of the objects and refer-
encing):
1. Creation of the serving and target BTS object
2. Creation of the serving and target PTPPFK (only for (E)GPRS capable cells)
46 Id:0900d8058052e632 A50016-G5100-B556-04-7620
3. Creation of the TGTBTS objects

4. Creation of the TGTPTPPFK objects (only for (E)GPRS capable cells)
5. Creation of the ADJC objects
In case of an external target PTPPKF the following attributes must be specified, when
creating the related TGTPTPPKF instance:
• RACOL (“routingAreaColour”) attribute of the external target PTPPKF: This attribute
represents the identification of the routing area which the cell belongs to.
• RACODE (“routingAreaCode”) attribute of the external target PTPPKF: This attri-
bute is used by the Mobile Station to identify the specific routing area.
g A single BTS can support up to 64 neighboring GSM cells. When the intra-cell han-
dovers are MSC controlled (attribute LOTRACH of HAND object set to FALSE) one
of the 64 allowed ADJCs is reserved by the BSC for LOTRACH handling. So the
user can configure only 63 ADJC cells or 62, if at least one ADJC3G object instance
has been created. In any case it is possible to configure 64 adjacent cells, but it is
necessary to reuse one or more frequencies in the BCCH allocation list.
Example for management of adjacency information

Figure 19 shows an example how adjacent cell relations are described with managed
objects. The BTS parameters like CELLGLID, BSIC, BCCH are well known and have
not to be specified or replicated. The user must specify only those attributes that are not
enclosed in BTS:n, i.e. the handover management attributes.
"43 "43
#%,,',)$ #%,,',)$
"3#)# "3#)#

!$*# !$*#
4'4#%,,"43-N"43 4'4#%,,"43-N"43

4'4#%,,4'4"43 4'4#%,,4'4"43
0400+& 0400+&

#ELL #ELL
4'4"43
"3# INTERNAL "3# INTERNAL
#%,,',)$
"3#)#

4'40400+&

#ELL
EXTERNAL"3#
Figure 19 Illustration of adjacent cell administration
3.9.1.1 Separate BCCH allocation lists for idle and active state
This feature allows to control the monitoring of adjacent cells by the MSs separately for
cell reselection and handover. Thus it is possible to prevent either cell reselection or
A50016-G5100-B556-04-7620 Id:0900d8058052e632 47
handovers for specific neighbour cell relations. Two lists of BCCH carriers called BCCH
allocation lists (BA lists) are provided, one for cell reselection, i.e. for MSs in idle mode,
the other one for handover purposes, i.e. for MSs in active or dedicated mode.
The separation of neighbour cells for cell reselection and handover can reduce the sig-
nalling load significantly. If for example an MS in idle mode is in an area covered by cells
of two separate MSCs and a cell reselection from a cell of MSC A to a cell of MSC B is
performed, a subsequent Location Update would probably occur, since it is not possible
to define the same Location Area within different MSCs. Thus such a cell reselection
shall be suppressed and only handovers shall be allowed.
Functional details
A Mobile Station is informed about the BCCH carriers to be monitored for either cell
reselection or handover purpose via system information messages. The relevant BCCH
Allocation list is included in the “Neighbor Cells Description” Information Element.
An MS in idle mode gets SYSTEM INFORMATION TYPE 2, 2bis and 2ter on the BCCH.
If a neighbour cell is included in the SYSTEM INFORMATION TYPE 2x, the MS
observes it for cell reselection. This means, that only in this case the MS measures the
DL receive level of this neighbour cell while it is in idle mode (the DL receive level is used
to calculate the C1 respectively C2 criterion for the ranking of the neighbour cells in the
MS internal book-keeping list for cell reselection, see chap. Cell changing and cell rese-
lection).
An MS in active mode gets SYSTEM INFORMATION TYPE 5, 5bis and 5ter on the
SACCH. If a neighbour cell is included in the SYSTEM INFORMATION TYPE 5 on the
SACCH, the MS regards it as a target cell for handover. This means, that only in this
case the MS measures the DL receive level of this neighbour cell while it is in busy mode
and reports it to the BTS via the SACCH. This again is the precondition for any outgoing
intercell handover decision by the BTS.
If the BA lists are different between SYSTEM INFORMATION TYPE 2x (= SI2) and
SYSTEM INFORMATION TYPE 5x (= SI5), the BSC has to assign complementary BA
indicators (possible values 0 or 1; 3GPP parameter: BA_IND) to SI2 and SI5. Corre-
spondingly the MS indicates which BA list it currently uses by the BA_USED flag (3GPP
parameter) included in the MEASUREMENT REPORT. This is necessary as the MS
may report the neighbour cells based on SI2 though in dedicated mode (e.g. directly
when the MS has changed from idle to busy mode, but has not yet read the new BA list
from the SI5) and the MS reports the neighbours always by their relative BCCH fre-
quency number. To correctly translate this relative BCCH frequency number into the
CGI of the neighbour cell, the BTS must know for which BA list the MEASUREMENT
REPORT is valid.
Attributes
The USG (“usage“) attribute subordinate to the ADJC object determines in which system
information messages an adjacent cell is included. The following USG values are pos-
sible:
• USG = SI_2: The neighbour cell is only broadcast in the SYSTEM INFORMATION
TYPE 2x. Thus only MSs in idle mode get this information and only cell reselection
to this neighbour cell is possible, while this cell is blocked for outgoing inter-cell han-
dover.
• USG = SI_5: The neighbour cell is only signalled in the SYSTEM INFORMATION
TYPE 5x. Thus only MSs in dedicated mode get this information and only outgoing
48 Id:0900d8058052e632 A50016-G5100-B556-04-7620
inter-cell handover to this neighbour cell is possible, while this cell is blocked for cell
reselection.
• USG = SI_2_5: The neighbour cell is included in both SYSTEM INFORMATION
TYPE 2x and SYSTEM INFORMATION TYPE 5x. Both idle and active MSs get the
neigbour cell information. Thus both cell reselection and outgoing inter-cell
handover to this neighbour cell is possible.
• USG = INACTIVE: The neighbour cell is only signalled in the SYSTEM INFORMA-
TION TYPE 5x in order to have the cell measured and reported by the MS –
however, outgoing inter-cell handover to this neighbour cell is not triggered by the
BTS, as the cell is only considered for measurement purposes.
The default value is SI_2_5.
3.9.2 Adjacencies to UMTS cells

ADJC3G objects and the ADJC3G list
The ADJC3G objects comprise the target cell information for inter-system handovers
from the GSM cell to a UMTS cell, one instance is set up for each adjacent UMTS cell.
The concept of the ADJC3G object is similar to the ADJC object concept. An ADJC3G
object instance contains the TGTCELL parameter which points to the related TGTFDD
or TGTDD object instance. TGTFDD is the managed object for a cell operated in FDD
mode, TGTTDD is for TDD mode. Both objects contain all the parameters which char-
acterize the affected UMTS cell, like:
– CGI: Cell Global Identity, consisting of MCC and MNC (specified by the RNC), LAC
and CI (specified on cell level in the UC object)
g The CGI for GSM is defined differently.
– MSTXPMAXUMTS (“msTxPwrMaxUmts”): Maximum transmission power level
(dBm) a mobile station is allowed to use in the UMTS cell
– RNCID: RNC Identification
– FDDARFCN or TDDARFCN: Frequency of the BCCH of the UMTS cell
g For TD-SCDMA adjacent cells an offset is added to the value of the TDDARFCN
which is enabled by setting bit 45 of the MNTBMASK attribute to 1, see proce-
dure Enabling interworking with TD-SCDMA.
Creating a UMTS adjacent cell

To define a UMTS neighboring cell for a specific BTS object instance, the user must
create an instance of the ADJC3G object (subordinate to the BTS object).
For each BTS object instance, the user can define up to 64 neighboring UMTS cells
(ADJC3G objects). More in detail, when defining the frequency and the cell type (FDD
or TDD) of the UMTS adjacent cells, the following rules must be obeyed by the user:
– Max. 3 different frequencies for cell type (FDD or TDD)
– Max. 32 ADJC3G objects for each frequency/cell type (FDD or TDD)
The creation of the ADJC3G object instance is similar to the creation of an ADJC object
for a GSM adjacency to an external cell; the user must set the following attributes:
1. NAME: represents the complete path related to the ADJC3G object instance;
2. TGTCELL: specifies the path to the target cell instance; this reference points to one
of the following objects:
A50016-G5100-B556-04-7620 Id:0900d8058052e632 49
– TGTFDD: contains the attributes characterizing a neighbour UMTS FDD cell;

e.g. IHSPA = TRUE indicates that the 3G cell provides HSDPA (high speed
downlink packet access) in downlink and HSUPA (high speed uplink packet
access) in uplink direction.
– TGTTDD: contains the attributes characterizing a neighbour UMTS TDD cell.
So, before creating the ADJC3G object related to a UMTS neighboring cell of a specific
BTS, the user must have already created either the TGTFDD or the TGTTDD object
defining the UMTS cell.
Much more attributes can be configured in the ADJC3G object, all attributes are
described in the BSC commands and eBSC commands manuals.
3.10 Barring a cell and barring access classes

Barred cell
A cell in barred state means that camping or any other access to the cell is forbidden.
This has the following consequences:
– RACH access to the cell is not allowed anymore.
– All mobiles in idle mode perform a cell reselection.
– Existing calls are continued and handovers to this cell are still possible but as soon
as the busy MSs return to idle mode they perform a cell reselection, too.
The BSC can automatically set a cell to the barred state if all TCHs or all SDCCHs are
locked. A cell is also barred for about 10 s if the hopping mode changes.
Attributes:
The operator can bar a cell by setting the CELLBARR (“cellBarred”) attribute to TRUE.
Barred access class
For MSs there are 15 access classes (1 to 15; classes 1 – 9 are ordinary subscribers,
class 10 is a mobile emergency call, classes 11 – 15 are priorized subscribers). Each
class can be explicitly barred for access to the cell except for class 10. The information
stating which classes are barred is sent on the BCCH (SYSTEM INFORMATION TYPE
1, 2, 3 and 4) in the “RACH Control Parameters” IE. If the MS receives the indication that
its access class is barred, it remains camping in the cell but it is not allowed to perform
a RACH access anymore. On the mobile phone, there is no special indication on the
display if the SIM's access class is barred while the MS is already booked in, the sub-
scriber only notices an immediate call rejection when he tries to set up a call.
For the MS there is a big difference between a barred cell and a barred access class:
When the MS receives the “cell barred” indication in the SYSTEM INFORMATION
message, it immediately performs a cell reselection. If the SYSTEM INFORMATION
indicates that its access class is barred, the MS stays in the cell.
Attributes:
Barring of an access class, e.g. class 5, is done by setting the value in the corresponding
list entry of the NALLWACC (“notAllowedAccessClasses”) parameter; here “na5” has to
be entered.
50 Id:0900d8058052e632 A50016-G5100-B556-04-7620
3.11 Sleeping cell and TRX detection

A cell or a TRX is referred to as "sleeping", if no Mobile Station is served by the cell/
TRX, but no alarm is generated and sent to the supervision systems (Radio Com-
mander, LMT Evolution). So a sleeping cell/TRX may be difficult to detect. The feature
“No call in cell or TRX detection” provides an effective means for early detecting the
sleeping cells/TRXs in order to allow the operator to trigger recovery actions. The
operator is informed in real time about possibly sleeping cells/TRXs. The following two
mechanisms are applied:
• For detecting sleeping cells, the SDCCH activations within the cell are supervised:
If at the end of the user configurable observation period no successful SDCCH
assignment could be registered, the alarm with error ID 66 – NO CALL IN CELL
WITHIN A PREDEFINED TIME FRAME is output (the alarm message includes infor-
mation whether the cell is barred/unbarred by O&M, if the cause is an SS7 fault and
user's access class information and overload barring classes). For this, the BSC
observes the number of ESTABLISH INDICATION messages for SDCCH received
from the observed BTS.
g The sleeping cell alarm will in any case be output if a BTS is barred (command:
CELLBARR). In many networks this approach is commonly used for cells which
are exclusively used as handover target. In this case these cells carry traffic but
issue the sleeping cell alarm due to missing SDCCH activity.
• For detecting sleeping TRXs, the TCH activations on each TRX are supervised:
If at the end of the observation period the TCH activation success rate is below a
fixed threshold, the alarm with error ID 70 – NO CALL IN TRX WITHIN A PRE-
DEFINED TIME FRAME is output (analogous content compared to the sleeping cell
alarm). For this, the BSC observes the number of CHANNEL ACTIVATION
ACKNOWLEDGE messages for TCH and the number of ESTABLISH INDICATION
messages for TCH. If for a certain TRX the difference between the number of
CHANNEL ACTIVATION ACKNOWLEDGE messages and the number of ESTAB-
LISH INDICATION messages is equal or greater than 8, the sleeping TRX alarm is
triggered.
g CHANNEL ACTIVATIONs are only considered in case of TCH activations for
CS TCH requests. Channel activations due to GPRS traffic are not considered
in the supervision mechanism; therefore the sleeping TRX alarm can never be
raised for TRXs which are exclusively used for GPRS traffic.

The ENANCD (“enableNoCallDetection“) attribute enables/disables the “No call in cell
or TRX detection” functionality. Two time zones (representing high-traffic time and low-
traffic time, e.g. for daytime and night time traffic) can be defined, in which the activity of
the cell respectively the TRX is observed within time zone specific observation periods,
defined by the parameters NCDP1 and NCDP2. For both alarms the ceasing of the
alarm can take place at the earliest at the end of the next observation period if in this
period the alarm condition has ceased (successful activities). A fast alarm clearing
mechanism is provided (clearing within 10 minutes) via an alarm ceased notification.
The parameters NCDP1 (“noCallDetectionPeriod1“) and NCDP2
(“noCallDetectionPeriod2“) allow to configure the first time-frame for the “sleeping
TRX/cell detection” procedure for time zone 1 and 2. The fields “startTime1/2” represent
the beginning of the time-frame, “timerNoCall1/2” represent the observation period.
A50016-G5100-B556-04-7620 Id:0900d8058052e632 51
Start sleeping Stop sleeping

cell/TRX alarm cell/TRX alarm
Sleeping cell/TRX Sleeping cell/TRX

alarm active alarm ceased
No successful Successful Successful

SDCCH SDCCH SDCCH
assignments assignment assignment
... ...
timerNoCall1 timerNoCall1 timerNoCall1 timerNoCall2 timerNoCall2
(Observation period)
startTime1 startTime2
Time zone 1 Time zone 2
Figure 20 Sleeping cell and TRX detection
52 Id:0900d8058052e632 A50016-G5100-B556-04-7620
Radio network management Channels
4 Channels
Physical channels, the carriers for transmitting data between MS and BTS, are
described only as far as radio network configuration from the BSC point of view is con-
cerned here, see 4.1 Physical channels. The logical channels described in chap.
4.2 GSM logical channels and channel combinations and 4.3 GPRS logical channels
carry control information and data to be transmitted via the radio resources. Chap.
4.4 Creation and configuration of radio channels shows how the TRX channels are con-
figured in order to map/multiplex the logical channels onto the TRX channels.
4.1 Physical channels

The GSM system employs a combination of frequency division multiple access (FDMA)
and time division multiple access (TDMA). Data transmission is done on radio carriers
with 200 kHz bandwidth taken from frequency bands described in the previous chapter
Cells, frequencies and transceivers.
The FDMA part is related with the distribution of calls on different radio carriers (with dif-
ferent radio frequencies). Therefor transceivers (TRXs) have to be configured in the
Radio Network, the mapping of the calls to appropriate radio carriers is performed during
the Radio Channel Allocation procedure (see chap. Radio channel allocation).
TDMA is applied by dividing a determined time interval for data transmission on one
radio carrier in 8 portions called timeslots and allocating different calls to the timeslots.
The data portions related to the timeslots are transmitted sequentially and in order, so
every 8th step the same timeslot is affected. Each timeslot on a given radio frequency
represents one physical channel (in (E)GPRS it is called PDCH, physical data channel),
and a transceiver with a certain radio frequency can provide up to 8 different connec-
tions. Figure 21 illustrates the TDMA concept for GSM. A complete turn of the 8
timeslots is called TDMA frame.
RADIOCHANNEL
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
MS 4$-!FRAME
MSBITS
Figure 21 TDMA frame structure and radio channels

Within the duration time of one timeslot just one so-called radio burst is transmitted
including a load of 114 bit for data (many other bits for training sequence, guard period
etc. shall not be considered here). These 114 bit carry the information to be transmitted
in an encrypted form (e.g. for error correction after reception). Regarding the Abis inter-
face, the smallest data size entering the radio network is the so-called Radio Block with
a data load of 456 bit. So, exactly four bursts transmit the data of one Radio Block, or –
in other words – a Radio Block needs four subsequent TDMA frames to deliver its
content via the air interface (see Figure 22).
A50016-G5100-B556-04-7620 Id:0900d805804c48db 53
Channels Radio network management
43 4$-!FRAME 4$-!FRAME 4$-!FRAME 4$-!FRAME

43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
2ADIO 2ADIO 2ADIO
"LOCK "LOCK "LOCK
Figure 22 Radio blocks

All TDMA frames are aligned within a cell area (even within a site, i.e. a BTSM area,
where all BTSs are time synchronized). In downlink direction this is straightforward done
by the BTS; in uplink direction the BTS instructs an MS to send its bursts in such a way
that each signal arrives at the BTS three timeslots later than the corresponding downlink
timeslot is sent. Therefor an MS far away from the BTS has to send its bursts with a
certain delay depending on the distance to the BTS. The information about the distance
between MS and BTS is carried in the Timing Advance (TA) parameter indicating the
round trip delay time (delay after one downlink and one uplink transmission, i.e. twice
the delay of an unidirectional burst due to the distance) as a number of bit periods.
Multiframes
The TDMA frames are organized in multiframes. The following types are used:
• Multiframes comprising 26 consecutive TDMA frames are used for GSM traffic chan-
nels, see Figure 23. The 13. frame is occupied for SACCH reports, the 26. frame is
idle in case of full rate traffic channels and is occupied for SACCH reports in case of
half rate traffic channels. All other frames carry user’s traffic data.
-ULTIFRAMEWITHFRAMESFORA428WITHTRAFFICCHANNELSMS

4#(S 4#(S 4#(S 3!##(S 4#(S 4#(S )DLE

3!##(S
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
4$-!FRAME
4#(S4RAFFIC#HANNELS3!##(S3LOW!SSOCIATED#ONTROL#HANNELS
Figure 23 Multiframes for GSM traffic with 26 TDMA frames
54 Id:0900d805804c48db A50016-G5100-B556-04-7620
• Multiframes comprising 51 consecutive TDMA frames are used for GSM signalling
channels, see Figure 24. Different kinds of signalling channels can be multiplexed
onto one physical channel within the multiframe.
-ULTIFRAMEWITHFRAMESFORA428WITHSIGNALLINGCHANNELSMS

43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
43
4$-!FRAME
Figure 24 Multiframe for GSM signalling with 51 TDMA frames

• Multiframes comprising 52 consecutive TDMA frames are used for GPRS channels
(both packet data traffic channels and packet data control channels), see Figure 25.
These multiframes are similar to the usual GSM 26-multiframes for traffic channels.
the 13th and the 39th TDMA frame are used for Packet Timing Advance Control, the
26th and the 52nd TDMA frame are idle frames. So 12 blocks (with 4 TDMA frames
each) remain for traffic and signalling.
B0 B1 B2 t B3 B4 B5 i B6 B7 B8 t B9 B10 B11 i
B0, B1, ... : Radio Block 0, Radio Block 1, ... (4 TDMA frames per Radio Block)
t: Packet Timing Advance Control (1 TDMA frame)
i: Idle (1 TDMA frame)
Figure 25 Multiframe for PS services with 52 TDMA frames

1326 TDMA frames (i.e. 51 26-multiframes or 26 51-multiframes) form a superframe.
After 1 superframe the relation pattern between signalling and traffic TDMA frames is
repeated.
2048 superframes or 2 715 648 TDMA frames form a hyperframe. 1 hyperframe has a
duration of 3 h 28 min 53 s and 760 ms and is used for synchronization in the encryption
process. The TDMA frames in a hyperframe are numbered with 0,1, 2 …, 2 715 647
(Frame Numbers, FN).
Attributes
The radio frequency of a certain radio carrier is set in the TRX object (see chap. Cells,
frequencies and transceivers).
The CHAN objects are subordinate to the TRX object. Each of them (CHAN:0 ...
CHAN:7) represents one physical radio channel denoted by the number of the associ-
ated timeslot. Details for the configuration of the CHAN attribute are described in
A50016-G5100-B556-04-7620 Id:0900d805804c48db 55
4.4 Creation and configuration of radio channels and take into account the logical
channels to be multiplexed on a physical channel.
4.2 GSM logical channels and channel combinations
4.2.1 Logical channels

Table 6 shows the logical channels defined for GSM and their hierarchical organization.
Group Subgroup Channel Function Direction

Traffic Traffic Channels TCH/F Traffic Full Rate MS <–> BSS
TCH/H Traffic Half Rate MS <–> BSS
Control Broadcast Channels BCCH Broadcast Control MS <– BSS
FCCH Frequency Correction MS <– BSS
SCH Synchronization MS <– BSS
Common Control Channels RACH Random Access MS –> BSS
AGCH Access Grant MS <– BSS
PCH Paging MS <– BSS
NCH Notification MS <– BSS
Dedicated Control Channels SDCCH Stand-alone Dedicated Control MS <–> BSS
SACCH Slow Asscociated Control MS <–> BSS
FACCH Fast Associated Control MS <–> BSS
Combined Combined Channel TCH/ Stand-alone Dedicated Control or MS <–> BSS
SDCCH Traffic
Table 6 GSM logical channels
Broadcast channels (BCHs) are defined for the downlink direction (from BTS to MS)
only and are subdivided into:
– BCCH: Broadcast Control Channel which is defined on a per cell basis and informs
the Mobile Station about the various parameters to be used in the cell
– FCCH: Frequency Correction Channel which supports the exact frequency tuning of
the Mobile Station
– SCH: Synchronization Channel which sends to the Mobile Station information about
the frame number and the BSIC (Base Station Identity Code)
Common control channels (CCCHs) are specified as unidirectional channels, either
on the downlink or on the uplink. There are three types of subchannels:
– PCH: Paging Channel which is used in the downlink direction to page Mobile
Stations
– RACH: Random Access Channel which is an uplink channel to indicate a Mobile
Station request for a dedicated channel
– AGCH: Access Grant Channel, also used in the downlink direction to assign a ded-
icated channel to a Mobile Station
56 Id:0900d805804c48db A50016-G5100-B556-04-7620
Dedicated control channels (DCCHs) are full duplex (bidirectional) channels. They
are subdivided into:
– SACCH: Slow Associated Control Channel which is a duplex channel always asso-
ciated with a TCH or SDCCH (embedded within the same frame structure). The
SACCH is used for the transmission of the radio link measurements and other layer
1 data as well as SMS messages in the event that an MS is in active mode.
– SDCCH: Stand alone Dedicated Control Channel which is a duplex channel
normally assigned after the MS request and that is used for signalling purposes, for
setting up the calls or other network procedures as well as for the transmission of
SMS messages to/from mobiles in idle mode.
– FACCH: Fast Associated Control Channel, which is a duplex channel always asso-
ciated with a TCH, used for the transmission of signalling data, after the call has
been set up and when the SDCCH has already been released. The FACCH data are
inserted into the TCH burst in place of traffic data (bit stealing). This insertion is indi-
cated by a "stealing flag".
– CBCH: Cell Broadcast Channel which provides cell broadcast information from the
Short Message Service Cell Broadcast (SMS-CB). This channel shares resources
with the SDCCH.
A combined channel (TCH/SDCCH) is usable as TCH/F, TCH/H or SDCCH. The BSC
decides the usage mode of this channel and informs the BTS on call basis. For more
information on the combined channel, please refer to 4.2.3 Combined channel.
4.2.2 Channel combinations

The following combinations of logical channel types – specified by the GSM Recommen-
dation 05.02 – can be multiplexed on a single physical channel (one transmission fre-
quency and one certain timeslot). In the following list “...CH/F” means that Full Rate
channels are supported, “...CH/FH” means that Full Rate and Half Rate channels are
supported.
1. BCCH + FCCH + SCH + CCCH
This configuration carries all common control channels and is used in timeslot 0 of
the BCCH carrier (Figure 26 shows the multiplexing scheme).
2. BCCH + FCCH + SCH + CCCH + SDCCH/4 (0..3) + SACCH/2 (0,1)
This configuration carries all the common control channels plus SDCCHs and
SACCHs. It is used in timeslot 0 of the BCCH carrier, principally in small cells (Figure
27 shows the multiplexing scheme). SDCCH/4 means 4 SDCCH blocks, i.e. 16
frames, in one 51-multiframe; SACCH/2 means 2 SACCH blocks accordingly.
3. FCCH + SCH + BCCH + CCCH + SDCCH/4 + SACCH/2 + CBCH
This configuration is similar to the configuration 2 but also supports cell broadcast
service (one radio block within the 51-multiframe for CBCH). It is used in timeslot 0
of the BCCH carrier, principally in small cells.
4. BCCH + CCCH
This channel configuration is always used in conjunction with configuration1 and can
be configured in even-numbered timeslots (2, 4 and 6) of the BCCH carrier. It is used
when the signalling capacity of configuration 1 is no longer sufficient.
5. SDCCH + SACCH
This configuration carries additional SDCCHs with their associated SACCHs. Its
usage is permitted in any timeslot of any carrier except timeslot 0 of the BCCH
carrier (Figure 26 shows the multiplexing scheme).
A50016-G5100-B556-04-7620 Id:0900d805804c48db 57
6. SDCCH + SACCH + CBCH

Similar to configuration 5, with an additional CBCH as subchannel No. 2 of SDCCH.
Its usage is permitted in any timeslot of any carrier except timeslot 0 of the BCCH
carrier.
7. TCH/F + FACCH/F + SACCH/F
This combination represents the configuration for a standard full rate traffic channel.
24 frames of a 26-multiframe are occupied by TCHs, the 13. frame is for SACCH,
the 26. frame is idle, FACCH is multiplexed on the TCHs (stolen from the TCHs).
8. TCH/FH + FACCH/FH + SACCH/FH
This is the configuration supporting full rate and half rate traffic channels.
9. SDCCH/8 + SACCH/2 + TCH/H(0,1) + FACCH/H(0,1) + SACCH/H(0,1) or TCH/F +
FACCH/F + SACCH/F
For more information on configuration 9, please refer to 4.2.3 Combined channel.
Figure 26 and Figure 27 show examples for the configuration of control channels.
#(490%-!)."##(
43
43
43
43
43
43
43
43
43
43
43
43
"##(###(&##(3#(
4$-!FRAME 4$-!FRAME
$OWNLINK
& 3 "##( ###( & 3 ###( ###( & 3 ###( ###( & 3 ###( ###( & 3 ###( ###(

5PLINK
2 22 2 2 2 2 2 2 2 2 22 22 2 2 2 2 2 2 2 2 22 22 2 2 2 2 2 2 2 2 22 22 2 2 2 2 2 2 2 2 22 2 2
&&##(33#(22!#(
#(490%3$##( ANYTIMESLOT
43
43
43
43
43
43
43
43
43
43
43
43
3$##(3!##(
4$-!FRAME 4$-!FRAME
$OWNLINK
3$##( 3$##( 3$##( 3$##( 3$##( 3$##( 3$##( 3$##( 3!##( 3!##( 3!##( 3!##(

5PLINK
3!##( 3!##( 3!##( 3$##( 3$##( 3$##( 3$##( 3$##( 3$##( 3$##( 3$##( 3!##(
Figure 26 Example configuration of control channels
58 Id:0900d805804c48db A50016-G5100-B556-04-7620
#(490%-"##(#
43
43
43
43
43
43
43
43
43
43
43
43
"##(###(&##(3#(3$##(3!##(
4$-!FRAME 4$-!FRAME
$OWNLINK
& 3 "##( ###( & 3 ###( ###( & 3 3$##( 3$##( & 3 3$##( 3$##( & 3 3!##( 3!##(

5PLINK
3$##( 2 2 3!##( 3!##( 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 3$##( 3$##( 2 2 3$##(
&&##(33#(22!#(
Figure 27 Combined configuration of control channels

Up to four channel combinations containing SDCCH subchannels can be equipped on
each TRX.
Attributes
The multiplexing of a combination of logical channels onto one physical channel is con-
figured by the CHTYPE attribute (“channelCombination”) of the CHAN object, which rep-
resents one timeslot of the superordinate TRX (see 4.4 Creation and configuration of
radio channels).
4.2.3 Combined channel

A combined channel, also called TCH/SD, is a radio resource which can be used either
as TCH or as SDCCH. The combined channel has been introduced to avoid blocking of
call setups in cases of unexpected high SDCCH loads generated by high SMS traffic or
in specific areas (e.g. airports, train stations, fairs or PLMN borders). If there is a lack of
TCHs (but sufficient SDCCHs), a combined channel is used as TCH; if there is a lack of
SDCCHs, the combined channel is used as SDCCH. The assignment is carried out
automatically (according to user configuration) by the BSC without additional operator
interaction. The BTS is informed by the CHANNEL ACTIVATION message for the
involved time slot.
The user sets up combined channels, by setting the CHTYPE attribute of the CHAN
object to TCHSD during channel creation. The TCH/SD channel is able to support
TCH/F, TCH/H or SDCCH/8 configuration.
Channel pools
Figure 28 shows how the available TCH/SD channel resources are administrated with
the help of channel pools in order to assign appropriate resources in case of a TCH or
SDCCH request. These channel pools allow a dynamic on-demand extension of the
SDCCH capacity in case of SDCCH congestion.
A50016-G5100-B556-04-7620 Id:0900d805804c48db 59
4IMESLOT 43 43 43 43 43 43 43 43
#(490% 3$##( 4#(3$ 4#(3$ 4#(3$ 4#(3$ 4#(3$ 4#(3$ 4#(&5,,

#(0//,490 3$##(0//, 4#(3$0//, 4#(3$0//, 4#(3$0//, 4#(0//, 4#(0//,
3$##(0OOL 4#(3$##(0OOL 4#(0OOL
3ECOND
&IRST (IGH !SSIGNMENT &IRST
!SSIGNMENT 3$##( !TTEMPT !SSIGNMENT
!TTEMPT ,OAD !TTEMPT
3$##(2EQUEST 4#(2EQUEST
3ECOND
!SSIGNMENT 3$##("ACKUP0OOL
!TTEMPT
Figure 28 Example of timeslot configuration and pool assignments

Three channel pools are defined:
– SDCCH_POOL: Channels in this pool behave as SDCCH/4 or SDCCH/8 channels.
– TCH_POOL: Channels in this pool behave as TCH/F or TCH/FH channels.
– TCH_SD_POOL: Channels in this pool behave as SDCCHs or TCHs depending on
the traffic scenario.
Each TCH/SD must be assigned to one of these pools during its creation; the pool is
chosen by setting the CHPOOLTYP attribute related to the CHAN object.
The CHPOOLTYP attribute can be changed via a SET CHAN command, without any
notification to the BTS. In this way the usage mode of TCH/SD channels, in other words
the amount of channels allocateable as SDCCHs or as TCHs, can be changed, without
causing a loss of service on the TRX (the usual configuration of SDCCHs and TCHs with
the CHTYPE attribute (e.g. CHTYPE = SDCCH / TCHFULL) does not allow a change of
the usage mode without service interruption).
Within each pool the idle interference band classifies the resources. This classification
is also valid for the TCH/SD used as SDCCH.
Additionally there is the system internal, not configurable SDCCH_BACKUP_POOL,
which contains the idle TCH/SD channels that shall temporarily be used as SDCCHs.
Restrictions:
The following restrictions apply when using TCH/SD channels:
– Maximum 4 timeslots per carrier can be configured as SDCCH/8 or as TCH/SD
belonging to the SDCCH_POOL on BTS1 due to memory availability.
– In case of dual band cells (GSM 900, GSM 1800) the SDCCH/8 and TCH/SD used
as SDCCH must be configured in the BCCH frequency band.
– A configuration change from TCH to TCH/SD or vice versa (and from SDCCH to
TCH/SD or vice versa) implies deletion of the channel (DELETE command) and its
re-creation.
– Using Concentric (or Extended) Cells, the assignment of a TCH/SD channel to the
TCH_SD_POOL is possible only on the Complete (or Far) Area.
– In order to prevent Cell Barring, at least one TCH/SD channel must be belong to the
SDCCH_POOL.
60 Id:0900d805804c48db A50016-G5100-B556-04-7620
TCH/SD channel assignment

The BSC searches for a SDCCH and assigns appropriate resources according to the
following rules:
• In case the SDCCH_POOL is not empty, a SDCCH request is satisfied by assign-
ment of a resource from the SDCCH_POOL.
• In case of high SDCCH load, a TCH/SD channel configured for usage both as
SDCCH and TCH is moved to the SDCCH_BACKUP_POOL, thus increasing the
number of available candidates for SDCCH allocation; this process is executed,
when the SDCCH subchannel occupation (calculated by the sum of busy channels
from the SDCCH_POOL and SDCCH_BACKUP_POOL) exceeds the threshold
SDCCHCONGTH (“sdcchCongestionThreshold”) for a time period of more than 2 s.
• If a new SDCCH request arrives and the SDCCH_POOL is empty, the request is sat-
isfied by a resource from the SDCCH_BACKUP_POOL – if this pool is not empty (in
case of empty SDCCH_BACKUP_POOL an IMMEDIATE ASSIGNMENT REJECT
message is sent to the BTS).
In case of a TCH request the BSC assigns a channel according to the following rules:
• In case the TCH_POOL is not empty, the TCH request is satisfied by assignment of
a resource from the TCH_POOL.
• In case no TCH is available from the TCH_POOL, a new TCH can be assigned from
the TCH_SD_POOL.
Release of SDCCHs
SDCCHs which have become idle are returned to the pool where they are taken from in
the assignment step:
– If the sub-channel to be released belongs to the SDCCH_POOL, it is returned to that
pool.
– If the sub-channel to be released belongs to the SDCCH_BACKUP_POOL, it is
returned to that pool.
When all the sub-channels of a radio timeslot belonging to the
SDCCH_BACKUP_POOL are idle, the BSC checks the BSC TGUARDTCHSD attribute.
If its value is SEC00, the timeslot is immediately moved to the TCH_SD_POOL. Other-
wise a timer (set to TGUARDTCHSD) is started; if the timeslot is still idle on timer expi-
ration, it will be moved to the TCH_SD_POOL.
Attributes
The following parameters have to be configured for the combined channels:
• CHTYPE (“channelCombination”)
This attribute of the CHAN object defines the logical channel combination mapped
onto the physical channel (timeslot). The attribute value TCHSD indicates a
common channel. For more information about CHTYPE see 4.4 Creation and con-
figuration of radio channels.
• CHPOOLTYP (“channelPoolType”)
This attribute of the CHAN object assigns a TCH/SD channel to one of the three
possible pools of channels: TCH_SD_POOL,TCH_POOL or SDCCH_POOL. The
CHPOOLTYP attribute is not effective for other than TCH/SD channels.
A50016-G5100-B556-04-7620 Id:0900d805804c48db 61
• SDCCHCONGTH (“sdcchCongestionThreshold”)
This threshold is set on a per cell basis (its a subordinate object of the BTS object)
and triggers the moving of sub-channels from the TCH_SD_POOL to the
SDCCH_BACKUP_POOL.
• TGUARDTCHSD (“timerGuardTchsd”)
This timer is an attribute of the BSC object and is used in the SDCCH release pro-
cedure which moves the IDLE sub-channels from the SDCCH_BACKUP_POOL to
the TCH_SD_POOL.
4.3 GPRS logical channels

A new set of logical channels is defined for 2G GPRS. In parallel to circuit-switched
logical channels they are grouped as described in Table 7.
Group Channel Function Direction

Traffic Channel PDTCH Traffic Full Rate MS <–> BSS
Broadcast Channel PBCCH Packet Broadcast Control MS <– BSS
Common Control Channels PRACH Packet Random Access MS –> BSS
PAGCH Packet Access Grant MS <– BSS
PPCH Packet Paging MS <– BSS
PNCH Packet Notification MS <– BSS
Dedicated Control Channels PACCH Packet Associated Control MS <–> BSS
PTCCH Packet Timing Advance MS <–> BSS
Control
Table 7 GPRS logical channels
All kinds of logical channels can be included on one physical channel; no separation in
traffic or control channel is necessary between different physical channels. The differ-
entiation is managed with the help of a header for every radio block, which is the
smallest content unit and consists of four regular bursts.
Packet Data Traffic Channel (PDTCH)

A PDTCH is temporarily allocated to one Mobile Station for data transfer. Packet data
(user data, e.g. point-to-point), GPRS Mobility Management data (GMM) and Session
Management data (GSM) as well is transmitted via PDTCH. In the multislot operation,
one Mobile Station uses multiple PDTCHs in parallel for individual packet transfer (for
example it uses a PDTCH on each assigned physical data channel (PDCH)). All packet
data traffic channels are uni-directional:
• Uplink PDTCH (PDTCH/Up), for a mobile originated packet transfer
• Downlink PDTCH (PDTCH/Down) for a mobile terminated packet transfer
A PDTCH also includes its dedicated control channels. Regarding the PDTCH assign-
ment, the following restrictions must be satisfied:
PDTCH/Up ≤ 7
PDTCH/Down ≤ 16
62 Id:0900d805804c48db A50016-G5100-B556-04-7620
PDTCH/Up + PDTCH/Down ≤ 16
Packet Broadcast Control Channel (PBCCH)

Within the GSM network, system information messages are regularly broadcasted by
the BCCH and busy TCHs. With the support of system information the Mobile Station
can decide to access to the network starting from the current cell. The PBCCH logical
channel broadcasts Packet data specific System Information (PSI). In addition the
PBCCH reproduces the information transmitted on the BCCH, to allow circuit switched
operation to the Mobile Stations that support both the services. In this way, a Mobile
Station in GPRS attached mode monitors the PBCCH only, when this last is configured.
The presence of the PBCCH is not mandatory in a cell supporting packet data services;
if the PBCCH is not allocated, the packet data specific system information is broadcast
on the BCCH (in the SYSTEM INFORMATION TYPE 13 message).
Packet Common Control Channels (PCCCHs)

The GPRS/EGPRS common signalling is carried out either on already existing CCCHs
for usual GSM (shared CCCH) or on CCCHs allocated for GPRS/EGPRS only. These
channels are defined as PCCCHs.
– The Packet Paging Channel (PPCH) is used in downlink direction to page a Mobile
Station.
– The Packet Random Access Channel (PRACH) is used in uplink direction to initiate
packet transfer, used by the network to derive the initial estimation of the Timing
Advance.
– The Packet Access Grant Channel (PAGCH) is used in downlink direction to assign
resources to the Mobile Station on the Um interface.
– The Packet Notification Channel (PNCH) is used for notification of an MS group for
Point-to-multipoint (PTM) multicast (which is not yet supported in the current
software version).
Packet Dedicated Control Channels (PDCCHs)

Two types of packet dedicated control channels support the GPRS/EGPRS services:
• Packet Associated Control Channel (PACCH): The PACCH conveys signalling infor-
mation related to a given Mobile Station. The signalling information includes for
example acknowledgements and power control information. The PACCH also
carries resource assignment and re-assignment messages, comprising the assign-
ment of resources for PDTCHs and for further occurrences of the PACCH.
• Packet Timing Advance Control Channel (PTCCH): This type of channel is used in
the timing advance update procedure. The PTCCH/Up is used to transmit the
random access burst to allow the estimation of the timing advance for one Mobile
Station in packet transfer mode; the PTCCH/Down is used to transmit timing
advance information updates to several Mobile Stations.
4.4 Creation and configuration of radio channels

The configuration of a physical radio channel allows the mapping of logical channels
onto a physical radio channel, specifying its attributes. The mapping between a physical
channel and a timeslot on Abis interface is automatically executed by the BSS system.
The TRX supports up to 8 radio channels modelled by the CHAN object (0..7) – corre-
sponding to the 8 timeslots available.
A50016-G5100-B556-04-7620 Id:0900d805804c48db 63
When creating a new CHAN object, the user must set the CHTYPE attribute. This attri-
bute defines the logical channel combination mapped onto the physical channel
(timeslot), see Table 8.
CHTYPE Channel combination

MAINBCCH FCCH + SCH + BCCH + CCCH
MBCCHC FCCH + SCH + BCCH + CCCH +SDCCH/4 (0..3) + SACCH/C4 (0..3)
BCBCH FCCH + SCH + BCCH + CCCH + SDCCH/4 + SACCH/4 + CBCH
CCCH BCCH + CCCH
SDCCH SDCCH/8 + SACCH/C8
SCBCH SDCCH/8(0..7) + SACCH/C8(0..7) + CBCH
TCHFULL TCH/F + FACCH/F + SACCH/TF
TCHF_HLF TCH/H(0,1) + FACCH/H(0,1) + SACCH/TH(0,1) or
TCH/F + FACCH/F + SACCH/TF
TCHSD Channels can be used either as TCHF_HLF or SDCCH
Table 8 Setting channel combinations with the CHTYPE attribute
Restrictions and Notes:

– The channel combinations 1 to 4 can be used for timeslot 0 of the BCCH TRX only.
– Only one FCCH/SCH is allowed per cell.
– The first channel containing SDCCH (MBCCHC, BCBCH, SCBCH or SDCCH) must
be configured on the BCCH TRX.
– In a concentric cell (CONCELL = TRUE), the BCCH, CCCH and SDCCH can be put
only on a TRX serving the complete area (TRXAREA = COMPLETE).
43 43 43 43 43 43 43 43
428 "##( 3$##( 4#( 4#( 4#( 4#( 4#( 4#(
428 4#( 4#( 4#( 4#( 4#( 4#( 4#( 4#(
428 4#( 4#( 4#( 4#( 4#( 4#( 4#( 4#(
COMPLETEAREA INNERAREA
Figure 29 Example of channel configuration in a concentric cell

– In an extended cell (CELLTYPE = EXTCELL), all control channels must be set in
extended mode (EXTMODE = TRUE, this attribute is subordinate to the CHAN
object). Only radio timeslots with even numbers (0, 2, 4, 6) have to be used.
At least one double timeslot has to be configured to support the CS services in the
far area.
64 Id:0900d805804c48db A50016-G5100-B556-04-7620
43 43 43 43 43 43 43 43
428 "##(EXT 3$##(EXT 4#( 4#( 4#(EXT
428 4#(EXT 4#(EXT 4#( 4#( 4#( 4#(
NEARAREA FARAREA
Figure 30 Example of channel configuration in an extended cell

– A MBCCHC or a BCBCH can only be created, if NBLKACGR ≤ 2 (“noOfBlocks-
ForAccessGrant“).
4.4.1 Configuring channels for (E)GPRS usage

Creating PBCCH and PCCCH
If a cell supports packet switched services, timeslots can exclusively be reserved for
GPRS and EGPRS signalling services on channel basis by setting the GDCH (“gprs-
DedicatedChannel“) attribute of a CHAN object related to the BCCH TRX.
– GDCH = PBCCH statically allocates the channel as PBCCH. This channel will
support broadcast signalling (it will support also EGPRS signalling if the TRX is
enabled to support EDGE).
– GDCH = PCCCH statically allocates the channel as PCCCH. This channel will
support GPRS common signalling (it will support also EGPRS signalling if the TRX
is enabled to support EDGE).
Figure 31 shows an example for a BCCH TRX with PBCCH and PCCCH.
GDCH = GDCH =
PBCCH PCCCH
PBCCH+ Configured for

TRX:0 BCCH SDCCH PS/CS PS/CS PCCCH PS/CS PS/CS
PCCCH CS/PS service
Configured for
TRX:1 SDCCH CS CS CS CS CS CS CS
CS service only
Configured for
TRX:2 PS/CS PS/CS PS/CS PS/CS PS/CS PS/CS PS/CS PS/CS
CS/PS service
Configured for
CS/PS service
Configured
TRX:4 PS PS PS PS PS PS PS PS
for GPRS only
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7
Figure 31 Example of channel configuration including PBCCH and PCCCH
g (E)GPRS channels can only be configured for TRXs which are enabled to support
(E)GPRS (via Layers and Service Layer Lists, see chap. Service layer lists).
PBCCH and PCCCHs must be created on the BCCH TRX only (after having enabled
it to support GPRS).
For the near area of an extended cell at least 2 single timeslots have to be config-
ured to support EGPRS/GPRS services.
A50016-G5100-B556-04-7620 Id:0900d805804c48db 65
The presence of the PBCCH is not mandatory in a cell supporting PS data; if the PBCCH
is not allocated, the packet data specific system information is broadcast on the BCCH
(in the SYSTEM INFORMATION TYPE 13 message). The PBCCH, when configured, is
allocated/mapped on a PDCH (physical data channel). Only one PDCH can support the
PBCCH (like in the GSM system, where the BCCH channel always resides in the slot 0
of the BCCH TRX), i.e., it is not possible to configure the packet system information in
two different PDCHs.
PCCCHs do not have to be allocated permanently on the cell. When no PCCCHs are
allocated, the already configured CCCHs (carrying e.g. PCH, AGCH and RACH) are
used to execute the signalling operations in the same way and with the same function-
alities provided for the GSM services. The first PCCCH is automatically allocated when
the PBCCH is configured, and it resides in the same PDCH containing also the PBCCH.
When more packet common signalling resources are needed, another PCCCH can be
configured in another PDCH.
Further specifications regarding the reservation of blocks on a multiframe for
PBCCH/PCCCH are described in chap. Multiframe configuration for PBCCH/PCCCH.
Reserving and limiting PDCHs for (E)GPRS on TRX and cell basis
The complete set of radio channels (PDCHs) of a TRX can be reserved for (E)GPRS
services via Layers and Service Layer Lists (see chap. Service layer lists).
Additionally, radio channels which are prepared for both CS and PS services via Layers
and Service Layer Lists can be reserved for PS services on cell basis via the PTPPKF
object. The attributes for reservation discriminate services (GPRS/EGPRS) and cell
areas (primary and complementary); the reserved channels belong to the first layer of
the Service Layer List of the indicated PS service which is shared with the CS services.
The following attributes determine the numbers of reserved PDCHs in the cell:
– GMANPRESPRM: Number of reserved GPRS PDCHs in the primary area of the cell
– GMANPRESCOM: Number of reserved GPRS PDCHs in the complementary area
of the cell. In case of a standard cell, only GMANPRESPRM is meaningful.
– EMANPRESPRM: Number of reserved EDGE PDCHs in the primary area of the cell
– EMANPRESCOM: Number of reserved EDGE PDCHs in the complementary area
of the cell. In case of a standard cell, only EMANPRESPRM is meaningful.
The GPDPDTCHA (“gprsPercentageOfDynamicPdtchAvailable“) attribute (range:
0..100) allows a weighting between PS and CS load: It indicates the percentage of
shared CS/PS radio channels which can be dynamically allocated to (E)GPRS calls.
Example:
In a cell, 3 TRXs are configured for CS and PS services including the BCCH TRX (see
Figure 31, TRX:0, TRX:2 and TRX:3). 1 channel among these 3 TRXs is occupied as
BCCH, 1 as SDCCH (the SDCCH of TRX:1 is not affected since this TRX is for CS
services only) and 2 as PBCCH and PCCCH, so 20 channels remain which are shared
for CS and PS traffic.
The GPRS parameters related to traffic shall be set as follows:
– GPDPDTCHA = 50 (i.e. 50%);
– GMANPRESPRM = 1, EMANPRESPRM = 1
(2 timeslots reserved for PDCHs)
Then, the resulting maximum number N of GPRS/EGPRS channels shared with CS
services is:
66 Id:0900d805804c48db A50016-G5100-B556-04-7620
N = (Number of shared timeslots for traffic – Number of reserved timeslots for traffic) ·
GPDPDTCHA/100 = (20 – 2) · 50/100 = 9
4.4.2 Multiframe configuration for PBCCH/PCCCH

If a channel is configured as PBCCH (GDCH = PBCCH), the radio blocks of the related
multiframe (52 TDMA frames) are used/shared for several subchannels:
In DL direction:
– PBCCH (e.g. PACKET SYSTEM INFORMATION messages)
– PAGCH (PACKET ACCESS GRANT REQUEST messages)
– PACCH
– PPCH (PACKET PAGING REQUEST messages)
– PDTCH (data transfer)
In UL direction:
– PRACH
– PACCH
– PDTCH
A channel configured as PCCCH (GDCH = PCCCH) is shared for the same subchan-
nels except for PBCCH.
The following attributes of the PTPPKF managed object specify the numbers of blocks
reserved for certain subchannels.
• BSPBBLK (“bsPbcchBlocks“): This attribute indicates the number of blocks allo-
cated to the PBCCH in a PBCCH multiframe in DL direction.
The field is coded as follows:
0 0 : Block B0 used for PBCCH

0 1 : Block B0, B6 used for PBCCH
1 0 : Block B0, B6, B3 used for PBCCH
1 1 : Block B0, B6, B3, B9 used for PBCCH
• BPAGCHR (“bsPagchBlocksReserved“): This parameter indicates the number of

blocks reserved for PAGCH, PDTCH and PACCH for a PBCCH/PCCCH multiframe
in DL direction.
The parameter is coded according to the following scheme:
0 0 0 0 : 0 blocks reserved for PAGCH, PDTCH and PACCH

0 0 0 1 : 1 block reserved for PAGCH, PDTCH and PACCH
... ...
1 1 0 0: 12 blocks reserved for PAGCH, PDTCH and PACCH
• BPRACHR (“bsPrachBlocksReserved“): This parameter indicates the number of

blocks reserved for PRACH on an UL PCCCH/PBCCH multiframe.
The parameter is coded according to the following scheme:
A50016-G5100-B556-04-7620 Id:0900d805804c48db 67
Coding Blocks reserved for PRACH

0 0 0 0 : none (default)
0 0 0 1 : Block B0
0 0 1 0 : Block B0, B6
0 0 1 1 : Block B0, B6, B3
0 1 0 0 : Block B0, B6, B3, B9
... ...
1 1 0 0: Block B0, B6, B3, B9, B1, B7, B4, B10, B2, B8, B5, B11
DL PBCCH Multiframe (GDCH = PBCCH) , BSPBBLK = 1 0 , BPAGCHR = 0 0 1 1
B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11
PAGCH +
PAGCH + PACCH +
PBCCH PACCH + PPCH +
PDTCH PDTCH
UL PBCCH/PCCCH Multiframe , BPRACHR = 0 0 1 1
B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 B10 B11
PRACH +
PRACH PACCH +
PDTCH
Figure 32 Example for a PBCCH multiframe configuration

The following rules apply:
1. The values of the BSPBBLK and BPAGCHR attributes have to be set in such way
to have at least one block of any type: PBCCH, PPCH and PAGCH. For instance if
BSPBBLK is set to 1 the maximum value for BPAGCHR is 9.
g The system does not refuse entering senseless values which may cause
blocking of the PBCCH functionality itself (e.g. reserving 12 PAGCH blocks
leaving no PPCH blocks).
2. The attribute BPRACHR has to be set to a value greater than 0 (which is guaranteed
by the default value).
g Also for this parameter the system does not refuse entering senseless values
which may cause blocking of the PBCCH functionality itself (e.g. reserving 0
PRACH blocks allows no more packet accesses in the cell).
For more details on the BSPBBLK, BPAGCHR, BPRACHR attributes, see the BSC
commands and eBSC commands manuals.
68 Id:0900d805804c48db A50016-G5100-B556-04-7620
Radio network management Coding and transmission modes
5 Coding and transmission modes
5.1 GSM channel coding for speech, data and signalling

channels
Before speech data, already having been speech coded (sampled, compressed etc.), is
transmitted via the radio interface, it has to be channel coded in order to allow error cor-
rection after transmission. Each channel type has its own coding scheme; however the
same sequence of operations is applied for all channels:
1. The information bits are coded with a block code (e.g. CRC or Fire Code) adding
parity and/or tail bits.
2. The resulting information + parity/tail bits are encoded with a convolutional code or
a turbo code. In this way redundancy is added; in many cases the data size is
doubled or roughly doubled.
3. The coded bits are reordered, an interleaving scheme is applied and stealing flags
are added.
All these operations are made block by block, the size of which depends on the channel.
The basic block size is 456 bit after channel coding, such a block is called radio block
and corresponds with the data size of 4 bursts. In case of a usual full rate speech TCH,
a radio block carries the information of one speech frame which has 260 speech bits. In
case of control channels, it carries one message. Each speech frame or radio block is
transmitted within 20 ms; so a speech frame of 260 bit refers to the net speech data
transmission rate of 13 kbit/s (which just corresponds with the usual GSM speech
coding), the 456 bit radio block refers to the gross data transmission rate of 22.8 kbit/s.
On the air interface the total capacity of one carrier frequency is 270.833 kbit/s, i.e.
about 33.9 kbit/s per timeslot. The difference between the 33.9 kbit/s (total capacity) and
the 22.8 kbit/s (gross data rate) is used for control (e.g. training sequence).
260 bit every 20 ms = 13 kbit/s
error correction overhead speech data

(channel coding) (speech coding)
456 bit every 20 ms = 22.8 kbit/s
Figure 33 Net and gross data transmission rate for GSM full rate speech
Background: Paths for speech frames

For the handling of speech coded data, both the BTS and the TRAU are concerned:
In uplink direction, the BTS applies channel decoding to the received speech data and
thus gets speech data blocks (speech frames). Then the BTS packs these speech
frames in so called TRAU frames, one TRAU frame per speech frame; the TRAU frames
pass transparently through the Abis interface, the BSC and the Asub interface and reach
the TRAU, where the speech data blocks are recovered and then converted into the 64
kbit/s PCM format at the A interface.
Vice-versa, in downlink direction, the speech data encoded in the 64 kbit/s PCM format
at the A interface is converted with the proper encoding law by the TRAU; the relevant
speech data blocks are embedded within TRAU frames and passed to the BTS where
the speech frames are channel coded.
A50016-G5100-B556-04-7620 Id:0900d8058052e614 69
Coding and transmission modes Radio network management
Figure 34 shows the frames and block types involved in the transport and radio trans-
mission of full rate speech data (including interleaving with a depth of 8).
The TRAU frame format used for speech channels is implemented according to the
GSM 08.60 Recommendation for FR and EFR coding laws; for HR it is a proprietary
format largely based on the GSM 08.61 Recommendation; the differences existing
between the GSM 900, GSM 1800 and the GSM 1900 applications reside only in the
PCM coding law used in European (A law) or American ( μ law) terrestrial networks,
both specified in ITU-T G.711 Recommendation; the correct PCM encoding is per-
formed by the TRAU on the speech data stream coming from or going to the A interface.
It should be noted that FR and EFR encoded speech blocks are transported through the
Abis and Asub interfaces at 16 kbit/s data rate, whereas the HR encoded speech blocks
are transported through the Abis interface at 8 kbit/s and through the Asub interface at
16 kbit/s.
Octet number
01 ... 39
01234567
Control bits
Bit number
Speech encoded data TRAU frame

(320 bit, 260 data bit)
Radio block N - 1 Radio block N (456 bit) Radio block N + 1

0123... 56
01234567
Bit number
Channel encoded data
odd bit
position
even bit
position Interleaving blocks
(2 x 57 bit each)
26 bit 8.25
57 bit data from 57 bit data from
radio block N
training
radio block N - 1
guard Normal burst
sequence bits
3 tail Stealing Stealing 3 tail

bits flag flag bits
Figure 34 Data frames and block types for full rate speech
Training sequence
Figure 34 also shows the structure of a normal burst containing a training sequence
between the data fields. There are 8 different training sequences for a normal burst.
From the BCC (Base Station Colour Code), which is transmitted downlink via the SCH,
70 Id:0900d8058052e614 A50016-G5100-B556-04-7620
the MS knows the TSC (Training Sequence Code) of the BCCH it has to select. The
appropriate TSC is necessary for the correct selection and decoding of the BCCH
bursts, especially if within a limited geographical area a frequency is used several times.
So, the BCC must correspond to the Training Sequence Code (TSC) assigned to the
BCCH of that cell.
Attributes:
• EEOTD (“enableEOTD“): This parameter represents the flag to enable the setting of
the TSC (Training Sequence Code) equal to the BCC (Base Station Color Code) for
all channels belonging to the BCCH TRX.
• TSC (“trainingSequenceCode“): This optional parameter specifies the Training
Sequence Code of the radio channel. If no value is entered, the BCC which has
been set during creation of the cell (CREATE BTS) is automatically selected.
Channel coding for full rate speech TCHs

Figure 35 shows the channel coding for a full rate speech TCH (FR, GSM 06.10 Rec-
ommendations). Other channel codings for speech TCHs are Half Rate (HR, GSM 06.20
Recommendations) and Enhanced Full Rate (EFR, GSM 06.60 Recommendations).
Speech Radio Block (TCH/FS)

Frame
Cyclic Code Convolutional

Reordering, Block Diagonal
on class I bits: Code
Partitioning, Interleaving
+ 3 bit parity on class I bits:
Stealing Flags Depth: 8
+ 4 bit tail Rate = 1/2
260 bit 267 bit 456 bit
class I: 182 bit class I: 189 bit class I: 378 bit

class II: 78 bit class II: 78 bit class II: 78 bit
Figure 35 Channel coding for full rate speech TCHs
Half Rate in comparison with Full Rate

Half rate speech TCHs (TCH/HS) operate with half the speech data transmission rate of
a full rate speech TCH (TCH/FS), i.e. 6.5 kbit/s instead of 13 kbit/s. This allows for a
virtual doubling of TCHs within the same RF bandwidth. On the other hand TCH/HSs
have a reduced quality mainly due to other speech coding.
The speech coding for half rate speech produces speech frames with 112 bits, which is
a bit less than half the size of the full rate speech frames (260 bits), and with different
ratios for class I bits (95 bits) and class II bits (17 bits). The channel coding for TCH/HS
is similar to the coding for TCH/FS, but modified in a way to get radio blocks with 228
channel encoded bits (half of 456 bits).
The half rate mode requires a much greater processing power of the speech compres-
sion algorithm in the Mobile Station as well as in the Transcoding Unit (TRAU) than FR.
As the number of manageable TCHs increases, a corresponding increase of the air
interface signalling channels (SDCCHs) are therefore required. The capacity gain
depends not only upon the percentage of half rate users within the network, but also
A50016-G5100-B556-04-7620 Id:0900d8058052e614 71
upon other parameters, such as the number of carriers of a cell/BTS and the
TCH/SDCCH load per subscriber. The following table shows an example of the capacity
gain versus the HR penetration and it is based on 25 mErl/TCH, 4 mErl/SDCCH and a
2-carrier BTS:
HR penetration in % 0 20 50 80 90 100
Capacity gain in % 0 9 33 73 91 120
Table 9 Capacity gain vs. half rate penetration
The HR introduction into an already existing mobile network is compatible with previ-
ously implemented frequency planning and cell engineering. No new frequencies (car-
riers) need to be added in order to increase capacity. Complex sectorization and cluster
rearrangements can thus be avoided.
Enhanced Full Rate in comparison with Full Rate

The Enhanced Full Rate (EFR) speech codec uses a more complex speech compres-
sion algorithm than the FR speech codec and a modified channel coding, leading to the
same speech data transmission rate on the air interface than for TCH/FSs (thus the
network capacity is unaffected). The major advantage of the EFR speech codec is that
it provides high speech quality (near-wireline speech quality at good radio frequency
signal levels). Moreover the performance is better under tandeming (mobile-to-mobile)
and noise conditions.
The speech frames for EFR carry 244 bits, the channel coding begins with an additional
cyclic code generating 16 additional parity/tail bits for each frame. On the resulting 260
bit frames, the same channel coding steps are applied as for TCH/FS.
EFR requires a much greater processing power of the speech compression algorithm in
the Mobile Station as well as in the Transcoding Unit (TRAU) than for FR. EFR can be
enabled/disabled on a per-BSC basis.
Channel coding for CS data channels and signalling

Table 10 and Table 11 show details about the channel coding for data TCHs and signal-
ling channels.
Data traffic channel Data frame Parity Tail Rate of conv. Radio block Interleaving
code depth
TCH/FR 14.4 kbit/s 290 bit 0 4 bit 294/456 456 bit 19
TCH/FR 9.6 kbit/s 4 · 60 bit 0 4 bit 244/456 456 bit 19
TCH/FR 4.8 kbit/s 4 · 60 bit 0 4 bit 244/456 456 bit 19
TCH/HR 4.8 kbit/s 60 bit 0 16 bit 1/3 228 bit 19
TCH/FR 2.4 kbit/s 72 bit 0 4 bit 1/6 456 bit 8
TCH/HR 2.4 kbit/s 72 bit 0 4 bit 1/3 228 bit 19
Table 10 Characteristics of channel coding for data TCHs
72 Id:0900d8058052e614 A50016-G5100-B556-04-7620
Signalling channel Signalling Parity Tail Rate of conv. Radio block Interleaving
frame code depth
FACCH Full Rate 184 bit 40 bit 4 bit 1/2 456 bit 8
FACCH Half Rate 184 bit 40 bit 4 bit 1/2 456 bit 6
SDCCH, SACCH 184 bit 40 bit 4 bit 1/2 456 bit 4
BCCH, NCH, AGCH, PCH 184 bit 40 bit 4 bit 1/2 456 bit 4
RACH 8 bit 6 bit 4 bit 1/2 36 bit 1
SCH 25 bit 10 bit 4 bit 1/2 78 bit 1
CBCH 184 bit 40 bit 4 bit 1/2 456 bit 4
Table 11 Characteristics of channel coding for signalling channels
5.2 14.4 kbit/s data transmission on a single timeslot

A channel coding increasing the data throughput of a single GSM timeslot to 14.4 kbit/s
is provided in order to meet the demand of higher data rate for modern data applications.
The 14.4 kbit/s coding can be used in combination with the GSM Phase 2+ multislot data
services, for example with HSCSD a single connection can reach a data rate up to 57.6
kbit/s (combining four timeslots). Both transparent and not-transparent connections are
supported.
The error correction mechanisms applied on 14.4 kbit/s data, transmitted via the Um
radio interface, is less effective compared to the one applied on 9.6 kbit/s data. As a
result the effective data rate of the 14.4 kbit/s coding, available to the user in non-trans-
parent mode or when an external end-to-end error control is applied, may drop below
the effective data rate achieved with the 9.6 kbit/s coding.
For this reason, a channel mode modify procedure in case of non-transparent mode
(upgrading and downgrading: 9.6 kbit/s –>14.4 kbit/s and vice versa) is implemented to
adapt the data rate appropriately to the C/I conditions. The BTS indicates the in-call-
modification to the BSC using the MODIFICATION CONDITION INDICATION message
which contains the suggested new data rate.
As it is foreseen in the GSM, the downgrading from 14.4 kbit/s to 9.6 kbit/s data rate is
not possible for a transparent call (both in case of the established call or during a
handover procedure). In transparent mode a 14.4 kbit/s call handover to a cell that does
not support the 14.4 kbit/s coding causes a drop.
g The usage of the 14.4 kbit/s coding in the TRAU is not supported by the TRAC V1
board.
Parameters
The SPEED145 attribute (subordinate to the BSC object) has been introduced for
enabling/disabling the 14.4 kbit/s data transmission on a single timeslot.
The following attributes have been introduced within the HAND object:
– ERUDGR: allows to enable/disable the evaluations for rate up/down-grading for
14.4 kbit/s data service
– TINHRUGR: the minimum time between an upgrade to 14.4 kbit/s and the next
downgrade request
A50016-G5100-B556-04-7620 Id:0900d8058052e614 73
– TINHRDGR: the minimum time between a downgrade to 9.6 kbit/s and the next
upgrade request
– RAVEW: specifies how many measurement samples are used in the gliding averag-
ing process for rate up-downgrading for 14.4 kbit data services
– RUGRUL: the upgrade threshold (9.6 kbit/s –> 14.4 kbit/s) for the uplink direction
– RUGRDL: the upgrade threshold (9.6 kbit/s –> 14.4 kbit/s) for the downlink direction
– RDGRUL: the downgrade threshold (14.4 kbit/s –> 9.6 kbit/s) for the uplink direction
– RDGRDL: the downgrade threshold (14.4 kbit/s –> 9.6 kbit/s) for the downlink direc-
tion
– RHOLTQUL: the receive signal quality threshold on uplink for the handover decision
for data calls where the rate up/downgrading mechanism is applied
– RHOLTQDL: the receive signal quality threshold on downlink for a handover
decision for data calls where the rate up/downgrading mechanism is applied
5.3 HSCSD
HSCSD (High Speed Circuit Switched Data) is a circuit switched service which offers a
higher data rate within one call of a mobile subscriber. The higher data rate is obtained
combining up to 4 consecutive timeslots in parallel (multislot connection).
Two types of multislot configurations exist:
• Symmetrical data transfer: The same data rates are transmitted in the uplink and
downlink direction. In this case only bi-directional channels exist.
• Asymmetrical data transfer: The data transmission rate in the downlink direction is
higher than in the uplink direction. This fulfills the needs of many applications (e.g.
of TCP/IP sessions), reduces the complexity of the Mobile Station and it reduces the
power consumption. An asymmetric connection is formed by both bi-directional and
unidirectional (downlink only) channels. Asymmetry is foreseen for not-transparent
data transmission.
Each HSCSD configuration includes one main traffic channel: a bi-directional channel
which carries also the main signalling (both FACCH and SACCH). All radio timeslots
used for one connection are Full Rate timeslots located on the same TRX and use the
same frequency hopping mode and the same TSC (Technical Service Center).
The group of radio channels available for HSCSD depends upon the hopping mode
used:
• In case of Base Band Hopping, on a given TRX only timeslots from 1 to 7 can be
used; single traffic channels equipped on these timeslots have to have the same
FHSYID. If one or more CCCH is already equipped, channels on the BCCH-TRX
cannot hop.
• In case of Synthesizer Hopping on a given TRX different from the BCCH one, all
single traffic channels have the same FHSYID and must have the same TSC.
Data rates
The data rate depends on the requested bearer capability and is negotiated between the
Mobile Station and the MSC. Multiples (up to 4 timeslots) of TCH/F 14.4 kbit/s, TCH/F
9.6 kbit/s and TCH/F 4.8 kbit/s are used for the data services (more robust channel
coding is required in case of poor radio conditions). The maximum transmission rate is
limited to 64 kbit/s; in this case the data stream of a call is solitarily multiplexed onto one
A interface circuit.
74 Id:0900d8058052e614 A50016-G5100-B556-04-7620
Resource allocation
The BSC is responsible for the flexible air resource allocation. It may alter the number
of TCH/F as well as the channel codings used for the connection. Reasons for the
change of the resource allocation may be either the lack of radio resources, handover
and/or the maintenance of the service quality. The change of the air resource allocation
is done by the BSC using ‘service level upgrading and downgrading’ procedures. For
transparent HSCSD connections the BSC is not allowed to change the user data rate,
but it may alter the number of TCHs used by the connection (in this case the data rate
per TCH changes). For non-transparent calls the BSC is also allowed to downgrade the
user rate to a lower value.
Handover
In symmetric mode individual signal level and quality reporting for each used channel is
applied. For an asymmetric HSCSD configuration individual signal level and quality
reporting is used for the main TCH. The quality measurements reported on the main
channel are based on the worst quality measured on the main and the unidirectional
downlink timeslots used. In both symmetric and asymmetric HSCSD configuration the
neighbour cell measurements are reported on each uplink channel used. All TCHs used
in an HSCSD connection are handed over simultaneously. The BSC may alter the
number of timeslots used for the connection and the channel codings when handing the
connection over to the new channels. All kinds of inter-cell handovers are supported,
intra-cell handover is possible only with cause ‘complete to inner’ or ‘inner to complete’.
Attributes
The following attributes are used for configuration of the HSCSD services:
– ENHSCSD (“enableHSCSD“): allows to enable/disable HSCSD services in the BSC
– BTSHSCSD (“btsHSCSD“): allows the activation of the HSCSD services in the cell
To increase the successful allocation probability of HSCSD calls, the ENFOIAHO
(“enableForcedIntracellHo”) attribute can be set to TRUE allowing forced intra-cell han-
dovers during the resource reallocation process in order to upgrade a downgraded
HSCSD call in case of congestion.
5.4 Adaptive multi-rate coding

Principle
The Adaptive multi-rate (AMR) feature adapts coding schemes for speech call data
according to the quality of the radio channel transmission resulting in changed transmis-
sion rates and changed robustness of transmitted data. It comprises:
• Channel mode adaptation: Dynamic switching between Full Rate and Half Rate
traffic channels due to the traffic load and the current radio channel quality reports.
• Codec mode adaptation: Dynamic selection of a speech codec from a pool of
codecs due to the current radio channel quality reports and the currently selected
channel mode. The different speech codecs are related to different levels of protec-
tion against radio transmission errors (channel coding).
Compared to the static speech codecs (resulting in Half Rate, Full Rate and Enhanced
Full Rate), which operate at constant bit transmission rates during a voice call, AMR
optimizes the data transmission rates for varying transmission conditions during calls
while keeping a good speech quality. In case of good radio channel quality, codecs with
A50016-G5100-B556-04-7620 Id:0900d8058052e614 75
low error correction facilities are chosen providing high data rates; in case of low radio
channel quality, codecs with high redundancy of data for good error correction are
chosen guaranteeing an acceptable speech quality.
In terms of speech coding (coding of the speech signal itself) and channel coding (result-
ing in the radio transmission error protection overhead), the different codecs offer differ-
ent balances between the bitrates for speech coded data and for error protection
overhead.
The estimation of the channel quality is based on measurements performed by the BTS
and the Mobile Station. The Mobile Station measures the downlink quality in the same
way as it does for the regular measurement reporting and the BTS derives quality values
from the uplink BER measurements.These measurements result in a Quality Indicator
comparable to the carrier to interference ratio. Additionally thresholds have to be defined
by the operator to have the AMR algorithm calculate the appropriate codec and codec
changes.

good radio conditions (channel coding) (speech coding)

poor radio conditions (channel coding) (speech coding)
16 kbit/s
Figure 36 AMR principle
Load dependent allocation of Half Rate traffic channels

With AMR enabled the selection of Full Rate or Half Rate traffic channels is load depen-
dent. If the percentage of busy TCHs is greater than a threshold, the BSC allocates a
half rate TCH (whenever possible), otherwise it allocates a full rate TCH. For a detailed
description of this strategy, please refer to the chapter “Cell Load Dependent Activation
of HR channels” in the section Radio channel allocation.
Narrowband and wideband AMR

Most speech coding systems in use today are based on a speech sampling rate of 8 kHz
deploying a typical bandwidth of speech between approx. 200 – 300 and 3400 Hz only
which limits the speech quality. Such speech codecs are used in today's wireline and
mobile networks including usual AMR (adaptive multi-rate) coding, here referred as nar-
rowband AMR.
Wideband AMR coding uses an increased speech sampling rate of 16 kHz, the
deployed bandwidth is extended and ranges from 50 to 7000 Hz. AMR wideband signif-
icantly improves the speech quality compared to today’s narrowband solutions and
allows for mobile applications requiring high quality audio parts.
76 Id:0900d8058052e614 A50016-G5100-B556-04-7620
Frequency spectrum of speech deployed with wideband AMR
Frequency spectrum
of speech deployed
with narrowband AMR
50 300 3400 7000

Hz Hz Hz Hz
Figure 37 Frequency spectrum of wideband AMR
Codecs
Three groups of different AMR codecs are provided:
– AMR codecs for full rate TCHs, based on a speech sampling rate of 8 kHz (usual
speech coding conditions)
– AMR codecs for half rate TCHs, again based on a speech sampling rate of 8 kHz
– Wideband AMR codecs for full rate TCHs, based on a 16 kHz speech sampling rate
Table 12 shows the available AMR codecs and the related data rates.
Channel and transmission mode AMR codec Speech data bit rate
TCH, full rate TCH/AFS12.2 12.2 kbit/s
8 kHz speech sampling rate TCH/AFS10.2 10.2 kbit/s
TCH/AFS7.95 7.95 kbit/s
TCH, half rate TCH/AHS7.95 7.95 kbit/s
8 kHz speech sampling rate TCH/AHS7.4 7.40 kbit/s
TCH/AHS6.7 6.70 kbit/s
TCH, full rate TCH/WFS12.65 12.65 kbit/s
16 kHz speech sampling rate TCH/WFS8.85 8.85 kbit/s
TCH/WFSS6.60 6.60 kbit/s
Table 12 AMR codecs and source codec bit rates
Examples:
TCH/AFS6.7 indicates the AMR codec for a full rate TCH and speech with a data rate
of 6.7 kbit/s, TCH/AHS5.15 indicates the AMR codec for a half rate TCH and speech
A50016-G5100-B556-04-7620 Id:0900d8058052e614 77
with a data rate of 5.15 kbit/s, TCH/WFS8.85 indicates the wideband AMR codec for a
full rate Traffic Channel and speech with a data rate of 8.85 kbit/s.
Information element for AMR

The information about AMR codecs to be used is carried by the “MultiRate configuration”
Information Element, see Figure 38. This Information Element is present in the following
messages within the radio access network:
– CHANNEL ACTIVATION (Abis)
– MODE MODIFY REQUEST (Abis)
– ASSIGNMENT COMMAND (Um)
– HANDOVER COMMAND (Um)
– CHANNEL MODE MODIFY (Um)
– DTM ASSIGNMENT COMMAND (Um)
Bit Number
8 7 6 5 4 3 2 1
Multirate speech configuration IE Identifier Octet 1
Length Octet 2
Multirate speech version NSCB ICMI Spare Start mode Octet 3
Set of AMR codec modes Octet 4
Spare Threshold 1 Octet 5
Hysteresis 1 Threshold 2 Octet 6
Threshold 2
Hysteresis 2 Threshold 3 Octet 7
(cont.)
Threshold 3 (cont.) Hysteresis 3 Octet 8
NSCB: Noise Suppression Control Bit

ICMI: Initial Codec Mode Indicator
Figure 38 MultiRate configuration IE for a set of 4 codec modes

Remarks:
– ICMI (Initial Codec Mode Indicator): This field indicates if the codec mode to be used
at the beginning of the transmission is defined by the Start mode field or implicitly by
3GPP standard rule.
– Multirate speech version: Version 1 includes narrowband speech codec modes only
while version 2 also includes AMR wideband speech codec modes.
– Set of AMR codec modes: Up to 4 codec modes can be included. Each bit position
is related to one AMR codec; the bit value 1 defines that the related codec is
included.
– If less than 4 codec modes are chosen, the information element is smaller.
78 Id:0900d8058052e614 A50016-G5100-B556-04-7620
BTS requirements
The availability of AMR Half Rate codec modes depends on the BTS version (there are
no restrictions regarding the Full Rate codec modes):
1. The mainline BTSs (“BTSplus”) support five 8 kbit/s sub-multiplexing half rate codec
modes: 4.75 kbit/s, 5.15 kbit/s, 5.90 kbit/s, 6.70 kbit/s, 7.40 kbit/s.
2. The legacy BTS1s (BS-20/21/22/60/61) support only the three lowest bit rates: 4.75
kbit/s, 5.15 kbit/s, 5.90 kbit/s. For the Half Rate Codecs with 6.70 kbit/s and 7.40
kbit/s there is not sufficient space in the proprietary TRAU frame.
3. Neither a BTS1 nor a mainline BTS supports the 7.95 kbit/s Half Rate Codec, which
needs a 16 kbit/s sub-multiplexing support.
Table 13 summarizes the narrowband AMR codecs supported by the two BTS types.
AMR FR codecs AMR HR codecs AMR FR codecs AMR HR codecs

supported by supported by supported by supported by
BTSplus BTSplus BTS1 BTS1
TCH/AFS 12.2 TCH/AFS 12.2
TCH/AFS 7.40 TCH/AHS 7.40 TCH/AFS 7.40
TCH/AFS 6.70 TCH/AHS 6.70 TCH/AFS 6.70
TCH/AFS 5.90 TCH/AHS 5.90 TCH/AFS 5.90 TCH/AHS 5.90
Table 13 Codecs supported by different BTS families
Application of wideband AMR codecs is not possible with BTS1; the carrier units (CUs)
must be of types ECU (enhanced carrier unit) or FlexCU (flexible carrier unit).
5.4.1 Link adaptation

The procedure of dynamically adapting the speech codec to the current radio channel
conditions is called Link Adaptation. When an AMR call is to be set up, the BSC sends
the AMR parameters to the BTS (via the CHANNEL ACTIVATION message) and to the
Mobile Station (via the ASSIGNMENT COMMAND message). These parameters
include the initial codec (to be used at first when the call has just been set up) and the
necessary threshold values for the AMR algorithm’s calculations. When a call has been
established, both the BTS and the MS continuously evaluate the radio interface quality.
Depending on the thresholds and on the results of the radio channel quality measure-
ments, the change to a suitable AMR codec is initiated. The decision for the codec
change is taken by the BTS where the increase/decrease of the radio conditions is
measured (uplink direction) or where a request for codec mode adaptation from the local
MS is reported to (downlink direction). Different codec modes can be applied for uplink
and downlink.
Link Adaptation is generally done by choosing a codec mode adjacent to the presently
used. When the channel quality is good, the BTS switches to the adjacent less robust
A50016-G5100-B556-04-7620 Id:0900d8058052e614 79
AMR codec mode; when the channel quality is poor, the BTS switches to the adjacent
more robust AMR codec mode providing better error correction.
If the BTS cannot find an adjacent more or less robust AMR codec, a codec modification
combined with handover is tried; for further information please refer to chap. Handover.
Threshold based codec selection

The adaptation algorithm uses some thresholds in order to decide when the switching
from the current codec to another codec has to be performed. For each pair of neigh-
boring codecs available, a threshold and a hysteresis value (a threshold offset) has to
be defined in terms of carrier to interference ratio. The threshold and the hysteresis
value trigger the change from one codec to the other. Figure 39 shows the connection
between neighboring codec modes and the related threshold and hysteresis values.
C/I
AMR Codec 4
Threshold + Hysteresis
AMR...TH34
Threshold

AMR Codec 3

AMR...TH23
Threshold

AMR Codec 2

AMR...TH12
Threshold
AMR Codec 1
Figure 39 Link adaptation thresholds

It is assumed that 4 codecs are available (in case of narrowband AMR to be included in
the Active Codec Set (see below); in case of wideband AMR only 3 codecs are avail-
able). The codec modes are numbered, a higher number means a codec with higher
throughput, but lower error correction facilities. The threshold values (in terms of C/I)
increase with higher numbering. Two codec changing events can happen:
• Upgrade: When the C/I value increases and reaches the threshold + hysteresis
value (upper threshold) for the transition between codec x and y (e.g. x = 2, y = 3),
the codec mode changes from codec x to codec y; in this case the channel quality
has improved before upgrade and allows to use a less robust codec mode providing
a higher data rate.
• Downgrade: When the C/I value decreases and reaches the threshold value (lower
threshold) for a transition between codec x and y (e.g. x = 2, y = 3), the codec mode
changes from codec y to codec x; in this case the channel quality has gone down
before downgrade which forces to use a more robust codec mode resulting in a
lower data rate.
Link adaptation signalling

The change of the codec is signalled in-band (within TCH) by 2 specific bits within the
Um speech frames (allowing the addressing of max. 4 codecs). Moreover, as each AMR
codec has its own TRAU frame format, each change of the AMR codec means a change
80 Id:0900d8058052e614 A50016-G5100-B556-04-7620
of the type of TRAU frame that is to be used between the BTS and the TRAU. The
change of the TRAU frame is also signalled in-band, i.e. within the AMR TRAU frames
exchanged between the BTS and the TRAU.
Figure 40 shows an example for link adaptation signalling for an AMR wideband codec
downgrade (for TFO see chap. 5.5 Tandem free operation).
-3 BTS1 TRAU1 TRAU2 BTS2 -3
TFO with original codec
Bad down-
link quality
detected
CMR: new codec

Decision (lower rate)
for codec
adaptation
CMR: new codec

CMR: new codec
CMR: new codec
CMC: new codec
(lower rate)
New
codec
is used
CMI: new codec

CMI: new codec
CMI: new codec
CMI: new codec
CMI: new codec
TFO with new codec
CMR = Codec Mode Request, CMC = Codec Mode Command, CMI = Codec Mode Indication
Figure 40 Example for signalling for an AMR wideband codec downgrade

The signalling is based on the following message types:
• CODEC MODE REQUEST (CMR)
CMRs are exclusively sent from MS to BTS. The purpose of a CMR is to request a
codec to be used for the downlink direction. If DTX (discontinuous transmission) is
not used, the CMR is continuously sent from the MS to the BTS even if no change
of the current codec is required. If the CMR request is correctly received by the BTS,
the BTS requests the corresponding downlink codec via a CMC from the TRAU.
• CODEC MODE COMMAND (CMC)
The CMC is sent from the BTS to the TRAU and the MS. Its purpose is to instruct
the TRAU and MS to use a specific codec. CMCs for the downlink direction are sent
from BTS to the TRAU within uplink TRAU frames to request the TRAU frame type
in correspondence with the codec required by the CMR from the AMR MS. The CMC
A50016-G5100-B556-04-7620 Id:0900d8058052e614 81
is sent to the TRAU after an averaging process in the BTS (parameter AMRAC-
MRDL in command SET HAND [BASICS]): The size of the associated 'averaging
window' for this process is defined in Codec Mode Requests (CMRs), i.e. the BTS
only instructs the TRAU to change the current downlink codec mode, if a sufficient
number of corresponding CMRs received from the MS have confirmed the request
to change the codec. CMCs for the uplink direction are sent from BTS to the MS in
the downlink bursts in order to indicate which codec the MS shall use for the uplink
speech frames.
• CODEC MODE INDICATION (CMI)
The CMIs are sent by MS, TRAU and BTS. CMIs are sent within the TRAU frames
as well as in the UL and DL speech frames. The purpose of the CMI is to indicate
which type of codec is currently used by the sending side, as the same codec must
be used to correctly decode the received speech signal, or TRAU frame, respec-
tively. The BTS inserts CMIs into downlink bursts according to the codec signaled
from the TRAU and into uplink TRAU frames according to the codec signaled by the
MS. The TRAU sets the CMI for the downlink TRAU frames as requested by the
CMC from the BTS. The MS sets the CMI in the uplink speech frames as requested
by the CMC received from the BTS.
5.4.2 Configurations for narrowband AMR

The AMR feature is basically set up by the following steps:
• Setting up the Active Codec Sets
• Setting the threshold values related to codec changes
• Determining the initial AMR codec during call setup
The following topics provide you with detailed information how to perform these tasks.
Further configurations concern intra-cell handovers between half rate and full rate AMR
traffic channels (compression/decompression handovers, see chap. Handover).
Active Codec Set

AMR codec adaptation is done within a restricted set of AMR codecs. This set is called
Active Codec Set (ACS) and can be composed by up to four codecs. The Active Codec
Set to be used by the BSS system and the Mobile Station is defined by default or by the
user. The user should specify two Active Codec Sets, one for Full Rate Traffic Channels
and one for Half Rate Traffic Channels – each with up to four codecs.
• Default Active Codec Set for Full Rate Traffic Channel (4 codecs):
– TCH/AFS12.2
– TCH/AFS7.95
– TCH/AFS5.9
– TCH/AFS4.75
• Default Active Codec Set for Half Rate Traffic Channel (4 codecs):
– TCH/AHS6.7
– TCH/AHS5.9
– TCH/AFH5.15
– TCH/AHS4.75
The codecs of the Active Codec Set are defined in each BTS by the parameters given
in Table 14. Different parameters are provided for full rate traffic channels and half rate
traffic channels with or without Frequency Hopping applied.
82 Id:0900d8058052e614 A50016-G5100-B556-04-7620
Full Rate TCH without Full Rate TCH with fre- Half Rate TCH without Half Rate TCH with fre-
frequency hopping quency hopping frequency hopping quency hopping
AMRFRC1 FHAMRFRC1 AMRHRC1 FHAMRFRC1
Table 14 Parameters for configuration of the Active Codec Set
For example AMRFRC1 defines the first codec mode (with the lowest bit rate) in the
ACS for a full rate traffic channel. If the ACS for full rate AMR shall consist of only 3 AMR
codecs, then AMRFRC4 has to be set to <NULL>; if it shall consist of only 2 codecs,
then AMRFRC3 has also to be set to <NULL>. For AMRFRC1 the value <NULL> is not
allowed, as at least one codec has to be defined within an ACS.
The codecs must be assigned to the codec parameters in ascending order regarding the
bit rates (because codecs change to adjacent codecs, see next topic).
Example: Active Codec Set for Half Rate Traffic Channel with three codecs:
AMRHRC1 –> TCH/AHS4.75
AMRHRC4 –> <NULL>
g In case of poor quality of the hardware connection between BSC and BTS (Abis
interface) the AMR codecs AHS6.7 and AHS7.4 should not be included in the Active
Codec Set. The reason for this is that due to the ETSI standard on the Abis interface
these codecs are protected by one Cyclic Redundancy Check (CRC) only. This
leads to a higher number of errors and subsequently to a significant loss of speech
quality.
Link adaptation thresholds

The threshold parameters for the link adaptation are shown in Table 15. Different param-
eters are provided for Full Rate and Half Rate traffic channels with and without Fre-
quency Hopping. Only thresholds for the downlink direction are provided. For the AMR
link adaptation in the uplink direction reference thresholds for the transition between the
possible codec modes are hardcoded. However, the effective thresholds are not fixed,
but they are calculated for each call, depending on the used Active Codec Set and the
tuning parameter AMRLKAT, see AMR link adaptation tuning in uplink direction.
Full Rate TCH without Full Rate TCH with fre- Half Rate TCH without Half Rate TCH with fre-
frequency hopping quency hopping frequency hopping quency hopping
AMRFRTH12 FHAMRFRTH12 AMRHRTH12 FHAMRFRTH12
Table 15 Threshold parameters
A50016-G5100-B556-04-7620 Id:0900d8058052e614 83
For example AMRFRTH12 determines the AMR threshold for full rate TCHs and
adjacent codec modes 1 and 2 (codec 1 ist the most robust one) in case no frequency
hopping is applied. The subordinate “threshold” field determines the lower threshold;
assumed that codec 2 is currently used and the measured carrier-to-interference ratio
falls below this threshold, a switch from codec 2 to codec 1 is triggered. The value of the
“hysteresis” field added to the value of the “threshold” field gives the upper threshold;
assumed that codec 1 is currently used and the measured carrier-to-interference ratio
exceeds this threshold, a switch from codec 1 to codec 2 is executed.
If the Active Codec Set comprises 3 codecs, then the two corresponding threshold
parameters must be defined (e.g. AMRFRTH12 and AMRFRTH12, if the ACS contains
just AMRFRC1, AMRFRC2, AMRFRC3).
Determining the initial AMR codec during call setup

The parameter AMRFRIC respectively AMRHRIC determines the initial AMR codec, i.e.
the AMR codec that shall be used in the beginning of the call. The initial codec is then
immediately adapted by the MS and BTS depending on the current radio conditions.
AMR link adaptation tuning in uplink direction

For the AMR link adaptation in the uplink reference thresholds for the transition between
the possible codec modes are hardcoded because they are optimized to the BTS’s
receiver performance. However, the effective thresholds are not fixed, but they are cal-
culated for each call, depending on the used Active Codec Set and the value of the
tuning parameter AMRLKAT (“aMRLinkAdapTuning“).
AMRLKAT tunes the transition between codec modes determined by internal thresh-
olds. A value higher than the default shifts the transition towards higher carrier-to-inter-
ference ratios. A value lower than the default has the opposite effect. Adaptation of AMR
Half Rate and AMR Full Rate is affected simultaneously. All possible transitions
between codec modes are simultaneously shifted. The default value is the optimum
setting and normally requires no modification.
5.4.3 Configurations for wideband AMR

g Wideband AMR can be deployed in combination with tandem free operation (TFO)
only, see chap. 5.5 Tandem free operation.
Initial configurations for wideband AMR mainly comprise the setup of the initial codec
and of the thresholds for link adaptation.
Further configurations concern intra-cell handovers between half rate and full rate AMR
traffic channels (compression/decompression handovers) and between wideband and
narrowband full rate traffic channels, see chap. Handover.
Initial codec
The initial wideband AMR codec to be used when a call is going to be established can
be set up by the attributes AMRWBFGIC (“aMRWBFullrateGmskInitialCodec“, in case
no frequency hopping is applied) and FHAMRWBFGIC (“FHaMRWBFullrateGmskIni-
tialCodec“, in case frequency hopping is applied). The assignment is done by numbers:
“1” stands for the most robust codec, “3” for the one with the highest speech data rate.
Instead of selecting a particular codec the selection can be done according to 3GPP
rules, which here results in the selection of the most robust codec with the lowest speech
data rate.
84 Id:0900d8058052e614 A50016-G5100-B556-04-7620
g The initial codec shall be selected according to the TFO setup mode, i.e. with
(FH)AMRWBFGIC = 1 or (FH)AMRWBFGIC = START_MODE_WFS.
Switching conditions between wideband AMR codecs

Table 16 shows the parameters available for the wideband AMR link adaptation, the
parameters are subordinate to the BTS object. Thresholds are provided for the downlink
direction (controlled by the BTS) only. For the AMR link adaptation in the uplink direction
reference thresholds for the transition between the possible codec modes are hard-
coded. However, the effective thresholds are not fixed, but they are calculated for each
call, depending on the value of the tuning parameter AMRLKATWFS (analogous to
AMRLKAT for narrowband AMR, see above).
Short name Long name Description Default Range

AMRWBFGTH aMRWBFullrateGmskT Lower threshold for switching threshold: threshold:
12 hreshold12 between codec 2 and 1 and hystere- 19 0 … 63
sis value to obtain the higher thresh- (= 8.5 dB) (0 … 31.5 dB)
old for switching between codec 1
hysteresis: 4 hysteresis:
and 2. 0 … 15
(= 2 dB)
(0 … 7.5 dB)
FHAMRWBFG fhAMRWBFullrateGms Lower threshold in case of frequency threshold: threshold:
TH12 kThreshold12 hopping for switching between codec 19 0 … 63
2 and 1 and hysteresis value to (= 8.5 dB) (0 … 31.5 dB)
obtain the higher threshold for
switching between codec 1 and 2. 0 … 15
(= 2 dB)
(0 … 7.5 dB)
AMRWBFGTH aMRWBFullrateGmskT Lower threshold for switching threshold: threshold:
23 hreshold23 between codec 3 and 2 and hystere- 25 0 … 63
sis value to obtain the higher thresh- (= 12.5 dB) (0 … 31.5 dB)
old for switching between codec 2
and 3. 0 … 15
(= 2 dB)
(0 … 7.5 dB)
FHAMRWBFG fhAMRWBFullrateGms Lower threshold in case of frequency threshold: threshold:
TH23 kThreshold23 hopping for switching between codec 25 0 … 63
3 and 2 and hysteresis value to (= 12.5 dB) (0 … 31.5 dB)
obtain the higher threshold for
switching between codec 2 and 3. 0 … 15
(= 2 dB)
(0 … 7.5 dB)
AMRLK- aMRLinkAdaptionTch- This attribute allows to favour either 100 (0 dB) 0 … 200
ATWFS Wfs more robust AMR codec or wideband (-10 … 10 dB)
AMR codec in uplink direction.
Table 16 Link adaptation parameters for wideband AMR
E.g. the attribute AMRWBFGTH12 defines the thresholds for switching between AMR
wideband codec 1 and 2 (codec 1 ist the most robust one) in case no frequency hopping
is applied. The subordinate “threshold” field determines the lower threshold; assumed
that codec 2 is currently used and the measured carrier-to-interference ratio falls below
this threshold, a switch from codec 2 to codec 1 is executed. The value of the “hystere-
A50016-G5100-B556-04-7620 Id:0900d8058052e614 85
sis” field added to the value of the “threshold” field gives the upper threshold; assumed
that codec 1 is currently used and the measured carrier-to-interference ratio exceeds
this threshold, a switch from codec 1 to codec 2 is executed.
5.4.4 Call setup with wideband AMR

The following transmission modes are possible for a speech call on a GSM TCH:
– AMR wideband, full rate
– AMR narrowband, full rate
– AMR narrowband, half rate
– GSM, full rate
– GSM, half rate
– GSM, enhanced full rate
Assumed that radio resources are provided for these transmission modes (via layers
and service layer lists), the selection of the AMR wideband mode depends not only on
the support and availability of the AMR wideband service, but also on the preference for
full rate TCHs. In brief and simplified, AMR wideband is the first choice, if full rate TCHs
are preferred. The algorithm for selection of the transmission mode during radio
resource management has the following main lines:
• First, the BSC checks, if wideband AMR is supported and available. If not, usual
radio channel allocation without wideband AMR codecs is applied.
• If compression from wideband AMR to narrowband AMR is allowed, the preference
for full rate or half rate TCHs is taken into account: This preference depends on the
traffic load in case the “Cell load dependent activation of half rate TCHs” function is
enabled, or on the MSC/MS settings. If full rate TCHs are preferred, AMR wideband
is selected; else AMR wideband cannot be applied and the traffic channel search
comprises half rate TCHs with and without narrowband AMR.
• If compression from wideband AMR to narrowband AMR is not allowed, the BSC
immediately looks for wideband AMR full rate traffic channels. If such a TCH is
found, it is allocated; otherwise usual radio channel allocation without wideband
AMR codecs is applied.
5.5 Tandem free operation

Principle
For an MS-to-MS call, the transmission path covers the radio access network (RAN) and
the core network (CN) as well. Since the transmission modes and coding standards are
different for RAN and CN, speech data is converted/transcoded at the transition points
from RAN to CN. This conversion is done in the TRAU network element which connects
RAN and CN. Figure 41 shows the signal path between the two BSSs for the MS-to-MS
call.
86 Id:0900d8058052e614 A50016-G5100-B556-04-7620
Uplink Downlink
BTS BSC TRAU MSC MSC TRAU BSC BTS
Abis Ater A A Ater Abis
16 kbit/s 16 kbit/s 64 kbit/s 64 kbit/s 64 kbit/s 16 kbit/s 16 kbit/s
Speech Speech G.711 G.711 G.711 Speech Speech

coded coded coded coded coded coded coded
Tandem operation
Transcoding
Transcoding
... ........ ...
TRAU frames TRAU frames PCM samples PCM samples TRAU frames TRAU frames
Transc.: Yes No
Transcoding: No
Tandem free operation
G.711 coded
... (transcoded) ...
Speech coded
TRAU frames (transparent) TRAU frames
TFO frame
Figure 41 Signal path for an MS-MS connection

Coding and transmission have the following main characteristics:
• Radio access network: Speech data is transported through the BSS (BTS, BSC and
TRAU) in the speech encoded form via TRAU frames. TRAU frames for full rate
TCHs have a fixed size of 320 bits and a fixed duration of 20 ms and are carried over
16 kbit/s channels via Abis interface and Ater interface.
• Core network: Speech data is transmitted in PCM encoded 8 bit speech samples
over 64 kbit/s channels. The PCM encoding originally refers to uncompressed nar-
rowband speech and is done according to the G.711 ITU-T recommendation.
Two transcodings are performed in case of narrowband speech, one in the TRAU of the
uplink part of the transmission path when speech data from the BSS is sent to the MSC,
the second in the TRAU of the downlink path when speech data from the core network
is passed to the receiving BSS. This operation method with the two transcodings in the
TRAU pair is called "Tandem operation".
The transmission of PCM encoded (uncompressed) wideband AMR speech data via A
interface would require a bitrate of 128 kbit/s (16 kHz sample transmission frequency
and 8 bit resolution) which exceeds the capacity of the A interface. The solution to this
problem is to transmit compressed wideband AMR speech data (at hand in the BSS
after speech encoding and transmitted via TRAU frames with 16 kbit/s) transparently
through the core network. This compressed data is not PCM encoded / not tandem
transcoded. In this configuration, "Tandem free operation" (TFO) is on-going.
A50016-G5100-B556-04-7620 Id:0900d8058052e614 87
For TFO the originating and terminating connections must use the same codecs.
Control
The major constraint of Tandem Free Operation is that the inter-PLMN transmission
links must be transparent to the compressed speech frames. This means that any
device located in the transmission path between the originating and the terminating
transcoder must keep unaltered any compressed speech frame sent over the transmis-
sion path.
If compatible speech codec types and configurations are used at both ends of the MS-
MS connection, the transcoders automatically activate Tandem Free Operation. TFO is
activated and controlled by the Transcoder Units (TRAUs) after the completion of the
call set-up phase at both ends of the call connection. The TFO protocol is fully handled
and terminated in the Transcoder Units. For this reason, the Transcoder Units cannot
be bypassed in TFO mode. In return, the Transcoder Units continuously monitor the
normal Tandem Free Operation and can terminate TFO as soon as necessary loosing
the benefits of wideband AMR encoding. Wideband audio is changed to narrowband
audio.
Data transmission and signalling in TFO mode

TFO performs a dual speech transmission:
• Compressed AMR wideband speech data, which requires a transmission rate of
16 kbit/s, is mapped onto the two least significant bits (LSBs) of the 8 bit 64 kbit/s
PCM speech samples, i.e. the lowest two bits per PCM sample are filled with com-
pressed speech.
The stream of speech data bits is structured in form of TFO frames which derive their
structure from GSM TRAU frames. A TFO frame has a size of 320 bits and a
duration of 20 ms.
Signalling is done in-band, i.e. within the TFO frames. TFO messages and control
bits are inserted at every sixteenth PCM sample into the least significant bit of the
PCM sample.
• In order to allow interworking with the narrowband world, G.711 encoded speech
data is simultaneously sent over the core network, too. For this data path the TRAUs
perform transcoding of speech as in tandem operation mode, the G.711 encoded
speech data is mapped onto the first 6 bits of the 8 bit PCM samples. For G.711
encoding, wideband AMR speech data has to be downsampled according to narrow-
band conditions, thus the speech quality of wideband AMR is not provided on this
path.
So, while tandem free operation is ongoing, there always remains a transmission path
with tandem transcoding.
TFO mode not possible

If compatible AMR wideband codec types are supported at both ends and if the TRAUs
have started TFO negotiation, but it turns out that TFO can not established, the TRAU
informs the BTS about this situation. The resulting behaviour depends on the setting of
the NBNOWB attribute:
• If NBNOWB is set to FALSE, the local link remains on the wideband channel, but no
uncompressed wideband speech data is sent via A interface. Thus the speech
quality is not better than for narrowband AMR due to the losses on the A interface,
although wideband AMR resources are deployed in the radio access network.
88 Id:0900d8058052e614 A50016-G5100-B556-04-7620
• If NBNOWB is set to TRUE, the BTS asks the BSC via the INTRACELL HANDOVER
CONDITION INDICATION message with cause "TFO unsuccessful (return to NB)"
for a switch to a narrowband AMR channel. After a check from the BSC, this switch
is executed – preferably by a channel modification (if CHMDMWBNB attribute is set
to TRUE), otherwise by intra-cell handover.
5.6 Ciphering
For security reasons, data is transmitted via air interface in a ciphered form. The cipher-
ing starts during SDCCH establishment after an authentication procedure has been suc-
cessfully passed and the BTS has transmitted the cipher mode settings to the MS (via
the CIPHER MODE COMMAND). Afterwards all data including signalling messages is
transmitted in ciphered form (beginning with the CIPHER MODE COMPLETE message
from the MS to the BTS).
MS and BTS apply ciphering in the same way. The transmitting side ciphers data after
channel coding (block coding, convolution coding and interleaving) and before modula-
tion, see Figure 42, the receiving side deciphers after demodulation.
Block code
Convolution code Ciphering Modulation
Interleaving
Figure 42 Embedding of ciphering between coding and modulation

In the basic form, ciphering is done by the transmitting side with a ciphering key Kc and
a cipher algorithm called A5/1. A5/1 generates a stream of ciphering bits which are con-
nected to the bits of the data stream via exclusive or (XOR) condition. The resulting bits
form the encrypted data stream. The receiving side applies the same cipher key Kc and
the same A5/1 algorithm on the encrypted data stream: The same stream of ciphering
bits is generated and the XOR connection with the encrypted data stream reproduces
the (not ciphered) data stream, see Figure 43. Correct deciphering requires the synchro-
nization between BTS and MS. This is done via TDMA frame numbers.
Ciphered Ciphered Deciphered

Data stream data stream data stream data stream
1 0 1 1 1 1 0 1 1 1 0 1 1 0 1 1
0 1 1 0 0 1 1 0
Generate
Generate
Synchronization
Cipher stream XOR Cipher stream XOR
via TDMA frame numbers
A5 A5
Kc MS Kc BTS
Figure 43 Ciphering with Kc and A5/1 (simplified)

A more advanced ciphering algorithm is A5/3 which uses block ciphering instead of
stream ciphering.
Provision of Kc:
A50016-G5100-B556-04-7620 Id:0900d8058052e614 89
The MS generates the cipher key Kc with its individual subscriber authentication key Ki
and a random number RAND which feed the generator algorithm A8. Ki is provided
(together with the IMSI) by the network operator after the new subscription, RAND is cal-
culated in the authentication center (AuC) and is transmitted to the MS via HLR and
VLR.
The BTS cannot generate the same Kc itself because it has no access to the Ki for
security reasons. Instead the BTS gets the Kc from the AuC via HLR and VLR. The AuC
possesses the subscriber’s Ki and calculates the Kc by the same generator algorithm
A8 as the MS and with the same RAND which is sent to the MS.
The RAND number is changed for every new connection.
Ki and RAND are also important for authentication (see chap. Authentication).
Variants of ciphering algorithms

The ciphering algorithms A5/0, A5/1, A5/2 and A5/3 have been specified.
• A5/0 means no encryption.
• A5/1 is a stream cipher based on a 64 bit key word length and is implemented in
hardware (via ASIC). For each burst, A5/1 produces a 114 bit sequence of cipher
bits which are XOR-combined with the 114 bits of the burst. A5/1 is initialized using
a 64 bit key together with a publicly-known 22 bit frame number. 10 of the key bits
are fixed to zero, resulting in an effective key length of 54 bits.
A BTS1 only supports A5/1.
• A5/2, also based on a 64 bit key word length, was formerly available as the only
GSM compliant ciphering algorithm for non-MoU countries/operators who were not
allowed to use A5/1, but it was removed from the BTS code due to serious security
gaps. This was done as the GSM association board has decided to support A5/2 not
any longer.
• A5/3 is a block cipher based on the KASUMI algorithm that is specified in the
TS35.202 Recommendation. A5/3 produces a 64 bit output from a 64 bit input under
the control of a 128 bit key. The user can configure only the A5/3 for GSM algorithm
as specified in the 55.216 Recommendation. It produces two 114 bit keystream
strings; one string is used for uplink encryption/decryption and the other string is
used for downlink encryption/decryption. Three A5/3 variants have been specified:
A5/3 for Circuit Switched Services using GMSK modulation, A5/3 for Enhanced
Circuit Switched Data (ECSD, an evolution of HSCSD) and GEA3 for GPRS ser-
vices.
A5/3 ensures a higher security against interception than A5/1. A5/3 is an optional
feature (the corresponding license has to be installed).
A5/3 is implemented only for GMSK modulated CS services (but not for HSCSD)
and is purely implemented in software.
A5/3 is only available for the current BTS hardware platform.
Selecting the ciphering algorithm according to the ciphering capabilities

The BSC, which supports the ciphering algorithms A5/1 and A5/3, makes the decision
for the cipher algorithm to be used by matching the list of allowed cipher algorithms as
indicated in the CIPHER MODE COMMAND and the ones defined in the parameter
ENCALSUP and selects the best (safest) algorithm (A5/3 is the 'stronger' and safer algo-
rithm and is therefore preferred against A5/1, if both are allowed) for the CIPHERING
MODE COMMAND towards the BTS.
90 Id:0900d8058052e614 A50016-G5100-B556-04-7620
Whether an MS supports cipher algorithm A5/3 or not, is indicated in the ‘Classmark 2’

IE which is contained in the CLASSMARK CHANGE message that is sent during call
setup (or after explicit CLASSMARK REQUEST). The MSC considers this capability
indication prior to the transmission of any ciphering request (that may be embedded in
the BSSMAP messages CIPHER MODE COMMAND or HANDOVER REQUEST).
The fact that different BTS HW generations do not support the same ciphering algo-
rithms has an effect on call processing during call setup and handover: If ENCALSUP
lists A5/3 as supported ciphering algorithm (ENCALSUP = GSMV3) on BSC level, this
does not reflect the ciphering capabilities of all BTSs of this BSC if some BTS are of type
BTS1. Therefore the BSC checks any BTS for limited cipher algorithm capabilities via
the ‘Expected SW version’ attribute (parameter EXPSWV in command CREATE BTSM)
in the following cases:
a) On reception of the CIPHER MODE COMMAND (during any call or signaling trans-
action setup with ciphering)
b) On reception of the HANDOVER REQUEST (during MSC-controlled handover)
c) During BSC-controlled handover towards this BTS.
If A5/3 is allowed but not supported by a BTS equipment, the BSC changes the cipher
algorithm to the next best one (the sequence is A5/3 –> A5/1 –> A5/0). Any change of
the ciphering algorithm during inter-cell handover is signalled to the MS via the “Cipher
Mode Setting” Information Element included in the HANDOVER COMMAND message.
Improving security in case of A5/1 ciphering

A5/1 ciphering could be a target for cracking attacks, since it is based on a 64 bit key
word length only. In order to improve the security level in GSM networks applying A5/1,
the following additional mechanisms are introduced:
• After the MS has transmitted the CIPHER MODE COMPLETE message to the BTS
via SDCCH (i.e. after authentication and with ciphering already applied), an intra-cell
SDCCH-to-SDCCH handover is performed (if possible).
• Before the intra-cell SDCCH handover, only the system information messages SI5,
SI5bis and SI5ter are sent and the transmission is done in a “tricky” way, thus hiding
information about adjacent cells. After the SDCCH handover has been executed
and a TCH has been established, the system information and measurement infor-
mation messages (SI5, SI5bis, SI5ter, SI6, MI) are regularly scheduled.
These additional security mechanisms are enabled by the IMMSDCCHO (“enableImme-
diateSDCCHHO”) attribute.
Attributes
• ENCALSUP (“encryptionAlgorSupport“): This parameter determines the algorithms
for the radio interface ciphering supported by the BSC.
– NOENCR means 'no ciphering'.
– GSMV1 represents the ciphering algorithm A5/1.
– GSMV3 represents the ciphering algorithm A5/3.
It is up to the operator to take care that the setting of ENCALSUP matches the cipher
algorithms supported by the used BTS SW loads.
• IMMSDCCHO (“enableImmediateSDCCHHO”): This attribute subordinate to the
HAND object enables/disables (TRUE/FALSE) the additional security mechanisms
in case of A5/1 ciphering (SDCCH-to-SDCCH handover after start of ciphering;
hiding adjacency information before this handover). Of course, the IMMSDCCHO
A50016-G5100-B556-04-7620 Id:0900d8058052e614 91
setting is active only if intra-cell SDCCH-to-SDCCH handovers are generally

enabled (IRACHOSDCCH = TRUE).
5.7 Discontinuous transmission and comfort noise insertion

The Discontinuous Transmission (DTX) feature stops the amplification and transmission
of speech data during speech pauses. Without further improvements a user could
assume that the connection has been lost in such an “empty” pause, therefore a low
noise level is generated and added at the receiver’s Mobile Station ensuring that the
user does not notice any interruptions. This feature is called Comfort Noise Insertion
(CNI). DTX and CNI have the following benefits:
– The power consumption of the Mobile Station is significantly reduced.
– The interference level at the air interface is reduced.
Voice Activity Detection, background noise and transmission of SID frames

During a normal conversation, the voices alternate so that, on average, each transmis-
sion direction is occupied not more than 50% of the time. A Voice Activity Detection
(VAD) algorithm detects phases with or without speech; additionally the VAD algorithm
isolates the background acoustic noise in order to transmit characteristic parameters of
this noise to the receive side. From these parameters the receive side generates a
similar noise – the comfort noise – during periods without radio transmission. VAD algo-
rithms are implemented in the MS as well as in the TRAU.
DTX reduces the speech data rate from 13 kbit/s to 500 bit/s. This low rate is enough to
encode the background noise. This means instead of one frame of 260 bits per 20 ms
only one frame per 480 ms is sent. These so-called SID frames (Silence Description
Frames) are sent at the start of every inactivity period and repeated every 480 ms, as
long as the voice inactivity between BTS and MS lasts, see Figure 44. Between TRAU
and BTS the comfort noise frames are sent every 20 ms.
Radio block transmission on TCH (UL/DL):
Voice Voice Voice SID no transmission SID no transmission SID no tr. Voice Voice SID no transmission SID
480 ms 480 ms 480 ms

MS
...
no voice activity no voice activity BTS
TRAU block transmission for traffic (UL/DL):
Voice Voice Voice SID SID SID ... SID SID SID Voice Voice SID SID ... SID
20 ms 20 ms
BTS SID = Silence Description TRAU
Figure 44 Discontinuous transmission
Impacts on measurement processing in the BTS and MS

When DTX is used during a certain measurement period, the MS (for DTX downlink) as
well as the BTS (for DTX uplink) have to consider the utilization of DTX during the radio
92 Id:0900d8058052e614 A50016-G5100-B556-04-7620
measurement process. Both the MS and the BTS indicate in the MEASUREMENT
REPORT resp. MEASUREMENT RESULT messages whether in the current measure-
ment period DTX is active or not. The BTS sets the DTX flag if DTX was applied in at
least one TDMA frame in the measurement period. Both MS and BTS provide two dif-
ferent measurement values for RXLEV and RXQUAL: the FULL and SUB values.
• The FULL values represent the measurements that were made on the TCH and the
SACCH frames with a sample period of 20 ms, assuming that every 20 ms a decod-
able TDMA frame is received. This means that, if DTX was active in a specific mea-
surement period (silence), the FULL values or RXLEV and RXQUAL may indicate
bad radio conditions due to missing speech frames, even if the radio conditions are
excellent. The higher the number of TDMA frames with active DTX, the worse the
RXLEV/RXQUAL values will look.
• The SUB values represent the measurements that were made on the SACCH
frames, which are repeated every 480 ms and which carry the SYSTEM INFORMA-
TION TYPE 5 and 6 (downlink) and the MEASUREMENT REPORTs (uplink). As a
general rule, the SUB values always mirror the real radio conditions, but have a
lower statistic reliability than the FULL values that were measured during speech
periods. To increase the reliability of the SUB values for AMR calls, the BTS does
not only consider the SACCH frames but also the speech frames carrying real
speech (as the BTS can recognize these frames from their contents).
DTX for data services

Besides, the DTX can be applied to non-transparent data services with 9.6 kbit/s and
4.8 kbit/s user data rate in downlink direction. The DTX algorithm for data services is
based on the Radio Link Protocol (RLP) and it is controlled by the Interworking Function
(IWF) in the MSC. The Radio Link Protocol function in the MSC indicates whether a RLP
frame is redundant and therefore may be omitted.
Attributes
The following attributes are used for the discontinuous transmission:
• DTXDLFR (“dTxDownLinkFullRate“): enables/disables the discontinuous transmis-
sion on downlink direction for the Full Rate (FR) TCHs
• DTXDLHR (“dTxDownLinkHalfRate“): enables/disables the discontinuous transmis-
sion on downlink direction for the Half Rate (HR) TCHs
• DTXUL (“dTxUplink“): enables/disables the discontinuous transmission on uplink
direction for the Mobile Station using the following TCHs:
– MAYFSHNH (MS may use DTX for FR and shall not use DTX for HR)
– SHLFSHNH (MS shall use DTX for FR and shall not use DTX for HR)
– SHNFSHNH (MS shall not use DTX for FR and shall not use DTX for HR)
– MAYFMAYH (MS may use DTX for FR and may use DTX for HR)
– SHLFSHLH (MS shall use DTX for FR and shall use DTX for HR)
– SHNFSHLH (MS shall not use DTX for FR and shall use DTX for HR)
A50016-G5100-B556-04-7620 Id:0900d8058052e614 93
5.8 GPRS channel coding

Four coding schemes – CS1, CS2, CS3 and CS4 – are defined for GPRS RLC/MAC
blocks used during the data transmission (for information about RLC/MAC see chap.
Protocol view on GPRS or the GPRS global description manual). Table 17 and Figure
45 summarize the main characteristics of each coding scheme.
Coding Bits of RLC Spare bits Network data rate Bits of RLC/MAC Total size of the
scheme data field in RLC header RLC/MAC block
(no spare bits) data field (including USF) (bits)
CS1 160 0 8 kbit/s (160 bit / 20 ms) 24 184
CS2 240 7 12 kbit/s (240 bit / 20 ms) 24 271
CS3 288 3 14.4 kbit/s (288 bit / 20 ms) 24 315
CS4 400 7 20 kbit/s (400 bit / 20 ms) 24 431
Table 17 GPRS coding schemes
CS1 Modulation
USF = 3 bits Block code 40 bits Convolutional Interleaving

+ 4 tail bits code ( R = 1/2 )
181 bits 184 bits 228 bits 456 bits
CS2 / CS3 Mod.
USF Block code 16 bits Convolutional

USF = 3 bits Puncturing Interleaving
pre-coding + 4 tail bits code ( R = 1/2 )
268 bits 271 bits 274 bits 294 bits 588 bits 456 bits
312 bits 315 bits 318 bits 338 bits 676 bits 456 bits
CS4 Modulation
USF Block code Interleaving

USF = 3 bits
pre-coding 16 bits
Figure 45 GPRS coding process

CS1 is the most robust coding scheme providing a reasonable throughput in case of
moderate C/I conditions where the higher coding schemes result in a very poor through-
94 Id:0900d8058052e614 A50016-G5100-B556-04-7620
put. On the other hand the higher coding schemes provide higher throughputs than CS1
in case of good C/I conditions.
Having applied the coding scheme, the BTS proceeds with the following steps:
1. Pre-coding of the USF (except for CS1, USF: see chap. 5.12 Temporary Block Flow)
2. Block coding and addition of a Block Check Sequence (BCS) for error detection
3. Addition of four tail bits (not for CS4)
4. Half rate convolutional coding for error correction (not for CS4)
5. Puncturing operation in order to obtain the target coding rate (for CS2 and CS3)
6. Interleaving
The coding process of a RLC/MAC block, using CS1, is shown in Figure 46. The 456
bits obtained after BTS coding are sent across four normal bursts carrying 2 · 57 bits. of
information each one.
PCU
RLC / MAC block
USF TFI Data bits BCS Tail
R = 1/2 Convolutional Code
Encrypted RLC frame
456 bits
456 bits are split

in 4 Normal Bursts Normal Burst
Training Guard
Tail Encrypted bits Encrypted bits Tail
Sequence Period
57 bits 57 bits
Stealing bits
Figure 46 RLC/MAC block coding for CS1

Regarding the Abis interface, the information is transmitted using two kinds of PCU
frames:
• Standard PCU frames are used, when the support of CS3/CS4 is disabled at the
BSC or at the BTS level. Standard PCU frames have been designed to carry the
A50016-G5100-B556-04-7620 Id:0900d8058052e614 95
necessary signalling and data information between the BSC and the BTS, the GPRS
capacity on the Abis interface is limited to 16 kbit/s.
• Concatenated PCU frames are used, when the support of CS3/CS4 is enabled at
both BSC and BTS level. Since the data rates resulting from CS3 and CS4 coding
schemes are too high for standard PCU frames, concatenated PCU frames have
been introduced. With concatenated PCU frames the Abis throughput per radio
channel (PDCH) have been increased to n · 16 kbit/s, using the flexible Abis alloca-
tion strategy (for more information on this feature, please refer to the Transmission
and transport network management manual).
The PCU frame format (concatenated or standard) is chosen at the Initial Time Align-
ment phase, and cannot be changed dynamically during data transfer. When CS3/CS4
is enabled, the selected PCU frame format is “Concatenated”, even if the initial coding
scheme could be supported by standard PCU frames.
Enabling/disabling CS3/CS4 coding schemes

As default, the CS1 and CS2 coding schemes are enabled in the BSS; the support of
CS3/CS4 coding schemes can be enabled/disabled by the user:
• CSCH3CSCH4SUP (“codingScheme3CodingScheme4Support”): This attribute of
the BSC Managed Object and of the PTPPKF Managed Object allows the user to
enable/disable CS3/CS4 coding schemes on the BSC level and on the cell level.
• ENOCS3CS4 (“edgeNoCs3Cs4”): This attribute of the BSC Managed Object allows
activating EDGE without CS3 and CS4.
g When enabling CS3/CS4 coding schemes with CSCH3CSCH4SUP, make sure that
ENOCS3CS4 is set to FALSE, otherwise the maximum coding scheme usable is
forced to CS2 independently from the CSCH3CSCH4SUP attribute.
5.9 EGPRS channel coding

Nine modulation and coding schemes – MCS1 ... MCS9 – are defined for the EGPRS
RLC/MAC blocks. Table 18 summarizes the main characteristics of each modulation
and coding scheme.
The high data transmission rates of MCS5 up to MCS9 are achieved by applying 8PSK
modulation instead of GMSK modulation (which is used for “simple” GSM and GPRS).
The 8PSK modulation of EGPRS has the same symbol transmission rate as the usual
GMSK modulation and the same pulse shapes are used, but each 8PSK symbol carries
the information of 3 bits (GMSK: 1 bit per symbol).
MCS1 is the most robust modulation and coding scheme since it provides a reasonable
throughput in case of moderate C/I conditions where the higher modulation and coding
schemes result in a very poor throughput. On the other hand the higher modulation and
coding schemes – particularly those which apply 8PSK modulation – provide higher
throughputs than MCS1 in case of good C/I conditions.
96 Id:0900d8058052e614 A50016-G5100-B556-04-7620
GMSK modulation 8-PSK modulation
Q Q
(0,1,0)
(0,0,0) (0,1,1)
1
(0,0,1) (1,1,1)
0 I I
(1,0,1) (1,1,0)
(1,0,0)
1 bit per symbol 3 bits per symbol
Figure 47 GMSK modulation and 8-PSK modulation
Coding Modula- Bits of RLC Net data rate Bits of RLC/MAC FBI+E Total size of the
scheme tion data field header DL/UL fields RLC/MAC block
(no spare bits) (including USF) (bits) DL/UL (bits)
MCS1 176 8.8 kbit/s 31/31 2 209
(176 bit / 20 ms)
MCS2 224 11.2 kbit/s 31/31 2 257
(224 bit / 20 ms)
GMSK
MCS3 296 14.8 kbit/s 31/31 2 329
(296 bit / 20 ms)
MCS4 352 17.6 kbit/s 31/31 2 385
(420 bit / 20 ms)
MCS5 448 22.4 kbit/s 28/37 2 478/487
(448 bit / 20 ms)
MCS6 592 29.6 kbit/s 28/37 2 622/631
(592 bit / 20 ms)
MCS7 448 + 448 44.8 kbit/s 40/46 2+2 940/946
8PSK
(896 bit / 20 ms)
MCS8 544 + 544 54.4 kbit/s 40/46 2+2 1132/1138
(1088 bit / 20 ms)
MCS9 592 + 592 59.2 kbit/s 40/46 2+2 1228/1234
(1184 bit / 20 ms)
Table 18 EGPRS coding schemes
The coding schemes are grouped in four families: A, A padding, B and C. Table 19 and
Figure 48 show the correspondence between the families and the coding schemes.
A50016-G5100-B556-04-7620 Id:0900d8058052e614 97
Family Modulation and coding schemes

A MCS3, MCS6, MCS9
A padding MCS3, MCS6, MCS8
B MCS2, MCS5, MCS7
C MCS1, MCS4
Table 19 Families of EGPRS modulation and coding schemes
MCS - 3
37 octets 37 octets 37 octets 37 octets

Family A
MCS - 6
MCS - 9
MCS - 3
34 + 3 octets 34 + 3 octets
Family A MCS - 6
padding
MCS - 8
MCS - 2

Family B
MCS - 5
MCS - 7
MCS - 1
Family C 22 octets 22 octets
MCS - 4
Figure 48 EGPRS coding schemes and families
98 Id:0900d8058052e614 A50016-G5100-B556-04-7620
Each family has a different basic unit of payload: 37 octets for the A family, 34 octets for
the A padding family, 28 octets for the B family and 22 octets for the C family respec-
tively. Different code rates within a family are achieved by transmitting a different
number of payload units within one Radio Block. For the families A and B one, two or
four payload units are transmitted, instead for the family C only one or two payload units
are transmitted.
5.10 Initial coding scheme for GPRS and EGPRS

Any Temporary Block Flow (TBF, see chap. 5.12 Temporary Block Flow) is started
using an initial modulation and coding scheme. Users define the initial coding scheme
(for example CS4, MCS9) on a cell basis, to be used for data transmission (signalling
uses always CS1) when no historical coding scheme is present in the BSC. The histor-
ical coding scheme is the last coding scheme used. After closure of the TBF, the last
used coding scheme is stored on the BSC for a period configurable by the user with the
STGTTLLIINF (“storageTimeTLLIInfo”) attribute and is deleted when the timer related to
STGTTLLIINF expires. In this way, when a TBF is re-opened and the timer has not
expired yet, the transmission can start with a more meaningful coding scheme.
For GPRS the user can set the initial coding scheme using the INICSCH (“initialCoding-
Scheme“) attribute related to the PTPPKF object. When setting ENOCS3CS4 = TRUE
(max. coding scheme usable is forced to CS2), the INICSCH attribute must be set to
CS1 or CS2.
For EGPRS the user can set the preferred initial coding scheme as follows:
• In the uplink direction not all the Mobile Stations that support the EGPRS services
support also the 8PSK modulation, therefor:
– The IMCSUL8PSK (“initialMcsUplink8psk“) attribute suggests the MCS to be
used in the uplink direction, if the Mobile Station supports the 8PSK modulation
in this direction.
– The IMCSULGMSK (“initialMcsUplinkGmsk“) attribute suggests the MCS to be
used in the uplink direction, if the Mobile Station supports only the GMSK mod-
ulation in this direction.
• In the downlink direction all the Mobile Stations supporting EGPRS services are
obliged to support the 8PSK modulation, so the INIMCSDL (“initialMcsDownlink“)
attribute suggests the MCS to be used in the downlink direction for all the EGPRS
Mobile Stations.
The link adaptation algorithm, if enabled, can change the coding scheme of the TBF
according to the radio conditions. If the link adaptation algorithm is not enabled, the
initial coding scheme is the only one used for the data transmission in the cell.
5.11 Link adaptation for GPRS and EGPRS

The Link Adaptation feature provides a dynamic selection and changing of the coding
scheme for transmitting the RLC blocks according to the present radio conditions. Only
data transmissions are concerned (all signalling is done with the CS1 coding scheme).
The basic idea of the Link Adaptation algorithm is to dynamically select the coding
scheme that allows the highest throughput with respect to the present radio conditions.
If the quality of the radio transmission decreases and falls below a certain threshold, a
more robust coding scheme is used; on the other hand, if the radio conditions exceed a
A50016-G5100-B556-04-7620 Id:0900d8058052e614 99
certain threshold, the BSC switches to a coding scheme with higher throughput and
lower robustness.
Figure 49 shows simulation results of gross throughputs for the GPRS coding schemes
depending on C/I values. The simulation assumes frequency hopping and low MS
speed. It can be seen that CS1 is the most robust coding scheme since it provides a
reasonable throughput in case of moderate C/I conditions (e.g. C/I = 0) where the higher
coding schemes result in a very poor throughput. On the other hand the higher coding
schemes provide higher throughputs than CS1 in case of good C/I conditions.
Gross 25
Throughput
[kbit/s]
CS1
CS2
20
CS3
CS4
15
10
-5
- 20 - 10 0 10 20 30 40
C/I [dB]
Figure 49 Simulated throughputs depending on coding schemes and C/I (dB)

Figure 50 shows simulation results of gross throughputs for the EGPRS modulation and
coding schemes of family A (+ MCS1) depending on C/I values. The simulation assumes
no frequency hopping, low MS speed and no incremental redundancy.
100 Id:0900d8058052e614 A50016-G5100-B556-04-7620

60
50
40
Throughput [kbit/s]
30
20
MCS1
MCS3
MCS6
MCS9
10
0
0 5 10 15 20 25 30 35
C/I [dB]
Figure 50 Simulated throughputs depending on MCSs for family A (+ MCS1) and C/I
(dB)
Regarding unsuccessful transmissions of data blocks while the radio conditions are
changing and a change of the coding scheme is indicated, GPRS data blocks which
have not been delivered successfully have to be re-transmitted with the same coding
scheme as at the first transmission attempt(s); so a change of the coding scheme is only
executed after all data blocks lost or faulty in previous transmission(s) have been re-
transmitted successfully. EGPRS data blocks have to be re-transmitted with a coding
scheme belonging to the same family as the original coding scheme.
Definition of switching points

The switch from one coding scheme to another is based on BLER measurements (indi-
rect measurements of the radio quality) and on predefined switching points regarding
BLER values. In case of acknowledged transmission mode (see chap. 5.14 Radio
resource operating modes; the transfer of RLC data blocks is controlled by ARQ (Auto-
matic Repeat Request) mechanisms), the BLER is the number of radio blocks to be
repeated (the number of not acknowledged blocks, NACK) versus the number of trans-
mitted blocks in total (i.e. the sum of the acknowledged blocks (ACK) and of the not
acknowledged blocks).
Regarding Figure 49, ”ideal” switching points in C/I terms from one coding scheme to
the adjacent one would be the intersection points of the related lines. With Figure 51 the
A50016-G5100-B556-04-7620 Id:0900d8058052e614 101

C/I values can be translated in BLER rates depending on the used coding scheme.
Table 20 gives these simulated switching points in terms of C/I and BLER. When for
example CS4 is currently used and the BLER exceeds 17 %, a switch to CS3 is indi-
cated; when e.g. CS3 is currently used and the BLER falls below 2 %), a switch to CS4
is indicated. In order to avoid too many codec mode changes, a hysteresis is applied.
102
CS1
CS2
CS3
CS4
101
BLER
100
10-1
-5 0 5 10 15 20 25 30 35 40
C/I [dB]
Figure 51 BLER as function of C/I (dB) for the GPRS coding schemes
Switching point in C/I Codec mode switch BLER

CS1 –> CS2 17 %
6.2 dB
CS2 –> CS1 43 %
CS2 –> CS3 14 %
9.6 dB
CS3 –> CS2 26 %
CS3 –> CS4 2%
16.5 dB
CS4 –> CS3 17 %
Table 20 Simulation results for CS switching points
In real networks optimum switching points depend on the actual radio scenario and it is
impossible to calculate such optimal values for each particular scenario. Therefore
102 Id:0900d8058052e614 A50016-G5100-B556-04-7620

switching points for upgrade and for downgrade of coding scheme are stored in precal-
culated matrix tables, one for each possible radio environment. These matrix tables
cannot be set by the user. Two matrix tables exist: The first one defines BLER thresh-
olds in case of a low diversity environment (i.e. the cell is characterized by low user
mobility, e.g. because the MS has a speed less than 50 km/h), whereas the second one
defines BLER thresholds in case of a high diversity environment (i.e. radio conditions
can change fast, e.g. because Frequency Hopping is enabled).
The user selects the desired matrix table, containing all the switching points (down-
grade/upgrade switching points from/to all coding schemes) for the particular radio sce-
nario, by setting the RAENV (“radioEnvironment”) attribute to LOWDIV or HIGHDIV.
Enabling GPRS and EGPRS link adaptation

The following attributes are common for GPRS and EGPRS.
Link adaptation can be enabled using the ELKADPT attribute of the PTPPKF object; this
attribute affects both uplink and downlink direction.
The matrix table defining the switching points from one coding scheme to another is
determined by the RAENV (“radioEnvironment”) attribute. It can assume two values:
• LOWDIV (“lowDiversity”): This value indicates that radio conditions can change
slowly, e.g. because Frequency Hopping is disabled and the cell is characterized by
low user mobility (e.g. because the MS has a speed less than 50 km/h or because
the cell is a small one).
• HIGHDIV (“highDiversity”): This value indicates that radio conditions can change
fast (e.g. in case Frequency Hopping is enabled).
Configuring the filtering period for link adaptation

The BLERAVEUL (“blockErrorRateAveragingPeriodUplink“) attribute specifies the filter-
ing period for the BLER calculation in uplink direction as number of radio blocks. So the
averaging time period in UL direction is BLERAVEUL · 20 ms (one radio block has a
duration of 20 ms) in case of single timeslot allocation. This time defines the minimum
time to pass between two consecutive upgrade/downgrade steps. The BLERAVEDL
attribute is the corresponding attribute for the downlink direction. An averaging time
period of about 1 s is recommended to average out fast fading effects.
In a call with N timeslots allocated, the number of BLERAVEUL/BLERAVEDL radio
blocks is transmitted N times faster than with a 1-timeslot allocation. Thus the averaging
time period for a multislot allocation would become too short to average out fast fading
effects resulting in a quite “nervous” link adaptation behaviour. Therefore the averaging
period determination as described above is applied only for allocations with 1 or 2
timeslots in uplink direction and for 3 or 4 timeslots in downlink direction. For other allo-
cations with more timeslots the averaging period is internally adjusted to get similar
averaging time periods as for the allocations with the low numbers of timeslots.
EGPRS MCS families

For EGPRS the user must define which families of coding schemes are to be used in
the cell, both in uplink and downlink direction.
• Uplink direction:
At least two families of available MCSs must be enabled: A 8PSK family for MSs
capable to transmit 8PSK, and the GMSK family for MSs capable to transmit GMSK
only (the switching points are well defined by the matrix table, even if several 8PSK
A50016-G5100-B556-04-7620 Id:0900d8058052e614 103

families are enabled). The attributes also contain the MCS of the initial coding
scheme. Examples of attributes:
– EMFA1UL8PSK (“enMcsFamAMcs1Uplink8Psk”): enables MCSs belonging to
family A and MCS1 to be used, if MS supports 8PSK modulation for uplink
– EMFCULGMSK (“enMcsFamCUplinkGmsk”): enables MCSs belonging to
family C to be used, if the MS does not support 8PSK modulation for uplink
– EMFGUL8PSK (“enMcsFamGmskUplink8Psk”): enables MCSs belonging to
family GMSK to be used if the MS supports 8PSK modulation in UL EGPRS TBF
• Downlink direction:
EGPRS mobiles are able to receive 8PSK modulated signals, therefore at least one
family of available MCSs must be enabled (enabling of the GMSK family is not nec-
essary). Examples of attributes:
– EMCSFAMGDL (“enMcsFamGmskDownlink”): enables MCSs belonging to the
GMSK family for downlink TBF
– EMCSFAMA1DL (“enMcsFamAMcs1Downlink”): enables MCSs belonging to
family A and MCS1 for downlink TBF
Additional attributes (e.g. for other families) are defined accordingly. For a complete
listing please refer to the BSC commands and eBSC commands manuals.
When configuring the sets of coding schemes, the following constraints are automati-
cally considered by the system:
a) MCS1 is always included in the selection: This is needed for signalling and due to
the fact that MCS1 is the only MCS that requires only one Abis timeslot.
b) If MCSx is implemented, all the lower order MCSy (y < x) of the same family must
be implemented. This is needed because re-transmissions may have to be per-
formed with a (lower order) MCS of the same family.
Jumps over EDGDE MCSs

Generally the GPRS and EDGE link adaptation strategy allows switching from a
CS/MCS to the next higher one (upgrade) or to the next lower one (downgrade) only. In
order to avoid losing time by switching step by step, the possibility to “jump” over MCSs
for EDGE is provided. This jumping is particularly suitable in the mode with all 9 MCSs
enabled, since the link adaptation switching periods last from 500 ms up to 2 s (jumping
over GPRS CSs would not greatly matter, since there are only four CSs).
The following mechanism is applied for MCS upgrade and downgrade:
• In case of an MCS upgrade the current BLER value is compared with the BLER
thresholds of the two next higher MCSs of the same family (e.g. a current BLER
value of MCS6 is compared with the thresholds of MCS7 and MCS9 taken from the
threshold table). If the current BLER value is higher than the more stringent require-
ment for the MCS of the same family, the switch to the adjacent MCS is performed;
else the next higher MCS is selected.
• In case of an MCS downgrade the current BLER value is compared with the BLER
thresholds of the two next lower MCSs of the same family (e.g. a current BLER value
of MCS9 is compared with the thresholds of MCS8 and MCS6 taken from the thresh-
old table). If the current BLER value is lower than the more relaxed requirement for
the MCS of the same family, the switch to the adjacent MCS is performed; else the
next lower MCS is selected.
In general jumping over MCS considers Abis and PDT (equivalent of an Abis
timeslot in the PCU) resources availability. A jump from MCS6 to MCS9 requires
more free PDTs and Abis subslots than the upgrade from MCS6 to MCS7. In case
104 Id:0900d8058052e614 A50016-G5100-B556-04-7620

of PDT and Abis resource congestion the MCS upgrade can be reduced to a switch
to the next higher MCS only or can even be denied.
Link adaptation jumps are applied only in the following scenarios and with the following
conditions:
– All MCSs are enabled.
– Only jumps within an MCS family plus MCS1 are considered.
– Only family A plus MCS1 or family B plus MCS1 are considered for jumping (not
family A padding and GMSK family C).
– In case of an upgrade from MCS1 either MCS2 (family B) or MCS3 (family A) are
the targets. The current BLER value and comparison with the threshold table deter-
mines the target.
Enabling MCS jumping:
MCS jumping is enabled by the ELAJMCSUPGUP (“enableLaJumpsMcsUpgrade“)
upwards and by ELAJMCSDGR (“enableLaJumpsMcsDowngrade“) downwards.
5.11.1 Link adaptation enhancements

Regarding SAIC (single antenna interference cancellation) MSs, DARP (downlink
advanced receiver performance) MSs and generally MSs with increased multislot capa-
bility, the following enhancements for the (E)GPRS link adaptation are provided:
– Fast (“emergency”) CS/MCS switch down
– Automatic identification of SAIC MSs
– EDGE BLER threshold tables for SAIC MSs
These sub-features are described in the following topics. The link adaptation enhance-
ments provide significant performance gain for both GPRS and EGPRS.
Fast CS/MCS switch down

The fast (“emergency”) CS/MCS switch down mechanism is mainly intended for MSs
with early proprietary SAIC implementation which do not indicate their SAIC capability.
It offers the very fast link adaptation downgrade from a 8PSK MCS to the previous
GMSK MCS in case of a previous upgrade step from the GMSK MCS to the 8PSK MCS
and if high BLER values are observed. Moreover the time period for staying in the GMSK
MCS after the fast downgrade can be prolonged. The time period for the fast downgrade
after the previous upgrade step is typically 250 – 500 ms. For allowing the fast down-
grade to the GMSK MCS after upgrade from this GMSK MCS to 8PSK MCS, this GMSK
MCS is temporarily stored.
The fast CS/MCS switch down is especially useful for SAIC MSs and EDGE service:
SAIC boosts the GMSK performance significantly but keeps the 8PSK performance
nearly unchanged. Hence upgrades from GMSK to 8PSK could be triggered at low
BLER, nonetheless after the link adaptation the BLER with 8PSK could be very high
resulting in a poor throughput during 8PSK. This situation probably leads to continuous
toggling between GMSK and 8PSK with a low overall throughput (1/2 of the GMSK
throughput in the extreme, if the 8PSK throughput tends towards zero).
g Fast MCS switch down works also in combination with jumping over MCS. Since the
original MCS has been stored, a fast switch down to the original MCS is performed
by jumping back over several MCSs.
Parameters:
A50016-G5100-B556-04-7620 Id:0900d8058052e614 105

The fast (“emergency”) CS/MCS switch down mechanism can generally be enabled by
the ELAESDGEN (“enableLaEsdGeneral“) attribute for all GPRS and EDGE link adap-
tation transitions. The ELAESDGMSK8PSK (“enableLaEsdGmsk8Psk“) attribute
enables the fast switch down for critical SAIC EDGE GMSK-to-8PSK link adaptation
transitions.
The following additional parameters are provided:
– THLKESDBLER (“thresholdLaEsdBler“): This attribute determines the BLER thresh-
old used for the fast downgrade decision after an MCS upgrade.
– TPLAESD (“timePeriodLaEsd“): This attribute fixes the percentage of the link adap-
tation switching period (determined by the averaging parameters BLER-
AVEUL/BLERAVEDL) after which the fast downgrade shall take place after the
previous MCS upgrade. A small percentage means a fast downgrade.
– TPLAAVGPRO (“timePeriodLaAvgProlong“): This attribute determines the factor by
which the link adaptation switching period is prolonged after the execution of the fast
downgrade.
EDGE BLER threshold tables for SAIC MSs

This sub-feature is automatically applied to SAIC MSs which have indicated their SAIC
capability. SAIC MSs have the same performance as non-SAIC MSs in case 8PSK mod-
ulation is applied; however, if GMSK modulation is applied, the performance of SAIC
MSs is significantly better than for non-SAIC MSs. This allows lower BLER thresholds
for MCS upgrades from GMSK modulation to 8PSK modulation and also lower BLER
thresholds for MCS downgrades from 8PSK modulation to GMSK modulation. Thus new
EDGE BLER threshold tables for SAIC MSs are implemented.
Automatic identification of SAIC MSs

Since fast (“emergency”) CS/MCS switch downs from EDGE GMSK to 8PSK are typical
for MSs with SAIC capability, a counter records the number of such fast switch downs
for an ongoing TBF. As soon as the counter exceeds the threshold determined by the
THLAESDIDSAIC (“thresholdLaEsdIdentifySaicMs”) parameter, the MS is identified as
SAIC MS for this particular TBF. Once the SAIC MS is identified, the EDGE BLER
threshold table for SAIC MSs in downlink direction is applied.
This sub-feature is applicable and valid within the range of a single TBF. The counter is
set to 0 at TBF setup; in case of SAIC MS identification the SAIC BLER threshold table
is used until release of this TBF.
5.12 Temporary Block Flow

A Temporary Block Flow (TBF) relates a PDCH (i.e. a timeslot) or a set of PDCHs tem-
porarily to the transfer of packet data from or to a Mobile Station (MS). TBFs allow mul-
tiplexing of calls for different Mobile Stations on the same radio resources: Different
TBFs are assigned to the data transfers of different MSs in the same direction, but the
PDCHs determined by these TBFs can be the same for the MSs in case of multiplexing
of the data transfers on the same radio channel.
More in detail, downlink and uplink TBFs are distinguished:
• Downlink TBF:
It is characterized by:
106 Id:0900d8058052e614 A50016-G5100-B556-04-7620

– a TFI (Temporary Flow Identity): identifies a TBF; each Mobile Station has its
own TFI value; TBFs belonging to the same transmission direction must have
different TFI values (a downlink and an uplink TBF can have the same TFI value)
– a PDCH (i.e. a timeslot) or a set of PDCHs
– an USF (Uplink State Flag): controls the multiplexing of subsequent uplink data
transfers of different MSs on the same PDCH(s); each MS is assigned an indi-
vidual USF value. This value, sent in downlink direction, tells the MS, when it can
send data, multiplexed on shared PDCH(s) (for more details, see below). USF
is used in the Dynamic Access Modes, comprises 3 bits and enables the coding
of 8 different states.
Each radio block sent in downlink direction carries the USF and the TFI in the header
of the block. The USF is placed at the beginning.
• Uplink TBF:
It is characterized by:
– a TFI (Temporary Flow Identity)
– a PDCH (i.e. a timeslot) or a set of PDCHs
In contrast to the downlink direction, no USF is sent in uplink direction.
TBFs are evaluated as follows:
Receiving data in downlink direction, all Mobile Stations, which have a downlink TBF on
the same PDCH(s), read all the downlink blocks inside a multiframe and decode the TFI
value. If a Mobile Station identifies the TFI value of a radio block as the one assigned to
itself, the Mobile Station accepts the block, otherwise the block is skipped.
B0 B1 B2 T B3 B4 B5 i B6 B7 B8 T B9 B10 B11 i
USF TFI Data
From TFI the MS detects if data is own
Figure 52 Multiplexing MSs on the same PDCH (downlink)

Additionally the Mobile Station, which has accepted a radio block with the correct TFI,
decodes the USF value. If the USF is the one assigned to the Mobile Station, the MS
sends its uplink data on the next uplink block or on the next four uplink blocks (depend-
ing on the USF granularity, see below); otherwise the MS does not send on these
blocks.
A50016-G5100-B556-04-7620 Id:0900d8058052e614 107

B0 B1 B2 T B3 B4 B5 B0 B1 B2 T B3 B4 B5
DL UL
USF TFI Data TFI Data

If USF is own
From USF, the MS

understand if it can
MS transmit its
transmit on the next
data and TFI
uplink block
Figure 53 Multiplexing MSs on the same PDCH (uplink)

USF granularity:
The USF granularity defines if the MS, having received the correct USF value, sends
either a single RLC/MAC data block or a sequence of four RLC/MAC data blocks on the
same PDCH. The USF granularity is transmitted to the MS via the PACKET UL
ASSIGNMENT message.
The USF granularity is configured by the USFGRAN (“uSFGranularity”) attribute subor-
dinate to the TRX object, i.e. on TRX basis.
– USFGRAN = DISABLED: This setting corresponds to USF granularity 0 (USF gran-
ularity 1 disabled) where the MS sends a single RLC/MAC data block.
– USFGRAN = ENABLED: This setting corresponds to USF granularity 1 where the
MS sends a a sequence of four RLC/MAC data blocks (the three next DL radio
blocks carry dummy USFs).
Multiplexing Mobile Stations on the same PDCH

As it has been described, more than one Mobile Station can be multiplexed on the same
physical data channel (PDCH), either in the downlink or in the uplink direction:
• In uplink direction up to 7 Mobile Stations can be multiplexed on the same physical
data channel; in fact, up to seven USF values can be used to multiplex Mobile
Stations on the same PDCH in the uplink direction.
• In the downlink direction, up to 16 Mobile Stations can be multiplexed on the same
physical data channel; this number is imposed by the Timing Advance Index (TAI)
necessary for the Timing Advance Update procedure.
• In total (uplink and downlink) up to 16 Mobile Stations can be multiplexed on the
same physical channel; this number is imposed by the Timing Advance Index (TAI)
necessary for the Timing Advance Update procedure.
If, for instance, 7 Mobile Stations are using a PDCH in the uplink direction, at most
9 further Mobile Stations can use the same PDCH in the downlink direction.
5.12.1 Simultaneous data transfers for different (E)GPRS services

Simultaneous data transfers for different services can be requested for a MS (especially
in DL direction). The handling and distribution of simultaneous data transmissions for
108 Id:0900d8058052e614 A50016-G5100-B556-04-7620

one MS depend on the facilities of the MS on the one side and the SGSN on the other
side. The following modes can be applied:
• Mode 1 is applied, if the SGSN does not support Packet Flow Management or
Packet Flow Management has been disabled in the BSS system or a Packet Flow
Identifier (PFI) is not present. In mode 1 only one DL TBF is possible for one MS.
The DL Packet Data Units (PDUs) are put in one LLC queue in the BSS, the RLC
instance takes the DL PDUs from the LLC queue and the PDUs are related to the
TBF. If two services require different RLC modes (Acknowledged/Unacknowledged
mode), they cannot be mapped onto the same TBF because the RLC mode is fixed
for a TBF. Instead each time a PDU arrives requiring a different RLC mode the TBF
needs to be released and reassigned.
In UL direction no queuing of multiple simultaneous data transmission is foreseen.
• Mode 2 is applied, if the SGSN supports Packet Flow Management, Packet Flow
Management has been enabled in the BSS system and the Packet Flow Identifier is
present. Again only one DL TBF is possible for one MS, but two several Packet Flow
Contexts (PFCs) can be requested from the SGSN side and these are put in differ-
ent LLC queues (PFC buffers, allocated on demand), one queue for each PFC.
5M)NTERFACE 'B)NTERFACE
"3#
0&#3CHEDULER
,,#1UEUE 0&#
$, 4"&
,,#1UEUE 0&#
Figure 54 Scheduling several PFCs for one TBF

The PFC scheduler now decides from which LLC queue the next PDU is taken. So,
several PFCs share one TBF. Again, if two services require different RLC modes
(Acknowledged/Unacknowledged mode), the TBF needs to be released and reas-
signed.
In UL direction there is no difference to mode 1.
• Mode 3 is applied if the SGSN and the MS support Packet Flow Management and if
the MS supports the Multiple Block Flow feature (i.e. the MS is compliant to
Release 6). This feature supports a 1:1 mapping between Packet Flow Context (ful-
filling the QoS requirements on the Gb interface) and Temporary Block Flows (ful-
filling the QoS requirements on the Um interface) supporting service specific QoS
requirements. In case of several active Packet Flow Contexts (predefined and non
predefined ones), the BSC allocates one Temporary Block Flow per each active
Packet Flow Context in each direction (when required) at the same time for the same
Mobile Station.
The multiple Temporary Block Flow (mTBF) feature supports services in parallel
while maintaining the service specific QoS requirements. For example, delay critical
and background services are provided to the user without allocating more resources
on the air interface than really needed. The multiple Temporary Block Flow can also
support the introduction of IP Multimedia Subsystem (IMS) services and allows to
handle several conversational/streaming services in parallel with background and
interactive service (including high-priority SIP signalling).
A50016-G5100-B556-04-7620 Id:0900d8058052e614 109

5M)NTERFACE 'B)NTERFACE
"3#
$, 4"& ,,#1UEUE 0&#
$, 4"& ,,#1UEUE 0&#
0&)
5, 4"& 0&#
0&)
5, 4"& 0&#
Figure 55 Multiple Temporary Block Flow (mTBF)
Attributes
• PFCSUP (“pfcSupport“): this parameter, subordinate to the CPCU object, allows to
enable/disable the Packet Flow Context procedure support. For other attributes
specifying details of PFC management, see the BSC commands and eBSC
commands manuals and the GPRS global description.
• TPFCBUFF (“timerPFCBuffer“): This timer is defined for each allocated PFC buffer
(mode 2 from above). It is started when the related PFC buffer gets empty. It is
stopped and cancelled if new LLC frames are coming for that buffer. When it expires,
the PFC buffer is de-allocated. TPFCBUFF is subordinate to the CPCU object.
• MTBFSUP: This attribute allows to enable/disable the multiple Temporary Block
Flow feature. Enabling is only possible if the Packet Flow Control feature has been
enabled before.
5.13 Uplink incremental redundancy

Uplink Incremental Redundancy provides a joint decoding mechanism of two RLC data
blocks where the first one could not be correctly decoded and the second one is a
retransmitted block.
The joint decoding increases the probability of correctly decoding RLC data blocks.
This feature is applicable for Temporary Block Flows running in EGPRS TBF mode and
acknowledged RLC mode (see chap. 5.14 Radio resource operating modes). Uplink
Incremental Redundancy is also known as Hybrid type II/III ARQ and it is an optional
feature for the mobile network, while it is mandatory for the Mobile Station.
In a EGPRS Temporary Block Flow (TBF), the RLC data block is coded and punctured
before being sent on the air interface. Different puncturing schemes can be used for the
same RLC data block in case of retransmissions. When Uplink Incremental Redundancy
runs, the BTS stores the received but failed RLC data blocks in its memory; in case of
retransmission the BTS performs a joint decoding based on two different transmissions
of the same RLC block with different puncturing schemes.
110 Id:0900d8058052e614 A50016-G5100-B556-04-7620

A special case for EDGE is the joint decoding between MCS5-7 and MCS6-9 codecs.
This case is important, since blocks with the same Block Sequence Number (BSN)
arrive in RLC blocks with different MCSs. The same applies for split blocks (e.g. MCS6
results in 2 · MCS3 or MCS5 in 2 · MCS2 or MCS4 in 2 · MCS1), since blocks with the
same BSN arrive in RLC blocks with different MCSs but with the Split Block Indicator set
in the RLC header. Reassembly of the split blocks is done in the PCU. Only concate-
nated PCU frames are affected (standard PCU frames not), because the Uplink Incre-
mental Redundancy is a EGPRS feature.
The uplink incremental redundancy feature needs a communication between BTS and
BSC, because currently the BTS has no knowledge about the multislot allocation of a
MS over different PDCHs and also no knowledge about ownership of a radio block to a
particular MS. Furthermore the BTS has no knowledge about extended dynamic alloca-
tion, USF granularity and multiple TBF capabilities of the MS (uplink incremental redun-
dancy supports multiple TBFs). The communication is done via in-band signalling in the
EDGE/EGPRS PCU frames (concatenated PCU frames) which enable the BTS to have
all information to execute uplink incremental redundancy autonomously. Especially the
short TLLIs signaled by PCU in the header of the first concatenated PCU frame trans-
porting a radio block is concerned. The short TLLI is a unique MS identifier on a specific
BTS transceiver (TRX). It is indicated both for the MS receiving the radio block in DL and
the MS scheduled in UL by USF. In this way the BTS is informed about which MS trans-
mits the next UL radio block (20 ms later, indicated by USF) and which MS is served with
data of the current DL block. The same short TLLI is used when referring a MS in DL
(MS receiving the radio block) and in UL (MS scheduled in the radio block) direction.
Attributes
The following attributes related to the PTPPKF Object support the configuration of the
Uplink Incremental Redundancy feature on cell basis:
• EULINCRED (“enableUplinkIncrementalRedundancy”): enables (value: TRUE) or
disables (value: FALSE) the Uplink Incremental Redundancy feature in cells sup-
porting EDGE.
• TSASHOTLLI (“timerSameShortTLLI“): This attribute allows to define the period
during which a short TLLI in concatenated PCU frames must be reused by the same
MS on the same TRX, and must not be reused for a different MS on the same TRX;
validity range: [0..20 s], in steps of one second.
For the attributes to enable MCS families for uplink data transfer, please refer to EGPRS
MCS families.
All attributes and commands related to the Uplink Incremental Redundancy feature are
described in detail in the BSC commands and eBSC commands manuals.
5.14 Radio resource operating modes

This chapter mainly provides background information on terminology used in several
chapters (e.g. in chap. 5.15 Dual transfer mode). The following radio resource operating
modes for a mobile station are distinguished:
• Idle mode: This mode refers to the CS part of GSM when no call connection has
been established, the MS listens to the BCCH and the PCH.
• Dedicated mode: This mode also refers to the CS part of GSM when a CS connec-
tion has been established.
A50016-G5100-B556-04-7620 Id:0900d8058052e614 111

• Packet idle mode: This mode refers to the PS part of GSM when no PS connection
has been established, the MS listens to the PBCCH and to the PPCH. If the
PBCCH/PCCCH is not present in the cell, the MS listens to the BCCH and the PCH.
• Packet transfer mode: This mode refers also to the PS part of GSM when a PS
connection has been established. Radio resources have been assigned providing
one or more TBFs. Data transfer can be executed in RLC acknowledged or RLC
unacknowledged mode.
– RLC acknowledged mode:
The transfer of RLC data blocks in the RLC acknowledged mode uses retrans-
missions of RLC data blocks in case the blocks could not correctly received
regarding the RLC part of layer 2 (data link layer, see Protocol view on GPRS
and packet data/message flow), ARQ (Automatic Repeat Request) mechanisms
are used. The transmitting side numbers the RLC data blocks via the block
sequence number (BSN) in the RLC data block header. The BSN is used for
retransmission and for reassembly. The receiving side sends PACKET (DL or
UL) ACK/NACK messages in order to indicate successful reception or to request
retransmission of RLC data blocks.
This mode is used for data applications which are not delay-sensitive and where
it is important/possible to preserve the payload content completely. It is the
typical mode for background applications (background delivery of e-mails, SMS,
download of databases) and interactive class applications (web browsing).
– RLC unacknowledged mode:
The transfer of RLC data blocks in the RLC unacknowledged mode does not
include retransmissions in case the blocks could not correctly received regard-
ing the RLC part of layer 2. The block sequence number (BSN) in the RLC data
block header is used to number the RLC data blocks for reassembly.
This mode is used for delay-sensitive services, such as conversational class
applications (voice, video conference) and streaming class applications (one-
way real time audio and video).
When selecting a new cell, the MS leaves the packet transfer mode, enters the
packet idle mode where it switches to the new cell, reads the system information and
may then resume to packet transfer mode in the new cell.
• Dual transfer mode: The MS has been assigned radio resources for both a CS con-
nection and one or more TBFs. While in dual transfer mode, the MS performs all
tasks of dedicated mode.
When handed over to a new cell, the MS leaves the dual transfer mode, enters the
dedicated mode where it switches to the new cell, may read the system information
messages sent on the SACCH and may then enter dual transfer mode in the cell.
5.15 Dual transfer mode

The Dual Transfer Mode (DTM) feature allows utilizing both Circuit Switched (CS) and
Packet Switched (PS) connections in parallel, i.e. operating multislot connections within
both the CS domain and the PS domain of the GSM network simultaneously (e.g. voice
call + web browsing) – one timeslot is used for the CS service, one or several timeslots
for PS services.
DTM is not supported in an Extended Cell and in the inner area of a Concentric Cell.
The capability to exploit the Dual Transfer Mode depends on the class of the MS:
112 Id:0900d8058052e614 A50016-G5100-B556-04-7620

• A Class B Mobile Station is not capable of DTM. Such MSs can be engaged either
in a PS session or in a CS connection. In networks without Gs interface (MSC-GSN
interface) they can receive an incoming CS voice call during a packet transfer. The
BSC supports this behaviour by the paging coordination.
• A Class A Mobile Station has a double transmitter and receiver and is able to use
simultaneously CS and PS services (e.g. a CS voice call in parallel to a Web
Browsing session), and so is DTM capable. The BSS (that currently ignores the MS
class) manages the CS and PS services for one MS as services for 2 different MSs.
A Class A Mobile Station normally does not transmit and receive at the same time;
this means that only configurations with 2 DL + 2 UL, 3 DL + 2 UL and 2 DL + 3 UL
adjacent timeslots are provided (UL: UpLink, DL: DownLink), where 1 DL + 1 UL
timeslot are used by CS (one or two Full Rate PDCHs are supported and only one
TCH, Full or Half Rate).
• A DTM Mobile Station, also called restricted class A Mobile Station, is DTM capable.
DTM is a feature for both the MS and the network. For this reason the network and the
MS as well have to indicate if they support DTM: The network does so in the SYSTEM
INFORMATION messages broadcasted in each cell, whereas the MS transfers its DTM
capability in the MS “Classmark 3” Information Element, respectively the “Radio Access
Capability”, to the network.
States and transitions of Class A Mobile Stations

Figure 56 shows the different modes and all possible transitions.
Figure 56 RR operation modes (including dual transfer mode) and transitions

For class A MSs and DTM MSs the “Dual transfer” RR operation mode is provided in
addition to the states “Dedicated”, “Packet transfer”, “Idle / Packet Idle” which are
already provided for class B Mobile Stations.
The black arrows show the transitions which a Class B MS is capable of, i.e. transmis-
sions where DTM is not involved. The blue arrows show the basic transitions for DTM;
the red arrows indicate additional transitions for DTM which are available with
“Enhanced DTM Establishment”.
Basic transitions for DTM:
A class A Mobile Station, within a DTM supporting network, is able to enter the “Dual
Transfer” state by moving from the “Dedicated” status and to return back into the “Ded-
icated” status outgoing from the “Dual Transfer” state.
A50016-G5100-B556-04-7620 Id:0900d8058052e614 113

Direct transitions from/to the “Packet transfer” state to/from the “Dual Transfer” state are
not provided. Instead, the status transitions affecting the “Packet Transfer” state have
the following behavior:
• The MS goes in “Dual Transfer” mode from the “Packet transfer” state by releasing
the PS session (going into the intermediate “Idle / Packet Idle” state), establishing
the CS connection (going into the intermediate “Dedicated” state) and then re-estab-
lishing the PS session in the “Dual Transfer” state.
• The MS goes in the “Packet Transfer” state from “Dual Transfer” Mode releasing the
PS session and CS connection (going into the intermediate “Idle / Packet Idle” state)
and then re-establishing the PS session.
Transitions with “Enhanced DTM Establishment”:
To reduce the PS session interruptions, an additional PACKET SYSTEM INFORMA-
TION TYPE 14 message has been introduced. Besides, the “Classmark3” and “Radio
Access Capability” Information Element have been modified to signal DTM support at
MS side. In case the MS and the network support “Enhanced CS establishment and
release”, a CS connection can be
– established while in “Packet Transfer” mode without release of the packet resources
(thus entering the “Dual Transfer” mode).
– released while in “Dual Transfer” mode without release of the packet resources (thus
entering the “Packet Transfer” state).
The Enhanced DTM is specified since 3GPP Release 6. To support Enhanced DTM, the
signalling on PACCH has been improved. (PACKET CS REQUEST, PACKET CS
COMMAND, PACKET CS RELEASE INDICATION).
For more information about establishing DTM see chap. Establishment of dual transfer
mode.
Prioritizing cells for DTM in hierarchical networks

In case of a hierarchical network, priorities can be defined in order to prefer certain cells
for allocating resources for DTM operation.
In a first step – after DTM has been enabled –, particular cells are defined as preferred
for CS services, others as preferred for PS services (this preference setting is only effec-
tive for DTM mode). In a second step the cells with preference for PS services are pri-
oritized for DTM radio resource allocation. Thus DTM MSs are prevented from being
allocated on CS preferred cells where the PS throughput might be reduced (usually in
CS preferred cells the radio resources for (E)GPRS) are rare, thus the PS part of a DTM
call may be downgraded) and where the PS part of a DTM call can be preempted by
other CS calls. Additionally DTM traffic can be concentrated on EDGE resources (con-
figured to prefer PS services). The distribution of resources for DTM calls to cells with
PS preference is done by means of DTM specific handover attributes including priority
levels and handover margins for the cells to move/keep DTM calls on PS preferred cells
via handover / handover prevention (mainly forced handover / supression of the power
budget condition regarding selection of target cells for handover). In order to direct a
DTM call request to a cell with PS preference, the BSC sends a FORCED HANDOVER
REQUEST to the BTS which indicates that the DTM priorities and handover margins
have to be used for Generation of the target cell list.
Attributes and objects to support DTM

The following attributes are provided:
114 Id:0900d8058052e614 A50016-G5100-B556-04-7620

• EDTMSUP (“enableDTMSupport”): This attribute (related to the PTPPKF object)

enables/disables the DTM service.
• EENHDTMSUP (“enabledEnhancedDTMSupport”): This attribute (related to the
BSC object) enables/disables the “Enhanced DTM Establishment” mode.
• TDTMWIND (“timerDTMWaitIndicator”): This attribute defines the waiting time
before a MS may re-send a DTM REQUEST and its value is included in the DTM
REJECT message.
For information about the attributes related to DTM in hierarchical networks, see chap.
Generation of the target cell list.
A50016-G5100-B556-04-7620 Id:0900d8058052e614 115

Frequency hopping Radio network management
6 Frequency hopping
With Frequency Hopping the radio transmission of the logical channels (except for the
logical channels on the broadcast channel, i.e. BCCH, FCCH, SCH) is done by changing
the transmission frequency for a call from one TDMA frame to the next.
Benefits
Frequency hopping reduces slow fading and keeps the effect of interference frequen-
cies low. The negative effects of multi-path fading are reduced and the service quality is
improved. In particular, the frequency hopping improves the average C/I ratio for inter-
ference-limited systems in urban areas.
Slow-moving subscribers get the most benefit from the frequency hopping: For a Mobile
Station moving with low speed, each doubling of the number of hopping frequencies, up
to the maximum number of 64, results in a further improvement of the average C/I ratio
of approximately 1.0 to 1.5 dB. For higher velocities of the Mobile Station and especially
for hilly terrain, the effect of frequency hopping becomes negligible. The following table
shows the typical S/N gain from frequency hopping in a GSM 900 mobile network
(signal-to-noise ratios required to obtain 0.2% residual BER for class 1b bits).
Number of hopping Typical urban Typical urban Hilly terrain

frequencies 3 km/h 50 km/h 100 km/h
None 11.5 7.5 6.8
2 10.0 6.5 6.7
4 8.25 6.0 6.6
8 7.5 6.0 6.6
16 6.75 6.0 6.6
Table 21 Typical S/N frequency hopping gain in dB for different terrains
These are typical values which may vary (by about 1 dB), e.g. with bad frame indication
processing. For a GSM 1800 mobile network, roughly the same values can be assumed
at half the speed (for example Typical Urban 25 km/h instead of Typical Urban 50 km/h).
Benefits for the customer:
– Improved resistance to sources of co-channel interference;
– Improved speech quality for slow-moving mobiles
– Increased frequency reuse and system capacity.
Baseband and synthesizer frequency hopping

Frequency Hopping can be done in the two following ways:
• Baseband Frequency Hopping
The TRXs operate at fixed frequencies and the information stream of one traffic
channel is switched to the different TRXs, frame by frame according to the frequency
hopping sequence.
The set of frequencies of the hopping system is limited by the number of TRXs con-
figured in a cell. The baseband hopping is ideally suited for cells with a large number
of carriers. Due to the fact that the TRX frequencies remain stable, it is possible to
116 Id:0900d8058053df78 A50016-G5100-B556-04-7620

Radio network management Frequency hopping
use either hybrid, on-air (duplexer) or filter combining; the latter configuration allows
the combining of up to 8 TRXs at minimum insertion loss.
A baseband frequency hopping system for a BTS may also include channels of the
BCCH-TRX (not applicable for site coordinated frequency hopping, i.e. SMA and
DMA), but not CHAN:0 carrying BCCH, FCCH and SCH.
If any TRX involved in the hopping sequence fails or is locked, hopping is disabled
(this system behavior is independent from the BCCH recovery). Mobile Stations with
calls in progress are notified in the form of an appropriate Layer 3 message. In addi-
tion, the Radio Commander/LMT Evolution are kept informed about the occurrence
of this procedure. The only calls to be lost are those which are hosted by the faulty
or locked TRX.
TDMA frame 1 TDMA frame 2 TDMA frame 3 TDMA frame 4 TDMA frame 5
Time-
slots 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
TRX:0 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 f1 ff1
B2 f1 f1 f1 f1 f1 f1 f1
Calls hopp to next TRX

TRX:1 f3 f2 f2 f2 f2 f2 f2 f2
f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2 f2
TRX:2 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3 f3
TRX:3 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4
f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4 f4
f1, f2, f3, f4: Frequencies of TRX:0, TRX:1, TRX:2, TRX:3
Timeslot 0 of TRX:0 (BCCH-TRX) does not hop
Calls of timeslots 1 - 7 (e.g. on TRX:0 in TDMA frame 1) hopp over TRX:0, TRX:1, TRX:2, TRX:3
Calls of timeslots 0 of TRX:1, TRX:2, TRX:3 hopp over TRX:1, TRX:2, TRX:3
Figure 57 Baseband frequency hopping

• Synthesizer Frequency Hopping
The TRXs are wideband and the information stream of one traffic channel is trans-
mitted on one TRX switching its frequency frame by frame according to the fre-
quency hopping sequence.
The set of frequencies used by synthesizer hopping does not depend on the number
of TRXs configured and used in a cell. Therefore, synthesizer hopping allows fre-
quency hopping over a large number of frequencies (up to 64), as well as for cells
with only 2 carriers, for example. Thus, in all cells with at least two TRXs, the perfor-
mance degradation due to interference and also the fading can be minimized. Syn-
thesizer hopping requires wide band combining, such as hybrid or on-air (duplexer)
combining.
Synthesizer frequency hopping is not allowed on the BCCH-TRX (namely all
timeslots/channels because all channels of the BCCH-TRX transmit with the same
frequency which particularly is the one of CHAN:0 carrying BCCH FCCH and SCH
and is therefore not hopping).
Synthesizer frequency hopping is not disabled if a TRX-HW involved in the hopping
sequence fails or is locked.
A50016-G5100-B556-04-7620 Id:0900d8058053df78 117

TDMA frame 1 TDMA frame 2 TDMA frame 3 TDMA frame 4 TDMA frame 5
Time-
slots 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
f1 f2 f3 f4 : Frequencies of TRX:0, TRX:1, TRX:2, TRX:3
TRX:0 (BCCH-TRX) does not hop

TRX:1, TRX:2, TRX:3 hopp with f2, f3 and f4
Figure 58 Synthesizer frequency hopping

The implementation of baseband frequency hopping shows the following difference
regarding the two BTSE generations, i.e. mainline BTSs and legacy BTS1s:
– Mainline BTSs: Baseband hopping is exclusively used in downlink direction whereas
in uplink direction always synthesizer hopping is applied. Downlink data is pre-pro-
cessed in the TRX related CU, but the burst data is then sent via the CU whose
carrier frequency is equal to that of the currently calculated burst. Thus, for a call, a
single RX path is used with multiple TX paths.
– BTS1s: Baseband hopping is done by multiplexing different TPUs (Transceiver Pro-
cessor Unit) to one BBSIG (baseband signal processing board) for both uplink and
downlink direction. The TX and RX paths are tied together by switching TX and RX
at the same time.
Information for the Mobile Station and interplay of the parameters

The following information is used by the Mobile Station:
• Cell Allocation (CA)
The list of frequencies (represented as ARFCNs, max. 64) in ascending order used
in the cell.
• Mobile Allocation (MA)
A selection of the cell allocation, giving the frequencies which are used for the
hopping sequence (see below). The selection is represented by list numbers of the
Cell Allocation.
• Hopping Sequence Number (HSN)
A value between 0 and 63 indicating the hopping algorithm to be used. The value 0
means cyclic hopping within the list of hopping frequencies determined by MA (in
combination with CA). Other values signify special pseudo-random hopping
sequences.
• Mobile Allocation Index Offset (MAIO)
A value between 0 and the number of frequencies in the MA indicating the starting
point for frequency hopping in the MA. The value 0 means that the first ARFCN is
the starting number, the number n means an offset of n and therefore points to the
frequency on the position (n+1).
CA, MA, MAIO and HSN determine the use of frequencies during the Frequency
Hopping (additionally the Frame Number, FN, is used to synchronize the Frequency
118 Id:0900d8058053df78 A50016-G5100-B556-04-7620

Hopping): CA and MA define all frequencies available for frequency hopping, MAIO
determines the starting ARFCN, the HSN defines the hopping law, i.e. which ARFCN is
to take next depending on the current ARFCN (in other words: the hopping sequence
gives the increments to proceed from one position in the MA to the next). The MAIO is
useful in order to avoid co-channel interference during Frequency Hopping: If two syn-
chronized TRXs are assigned the same HSN and MA (this is the usual case for a whole
BTS site, see below), but have different MAIOs, they always send with different frequen-
cies. Adjacent channel interference can also be suppressed by appropriate MAIOs: If
the difference between two MAIOs is greater than 1, the related frequencies can not be
proximate because the frequencies in the CA/MA are ordered.
For ongoing calls, the information stating whether frequency hopping is applied or not is
indicated by the H-bit of the “Channel Description” IE (IE: Information Element) sent to
the MS via the ASSIGNMENT COMMAND or the HANDOVER COMMAND message. If
H = 0, then frequency hopping is not applied; if H = 1, then frequency hopping is applied
(on one carrier only, if frequency hopping is configured but not enabled). For MSs in idle
mode the status of frequency hopping is indicated by the SYSTEM INFORMATION
TYPE 1 message which is sent on the BCCH. In case of H = 1 the “Channel Description”
IE also contains the MAIO and the HSN.
Bit Number
8 7 6 5 4 3 2 1
Channel Description IE Identifier Octet 1
Channel type and TDMA offset Timeslot number (TN) Octet 2
H=1 MAIO (high part)

Training sequence (TSC) Octet 3
H=0 Spare ARFCN (high part)
MAIO (low part) Hopping sequence number (HSN)
Octet 4
ARFCN (low part)
Figure 59 Channel description information element

The CA is derived from the “Cell Channel Description” IE, MA is contained in the “Mobile
Allocation” IE, both IEs are transmitted together with the “Channel Description” IE.
For the “Cell Channel Description” IE different formats are possible. The basic format
provides a bitmap representation of the ARFCNs allocated in the cell: Each bit of the IE
in the content part is related to a certain ARFCN (124 bits/positions are available accord-
ing to the ARFCNs 1 ... 124 for baseband GSM900) and a bit value 1 indicates that the
related ARFCN is part of the CA, see Figure 60.
Analogously, the “Mobile Allocation” IE represents a selection of the CA as a bitmap. For
every list number in the Cell Allocation frequency list an own bit position is provided. If
the bit related to a CA list number has the value1, then the associated ARFCN frequency
is used for frequency hopping. The size of the “Mobile Allocation” IE is variable and
depends on the number of frequencies in the CA.
Frequency Redefinition:
Generally every change of the frequency hopping mode and frequency hopping param-
eters causes a a frequency redefinition procedure and the cell is set to 'barred' for about
10 s (locking/unlocking of BTSE hardware managed objects is not allowed during this
phase). This is done to avoid unpredictable hopping errors in the hopping mode switch-
A50016-G5100-B556-04-7620 Id:0900d8058053df78 119

over phase as the starting time of the new hopping system is not known to mobiles cur-
rently in idle mode.
The frequency redefinition is reported to all busy MSs of a cell by a FREQUENCY
REDEFINITION message. These messages contain the channel data such as the new
“Mobile Allocation” IE, HSN and MAIO and are specific for each ongoing call. When
hopping is disabled (no matter whether this is done by command or automatically
because of a fault), the FREQUENCY REDEFINITION message points out a new
“Mobile Allocation” IE which consists of only one carrier and MAIO = 0. This means that
the MS hops on one carrier frequency only.
Cell Channel Description IE

Bit Number
8 7 6 5 4 3 2 1 Cell Allocation
Frequency List
Octet 1 Cell Channel Description IE Identifier
List no. ARFCN
1 0 0 0
Octet 2 Format ID Spare (124) (123) (122) (121)
1 002
0 0 1 0 0 0 0 0
Octet 3 2 008
(120) (119) (118) (117) (116) (115) (114) (113)
3 014
1 0 0 0 0 0 1 0
Octet 4 (112) (111) (110) (109) (108) (107) (106) (105)
... ...
...
21 106
0 0 1 0 0 0 0 0 22 112
Octet 16 (016) (015) (014) (013) (012) (011) (010) (009)
23 118
1 0 0 0 0 0 1 0 24 124
Octet 17 (008) (007) (006) (005) (004) (003) (002) (001)
Mobile Allocation IE
8 7 6 5 4 3 2 1
Octet 1 Cell Channel Description IE Identifier Mobile Allocation
Octet 2 Length ARFCN
0 1 0 1 0 1 0 1 002
Octet 3 (24) (23) (22) (21) (20) (19) (18) (17) 014
... ...
0 1 0 1 0 1 0 1 106
Octet 5 (8) (7) (6) (5) (4) (3) (2) (1) 118
Figure 60 Cell channel description IE and mobile allocation IE (example)
6.1 Static MAIO allocation

Sometimes, especially in case the network must handle considerable traffic capacities,
the number of available frequencies is too low to assign different frequency sets to the
cells of a site in order to avoid interferences between neigbour cells. In this case fre-
quencies have to be used in more than one cell. The resource planning can therefore
not be based on the frequencies only and a different approach must be used. Usually,
in such networks, frequency planning is reduced to the BCCH-TRXs only. For the non-
BCCH-TRXs the operator may decide to deploy e.g. a 1x1 frequency reuse pattern,
which means that the non-BCCH-TRXs use the same set of hopping frequencies. In
such configurations the interference is minimized by minimization of possible collisions
120 Id:0900d8058053df78 A50016-G5100-B556-04-7620

of the hopping channels by an intelligent MAIO (Mobile Allocation Index Offset) manage-
ment.
Usually, in a 1x1 frequency reuse network with Synthesizer Frequency Hopping
enabled, all cells within a site (including all cells managed by a BTSM object) get the
same Hopping Sequence Number (HSN) and different sites get different HSNs. In order
to coordinate the frequency hopping over a whole site, a common Mobile Allocation for
the site has to be established. If synchronization holds among the cells of the site (i.e.
the sectors derive the timing for Digital Signal Processing and the carrier frequencies
from the same clock source and use the same Frame Number), intra-site interference
can be controlled via appropriate MAIOs (Mobile Allocation Index Offsets) as follows:
The set of MAIOs allocated to a site with three sectors (cells) is split into three subsets
with different MAIO values for each sector; each TRX gets an own MAIO out of the MAIO
subset of the related sector (the subordinate channels (related to timeslots) inherit the
MAIO of the superordinate TRX). This assignment is done statically at installation or
configuration time, hence this kind of frequency hopping is called Static MAIO Allocation
(SMA). Co-channel interference is avoided because the TRXs use different MAIO
values; adjacent channel interference between two TRXs is suppressed, if the differ-
ence between the related two MAIOs is greater than 1 (the related frequencies can not
be proximate because the frequencies in the MA are ordered).
-OBILE!LLOCATION-!
4$-!&RAME
#ELL 428 -!)/
2ANDOM(OPPING3EQUENCE(3. 428 -!)/
428 -!)/
#ELL 4$-!&RAME
#ELL
428 -!)/
428 -!)/ #ELL
428 -!)/
4IME #ELL
#ELL 428 -!)/
428 -!)/
428 -!)/
Figure 61 Example for static MAIO allocation

Since there are only as much MAIOs as frequencies in the Mobile Allocation, the number
of TRXs to be used in the site for Frequency Hopping shall not exceed the number of
A50016-G5100-B556-04-7620 Id:0900d8058053df78 121

available hopping frequencies. Otherwise, if the number of TRXs installed on the site is
greater than the number of hopping frequencies available, MAIO values must be reused
within the site, thus introducing continuous intra-site co-channel interference and
degrading the radio quality below acceptable values.
Application of static MAIO allocation

The Static MAIO Allocation (SMA) shall be applied in the following cases:
– For cells with the Base Band Hopping enabled
– In case of services not appropriate for Dynamic MAIO Allocation (e.g. data services
like HSCSD or (E)GPRS)
– In case of services allocated to layers with a reuse factor different from 1x1
6.2 Dynamic MAIO allocation

In order to increase the network capacity using a number of hopping TRXs per site
greater than the number of hopping frequencies, the Dynamic MAIO Allocation (DMA)
strategy is provided. By means of this allocation type, the list of the MAIO values for the
site is no more divided into static subsets to be assigned to the sectors, but it is consid-
ered as a common resource at site level. Now MAIO values are assigned dynamically
during the channel activation time by selecting the most suitable MAIO from the common
pool available to all of the cells of the same site. This leads to a significant statistical
capacity gain especially in cases of instantaneous inhomogeneous traffic distribution
within the site. The common MAIO pool is efficiently exploited at site level. Using DMA
it is possible to increase the number of installed TRXs per sector – instead of site – to
the number of frequencies.
Additionally to the capacity enhancement mentioned above, Switched Beams represent
a means for further capacity increase. The narrow beams reduce interference and allow
to use co-channels simultaneously, i.e. to deploy more TRXs. Consequently MAIOs can
be reused within a site. In case of low-medium load conditions, even when Switched
Beams are used, DMA provides higher capacity values than SMA.
Applicability
The Dynamic MAIO Allocation applies to speech calls only (ASCI excluded). DMA is not
appropriate for serving data services like HSCSD or (E)GPRS due to the low C/I result-
ing from 1x1 reuse. For these services the operator will provide resources planned with
a looser frequency reuse factor; these TRXs then belong to a different service layer. This
is also necessary because multislot allocation requires identical MAIO values assigned
to the respective hopping channels.
DMA is supported in dual band standard cells independently on each frequency band
and can use the radio resources reserved for the speech services CS speech (EFR, FR,
HR, AMR FR, AMR HR). It can be applied also in case of Switched Beams available.
DMA is not supported for:
– Extended cells
– Concentric cells
– GSMR
DMA can be applied to cell objects only; the operator is allowed to set it on cell basis
and by default the feature is not enabled.
The Dynamic MAIO Allocation feature is not supported by the BS-2x/6x family.
122 Id:0900d8058053df78 A50016-G5100-B556-04-7620

DMA strategy
The DMA strategy estimates the expected interference for all of the idle TS/MAIO com-
binations (TS: Timeslot) by taking the TS/MAIO pairs currently in use at the site into
account, and allocates the TS/MAIO pair with the minimum expected interference level
to the incoming call. This strategy is based on an optimization algorithm operating within
the entire TS/MAIO domain. Thus, all MAIOs can be used and reused in all sectors of
the site. In particular, the algorithm:
– avoids the repetition of MAIO values in the serving cell, i.e. it avoids intra-cell co-
channel interference
– minimizes the number of MAIO repetitions at the site, i.e. the number of channels
affected by intra-site co-channel interference
– controls the number of MAIO adjacencies in the serving cell, i.e. the number of times
the MAIO values i, i – 1 and/or i + 1 are used on the same TS, i.e. the number of
channels affected by intra-cell adjacent channel interference, is minimized.
– controls the number of MAIO adjacencies within the site, i.e. the number of channels
affected by intra-site adjacent channel interference is minimized.
In case of Half Rate coding the same MAIO value is assigned to the two sub-channels
multiplexed on the same timeslot. At the channel assignment, if some unpaired sub-
channels are present on the DMA-TRXs, then the channel pairing is applied. This means
that a MAIO already assigned to a unpaired sub-channel is selected. When no sub-
channel is free, the Dynamic MAIO Allocation process is triggered and a channel <Best
timeslot, best MAIO, sub-channel i> is returned, where the sub-channel index i (i = 0, 1)
is randomly chosen.
Integration of DMA into the radio channel allocation strategy

DMA is an integral part of the channel resource and allocation procedure based on the
Service Layer List (SLL) and Layer (LY) concept (see chap. Service layer lists and chap.
Layer and service oriented channel allocation). It is activated, when the system looks for
resources in a DMA layer and the DMA feature is enabled in the cell. The DMA algorithm
is applied to incoming new calls, to handovers and in case of resource re-allocation (this
last case is applied for ongoing calls moved to the DMA layer, because they had been
served in a layer less preferred than the DMA layer). It is not applied in case of CS pre-
emption: in this case the preempted radio timeslot keeps the already allocated MAIO
parameter. The frequency band and the priority in the Service Layer List (SLL) are
chosen according to the layer and service oriented channel allocation strategy.
The DMA algorithm follows the preferences forced by the “Cell Load Dependent Activa-
tion of half rate” feature, if it is enabled in the cell, by first looking for that forced channel’s
rate. In case of a dual rate standard codec Mobile Station (if this feature is not enabled),
the DMA algorithm looks for both full and half rate channels by selecting the timeslot’s
position less interfered regardless of the Mobile Station’s preferred channel rate. In case
of a dual rate AMR Mobile Station, this cannot be applied because the CS speech AMR
FR and CS speech AMR HR services have different service layer lists (if both config-
ured) and the DMA algorithm cannot look for both full and half rate channels at the same
time.
A50016-G5100-B556-04-7620 Id:0900d8058053df78 123

Mandatory requirements for DMA

The following items are mandatory pre-requisites for Dynamic MAIO Allocation:
– All cells of the same site (i.e. all cells of one BTSM object) are synchronized via air
interface (i.e. the sectors derive the timing for the digital signal processing and the
carrier frequencies from the same clock source and use the same Frame Number).
– Synthesizer Frequency Hopping is applied.
– DMA applies to speech calls only (AMR, non-AMR).
– Service layers for DMA are exclusively dedicated to speech services (service layers
for data calls and (E)GPRS) can only use Static MAIO allocation (SMA)).
DMA can not be applied for the BCCH TRX.
– The same HSN is assigned to all the TRXs using the same instance of the DMA
algorithm.
– The Mobile Allocation (in case of 1x1 frequency reuse) is identical in all the TRXs
using the same instance of the DMA algorithm. Identical Mobile Allocations in all the
TRXs of the network using DMA is strongly recommended for capacity maximization
(1x1 frequency reuse pattern).
Considerations about enabling/disabling DMA

The Dynamic MAIO Allocation can be enabled in one site only if it has already been
enabled in at least two cells in the site. When the user needs to enable/disable the DMA
in a cell, it is recommended to consider the following remarks:
– The DMA can be enabled in one cell only if the frequency hopping has been already
enabled in the cell but the DMA is not enabled in the site yet;
– The DMA can be disabled in one cell only if it has been already disabled in the site;
– The frequency hopping can be disabled in one cell only if the DMA has been already
disabled in the cell;
– Each time the DMA feature is disabled in the site (DMA –> SMA transition) the DMA
algorithm is reset, this means that the MAIOs’ distribution history previously devel-
oped is lost;
– The user can execute any command affecting the MAIO list only if the DMA feature
has been already disabled in the site (if a DMA –> SMA transition has occurred);
– After a DMA –> SMA transition, no changes are performed on the ongoing calls:
these calls maintain the previous MAIO value and the previous mobile’s allocation;
– If a Frequency Redefinition procedure occurs, at the frequency hopping restoring,
channels pertaining to TRXs in the DMA layer must restart frequency hopping by
using the static MAIO value and the mobile allocation (that may have been changed)
assigned to its channel. This causes a low interference in a transitory period.
When Dynamic MAIO Allocation is enabled, it could happen than the BSC resets the
tables storing the information on the allocated MAIO values. As a consequence a MAIO
value that is already in use in the cell could be assigned again by the DMA algorithm and
the call drops due to co-channel interference. For avoiding the occurrence of this situa-
tion the related cells shall be locked by the user both in case of activation/deactivation
of the DMA procedure. For this purpose specific checks are executed by the BSC data-
base.
The transition SMA –> DMA and the corresponding transition DMA –> SMA is managed
with the call in progress.
124 Id:0900d8058053df78 A50016-G5100-B556-04-7620

6.3 Configuring frequency hopping

Overview
Frequency Hopping is disabled by default and can be enabled via the HOPP attribute of
the BTS object. The Hopping Mode is also determined on BTS level via the HOPMODE
attribute.
The Mobile Allocation and the Hopping Sequence Number are determined by a so called
Frequency Hopping System which can be defined either for a BTS via the FHSY object
or for a whole BTSM area via the CFHSY (Common Frequency Hopping System) object,
the latter case is relevant for SMA or DMA configurations. Afterwards the Frequency
Hopping System has to be related to the radio resources in the following way:
• In case the FHSY object is used, the desired radio channels are related to the FHSY
to be used which is done via the FHSYID attribute of the CHAN objects; in this case
the MAIOs are also defined on CHAN level.
• In case the CFHSY object is used, the CFHSY has to be related to the desired TRXs
which is also done via the FHSYID attribute; the MAIOs are defined on TRX level,
too.
DMA has to be enabled for all BTSs involved by the ENDMA attribute subordinate to the
BTS object, for enabling SMA no further attributes have to be configured.
Objects and parameters

Figure 62 shows the parameters involved in the configuration of frequency hopping.
BTSM
BTS:1 CBTS
CALLF01 TRX:1 FHSY:1 CCALLF01 CFHSY:1
CALLF01 CHAN:0...7 MOBALLOC CCALLF02 CMOBALLOC

(e.g. CALLF01, (e.g. CCALLF01,
CALLF... FHSYID FHSYID CALLF02, ...) CCALLF... CCALLF02, ...)
(e.g. = CFHSY_1) (e.g. = FHSY_1)
HOPP MAIO MAIO HSN HSN

(e.g. = TRUE)
HOPMODE ENDMA SUBBAND

(e.g. = BBHOP) (e.g. = BB900)
ENDMA In green colour: Parameters in case BTS (cell) specific frequency hopping is applied
In blue colour: Parameters related to frequency hopping coordinated for the whole site
and Dynamic MAIO Allocation
Figure 62 Managed objects and parameters for frequency hopping

The following objects are related to frequency hopping in a cell:
– FHSY (a frequency hopping system)
– BTS (the cell)
– TRX (the used transceivers)
– CHAN (the used channels)
To support the DMA configuration or SMA configuration for a whole site, the following
additional objects have to be configured, too:
A50016-G5100-B556-04-7620 Id:0900d8058053df78 125

– CBTS (Common BTS)

– CFHSY (Common FHSY)
These objects and the parameters related to frequency hopping are described in the fol-
lowing:
• The CBTS object is subordinate to the BTSM object and defines parameters
common for all BTSs of the site. It has the following attributes:
– CCALLF<nn> (“commonCellAllocationF<nn>”; <nn>: number between 1 and
63): the list of frequencies usable in all BTSs of the superordinate BTSM.
– ENDMA: This attribute permits the user to enable DMA (ENDMA = TRUE) or
disable DMA (ENDMA = FALSE); DMA is disabled by default.
• The CFHSY object subordinate to the CBTS object defines the hopping laws to be
shared by the BTSs of the same BTSM. Two instances per BTSM can be configured
(DMA must be configurable in different bands). This object has the following attri-
butes:
– HSN: Hopping Sequence Number
– CMOBALLOC: The list of frequencies included in the common frequency
hopping system.
The frequencies are defined in terms of CCALLF<nn> attributes (<nn>: number
between 1 and 63).
– SUBBAND: Defines the band to which the CFHSY is applicable.
The CFHSY object is not relevant for the TRXs where the FHSY object is used.
• The FHSY object subordinate to the BTS object defines a frequency hopping system
in case SMA limited to the related cell is applied (i.e. without regarding the other
BTSs of the site). Up to 10 different FHSYs can be created for a single cell. The
FHSY object contains the following attributes:
– HSN: Hopping Sequence Number
– MOBALLOC: The list of frequencies included in the frequency hopping system.
In case of base band hopping the frequencies must be the ones of the previously
created TRXs (TRXFREQ) and of the frequencies previously assigned to the
BTS; in case of synthesizer hopping the frequencies can be chosen between all
possible frequencies defined for the cell, also if not related to the TRXs. There-
fore the number of assigned frequencies can be higher than the number of TRXs
configured.
The frequencies are defined in terms of CALLF<nn> attributes (<nn>: number
between 1 and 63) of the BTS object.
The FHSY object is not relevant for the TRXs where the CFHSY object is used.
• The BTS object has the following frequency hopping attributes:
– HOPP: This parameter allows to enable (HOPP = TRUE) or disable (HOPP =
FALSE) the frequency hopping; the default value is FALSE. In case a common
frequency hopping system (CFHSY) has been assigned to the TRXs, HOPP =
FALSE means that the MSs hop on one carrier only.
– HOPMODE: Enables baseband hopping (HOPMODE = BBHOP) or synthesizer
hopping (HOPMODE = SYNHOP)
– ENDMA (“enableDMA”): Allows to enable DMA (ENDMA = TRUE) or disable
DMA (ENDMA = FALSE); DMA is disabled by default.
In case a common frequency hopping system shall be applied, the list of frequencies
usable in the BTS (determined by the CALLF<nn> attributes) must be defined
according to the CMOBALLOC list of the CBTS (e.g. by setting the CALLF<nn>
values in terms of CCALL<nn> parameters).
126 Id:0900d8058053df78 A50016-G5100-B556-04-7620

• The TRX object contains the attributes which relate this TRX and the subordinate
channels to a common frequency hopping system and determines the MAIO value
in this case. In case the TRX shall be related to a frequency hopping system limited
to the cell, the relation to the local frequency hopping system and the setting of the
MAIO has to done via the subordinate channel objects (see below). The following
TRX attributes are affected:
– FHSYID: The Frequency Hopping Sequence Identifier relating the TRX to the
common frequency hopping system. FHSYID = 0 corresponds to H = 0 in the
“Channel Description” IE informing the MS that frequency hopping is not applied;
when FHSYID is set to another value than 0, then H = 1 is sent to the MS indi-
cating that frequency hopping shall be applied (frequency hopping on more than
one carrier frequency additionally requires HOPP = TRUE).
– MAIO: Mobile Allocation Index Offset to be applied to all subordinated channels
A TRX which shall be included in SMA baseband frequency hopping must have
been assigned a frequency (via the TRXFREQ attribute) included in the
MOBALLOC list. In case of synthesizer hopping the TRX has to be related to all fre-
quencies desired.
• All CHAN objects of a TRX have to be related to a frequency hopping system in this
system is limited to the BTS; in case of a common frequency hopping system the
following attributes are not relevant:
– FHSYID: The Frequency Hopping Sequence Identifier relating a local frequency
hopping system to the channel.
– MAIO: Mobile Allocation Index Offset
All these parameters can be configured via the Radio Commander and via LMT Evolu-
tion.
System-internal control of frequency hopping

Whether frequency hopping is actually active or not is not only determined by the BTS
attribute HOPP, but also by a system-internal flag BTS_IS_HOPPING (which can be
interrogated by the command GETINFO BTS). If e.g. in a BTS with active baseband fre-
quency hopping a TRX-HW (BBSIG, TPU, PA or CU) fails or is manually locked, fre-
quency hopping is automatically disabled by the BSC for the BTS to make sure that
there is no impact on the call quality. In this case the state of the flag BTS_IS_HOPPING
changes to 'NO' while the (exclusively command-controlled) HOPP attribute does not
change. In any case the BSC is the master for both the HOPP attribute and the
BTS_IS_HOPPING flag, i.e. the BTS only changes the frequency hopping if explicitly
requested by the BSC via the LPDLM link. For the BTS there is actually no difference
between a disabling of hopping due to HOPP = FALSE or due to BTS_IS_HOPPING =
NO. If frequency hopping was disabled automatically due to failure or locking of a TRX-
HW, it is again automatically enabled by the BSC if the failed/locked TRX-HW is put
back to service: BTS_IS_HOPPING changes its state to 'YES'.
Parallel usage of SMA and DMA

The BSS system does not support mixed configuration between SMA and DMA on
channels of the same TRX.
Basically there are two main possibilities to configure SMA and DMA in parallel within a
BTS:
• Separate frequency sets used for DMA and SMA:
A50016-G5100-B556-04-7620 Id:0900d8058053df78 127

– The DMA layers use a Cell Allocation (list of cell frequencies) as defined by the
CCALL parameter and a Mobile Allocation (i.e. list of hopping frequencies) as
defined by parameter CMOBALLOC. Here the FHSYID and MAIO data must be
assigned in the TRX object.
– The SMA layers use a Cell Allocation (list of cell frequencies) as defined by the
CALLF<nn> parameter and a Mobile Allocation (i.e. list of hopping frequencies)
as defined by parameter MOBALLOC. Here the FHSYID and MAIO data can be
either assigned in the TRX object or in the CHAN objects subordinate to the
SMA TRX.
• Common set of frequencies used for DMA and SMA:
In this configuration the DMA layers and SMA layers use the same Cell Allocation
(list of cell frequencies) as defined by the CCALL parameter and a Mobile Allocation
(i.e. list of hopping frequencies) as defined by the parameter CMOBALLOC.
Here the CFHSYID and MAIO data
– of the DMA layer TRXs must be configured in the TRX object
– of the SMA layer TRXs can be either configured in the TRX object or in the
CHAN objects subordinate to the SMA TRX.
The MAIO values assigned to the DMA layer TRXs are only in effect when DMA is still
disabled (ENDMA = FALSE in BTS and CBTS object). When DMA is enabled, the
number of available MAIOs is automatically determined by the number of hopping fre-
quencies in the Mobile Allocation. This pool of MAIOs is then used as a common
resource on BTSM (= site) level and allocated in correspondence with the description
above.
g When the SMA TRXs use the same CFHSY like the DMA TRXs, the BSC excludes
the MAIO values of the SMA TRXs automatically from the pool of MAIOs that can
be used and allocated for calls on the DMA layers.
If for both the SMA and DMA TRXs the CFHSYID and MAIO data are assigned in the
TRX object, there is no visible difference in the TRX creation data between the SMA
from the DMA TRXs. The BSC can distinguish the SMA from the DMA TRXs by their
service layer association: all TRX belonging to 'CS speech only' service layers are
regarded as DMA TRXs, all others are considered for SMA.
128 Id:0900d8058053df78 A50016-G5100-B556-04-7620

Radio network management Services
7 Services
7.1 ASCI services

ASCI services (Advanced Speech Call Items) include the Voice group call service and
the Voice broadcast service. The features Release of ASCI VBS and VGCS channels,
CS data transmission during active voice group call and Reactivation of VGCS/VBS
channels after service unavailability are enhancements of these ASCI services.
7.1.1 Voice group call service

The Voice Group Call Service (VGCS) allows the distribution of speech, generated by a
service subscriber, into a predefined geographical area to all or to a group of service
subscribers located in this area. The geographical area is the so-called Group Call Area
(GCA) which is composed of one or more cells. The GCA comprises a number of cells
and shall be predefined in the network by the service provider, ordered and coordinated
by the network user. The group of service subscribers is determined by a group ID and
a group call number.
$,
GROUP"
POTENTIALLISTENER
GROUP!
LISTENER
'#!"'#!!
GROUP! GROUP"
NOGROUPCONNECTION NOGROUPCONNECTION
$, 5,
'#!" '#!!
GROUP"
POTENTIALLISTENER GROUP!
GROUP! SPEAKER
$, LISTENER
'#!" '#!!
GROUP!
GROUP! NOGROUPCONNECTION
LISTENER
'#!! NO'#!
'#!'ROUP#ALL!REA
5,$,5PLINK$OWNLINK NOGROUP
NOGROUPCONNECTION
4RANSMISSIONPATHFORACTIVEGROUPCALL '#!!
Figure 63 Voice group call service in a group call area

A Voice Group Call is initiated by a calling subscriber via service selection and dialling
of the group call number. The Voice Group Call attributes are maintained by the network
in an own network entity called Group Call Register (GCR). The GCR is mainly a data
A50016-G5100-B556-04-7620 Id:0900d8058054086e 129

Services Radio network management
base and it is connected to the MSC in order to provide information about the Voice
Group, e.g. the cells belonging to the GCA.
Priority levels
The Voice Group Calls have an eMLPP priority.
The following priority levels are foreseen for eMLPP:
– Level A: The highest priority; this level can be assigned by the network only, e.g. for
VBS/VGCS emergency applications; in such a case the priority information is stored
in the Group Call Register (GCR).
– Level B: This priority level is also reserved for the assignment by the network, e.g.
for safety.
– Level 0: The highest priority for subscription; e.g. this level can be reserved for public
emergency calls.
– Level 1, 2, 3 and 4: The lower priority levels available for subscription.
Call set up
Dialling the group call number initializes the parallel set-up of connections into all cells
of the assigned service area (point-to-multipoint connection). One common voice traffic
channel is established in each cell of the GCA for the given Voice Group Call, the
members of the group being in the group call area listen to the call via the downlink part
of this channel. The talker speaks to the listeners via the uplink part of the voice group
call channel (1.0 channel mode) or gets an additional dedicated standard uplink traffic
channel (1.5 channel mode), in the latter case the uplink part of the group channel is not
used for speaking, see Figure 64. The members of the group being in the service area
receive notifications of the ongoing group call (see below for details).
Dependent on the call ID and the call priority (e.g. emergency group call) members of
the affected group can decide to join the call or not.
a) ASCI 1.0 Channel Mode b) ASCI 1.5 Channel Mode
DL DL
DL Common VGCS Channel (ARFCN 1) DL Common VGCS Channel

DL DL
UL UL UL UL
(used for speaking) (not used for speaking)
UL
Listeners Speaker Listeners Speaker
Additional UL Channel
(ARFCN 2)
Figure 64 1.0 and 1.5 channel mode

Details on notifications:
The details of sending notifications about a Voice Group Call to an ASCI MS belonging
to the affected group depend on its current state:
130 Id:0900d8058054086e A50016-G5100-B556-04-7620

• The ASCI MS is in idle mode, no call is ongoing:

Such an MS is reached by the paging procedure.
• The ASCI MS owner is listener in another ongoing VGCS/ VBS call:
When the ASCI MS is currently involved in a VGCS/VBS call, it may still receive and
accept normal CS calls and be informed about other VGCS/VBS calls. As the ASCI
MS normally does not monitor to the paging channel (PCH) of the BCCH during an
ongoing ASCI group call, the BSC can instruct the ASCI MSs (currently involved in
a group call) to monitor the PCH if a paging message is to be transmitted. This is
done with the NOTIFICATION FACCH message which is sent via the FACCH of the
ASCI common TCH (one DL TCH used by all ASCI MSs in the cell) directly prior to
the PAGING COMMAND itself (which is sent via the PCH as usual) and which indi-
cates 'paging information is included'.
The BSC sends the NOTIFICATION FACCH message to all cells with an activated
ASCI common TCH only if the PAGING message from the MSC contains the
optional IE 'eMLPP priority' and if the priority level indicated in the 'eMLPP priority'
IE is equal or higher than the priority level defined by the system operator.
• A CS call is ongoing on the ASCI MS:
When the ASCI MS is currently involved in a CS call, the ASCI subscriber may still
receive a VBS/VGCS group call. In this case the BSC informs the busy ASCI sub-
scriber about the new ASCI group call via the NOTIFICATION FACCH message,
which is sent on the FACCH of the dedicated CS TCH and which indicates 'group
call information is included'.
However, the BSC sends the NOTIFICATION FACCH message to the busy ASCI
subscriber only if the VBS/VGCS ASSIGNMENT REQUEST message from the
MSC contains the IE 'call priority' and if the priority level indicated in the 'call priority'
IE is equal or higher than the priority level defined by the system operator.
The notifications can be configured as periodical or single shot dependent on the call
priority. In case a group member enters the area where a Voice Group Call has already
been established, the MS also gets the notifications and can participate the call (“late
entry”). In the basic form, periodic notifications are performed on a common/broadcast
channel and single-shot notifications on dedicated channels, both controlled by the
BSC. The periodic notifications can be extended to the dedicated channels, in this case
the BTS controls the notifications.
Change of speaker
The VGCS feature allows to change the talking subscriber during the call. If the current
speaker wants to stop speaking, the following procedure takes place:
1. The current talker (the group call originator or a subsequent talker) releases the ded-
icated uplink channel or the uplink part of the VGCS channel and joins the common
downlink channel of the cell.
2. The indication that the uplink channel has become free is sent to the listening sub-
scribers (by the UPLINK FREE message from the BTS via the FACCH associated
to the ASCI common TCH).
3. Other group members wanting to become the next talker use the so called push-to-
talk button. As a result, the MSs send UPLINK ACCESS messages to the BTS.
4. The next (succeeding) talker is selected on the principle “first come, first served”.
The BTS sends the VGCS UPLINK GRANT message to the MS of the subsequent
talker.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 131

5. After the MS has replied with SABM with TALKER INDICATION included, an uplink
TCH is allocated in one of the following ways (determined by the ASCIONECHMDL
attribute):
– A separate uplink TCH is allocated to the talking ASCI service subscriber for the
transmission of the uplink speech information ('ASCI 1.5 channel model', the
uplink part of the VGCS channel is not used in this case)
– The uplink part of the ASCI Common TCH is activated and allocated to the
talking ASCI service subscriber ('ASCI 1.0 channel model', saving resources
compared with the 1.5 channel model).
6. The other listening subscribers who have issued a request are rejected.
Security
In order to guarantee confidentiality over the downlink air path, ciphering can be enabled
in the network.
For those ASCI subscribers that use a dedicated channel (i.e. originator of a VGCS call
or the subsequent talker), the usual ciphering procedure as known for CS calls (IMSI
related ciphering based on a subscriber-individual cipher key Kc) is applied in any case.
Special conditions apply, however, for all other subscribers participating in a group call:
• The overall (not talker-related) ciphering of a group call is not based on an individual
cipher key Kc but on the group ciphering key ciphering key KcGroup.
• Within different cells, different Voice Group or Broadcast ciphering keys KcGroup are
used. This means that in case of cell change of an MS also the KcGroup changes.
• The lifetime of the same KcGroup is not longer than the TDMA frame number cycle
(which is equal to 3 hours and 28 minutes period).
• In the BSS and MS, the ciphering key KcGroup is calculated using the so-called ‘Key
Modification Function’ (see below) each time a new ASCI group call is set up in a
cell. Additionally, a new KcGroup is calculated after each TDMA frame number cycle.
Key Modification Function (KMF)
The KMF has the task to fulfill the requirement that in different cells different group
cipher keys KcGroup must be used at different points of time. To achieve this goal, the
KMF calculates different KcGroup keys based on the following input:
– VSTK: a 128 bit short term key provided by the MSC via signalling
– CGI: the Cell Global Identity
– CELL GLOBAL COUNT: used for ensuring that the recalculation of the KcGroup is
done after each complete TDMA frame number cycle
The output of the KMF is the 128 bit group ciphering key KcGroup.
Attributes
The Voice Group Call Service and the Voice Broadcast Service (see 7.1.2 Voice broad-
cast service) are configured with the same attributes. Configurations have to be carried
out on the BSC and the BTS.
Attributes for configurations on the BSC level (command: SET BSC):
– NOTFACCH: This attribute determines for which call priorities a single-shot notifica-
tion/FACCH message is sent in case a VGCS/VBS call is initiated (e.g. NOTFACCH
= HIGHEQ2 means that NOTIFICATION/FACCH messages will be sent for calls
132 Id:0900d8058054086e A50016-G5100-B556-04-7620

having priority equal or higher than 2; NOTFACCH = NOSUPP means that sending
of NOTIFICATION/FACCH messages is not supported).
The priorities regarding periodic notifications and late entry notifications are con-
trolled by the PRIOPERNOTFA attribute, see below.
– ASCIONECHMDL: (relevant for VGCS only) The value TRUE enables the usage of
the uplink part of the common group call channel by the subsequent new talker (1.0
channel model saving resources). The value FALSE disables this feature; in this
case an additional uplink TCH is allocated to the subscriber following the previous
speaker (1.5 channel model, the uplink part of the group channel is not used in this
case).
Attributes for configurations on the BTS level (command: SET BTS), gathered in the
CCCH attribute group:
– ASCISER: enables (value: ASCI_ENABLED) or disables (value: ASCI_DISABLED)
ASCI services in the cell
– ASCICIPH: enables/disables the ciphering of VGCS/VBS calls
ASCICIPH can only be set to TRUE, if:
– ENCALSUP (“encryptionAlgorSupport“, a BSC attribute) includes GSMV1 in
case of legacy BTS1s.
– ENCALSUP includes GSMV1or GSMV3 in case of current BTSs.
– ENPERNOTDE: enables/disables the periodical notification on FACCH of a dedi-
cated TCH, i.e. in case a CS call is already ongoing on the MS. Periodical notification
additionally requires appropriate setting of the PRIOPERNOTFA attribute, see
below. If ENPERNOTDE = FALSE (default value), only a one-shot notification is
sent on the FACCH of a dedicated channel. The ENPERNOTDE value has no influ-
ence in case the MS is in idle mode or an ASCI call is ongoing.
– NOCHFBLK: defines the first block to be used for notification channel.
– NOCHBLKN: defines the number of blocks to be used for notification channel.
– NBLKACGR: defines the number of TDMA frames reserved for the Access Grant
channel during a period of 51 TDMA frames (a multiframe). The NBLKACGR value
must be greater than the NOCHBLKN value.
– PNOFACCH: defines the period for the FACCH notification for a given ASCI call.
Attributes for configurations on the BTS level (command: SET BTS), gathered in the
TIMER attribute group:
– TNOCH: defines the timer used for the minimum period for the NOTIFICATION NCH
and NOTIFICATION FACCH messages.
– TGRANT (“timerGrant”): (relevant for VGCS only) timer used for the repetition of the
VGCS UPLINK message.
– NRPGRANT: (relevant for VGCS only) defines the maximum number of repetitions
of the VGCS UPLINK GRANT message during an uplink access procedure.
– VGRULF: (relevant for VGCS only) defines the timer used for the repetition of the
UPLINK FREE message.
The PRIOPERNOTFA (“priorityPeriodicalNotificationFACCH”) attribute determines the
call priority necessary for periodical notifications on FACCH and in case of late entries
(also controlling the priority for single-shot notification in this case). When e.g. the call
priority is equal or higher than the one defined by this attribute, the notification will be
sent periodically on the common/broadcast channel (additionally in case of an ongoing
CS call on an MS to be informed (a dedicated channel is affected) the value of the
A50016-G5100-B556-04-7620 Id:0900d8058054086e 133

ENPERNOTDE attribute has to be set to TRUE). The PRIOPERNOTFA attribute can

not be set by usual command handling, but is set via a specific patch.
7.1.2 Voice broadcast service

The Voice Broadcast Service (VBS) allows the distribution of speech, generated by a
service subscriber, into a predefined geographical area to all or to a group of service
subscribers located in this area. The geographical area is the so-called Group Call Area
(GCA) which is composed of one or more cells. The GCA comprises a number of cells
and shall be predefined in the network by the service provider, ordered and coordinated
by the network user. The group of service subscribers is determined by a group ID and
a group call number.
A Voice Broadcast Call is initiated by a calling subscriber via service selection and the
dialling of the group call number. The Voice Broadcast Call attributes are maintained by
the network in an own network entity called Group Call Register (GCR). The GCR is
mainly a data base and it is connected to the MSC in order to provide information about
the voice group, e.g. the cells belonging to the GCA. The VBS calls have an eMLPP pri-
ority.
A standard uplink traffic channel is assigned to the calling subscriber who initiates a
Voice Broadcast Call and one duplex broadcast channel is established in each cell of
the GCA for the given Voice Broadcast Call. All the Mobile Stations in the GCA belong-
ing to the affected group listen to this call on the broadcast channel.
Differently from the Voice Group Service the listening group members can not become
speakers.
Dialling the group call number initializes the parallel set-up of connections into all cells
of the assigned service area (point-to-multipoint connection). The members of the group
being in the service area receive notifications of the ongoing broadcast call (for details
see 7.1.1 Voice group call service).
Depending on the call ID and the call priority (e.g. emergency group call) members of
the affected group can decide to join the call or not.
Confidentiality over the downlink air path may be guaranteed by the application of
ciphering – if enabled in the network.
Attributes
The Voice Broadcast Service is configured with the same attributes as the Voice Group
Service. So, please refer to the attributes section of 7.1.1 Voice group call service.
7.1.3 Release of ASCI VBS and VGCS channels

When no Mobile Station is detected in a cell, the group/broadcast channel for that call
in that cell is released. This feature avoids the waste of radio resources.
Group/broadcast channels for an ASCI call are allocated only in cells where at least one
Mobile Station is present. When a late entry occurs (for example a Mobile Station enters
that cell), this Mobile Station starts a notification response procedure. As a conse-
quence, the network re-activates the group/broadcast channel in the cell.
The release of VBS and VGCS Channels is done by the Uplink Reply Procedure.
134 Id:0900d8058054086e A50016-G5100-B556-04-7620

Uplink reply procedure

Starting from a VBS/VGCS request the Uplink Reply Procedure is executed by the fol-
lowing sequence of steps:
1. The BSC evaluates the ASSIGNMENT REQUIREMENT TYPE message sent by the
MSC and checks, if the Uplink Reply Procedure shall be applied; if yes, the proce-
dure goes on with the next step.
2. The BSC initiates the activation of a new group/broadcast channel by sending a
CHANNEL ACTIVATION message to the relevant BTS. The message contains the
“Channel Options” Information Element. If this element is filled with the bit field value
“Bts shall perform polling” and also with the information that “the ASCI talker is not
currently in this cell”, the Uplink Reply procedure goes on with the next step (else,
either if no “Channel Options” IE is included, or if it is included with the value “Bts
shall not perform Uplink-Reply procedure”, or if it is included with “the ASCI talker is
currently in this cell”, the Uplink Reply procedure is not performed).
3. The BTS activates a new group/broadcast channel and starts the timer TUPLREP
immediately after the channel activation. This timer determines, how often the next
step (sending the UPLINK FREE message) is to be repeated. When the timer
expires, another repetition is triggered.
4. The BTS sends the UPLINK FREE message on the affected channel thereby polling
the presence of Mobile Station listeners (this UPLINK FREE message is discrimi-
nated from the UPLINK FREE message sent in case of VGCS calls during the pro-
cedure to change the talker by the Uplink Access Request bit: This bit is set to a
value indicating that the Uplink Reply Procedure is applied and that the uplink
channel is not free for the uplink access procedure, so a VGCS Mobile Station will
not try to seize the uplink channel).
Additionally the BTS internal timer Twupa (not visible to the user) is started immedi-
ately after having sent the UPLINK FREE message. The timer determines the time
period waiting for replies of MSs, before the BTS reacts; the following two cases can
occur:
• If a MS is listening and receives the BTS message, it sends two UPLINK
ACCESS messages to the BTS (this is the uplink reply). As a result the BTS
stops the timer and the channel is not released.
• If the timer expires and no subscriber reply (i.e. no uplink reply) has been
received meanwhile, the BTS initiates the release of the VBS/VGCS channel by
sending the VBS/VCGS CHANNEL RELEASE INDICATION message to the
BSC.
After reception of this message, the BSC makes sure that the Uplink Reply
feature is enabled in that cell (indicated by the ASCIULR (“AsciUplinkReply”)
attribute) and releases the group/broadcast channel (in case of VGCS calls, the
BSC will not deallocate the group/broadcast channel, if the VBS/VCGS
CHANNEL RELEASE INDICATION refers to the same cell as the talker’s one).
At last the BSC sends a NOTIFICATION COMMAND message to the BTS and
a VBS/VCGS ASSIGNMENT RESULT message to the MSC.
Attributes
The following attributes, belonging to the BTS object (BASICS attribute group), have to
be configured:
1. ASCIULR (“AsciUplinkReply”): allows to enable/disable the Uplink Reply Procedure
for both VCS and VGCS services. The possible values are:
A50016-G5100-B556-04-7620 Id:0900d8058054086e 135

– ULRDISABLE: No Uplink Reply is enabled

– VBSENABLE: VBS Uplink Reply is enabled
– VGCSENABLE: VGCS Uplink Reply is enabled
– VBC_VGCSENABLE: Both VBS and VGCS Uplink Reply are enabled
2. TUPLREP (“TimerUplinkReply”): The value of this timer determines the repetition
time for sending the UPLINK FREE message; range: 5 ... 60 s.
For more information about the attributes, ranges and default values, please refer to the
BSC commands and eBSC commands manuals.
7.1.4 CS data transmission during active voice group call

Short application data (e.g. commands, addresses) can be sent during an ongoing voice
group call without interrupting the group call and with negligible delay. More in detail:
• Any subscriber (listener or talker) is able to send short application data to all other
participants of the ongoing VGCS call. In case it is a listener who sends data, his
identity is included. The transmission of short application data is triggered by
pressing the push-to-send key on the MS.
• Any subscriber (listener or subsequent talker) is able to confirm the receipt of data
by sending an acknowledgement regardless if someone is currently talking or not.
Confirmation is done by pressing the push-to-confirm key on the MS.
• The transmission time of the short application-specific data from pressing the "push-
to-send" (PTS) key at the sender's terminal to displaying the data at the receivers'
mobiles does not exceed 500 ms.
The basic ideas to avoid interrupting of an ongoing group call while sending and distrib-
uting short data are the following:
– Short CS application data is usually sent and distributed on air interface via FACCH.
– The ASCI 1.5 channel mode shall be used providing one common DL channel and
two UL channels (one is the counterpart of the DL channel, the other is an additional
allocated dedicated UL channel). In case a listener sends data, one UL channel is
still used for the UL VGCS call, the other for sending CS data.
The ASCI 1.0 channel mode – only one UL channel, which is the counterpart of the
common DL channel – also allows additional transmitting of short data, but with per-
formance degradation.
– Application data is short enough to fit in one SABM frame.
The details of the execution of a "CS Data Transmission During Active Voice Group Call"
depend on the role (talker/listener) of the subscriber who wants to send application data
and on the used ASCI channel configuration (ASCI 1.0 or 1.5 channel mode). The dif-
ferent scenarios can be covered by the following cases:
– Application data is sent by a listener in case the uplink part of the VGCS channel is
free
– Application data is sent by a listener in case the uplink part of the VGCS channel is
not free
– Application data is sent by the current talker
The procedures performed for these cases of data transmission are described in the fol-
lowing topics. The first topic is considered as the basic use case and is treated particu-
larly detailed. The other cases are considered as variations of the basic one.
136 Id:0900d8058054086e A50016-G5100-B556-04-7620

Application data is sent by a listener if the uplink part of the VGCS channel is free
This use case always occurs, if the VGCS call is configured in ASCI 1.5 channel mode
(the current talker uses an own dedicated uplink channel for talking). It also occurs, if
the ASCI 1.0 channel mode is used (the current talker is assigned to the uplink part of
the VGCS channel) and the current talker does not speak at the moment.
In a few words the listener sends the application data via FACCH on the uplink part of
the VGCS channel. The transmitted application data is forwarded to the related BSC and
MSC and from there to the other participants of the VGCS call via FACCH of the
common downlink VGCS channel in the affected cells. The distribution of application
data is controlled by MSC or BSC (depending on the configuration). Figure 65 shows
the associated message flow.
More in detail the following procedure is applied:
1. The listening subscriber prepares short application data to be sent and triggers the
transmission by pressing the push-to-send key.
2. From the UPLINK FREE message periodically sent from the network, the sub-
scriber’s MS knows that the uplink part of the VGCS channel is free. So the MS
requests its specific usage of this uplink channel for application data transmission
by sending an UPLINK ACCESS message to the BTS just on this uplink channel.
The UPLINK ACCESS message contains the “establishment cause” information
element with the entry “UL request for sending application-specific data”.
3. The BTS immediately grants the uplink VGCS channel for application data by
responding with the VGCS UPLINK GRANT message.
4. The listener’s MS packs the application data into the DATA INDICATION message
and sends it as SABM (SET ASYNCHRONOUS BALANCED MODE) message on
the FACCH of the uplink VGCS channel to the BTS. The DATA INDICATION
message, which also includes the MS’s identity, fits into one SABM frame.
5. Having received the data, the BTS acknowledges with the UNNUMBERED
ACKNOWLEDGEMENT (UA) message referring to the DATA INDICATION
message and forwards the DATA INDICATION message to its serving BSC via the
ESTABLISH INDICATION message. The uplink FACCH is released applying the
usual release procedure.
6. The BSC adds the sender’s cell identifier and passes the DATA INDICATION
message to the MSC via the UPLINK APPLICATION DATA message.
7. The MSC, which usually controls the group call, distributes the application data to
all involved BSCs via the NOTIFICATION DATA message, and the BSCs forward
the application data to all BTSs of the group call area.
8. The BTSs pack the application data into the NOTIFY APPLICATION DATA
message and immediately broadcast this message on the FACCH of the relevant
downlink group call channel to all MSs of the group call.
Sending this data can be repeated by the BTSs up to three times (configurable by
network operators). This repetition is useful for cells with bad radio conditions in
order to increase the probability that all group call participants receive the data. The
repetition rate is fixed to 200 ms.
9. Any subscriber who feels concerned about the received short application data can
confirm the receipt of data by pressing the push-to-confirm key on the mobile. The
MS then sends an acknowledgement message.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 137

MS1 BTS BSC MSC
Ongoing VGCS call
Uplink Free
FACCH
Uplink Access
FACCH
(Establishment cause:
UL request for sending data)
VGCS Uplink Grant

FACCH
Set Asynchronous Balanced Mode

FACCH
(Data Indication Establish Indication
(Data, Data_ID, MS1_ID))
(Data Indication) Uplink Application Data
Unnumbered Acknowledgement
(Cell_ID, Data Indication)
FACCH
(Data Indication) Data Request
Uplink Release (Uplink Release (FACCH))

FACCH
Uplink FACCH for MS1 is released
Optionally, the BSC distributes

MSx the data immediately
Unit Data Request
Notify Application Data (Notification Data (Data, Data_ID))
(Data, Data_ID) FACCH
Notify Application Data Notification Data
(Data, Data_ID) FACCH (Data, Data_ID, MS1_ID)

Unit Data Request
Notify Application Data (Notification Data

(Data, Data_ID, MS1_ID))
(Data, Data_ID, MS1_ID) FACCH
Notify Application Data
(Data, Data_ID, MS1_ID) FACCH
Figure 65 Message flow for listener’s data transmission during active VGCS call
138 Id:0900d8058054086e A50016-G5100-B556-04-7620

When the talker is speaking while application data is sent to the affected MSs on the
common downlink VGCS channel, the speech quality may be influenced, because the
downlink transmission of short application data via FACCH “steals” speech frames from
the VGCS channel. This impact is considered as minor, because it spans only a short
time period where the speech can be considered as less important than the successful
transmission of application data (data sent on FACCH is more protected than usual
speech data on a traffic channel).
Immediate distribution of application data by the BSC (not by MSC):
The control of the distribution of application data can be delegated to the BSC as much
as possible (even completely in case only one BSC controls the entire group call area,
which is usually the case e.g. for railway shunting yards applications). Then the serving
BSC distributes the application data immediately to all cells under its control belonging
to the voice group area. Thus the data transfer time can be accelerated up to 200 ms.
The immediate distribution by the BSC is done via the NOTIFICATION DATA message.
The sender’s identity is not included in this notification message in this case.
In addition the BSC adds the sender’s cell identifier and passes the data to the serving
MSC via the UPLINK APPLICATION DATA message. This message includes a flag
informing the MSC that the application data has already been distributed to the BSC’s
cells. The MSC then distributes the data only to the other BSCs belonging to the group
call area – if there are any.
The BTSs broadcast the application data as in the case with MSC controlled distribution.
Application data is sent by a listener in case the uplink part of the VGCS channel
is not free
This use case occurs if the following conditions take place simultaneously:
– The VGCS call is configured in ASCI 1.0 channel mode (thus the current talker uses
the uplink part of the VGCS channel).
– The current talker resides in the same cell as the listener who wants to send appli-
cation data.
– The current talker is speaking.
In this case the network broadcasts the UPLINK BUSY message in the relevant cell,
indicating that the uplink part of the VGCS channel is occupied. So an SDCCH is estab-
lished between the MS of the listener and the BTS for the transmission of the application
data. This is done in the usual way: The listener’s MS requests an SDCCH via RACH
and receives the SDCCH by the IMMEDIATE ASSIGNMENT message. Then the MS
packs the application data into the DATA INDICATION 2 message and sends it as
SABM message on the SDCCH to the BTS. Having received the data, the BTS acknowl-
edges with the UA message and forwards the DATA INDICATION 2 message to its
serving BSC via the ESTABLISH INDICATION message. The SDCCH is released
applying the usual release procedure. The further distribution of the application data is
done in the same way as in the case that the listener has sent data on the uplink part of
the VGCS channel being free (see the previous topic).
Sending of short application data via SDCCH takes longer than sending it on FACCH of
an already allocated radio resource, because the establishment of the SDCCH requires
some time.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 139

Application data is sent by the current talker

When the current talker in an ongoing group call has prepared short application data to
be sent and triggers the transmission by pressing the push-to-send key, the application
data is packed into the DATA INDICATION message which is directly transmitted via
FACCH on the already allocated dedicated uplink radio resource for speaking. This
uplink resource is the dedicated uplink channel in case of ASCI 1.5 channel mode (the
uplink part of the common VGCS channel is not used in this case) or the uplink part of
the VGCS channel in case of ASCI 1.0 channel mode (the UPLINK BUSY message,
broadcast in case the talker is speaking, is ignored). Further distribution of the applica-
tion data is done as in the case where a listener sends application data.
When the ASCI 1.0 channel mode is used, the transmission of short application data via
FACCH “steals” speech frames and may therefor influence the speech quality additional
to the “stealing” effects occurring during the downlink transmission of application data
from the BTSs to the affected MSs. Again, this impact is considered as minor.
Parameters

Parameters of the BSC Managed Object
EPTT enableEnhancedPush- The “CS data transmission during FALSE TRUE/FALSE
ToTalk ongoing VGCS call” feature can be
enabled/disabled by this attribute
VGSDBB VGShortDataDistribu- This attribute allows to distribute the FALSE TRUE/FALSE
tionByBSC short data to be transmitted within the
group call area by control of the BSC in
case only one BSC covers this area;
otherwise the MSC is involved which
causes a certain time delay
Parameters of the BTS Managed Object
T3151 timer3151 This attribute determines the repetition 3s 1 ... 9 s
time for the UPLINK BUSY message in
the cell
NEPTTREP numberOfEnhanced- This attribute determines the number of 0 0 ... 3
PushToTalkRepetitions repetitions of the application-specific
data transmissions
Table 22 Parameters for enhanced pushed-to-talk
7.1.5 Reactivation of VGCS/VBS channels after service unavailability

The feature “Reactivation of VGCS/VBS Channels After Service Unavailability” offers
the (re-)establishment of an ASCI call in the involved cells automatically by the BSC, as
soon as the reasons for the release/rejection have been overcome. Also a reconfigura-
tion of VGCS/VBS Channels in case of shutdown commands and appropriate reconfig-
uration reports are provided. Thus ASCI messages are broadcast in a reliable way even
in case of temporary connection failures.
g The “Reactivation of VGCS/VBS channels after service unavailability” feature can
not be applied together with the “Wireless Priority Service” feature.
140 Id:0900d8058054086e A50016-G5100-B556-04-7620

The feature comprises the following functions:

– VGCS/VBS call re-establishment after failure of the common VGCS/VBS channel in
a cell
– Release of VGCS speaker / VBS call after failure of the speaker’s dedicated UL
channel (if configured)
– Suspension/release of a VGCS/VBS channel request in case of congestion or pre-
emption
– Reconfiguration of a VGCS/VBS channel after a shutdown of VGCS/VBS radio
resources
These functions are described in detail in the next topics.
VGCS/VBS call re-establishment after failure of the common VGCS/VBS channel

in a cell
The reason for a failure of the common VGCS/VBS channel in a cell can be the outage
of the whole cell, the outage of the TRX where the VGCS/VBS channel was allocated,
or a preemption process. In all these cases the radio resource has to be released by the
affected BTS and BSC.
The possibilities of call re-establishment depend on the kind of the ASCI call and the sit-
uation for the talker:
• If in a VBS call the talker has spoken via the uplink part of the VBS channel, which
had to be released in this cell, the complete VBS call is released, since the originator
and unique speaker is lost.
• If in a VGCS call the current talker has spoken via the uplink part of the VGCS
channel, which had to be released in this cell, the call is suspended for the listeners
in this cell. The resources for the call on the A interface are kept and the ASCI call
is buffered to be re-established after the failure has gone or new radio resources are
available. The talker is released (thus a new talker can be established in another
cell), the BSC sends the UPLINK RELEASE INDICATION message to the MSC.
• If in a VGCS/VBS call the talker is not present in the cell, where the VGCS/VBS
channel had been released, or he has got an additional dedicated uplink channel for
speaking, which is not out of order, he can continue speaking. The call is suspended
for the listeners in the cell with the failed VGCS/VBS channel, the resources for the
call on the A interface are kept and the ASCI call is buffered to be re-established
after the failure has gone or new radio resources are available.
The following procedure is applied (see Figure 66) for the listeners in a cell where the
VGCS/VBS channel has been released and the ASCI call is suspended:
1. The BSC buffers information about the suspended ASCI call in the new so-called
ASCI re-establishment buffer and looks/waits for radio resources allocateable as
common VGCS/VBS channel (this behaviour is different from that of the usual
queue, which requests are removed from the queue in case the whole cell fails). A
timer limits the time period how long an ASCI call can be suspended before it is
released. (While waiting for radio resource recovery or new radio resources, new
call requests can come in and are put into the queue.)
2. The BSC does not send a CLEAR REQUEST message to the MSC as usual, but the
new VGCS/VBS ASSIGNMENT STATUS message which is transmitted via the
existing SCCP connection of the VGCS/VBS call. This message contains the infor-
mation “cell temporarily unavailable”.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 141

3. After having received the VGCS/VBS ASSIGNMENT STATUS message, the MSC
stops handovers of participants of the VGCS/VBS call (approaching from other cells)
into the cell with the failure. HANDOVER REQUEST messages for that VGCS/VBS
call into the cell with the VGCS/VBS channel failure are no longer sent.
4. The BSC autonomously releases the radio resources of the VGCS/VBS channel.
The resources at the A interface remain established.
5. The BSC orders the BTS to stop sending its notification messages to the ASCI MSs
by sending the NOTIFICATION NCH and NOTIFICATION FACCH messages.
6. In case the failed radio resource recovers or other appropriate radio resources
become available, the ASCI re-establishment buffer and the queuing buffer (if not
empty) are depleted taking into account the call priority: The call or call request with
the highest priority in both buffers is selected at first, in case of equal priority the sus-
pended call in the ASCI re-establishment buffer is preferred. The radio channel allo-
cation for a usual call is done as usual, for re-establishment of the ASCI call see next
steps.
7. After the suspended ASCI call has been selected from the ASCI re-establishment
buffer, the BSC activates the radio resource (either the recovered old VGCS/VBS
channel or a new channel) by sending the CHANNEL ACTIVATION message to the
BTS and then instructs the BTS to resume notification messages for the ASCI call
by sending the NOTIFICATION NCH and NOTIFICATION FACCH messages to the
BTS including the description of the new VGCS/VBS channel.
The BSC also informs the MSC about the successful re-establishment of the
common VGCS/VBS channel by sending another VGCS/VBS ASSIGNMENT
STATUS message. It contains the information “ cell availabe” for the ASCI call. Con-
sequently requests for handover into this cell from participants of the VGCS/VBS call
entering that cell can be handled again.
8. The BTS resumes notifying the ASCI MSs about the re-established common ASCI
channel by sending NOTIFICATION NCH messages on NCH and NOTIFICATION
FACCH messages on FACCH including the description of the new VGCS/VBS
channel.
So, the suspension of a VGCS/VBS call without release of the resources on the A
interace requires only the new message VGCS/VBS ASSIGNMENT STATUS sent from
BSC to MSC.
As described above, if the current talker of a VGCS call is in the cell where the common
VGCS channel failed, but has got a dedicated uplink channel, he can continue talking.
The talker can give off his role as usual, if he wants to, and becomes a listener. In this
case the dedicated uplink channel is released in the usual way, but with a slight modifi-
cation regarding the CHANNEL RELEASE message sent from BSC to BTS during the
channel release procedure: The “Group Channel Description” Information Element is
not included in the CHANNEL RELEASE message in this case, since the group channel
has been released.
142 Id:0900d8058054086e A50016-G5100-B556-04-7620

MS BTS BSC MSC
VGCS/VBS TCH fails and is released
Notification NCH VGCS/VBS Assignment Status
(Stop VGCS/VBS TCH) (SCCP: Resource Controlling -

Cell temporary unavailable)
Notification FACCH
VGCS/ASCI participants into the cell with failure

(Stop VGCS/VBS TCH)
Waiting for the opportunity to
No more handovers of other

assign a VGCS/VBS TCH again
New radio resource for

VGCS/VBS TCH becomes available
Channel Activation
Channel Activation Ack.
Notification NCH Notification NCH VGCS/VBS Assignment Status

NCH (Start new VGCS/VBS TCH) (SCCP: Resource Controlling -
(Start new VGCS/VBS TCH)
Cell available)
Notification FACCH Notification FACCH VGCS/VBS handovers into the cell
FACCH with new VGCS/VBS TCH resumed
(Start new VGCS/VBS TCH) (Start new VGCS/VBS TCH)
Figure 66 ASCI call re-establishment after failure of the VGCS/VBS channel
Release of VGCS speaker / VBS call after failure of the speaker’s dedicated UL
channel (if configured)
There are two possibilities to assign uplink radio resources to the current talker in a
VGCS/VBS call:
• The talker gets the uplink part of the common VGCS/VBS traffic channel. This mode
of operation is called “1.0 channel mode”, since just one duplex traffic channel is
allocated in the cell, which saves resources compared to the other mode.
• The talker gets an additional, dedicated uplink traffic channel. The uplink part of the
common VGCS/VBS traffic channel is not used. This mode of operation is called
“1.5 channel mode”, requires more resources, but is more flexible than the “1.0
channel mode”.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 143

If the call is a VGCS one and the dedicated channel assigned to the calling subscriber
fails, then the resources of this channel are released by MSC and BSC in the usual way
for ASCI calls and a new talker can seize the talker role.
If the call is a VBS one and the dedicated channel assigned to the calling subscriber
fails, the call is released (according to 3GPP the call must be released when the origi-
nator is lost, even if the broadcast channel still goes on).
Suspension/release of a VGCS/VBS channel request in case of congestion or pre-

emption
If the VGCS/VBS channel can not be allocated in the cell where the group call originator
resides, the call request is rejected (usual behaviour not affected by the new feature).
Else if a VGCS/VBS Assignment Request can not be served in another cell and subse-
quent preemption and queuing are not successful, the following procedure is performed
(including the initiating step; successful execution is assumed):
1. The MSC sends the VGCS/VBS ASSIGNMENT REQUEST message to the BSC.
2. The BSC stores the ASCI call request in the ASCI re-establishment buffer (taking
into account the priority and time of arrival) and waits for radio resources allocate-
able as common VGCS/VBS channel. A timer limits the time period how long the
ASCI call request can be stored before it is rejected (the same timer is used as for
call re-establishment).
3. The BSC responds to the MSC with the VGCS/VBS ASSIGNMENT RESULT
message where the “Chosen Channel” Information Element (referring to SCCP:
Resource Controlling) is set to “none”.
4. Additionally the BSC sends the VGCS/VBS ASSIGNMENT STATUS message to
the MSC, including the information that the “cell is not operational for the call”.
Having received the VGCS/VBS ASSIGNMENT STATUS message, the MSC will
not request handovers of participants of the VGCS/VBS call (approaching from other
cells) into the congested cell. HANDOVER REQUEST messages for that
VGCS/VBS call into the cell with the VGCS/VBS channel failure will not be sent.
5. When new resources are available, the ASCI re-establishment buffer and the
queuing buffer (for point-to-point call requests which could not be served, too) are
depleted taking into account the call priority: The call or call request with the highest
priority in both buffers is selected at first, in case of equal priority the suspended call
in the ASCI re-establishment buffer is preferred. The radio channel allocation for a
usual call is done as usual, the establishment of the ASCI call is started in the same
way as the re-establishment of ASCI calls after failure of the common VGCS/VBS
channel: Channel activation, Start of notifications on NCH and FACCH.
6. Eventually the BSC informs the MSC about the successful establishment of the
common VGCS/VBS channel by sending another VGCS/VBS ASSIGNMENT
STATUS message. It contains the information “cell is operational for the call”. Con-
sequently requests for handover into this cell from participants of the VGCS/VBS call
entering that cell can be handled.
144 Id:0900d8058054086e A50016-G5100-B556-04-7620

Reconfiguration of a VGCS/VBS channel after a shutdown of VGCS/VBS radio

resources
A shutdown of a radio resource (e.g. TRX, channel) allows to exclude this radio resource
from the running system (e.g. for configuration and maintenance) without immediate
release of the calls allocated to this resource. Instead, it is attempted to move the calls
on other radio resources. Only if no alternative resources are available and a certain
time limit is exceeded, the affected calls are released. After timer expiry all shutdown
radio resources are released.
For usual point-to-point calls handovers are performed to replace the shutdown radio
resource. However, for ASCI calls on a VGCS/VBS channel usual handovers, requiring
1:1 relations between calls and channels, are not feasible, because many listeners (can)
share the same channel. Therefore a new VGCS/VBS reconfiguration procedure has
been introduced: The VGCS/VBS is moved onto another radio resource and the sub-
scribers of the ASCI calls are informed via the VBS/VGCS RECONFIGURE message.
More in detail the following procedure is performed (successful execution is assumed):
1. Having received the SHUTDOWN command, the system calculates the starting time,
when the shutdown resources will be released and the new VGCS/VBS assignment
will become active.
2. The BSC activates a new radio resource for the VGCS/VBS channel by sending the
CHANNEL ACTIVATION message to the BTS, which responds with the CHANNEL
ACTIVATION ACKNOWLEDGE message.
3. The BSC informs the BTS about the starting time by sending the NOTIFICATION
COMMAND message including this time. Beginning from the indicated time, the
BTS will no more send notification messages related to the old VGCS/VBS channel
on the NCH to the MSs. Accordingly the BSC triggers the stopping of notification
messages related to the old VGCS/VBS channel on the FACCHs to the MSs, by
sending the NOTIFICATION FACCH message.
4. The BSC reports the new VGCS/VBS channel assignment by sending the
VBS/VGCS RECONFIGURE message to the BTS. This message contains the new
group channel description along with the starting time. If the Cell Channel Descrip-
tion is to be changed, too, then the VBS/VGCS RECONFIGURE2 message is addi-
tionally sent. In this case the Additional Segment field in the VBS/VGCS
RECONFIGURE message indicates that the VBS/VGCS RECONFIGURE2
message is to follow (otherwise this field is set to “0”).
The BTS forwards the VBS/VGCS RECONFIGURE message and the VBS/VGCS
RECONFIGURE2 message (if available) to the MSs on the main DCCH.
5. When the starting time has been reached, the VGCS/VBS channel is switched from
the old radio resource to the new one. This is done by the MSs in the cell, the BTS
and the BSC.
The time period from SHUTDOWN command to the release of the related radio resource
is 30 s.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 145

Parameters

Parameters of the BSC Managed Object
EASCICRE enableASCICallReEs- The “Reactivation of VGCS/VBS FALSE TRUE/FALSE
tablish Channels ... ” feature can be
enabled/disabled by this attribute.
BSCT14PUB bscTimer14Public The queuing timer for the ASCI calls TunitType: TunitType:
in the “public” ASCI re-establishment HLFSEC HLFSEC /
buffer. When the queuing timer
TvalueType: SEC5
expires, a call in the ASCI re-estab-
16 TvalueType:
lishment buffer is released. The
“public” queue is used for ordinary 0 – 254
subscribers.
BSCT14WPS bscTimer14WPS The queuing timer for the ASCI calls TunitType: TunitType:
in the WPS ASCI re-establishment HLFSEC HLFSEC /
buffer. When the queuing timer
TvalueType: SEC5
expires, a call in the ASCI re-estab-
16 TvalueType:
lishment buffer is released. The WPS
queue is used for prioritized sub- 0 – 254
scribers.
Table 23 Parameters for ASCI: reactivation of VGCS/VBS channels
7.2 Location services

The Location Services (LCSs) are a set of methods using GSM mobile network facilities
to determine the position of a Mobile Station (MS) with little margin of error in order to
fulfill local regulatory requirements or commercial purposes. The LCS feature provides
the localization of a MS (target MS) in terms of universal coordinates (latitude and lon-
gitude) and allows a LCS client to specify special Quality of Service (QoS) parameters
like the accuracy or the response time. The location services are supported by the
Serving Mobile Location Centre (SMLC) which is connected to the eBSC via the Lb inter-
face or to the MSC via Ls interface.
Some Location Services features are applicable to any target MS, even if the MS has
no special location service properties; in this case the choice of the positioning method
is restricted.
The Location Services methods are the following:
• Timing Advance positioning method (TA): The TA positioning method locates the
target MS with the help of the TA value within a circle with the radius “r” and the BTS
as its center. The resulting error margin amounts to about 550 meters at most. The
TA positioning method is a standard compliant service.
• GPS positioning method (GPS): The GPS positioning method makes use of the
Standard Positioning Service (SPS), a grade of GPS service available for commer-
cial applications, thus including positioning of the target MS with a built in GPS
receiver.
Two kinds of GPS positioning methods have been implemented:
146 Id:0900d8058054086e A50016-G5100-B556-04-7620

– Mobile Assisted GPS: The network provides assistance data to the GPS
equipped MS to improve the measurement performance (e.g. a list of GPS sat-
ellites in view for improved time-to-first-fix (TTFF); this is a mean of decreasing
the acquisition time for GPS positioning results). The MS performs GPS posi-
tioning and provides the result to the network for correction, for example by
means of correction data for Differential GPS (DGPS).
– Mobile Based GPS: The MS performs both GPS positioning and corrections.
The network provides assistance data to the MS to both improve the measure-
ment performance and to correct the GPS positioning results. The assistance
data is provided to the MS via a dedicated link.
• Enhanced Timing Advance positioning method (E-TA): E-TA uses a TA param-
eter similar as in the TA method, but with higher accuracy (the BTS detects the burst
shift with an enhanced accuracy: 1/16 symbol period). Moreover E-TA executes and
evaluates further measurements of the MS and the BTS (e.g. RXLEV of the serving
and neighboring cells) and applies a prediction matching algorithm, allowing a better
and more precise localization of the MS than the standard TA method. In brief the
measured field strengths of the serving and neigbour cells at the MS’s position are
compared with pre-calculated field strength predictions. The MS position is then cal-
culated from the best prediction match.
The E-TA positioning method is not standard compliant and is always triggered by
the SMLC.
• Uplink Time Difference of Arrival positioning method (U-TDOA): This method
requires so called Location Mobile Units (LMUs) in the geographic vicinity of the
Mobile Station. LMUs shall receive the Time of Arrival of a known signal sent from
the Mobile Station. The geographical coordinates of the LMUs are known and the
position of the Mobile Station is calculated via hyperbolic tri-lateration. The known
signal is the normal burst generated by the Mobile Station while operating in dedi-
cated mode, either on the SDCCH or TCH.
g For the U.S. market several sub-functionalities have been implemented enhanc-
ing the U-TDOA performance, e.g.:
– AMR information is included in the U-TDOA positioning messages, improv-
ing the accuracy and efficiency of AMR calls for U-TDOA.
– The uplink power value actually beeing used is provided from the BSC
towards the SMLC.
– MS measurements, along with the concerned neigbour cells, are provided
from the BSC towards the SMLC. The provision of this information is
enabled by setting the CITAMEASSUP (“cellIdTimeAdvMeasSupported“)
attribute to TRUE.
Network architecture for location services

Figure 67 shows the network elements involved for the location services (Location
Mobile Units are not included). The network elements play the following roles:
– MS (Mobile Station): It supports the measurements in case of Mobile Assisted GPS
and calculates the approximate location in case of Mobile Based GPS.
– BTS: It supports measurements, calculates the Timing Advance (TA) and transmits
the results to the BSC.
– BSC and MSC: BSC and MSC forward data and guide the Location Services proce-
dure; the role depends on the details of the network configuration, see below.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 147

– SMLC (Serving Mobile Location Center): The SMLC manages the overall coordina-
tion and scheduling of resources required to perform positioning of the target MS.
– GMLC (Gateway Mobile Location Center): It is the first node an external LCS client
accesses in a GSM PLMN. The GMLC sends positioning requests to and receives
final location estimates from the SMLC (through the MSC). In one PLMN, there may
be more than one GMLC.
The configuration of the interface between SMLC and BSC can be done by the Radio
Commander and the LMT Evolution as well.
Lp SMLC
SMLC
Lb
Um
BTS eBSC
MSC/VLR External
GMLC
LCS client
Abis A Lg Le
MS
Lc
GMLC
HLR
Other PLMN
Figure 67 Network architecture for location services

Two different network configurations are possible resulting in some differences regard-
ing the processing of the location services:
• NSS centric architecture: Network and Switching System Architecture; the SMLC
is connected to the MSC via the Ls interface. So the SMLC is both physically and
logically connected to the MSC, as represented in Figure 68.
SMLC
Ls
Um
BTS eBSC
MSC/VLR
Abis A
MS
Figure 68 NSS centric architecture

• BSS centric architecture: Base Station System; the SMLC is still physically con-
nected to the MSC, but it is logically connected to the eBSC via the Lb interface as
represented in Figure 69.
148 Id:0900d8058054086e A50016-G5100-B556-04-7620

SMLC
Lb
Um
BTS eBSC
Abis A MSC/VLR
MS
Figure 69 BSS centric architecture

In case of BSS centric architecture, the BSC is the master of the location procedure,
after having received the request from the MSC; in case of NSS centric architecture the
procedures are driven from the MSC and the BSC acts as slave. More detailed the fol-
lowing steps are executed when a location request regarding the TA positioning method
arrives at the GMLC:
• In case of NSS centric architecture:
1. The GMLC asks the MSC to locate the MS.
2. The MSC forwards the request to the SMLC (via the Ls interface).
3. The SMLC asks the MSC for the MS data (for example TA data).
4. The MSC routes the request to the BSC.
5. The BSC delivers the location answers to the MSC.
6. The MSC forwards this information to the SLMC which answers to the GLMC.
• In case of BSS centric architecture:
1. The GMLC asks the MSC to locate the MS.
2. The MSC forwards the request to the BSC (via the A interface).
3. The BSC interacts directly with the SMLC (via Lb interface) exchanging informa-
tion about the location.
4. The BSC provides the location answer to the MSC.
Localization procedure with DTM feature enabled

If a localization procedure is running and the DTM (Dual Transfer Mode) assignment
procedure interferes changing the relevant CS resource, the localization is stopped by
means of the related Reset message on the Lb interface. This behaviour is applied for
all types of localization and it is not affected by the DTM implementation.
Attributes
To configure the Location Services feature, the following parameters have to be config-
ured:
• LCSNSSC (“lcsNssCentric“): This parameter of the SMLC object (subordinate to the
DPC object, see Transmission and transport network management) allows to
choose the location service type (NSS centric / BSS centric) supported by the BSC.
• CITASUP (“cellIdTimeAdvSupport“): This parameter of the SMLC object allows (for
both NSS and BSS Centric Architectures) to enable sending of the Cell Identifier (CI)
and the Timing Advance (TA), via the A interface from the BSC to the MSC; then the
MSC will send the information to the SMLC.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 149

• CITAMEASSUP (“cellIdTimeAdvMeasSupported“): This attribute of the BSC object

is used to enable/disable the provision of standard MS measurements along with the
concerned neighbouring cells.
On the BTS Managed Object the TAADJ parameter (Timing Advance Adjust parameter)
is used to avoid that the delay introduced from the cables, between antenna and BTS,
could be of the same granularity as the timing advance measurement. In fact the better
accuracy of the E-TA method requires to take into account the signal delays due to the
wave propagation in the wires. The BTS detects the burst shift with an enhanced
accuracy (1/16 symbol period). As consequence of this high resolution, the propagation
delays created on the BTS internal signal path have the same magnitude as the
detected burst shift. Then the BTS corrects the detected burst shift with the configured
TAADJ value.
Further attributes to be configured for the Location Services concern the core network
(e.g. the OPC Managed Object) and are out of scope of the radio access network
manuals. For further information please refer to manuals for the core network.
7.2.1 Response timer for location services

The response timer for Location Services (LCS response timer) in the BSC controls the
duration of how long the response from SMLC to BSC on the Lb interface regarding
Location Services can be performed by the SLMC. The timer is used for all the position-
ing methods supported by the BSS system. The LCS response timer is configurable by
the user, in order to add flexibility to the procedures for Location Services (LCS).
In particular, the timer configuration is applied to the following BSSMAP-LE procedures:
– Location Request (Perform Location Request, Perform Location Response)
– Abort (Perform Location Abort)
– BSC-SMLC Layer 3 procedures (e.g. TA response, E-TA response, reject)
Via timer attributes, the BSC takes into account the LCS client type (“emergency”/“non-
emergency”) and LCS QoS information (“low delay”/”delay tolerant”), carried by each
BSSMAP-LE Perform Location Request message.
Each time a LCS Perform Location Request is handled, a new LCS response timer value
is used. Once the value has been assigned, it is kept unchanged till the ending of the
LCS process, i.e. changes of timer attributes by the user do not modify a timer value
during a transaction.
Operation and maintenance attributes

The feature is supported by four timer attributes related to the BSC object and used
during the Location Request.
QoS
Client type Low delay Delay tolerant
Emergency call TEMLD TEMDTOL
Non-emergency call TNEMLD TNEMDTOL
Table 24 Attributes for the LCS response timer
150 Id:0900d8058054086e A50016-G5100-B556-04-7620

• TEMLD (“TimerEmergencyLowDelay”): determines the maximum time for the LCS

response timer for LCS procedures with client type “Emergency” and QoS “Low
Delay”
• TEMDTOL (“TimerEmergencyDelayTolerant”): determines the maximum time for
the LCS response timer for LCS procedures with client type “Emergency” and QoS
“Delay Tolerant”
• TNEMLD (“TimerNonEmergencyLowDelay”): determines the maximum time for the
LCS response timer for LCS procedures with client type “Non-Emergency” and QoS
“Low Delay”
• TNEMDTOL (“TimerNonEmergencyDelayTolerant”): determines the maximum time
for the LCS response timer for LCS procedures with client type “Non-Emergency”
and QoS “Delay Tolerant”
For more details about these attributes, please refer to the BSC commands and eBSC
commands manuals.
7.3 Wireless priority service

The Wireless Priority Service (WPS) feature allows qualified and authorized NS/EP
users to obtain prioritized access to radio traffic channels in congested situations (on
radio interface or Abis interface) when usual call attempts are blocked. WPS is a sub-
scription service, the NS/EP priority assignment to the users is done by the network
control system and takes into account the user responsibility.
WPS is foreseen for speech and asynchronous circuit switched data calls, and it is
intended as a service offered voluntarily by a service provider. When offered, WPS is
always available, no activation is required.
WPS is invoked on a per call basis and does not preempt established calls. Enhanced
multi-level precedence and pre-emption capabilities are used to provide WPS, including
WPS priority levels and a WPS queuing mechanism.
WPS is intended for a very small fraction of all users, but even if the number of these
WPS users is small, it is in any case possible to have significant concentrations of these
users in a particular cell causing an unreasonable impact on public users; therefore it
should be guaranteed that a reasonable amount of public users are served. It is recom-
mended that in case of congestion 75 % of the resources should be available for the
public users, assigning the remaining 25 % to the WPS users.
In case there is no congestion of resources, WPS is not applied.
Functional details
Incoming TCH requests for which queuing is allowed and which cannot be served by
Preemption (if allowed) or via Directed Retry (see Strategies for handling congestion sit-
uations) are put in different cell-specific queues based on their priorities. If a TCH
request is enqueued, the MSC is informed about this process by the QUEUING INDI-
CATION message (as a general rule, incoming inter-BSC directed retries are not
queued).
The information wether queuing is allowed and which priority a TCH request has is given
by the “Priority” Information Element included in the ASSIGNMENT REQUEST and the
HANDOVER REQUEST message. There are 14 different priority levels (1..14, 1 the
highest, 14 the lowest priority). A priority table which correlates the subscriber and event
A50016-G5100-B556-04-7620 Id:0900d8058054086e 151

dependent priorities and the associated parameter settings for the 'Priority' IE is main-
tained in the MSC.
Each cell has 14 queues, one for each priority. These 14 queues are separated into two
different queue groups, i.e. the queues with the higher priority levels make up the WPS
queue group, the ones with the lower priority levels make up the public queue group.
TCH requests are put into the WPS queues or the public queues depending on their
priority level using a first-in/first-out queuing discipline for each priority level. If one
queue group (i.e. WPS or public) is full and an incoming TCH request has a higher
priority than at least one of the queued requests, the TCH requests in the queue group
are re-ordered in order to insert the new request and to remove the (youngest) lowest
priority one from the respective queue (resulting in a rejection of the TCH request with
an ASSIGNMENT FAILURE or HANDOVER FAILURE with cause “no radio resource
available”). If the queue group is full and the new TCH request is lower than the lowest
queued one, the request is rejected in the same way as described above.
TCH request
(PL = 2, QA = 1*) *: Queuing allowed
Directed Retry, Congestion of

Preemption radio resources
not successful
Priority level: 1 2 3 4 5 6 7 14
WPS queues Public queues

LWWPSPRI = 4 (Lowest WPS priority)
QLWPS = 20 (Queue length WPS) QLPUB = 60 (Queue length Public)
Figure 70 WPS queues and public queues

When a previously busy TCH becomes idle again (i.e. when the previously active call on
one TCH resource is released) while TCH requests are queued, the enqueued TCH
requests are served according to the following mechanism:
Starting from the beginning, the first call to be served is a TCH request in the WPS
queue group (if any is available), then, in order to realize e.g. a requested sharing
between WPS and Public calls of 25 %, the subsequent 3 requests will be taken from
the public queue group, when present. If they are not present or the queue group
becomes empty again, it will be served the WPS queue group or if also this queue is
empty the resource will be available for the other needs.
Priority mapping
WPS offers 5 priority levels which allow preferred access to radio resources in case of
congestion; these priority levels are defined in the HLR and are taken into account in
152 Id:0900d8058054086e A50016-G5100-B556-04-7620

case of radio resource congestion. The WPS priority levels based on the mobile access
class and eMLPP priorities are mapped onto the 3GPP or GSM priority levels (14 levels)
which are relevant for the radio resource management. Table 25 shows the relations,
together with the queuing allowed indication on the A interface.
WPS priority Mobile access eMLPP 3GPP/GSM 3GPP/GSM

class priority priority queuing
allowed
(test) 0 ... 15 A 1 0 ... 1
1 12, 13, 14 B 2 1
2 12, 13, 14 0 3 1
3 12, 13 1 4 1
4 12, 13 2 5 1
5 3 12 6 1
(none) 0 ... 10 4 7 ... 14 0 ... 1
Table 25 Mapping of WPS priority levels and eMLPP priority levels to 3GPP/GSM
priority and queuing allowed levels
Attributes for the BTS object

The following attributes are provided in BTS managed object:
• QLWPS (“queuingLengthWPS”): Specifies the maximum number of TCH requests
that can be queued in the WPS area in the cell. Range : 0…100, default value 0.
When QLWPS is set to 0, no WPS queue is foreseen.
• QLPUB (“queuingLengthPublic”): Specifies the maximum number of TCH requests
that can be queued in the public area in the cell. QLPUB should have the same
range and default value as the former QL attribute which will be replaced; because
it becomes equivalent to QL when QLWPS = 0; Range : 0…100, default value 50.
• LWWPSPRI (“lowestWPSPriority“): Specifies the lowest priority level to be consid-
ered in the WPS queues. Range: 1…10, default value 6.
• WPSPREF (“wPSPreference”): This attribute consists of the following 2 fields:
– CounterCycle: Defines which is the complete cycling period in terms of number
of calls served (WPS plus public ones), before restarting the cycle with the WPS
queues again. Range : 2…10, default value 4.
– NumberWPS: Indicates for each complete cycle period, how many WPS
requests should be consecutively served. Range : 1...3, default value 1.
g If the EQ (“enableQueuing“) attribute on cell basis is set to the DISABLED value, the
other queueing attributes are meaningless.
Attributes for the BSC object

The following attributes are provided in the BSC managed object:
• BSCT11WPS: Defines the maximum allowed queueing time for assignment
requests in the WPS queue.
• BSCT11PUB: Defines the maximum allowed queueing time for assignment
requests in the public queue. BSCT11PUB should have the same validity range and
default value as the present BSCT11 which will be replaced.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 153

• BSCTQHOWPS: Defines the maximum allowed queueing time for handover

requests in the WPS queue.
• BSCTQHOPUB: Defines the maximum allowed queueing time for handover
requests in the public queue. BSCTQHOPUB should have the same validity range
and default value as the present BSCTQHO which will be replaced.
7.4 SMS cell broadcast service

SMS cell broadcast (SMS-CB) service allows to broadcast text or binary messages to
all mobile stations connected to a set of cells (see Figure 71). In contrast to usual Short
Message Service (SMS), which offers a point-to-point service, SMS-CB messages are
sent point-to-area. The broadcast range, assigned to a SMS-CB message by mutual
agreement between information provider and PLMN operator, may comprise one cell or
a group of cells up to the entire network. SMS-CB is an unconfirmed push service,
meaning that the originator of the message does not know who has received the
message.
Cell Broadcast Center: CBC SMS-CB

message
SMS-CB
message
BTS
SMS-CB SMS-CB
messages messages
MSC BSC
BTS
Figure 71 SMS cell broadcast service

Typical use cases for SMS-CB are the delivery of emergency, traffic, weather and
provider information. A major benefit is that SMS-CB is not affected by the current traffic
load (especially important in emergency cases).
Structures for SMS-CB and data flow

The BSC gets SMS-CB messages from a Cell Broadcast Center (CBC) and forwards
them to the BTSs belonging to the specified broadcasting area and configured for SMS-
CB services. Broadcasting on air interface is done via the CBCH. Additionally, in order
to inform about the SMS-CB usage, the “CBCH Description” IE is added to the SYSTEM
INFORMATION TYPE 4 message on the BCCH and – if frequency hopping is enabled
– the “CBCH Mobile Allocation” IE, too.
A SMS-CB message can be broadcast in two modes, the basic one and the extended
one. In the basic mode, the broadcasting via CBCH is done only in the 51-multiframes
with TB = 0, 1, 2 and 3 (with TB = (FN div 51) mod 8, FN is the frame number), i.e. in
the first four multiframes in a sequence of 8 51-multiframes. During the other four multi-
frames the MS has time to execute other tasks, e.g. idle measurements. In the extended
mode the 51-multiframes with TB = 4, 5, 6 and 7 are used for SMS-CB broadcasting,
too. A MS is always able to read CBCHs in basic mode, while coping with the extended
mode is optional and may collide with other MS’s tasks.
154 Id:0900d8058054086e A50016-G5100-B556-04-7620

A SMS-CB message is built by up to 15 pages each page comprising 82 data octets

which equates to 93 characters. With header information one page requires 88 octets,
after preparation for transmission via air interface it is 92 octets. One CBCH radio block
(four bursts) contains 184 data bits (as for SDCCH), thus four radio blocks are required
for the transmission of one SMS-CB page. Taking into account that only one radio block
within a signalling 51-multiframe with CHTYPE = BCBCH is CBCH and that only half of
the CBCH capacity is used in basic mode (due to the restriction to TB = 0, 1, 2 and 3),
an average of eight 51-multiframes, with a duration of 1.883 s, is necessary to transmit
one SMS-CB page. An averaged transmission rate of 391 bit/s is achieved which is half
of the comparable SDCCH transmission rate.
Each page of a SMS-CB message carries the same identifier (indicating the source of
the message) and the same serial number. Using this information, the MS is able to
identify and ignore re-broadcasts of already received messages. To permit MSs to
selectively display only those SMS-CB messages required by the MS user, the
messages are assigned a message class which categorizes the type of information that
they contain and the language (relevant for the data coding scheme) in which the
message has been compiled.
Figure 72 shows the message flow from the Cell Broadcast Center to the MS.
CBC BSC BTS MS
Write-Replace
SMS Broadcast Command
(page 1, page 2, ..., page n)
Radio block 1
(page 1)
CBCH
Report-Success Radio block 2
CBCH
2s
Radio block 3
CBCH
Radio block 4
SMS Broadcast Command CBCH
(page 2) ...
...
Figure 72 Message flow for SMS cell broadcast service
1. The CBC orders the broadcasting of a SMS-CB message by sending the WRITE-
REPLACE message to the BSC. It includes the SMS-CB message information for
all pages and various control attributes, e.g.:
– Message identifier
– Serial number
– Cell list
– Repetition period
– Number of broadcasts requested
– Number of pages
– Data coding scheme
2. The BSC forwards the SMS-CB content for each page with a separate SMS
BROADCAST COMMAND message to the assigned BTSs. Since transmission on
A50016-G5100-B556-04-7620 Id:0900d8058054086e 155

air interface will last 1.883 s, the BROADCAST COMMAND for each following page
is sent with a delay of 2 s.
The BROADCAST COMMAND contains the 88 octets of the SMS-CB message
information (content + header) for one page and some control information.
3. The BTS splits the content of a page into four 22 octet blocks, adds the sequence
number and transmits the four resulting radio blocks to the MS.
Repeating and scheduling SMS-CB messages

SMS-CB messages are broadcast cyclically by the cell for a duration agreed with the
information provider. The repetition rate depends on the kind of information to be broad-
cast, for example it is likely that dynamic information such as traffic information requires
more frequent transmission than weather reports.
An appropriate scheduling mechanism has been implemented.
Attributes
• SMSCBUSE (“smsCBUsed”): This attribute, subordinate to the BTS object, indi-
cates if the SMS Cell Broadcast is enabled or disabled.
This parameter can only be set to TRUE if the BTS radio channels are created
accordingly (CHTYPE = BCBCH or SCBCH). Control channels with CBCH capabil-
ity (CHTYPE = BCBCH or SCBCH) may only be deleted if SMSCBUSE is set to
FALSE.
• CBCPH (“CBCphase”): This parameter, subordinate to the BSC object, defines the
type of Cell Broadcast Center (CBC) connected to the BSC. CBCPH = PH1_CBC
indicates that the CBC connected to the BSC is a phase 1 one; CBCPH = PH2_CBC
indicates that the CBC connected to the BSC is a phase 2 one. To indicate that the
CBC connected to the BSC does not support the extended CBCH, the operator has
to set CBCPH = PH1_CBC; if the CBC connected to the BSC supports the extended
CBCH, CBCPH = PH2_CBC shall be selected.
• TCBCSI (“timerForCBCServiceInterruption”): Timer for CBC service interruption.
The BSC transiently stores all SMS Cell Broadcast messages received from the Cell
Broadcast Center in the TDPC memory. The timer TCBCSI, subordinate to the BSC
object, defines the time the BSC delays the deletion of the CBC messages from the
TDPC memory. In other words: when the outage time of a BTS exceeds the time
specified by TCBCSI, all SMS-CB messages for the affected BTS are deleted from
the transient TDPC memory. On recovery of the failed BTS the BSC sends a
RESTART INDICATION to the CBC which initiates a realignment with the BSC
which re-establishes the transient SMS-CB data in the TDPC.
TCBCSI = 0 means that he SMS-CB messages are not cleared from the TDPC
memory – therefore the RESTART INDICATION towards the CBC is not necessary
after BTS recovery.
• LCBM<n> (“localCellBroadcastMessage<n>”), n = 0 ... 3: This parameter, subordi-
nate to the BTS object, specifies the handling and the contents of the local cell
broadcast message. Format: msgid, page, repetition rate (e.g. SEC_0240), scheme
(e.g. ENGLISH).
7.5 Service layer lists

Each kind of possible service is associated with a special Service Layer List (SLL) which
denotes the kind of service and relates a group radio resources – layers, see below – to
this service (a service is supported in a cell only if the associated Service Layer List
156 Id:0900d8058054086e A50016-G5100-B556-04-7620

includes one or more layers). In case of dual area cells (extended and concentric) and
dual band cells two Service Layer Lists per kind of service – one for the primary area
and one for the complementary area – have to be configured. Table 26 shows the kinds
of available services and the related Service Layer Lists. Primary area means complete
area for a concentric cell and far area for an extended cell; complementary area means
inner area for a concentric cell and near area for an extended cell. For dual band cells
the lists for the primary area apply to the frequency band including the BCCH frequency,
the lists for the complementary area to the other band. For all cells which are not dual
area or dual band ones only the Service Layer Lists for primary area are relevant.
Service type Service layer list for primary area Service layer list for complementary
area
Signalling SLLPRM –
(“signallingLayerListPrimary“)
CS speech CRTSWSPELLPRM CRTSWSPELLCOM
HR/FR/EFR (“circuitSwitchedSpeechLayerListPri- (“circuitSwitchedSpeechLayerListComp“)
mary“)
CS speech AMR FR AMRFRLLPRM AMRFRLLCOM
(“aMRFullRateLayerListPrimary“) (“aMRFullRateLayerListComplementary“)
CS speech AMR AMRWBFRGLLPRM AMRWBFRGLLCOM
wideband FR (“aMRWBFullRateGMSKLayerListPri- (“aMRWBFullRateGMSKLayerListCom-
mary“) plementary“)
CS speech AMR HR AMRHRLLPRM AMRHRLLCOM
(“aMRHalfRateLayerListPrimary“) (““aMRHalfRateLayerListComplementary)
CS Data CRTSWDLLPRM CRTSWDLLCOM
(“circuitSwitchedDataLayerListPrimary“) (circuitSwitchedDataLayerListComp““)
HSCSD HSCSDLLPRM HSCSDLLCOM
(“hscsdLayerListPrimary“) (“hscsLayerListComplementary“)
GPRS GLLPRM GLLCOM
(“gprsLayerListPrimary“) (“gprsLayerListComplementary“)
EGPRS ELLPRM ELLCOM
(“edgeLayerListPrimary“) (“edgeLayerListComplementary“)
ASCI ASCILLPRM –
(“asciLayerListPrimary“)
Table 26 Service types and associated service layer lists
Details about the services:

• Signalling
Stand alone Dedicated Control Channel (SDCCH) service for signaling purposes,
e.g., call setups, short message service, location updates, location services, etc.
• CS speech HR/FR/EFR
Circuit-switched single slot speech services with the modes enhanced full rate
(EFR), full rate (FR) or half rate (HR)
A50016-G5100-B556-04-7620 Id:0900d8058054086e 157

• CS speech AMR FR
Circuit-switched single slot speech services that use adaptive multirate full rate
codecs (AMR FR)
• CS speech AMR wideband FR
Circuit-switched single slot speech services that use wideband adaptive multi-rate
full rate codecs (AMR FR)
• CS speech AMR HR
Circuit-switched single slot speech services that use adaptive multirate half rate
codecs (AMR HR)
• CS data
Circuit-switched single slot data transfers with data transmission rates up to
9.6 kbit/s or up to 14.4 kbit/s
• HSCSD
Circuit-switched single slot or multi-slot data transfers provided by high speed circuit
switched data services (HSCSD)
• GPRS
Packet-switched single slot or multi-slot data transfers for General Packet Radio
Services on the packet data traffic channels (PDTCH) that are either embedded
alone or multiplexed in dynamically allocated packet data channels (PDCH)
• EGPRS
Packet-switched single slot or multi-slot data transfers for Enhanced General Packet
Radio Services in packet data traffic channels (PDTCH) that are either embedded
alone or multiplexed in dynamically allocated packet data channels (PDCH)
• ASCI
Broadcast channel to be used for allocating ASCI VBS/VGCS services
The Service Layer Lists for primary area are used for single band standard cells, for the
BCCH band of dual band standard cells and for the primary area (complete/far) of con-
centric/extended cells.
Restrictions:
– HSCSD can not be related to the SLL of primary area of an extended cell.
– Packet switched services must always belong to the complete area in case of a con-
centric cell; in this case GPRS and EGPRS for the SLL of complementary area are
not supported.
– No SLL for complementary area is provided for ASCI services and Signalling.
Layers
A layer is a group of radio resources in a cell and has the purpose to signify all members
of the group as equal regarding the priority of allocation to a call request. Therefore a
layer should include the radio resources which have the same expected radio quality.
There are 12 layers which can be filled with radio resources by assigning the TRXs of
the cell to the layers. This is done via the LAYERID attribute of the TRX object, deter-
mining the number of the layer which the TRX shall belong to (the radio resource of a
TRX is defined by the TRXFREQ attribute). In case of a dual area cell the maximum
number of layers remains 12. When defined in the TRX objects, the layers do not yet
have any service association but just a layer number. The relation to a service is done
later via Service Layer Lists.
The radio resources of one TRX are contained in one layer. It is possible to group TRXs
having the same expected radio quality in one layer or in different layers. The latter case
158 Id:0900d8058054086e A50016-G5100-B556-04-7620

is applied to support for example a service only on a subset of transceivers, or to have

them reserved for a particular service. In case of concentric cells, extended cells or dual
and standard cells, a layer can have mixed channels (channels belonging to inner/com-
plete area, BCCH/no-BCCH band, single/double).
In order to allow various and sophisticated TCH allocation strategies, it is useful to
establish own layers for Packet Switched (PS) services, Circuit Switched (CS) multislot
data services and also for Dynamic MAIO Allocation (a special CS speech call layer is
required).
g It is suggested to include the BCCH TRX in the layers for packet switched services.
Then the whole BTS including both circuit switched and packet switched services is
put “Out of Service” if there is a BCCH outage.
Adding layers to service layer lists

Radio resources are made available for a service by adding layers to the related Service
Layer List. A service is supported in a cell only if the associated Service Layer List
includes one or more layers (otherwise no radio resources are assigned to the service).
A layer <NN> is added to a Service Layer List by inserting a special layer identity, here
LY_<NN>, in the attribute denoting the Service Layer List.
Example:
TRX:3 has been related to layer 3. In order to make TRX:3 available for Circuit Switched
Speech calls, the value LY_03 has to be entered for the CRTSWSPELLPRM attribute.
Within a Service Layer List the layers are sorted with decreasing priority in order to allow
to allocate the most appropriate radio resources first. The priority of a layer inside an
SLL can be increased or decreased with the SET BTS command.
Enabling/disabling/deleting services
Usually the particular services are not enabled/disabled on the level of radio resources
only, but also on higher levels (e.g. on BSC and/or BTS level; e.g. enabling of AMR
requires to set the EAMR attribute to TRUE on BSC level first and later on BTS level).
The enabling within the BTS system has usually to be done “bottom-up”: In case an
extra attribute on BTS level is foreseen for enabling/disabling a service, the system
allows enabling of the service only, if a Service Layer List (SLL) has been associated to
that service. Additionally consistency checks are performed, allowing the enabling of a
service on BTS level only if an appropriate radio resource is available. This availability
is calculated via the SLL configuration.
Vice versa, a Service Layer List can be depleted only, if the relevant enabling/disabling
attribute has been set to FALSE. When disabling a service, no cross checks between
the Service Layer List and the enabling/disabling attributes are executed, because the
user may use the enabling/disabling attribute to switch off the feature temporary.
A50016-G5100-B556-04-7620 Id:0900d8058054086e 159

Signalling and call establishment/release Radio network management
8 Signalling and call establishment/release

Chap. 8.1 GSM connection establishment describes the GSM call set up procedure.
Chap. 8.2 Paging deals with details of the paging procedure.
Chap. 8.3 Immediate downlink repetition of FACCH messages and 8.4 Repetition and
modified scheduling of SACCH messages explain how signalling via FACCH and
SACCH can be performed more robust.
Chap. 8.7 CCCH and PCCCH for GPRS/EGPRS signalling and 8.8 GPRS TBF estab-
lishment and further chapters deal with GPRS signalling and connection management.
8.1 GSM connection establishment
8.1.1 Mobile initiated call

The following steps are performed for a MS initiated call set up (see also Figure 73):
1. The MS sends the CHANNEL REQUEST message on the RACH to the BTS.
2. The BSC allocates a dedicated signalling channel (SDCCH) and informs the MS
about it by the IMMEDIATE ASSIGNMENT message sent on the AGCH via BTS.
The BSC also starts the timer T3101 which runs until the MS indicates that it has
correctly seized the new channel (which the BSC finds out by reception of the CM
SERVICE REQUEST message from the BTS, see below) or until the timer expires.
In the latter case the SDCCH is released.
3. The MS listening to the broadcast channels synchronizes to the allocated SDCCH.
In case of successful access it sends the CM SERVICE REQUEST message on the
new channel which is forwarded to the BSC. The BSC receiving this message stops
T3101.
4. An authentification procedure takes place and the ciphering mode is set up; the sig-
nalling on the Um interface is done via the SDCCH.
5. The BSC allocates a TCH (which requires message exchanges with the BTS) and
reports this radio resource to the MS by the ASSIGNMENT COMMAND message
sent via SDCCH. The BSC also starts the timer BSCT10 which runs until the MS
indicates that it has correctly seized the new channel (which the BSC finds out by
the ASSIGNMENT COMPLETE message, see below) or until the timer expires. In
the latter case the TCH is released.
6. The MS seizes the assigned channel and acknowledges successful establishment
by sending the SET ASYNCHRONOUS BALANCED MODE layer-2 message on the
FACCH of the new radio resource.
7. The BTS acknowledges the establishment of the radio connection by sending the
UNNUMBERED ACKNOWLEDGEMENT layer-2 message to the MS on FACCH.
8. The Assignment of the TCH is accomplished by the MS sending the ASSIGNMENT
COMPLETE message which is forwarded to BSC and MSC. The BSC stops the
timer BSCT10. The connection is now active from the call initiating MS’s point of
view. When the connection to the addressed MS has been established by the
network, the addressed (mobile) station rings which is reported to the originating MS
by the ALERTING message on the FACCH.
9. The SDCCH is released (this requires message exchanges between BSC and BTS).
160 Id:0900d8058052e376 A50016-G5100-B556-04-7620

Radio network management Signalling and call establishment/release
10. As soon as the call has been accepted from the terminating side, the originating MS
gets a CONNECT message via FACCH, responds with the CONNECT ACKNOWL-
EDGE message and the conversation / data exchange can start.
-3 "43 "3# -3#
#HANNEL2EQUEST #HANNEL2EQUIRED
2!#(
#HANNEL!CTIVATION3$##(
#HANNEL!CTIVATION!CK
)MMEDIATE!SSIGNMENT )MMEDIATE!SSIGN#OMMAND
!'#(
#-3ERVICE2EQUEST
3$##( #-3ERVICE2EQUEST
5NNUMBERED!CKNOWL #-3ERVICE2EQUEST
3$##( -32&0OWER#APAB)ND
!UTHENTICATION2EQUEST
!UTHENTIC2ESPONSE 3$##(
#IPHERING-ODE#OMMAND #IPHER-ODE#OMMAND
#IPHER-ODE#OMPL 3$##( #IPHER-ODE#OMPLETE
3ETUP
3$##(
#ALL0ROCEEDING
3$##(
4#(!CTIVATION
!SSIGNMENT2EQUEST
!SSIGNMENT#OMMAND
3$##(
3ET!SYNCHR"AL-ODE
&!##( %STABLISH)NDICATION
5NNUMBERED!CKNOWL
&!##(
!SSIGNMENT#OMPLETE
&!##(
3$##(2ELEASE h2INGINGv
!LERTING
&!##(
#ALL!CCEPTED
#ONNECT
&!##(
#ONNECT!CKNOWL
4#( 3PEECH$ATA
Figure 73 Messaging during call setup (MS originated)
A50016-G5100-B556-04-7620 Id:0900d8058052e376 161

8.1.2 Mobile terminated call

The procedure of call setup for the MS being the terminating point of a connection is very
similar to the setup of an MS initiated call. The main difference is, that the procedure
includes paging steps and paging information (see chap. 8.2). The paging information
is transmitted to the MS by the PAGING REQUEST message sent on the PCH. The MS
answers with the CHANNEL REQUEST message, and the establishment of the traffic
connection is done as described in the previous topic (including establishment of an
SDCCH, authentification and setup of the ciphering mode, setup of the TCH). After
establishment of the SDCCH, paging response information is included in the messages
transmitted from the MS via the BTS and BSC to the MSC. When the TCH is allocated
at the terminating MS, this MS gets the ringing signal which it answers with the
ALERTING message. As soon as the MS has accepted the call, it sends the CONNECT
message to the network (in case of an MS originating the call the CONNECT message
is forwarded to this MS). The conversation can begin when the terminating MS receives
the CONNECT ACKNOWLEDGE message (coming from the originating MS – if so –
and forwarded by the network).
8.1.3 Discrimination of valid and invalid access bursts on RACH

The BTS evaluates the RACH signals in two main stages:
1. The Um layer 1 SW subsystem of the BTS continuously observes the signals
received on the RACH slots. As even without any MS RACH access there are
always at least some noise signals on the RACH, the task of the layer 1 SW subsys-
tem is to evaluate the received signal with respect to specific criteria, e.g. it
measures the receive level and checks if it exceeds a hardcoded minimum threshold
(RSSI level), measures the signal-to-noise ratio, evaluates a soft decision criterion,
tries to decode the training sequence, checks the convolution code, checks for block
CRC errors and measures the delay of the RACH burst to determine the MS-BTS
distance. Together with the decoded signal itself, the results of these checks are for-
warded in form of a set of flags to the BTS call handling SW subsystem. These flags
indicate the results of the BTS layer 1 evaluation (the value 1 indicates: criterion not
fulfilled). On the basis of the flags received, the BTS call handling subsystem clas-
sifies the received signals either as noisy or not noisy. Five flags resulting from the
layer 1 evaluation of the criterions described above (RSSI, signal-to-noise ratio, soft
decision criterion, convolution code and training sequence) are regarded as killer cri-
teria, i.e. if one of these flags was set to 1 by the layer 1 subsystem, the call handling
subsystem regards the received signal as noisy, which leads to an immediate dis-
carding of the received signal. In this case the signal will neither lead to the trans-
mission of a CHANNEL REQUIRED message, nor will it be counted by the PM
counter NINVRACH (Number of invalid RACH messages per cause).
2. If the mentioned five flags assume the value 0 (criterion fulfilled), the BTS call
handling subsystem evaluates three further criteria to check whether a RACH signal
is to be regarded as valid or invalid. A RACH signal is regarded as invalid if one of
the following conditions occur:
2.1 The block CRC error flag has the value 1.
2.2 The received signal level is below the threshold defined by the parameter
RACHBT (“rachBusyThreshold“).
162 Id:0900d8058052e376 A50016-G5100-B556-04-7620

2.3 The delay of the RACH burst indicates that the MS-BTS distance is greater than
the distance defined by the parameter EXCDIST (“excessiveDistance“).
If none of the aforementioned conditions applies, the RACH access is regarded as
valid and the CHANNEL REQUIRED message is transmitted towards the BSC.
Parameters
The RACHBT (“rachBusyThreshold“) attribute subordinate to the BTS object determines
the minimum signal level for regarding a RACH burst as valid. RACH bursts with a signal
level below RACHBT are considered as noise and are discarded. A high dBm value for
the RACH threshold efficiently prevents from phantom RACH access bursts even in
networks with high RACH interference figures and allows only sufficient signal levels
which guarantees a certain QoS level in uplink direction.
g There is another and independent threshold for signal-to-noise discrimination on
TCH/FACCH (relevant for handover requests and for the change of speaker in a
VGCS call) determined by the FACHBT (“fachBusyThreshold“) attribute.
The EXCDIST (“excessiveDistance“) parameter specifies the distance limit for estab-
lishing a call. It is also used for call release and can have influence on handover deci-
sions.
8.1.4 Acknowledgement control

During any dedicated connection the BTS and the MS exchange specific LAPDm sig-
nalling messages in the so-called acknowledged mode: All signalling messages within
acknowledged mode are checked by the LAPDm flow control mechanisms based on
sequence numbers that are assigned to each transmitted LAPD message (LAPDm
refers to layer 2, i.e. the data link layer). Messages in acknowledged mode are SABM
(e.g. including the CM SERVICE REQUEST message), DISCONNECT and I-frames.
Signalling messages that do not have to be acknowledged are transmitted in “unac-
knowledged mode” via UI-frames, such frames are in the downlink direction e.g. the
SACCH messages SYSTEM INFORMATION TYPE 5 and TYPE 6 and in the uplink
direction the SACCH message MEASUREMENT REPORT; for more information about
layer 2 and layer 3 messages and LAPDm frames please refer to the Appendix.
The acknowledged mode is started by a SABM message, and it normally ends with the
DISCONNECT message.
When the BTS transmits a DL layer 2 frame on the air in acknowledged mode – usually
an I-frame with an embedded layer 3 message –, the BTS starts the timer T200 and
waits for the acknowledgement frame from the MS. The acknowledgement frame can
be another I-frame sent by the MS in the UL direction as well as the RECEIVE READY
(RR) message if there is nothing else to be transmitted on layer 3. If the acknowledge-
ment from the MS is not received within the T200 limit, the transmission of the layer 2
frame is repeated and T200 is restarted. The total number of repetitions is restricted to
N200, a fixed value for the BTS side specified by GSM which depends on the control
channel types:
– N200(SDCCH) = 23
– N200(SACCH) = 5
– N200(FACCH/FR) = 34
– N200(FACCH/HR) = 29
A50016-G5100-B556-04-7620 Id:0900d8058052e376 163

If T200 expires after the last layer 2 frame repetition, the BTS sends an ERROR INDI-
CATION message with cause “T200 expired N200+1 times” (followed by a RELEASE
INDICATION message) to the BSC, which releases the associated resources.
The MS uses the layer 2 acknowledgement mechanisms based on T200 in the same
way as the BTS. In the MS, however, the T200 timer values are not variable but hard-
coded.
g Deviating from the N200 numbers listed above, special rules apply for layer 2 con-
nection setup and release: For SABM and DISCONNECT messages the value of
N200 is restricted to 5 (i.e. SABM and DISCONNECT are transmitted at the
maximum 6 times). SABM and DISCONNECT frames are usually sent by the MS
only.
For UA frames, there is no repetition based on T200. UA frames are only sent as a
response to received command frames (e.g. SABM or DISC).
Attributes
T200: LAPDm timer 200 used on different control channel types and determining the
waiting time for a layer 2 frame acknowledgement. The T200 attribute allows to enter
channel-type-specific timer values; the values should be set in correspondence with the
channel mapping and channel characteristics on the radio interface. To achieve an
optimum radio interface performance (from the subscriber's point of view), the following
rules for the T200 timer values should be regarded:
– A Um layer 2 frame retransmission should take place at the earliest after a time
period the MS needs for the transmission of an acknowledgement of a received
layer 2 frame.
– A Um layer 2 frame retransmission should take place as early as possible when the
aforementioned time period has passed and no acknowledgement was received
from the MS.
– Unnecessary retransmissions should be avoided.
On the basis of these considerations, the following T200 default values (different values
for different channels) have been been implemented:
T200:
sdcchSAPI0: 29
facchTCHF: 31
facchTCHH: 38
sacchTCHSAPI0: 90
sacchSDCCH: 70
sdcchSAPI3: 29
sacchTCHSAPI3: 168
g In networks where TMSI reallocation is activated for SMS services, the T200 timer
for SDCCH SAPI3 should be set to 60 (T200(sdcchSAPI3) = 60).
g These values are the best settings from the technical point of view. The recom-
mended values shown above might probably not be suitable to make a call drop rate
(due to ERROR INDICATIONs with cause “T200 expired (N200+1) times”) look
“nice”. In fact, with these settings, the call drop rate due to T200 expiries will deliver
164 Id:0900d8058052e376 A50016-G5100-B556-04-7620

a realistic image of the actual radio interface quality (rather than faking a good call
drop rate in the performance measurement counters).
Remarks:
• The SAPI (Service Access Point Identifier) is used as address for different radio sig-
nalling applications by the LAPDm protocol. SAPI 3 is used for Short Message
Service (point-to-point) transmission only, while SAPI 0 is used for all other layer 3
radio signalling procedures.
• The LAPDm mechanisms are only used for signalling messages. Speech frames
are not transmitted via LAPDm.
• The T200 values for sacchTCHSAPI0 and sacchSDCCH can be changed, but their
values do not have any impact on the system behaviour, as on the SACCH associ-
ated to a TCH and the SACCH associated to an SDCCH the “acknowledged mode”
is not used at present (i.e. T200 is never used on these channel types). The men-
tioned fields are available because, possibly for future purposes, the associated
T200 values are foreseen in the GSM standard.
• When the BTS sends an ASSIGNMENT COMMAND or HANDOVER COMMAND
message to the MS, the BTS starts T200 for these messages as they are embedded
in an I-frame. Whether the MS acknowledges this I-frame on the old channel (by RR
messaging) before it switches over to the new channel or on the new channel,
depends on the mobile type (some mobiles do send the RR message, others do
not). So it can happen that, during an ongoing channel change procedure (han-
dover, TCH assignment etc.) the I-frame containing the channel change message
(e.g. HANDOVER COMMAND) is continuously repeated by the BTS due to missing
layer-2 acknowledgement on the old channel. This “T200-context” can be termi-
nated in the following ways:
– After successful access to the new channel: by the release of the old channel
(RF CHANNEL RELEASE received at the BTS)
– By the receipt of a new SABM message from the MS on return to the old channel
after unsuccessful access to the target channel (this SABM message initializes
the T200 context and flushes the previous timer history)
It is up to the operator to ensure that the T200 values are set long enough to avoid
a call drop indication during a channel change procedure (e.g. handover).
8.1.5 Retransmission of RACH messages

To request a dedicated control channel (normally an SDCCH) from the network, the MS
performs a RACH access by sending a CHANNEL REQUEST message to the BSS via
the RACH. The following reactions can occur:
• The MS receives an IMMEDIATE ASSIGNMENT COMMAND via the AGCH. In this
case, the RACH access was successful and the MS seizes an SDCCH; there is no
retransmission of the CHANNEL REQUEST message on RACH.
• The MS receives an IMMEDIATE ASSIGNMENT REJECT message via AGCH from
the BSC. This happens in case the BSC cannot find any idle SDCCH to satisfy the
request and rejects the access attempts. The timer T3122 defines the time the MS
must wait before it is allowed to send another CHANNEL REQUEST via the RACH
in the same cell. This timer value is sent to the MS in the “Wait Indication” IE within
the IMMEDIATE ASSIGNMENT REJECT message.
• The MS neither receives an IMMEDIATE ASSIGNMENT COMMAND nor an IMME-
DIATE ASSIGNMENT REJECT message via the AGCH before a certain time period
A50016-G5100-B556-04-7620 Id:0900d8058052e376 165

is reached (the time period for retransmission). Such unsuccessful attempts on

RACH can occur due to:
– RACH collisions: This happens when several MSs access the same RACH at
the same time. In this case the BTS cannot decode the CHANNEL REQUEST(s)
and discards the messages.
– Radio interface problems (loss of messages)
– Delayed IMMEDIATE ASSIGNMENT sending due to Abis via satellite link (with
the correspondingly high propagation delay on Abis)
– overload handling which features the discarding of CHANNEL REQUIRED
messages and thus the discarding of the embedded CHANNEL REQUEST
In case of an unsuccessfull RACH access attempt (without receipt of an IMMEDI-
ATE ASSIGNMENT REJECT message), the MS may repeat this attempt up to a
certain maximum number. This maximum number is configurable and is sent to the
MS on the BCCH (SYSTEM INFORMATION TYPE 1, 2, 3 and 4) in the “RACH
Control Parameters” IE. If the MS still did not receive any IMMEDIATE ASSIGN-
MENT COMMAND or IMMEDIATE ASSIGNMENT REJECT message after the last
retransmission, it starts cell reselection to a suitable neighbour cell. To avoid a ping-
pong cell reselection, the MS must obey a waiting time of 5 s before it can return to
the original cell with a further cell reselection procedure, if it has previously left it due
to unsuccessful RACH access attempts.
Parameters
• T3122 (“waitIndication”): This timer sets the MS´s waiting time before the MS is
allowed to attempt another RACH access by sending a CHANNEL REQUEST, if the
BSS response to the previous RACH access was an IMMEDIATE ASSIGNMENT
REJECT message.
• MAXRETR (“maxNumberRetransmission”): This parameter defines the maximum
number of retransmissions a MS can perform on the RACH (before starting a cell
reselection).
The level of MAXRETR has an impact on the RACH load and the speed of MS
access to a cell. In case of RACH and AGCH overload a decrease of MAXRETR can
be used to decrease the number of access attempts of the MSs and therefore the
RACH overload without barring any access classes. A high value of MAXRETR
speeds up the access and thus increases the RACH and AGCH load, a low value
delays the access and may result in cell reselection and therefore in a delay or
unsuccessful cell access if no other cell is available.
• NSLOTST (“numberOfSlotSpreadTrans”): This attribute (indirectly) determines the
number Nd (d: determined) of RACH slots an MS is not allowed to retransmit a
CHANNEL REQUEST message on RACH after an unsuccessful attempt. The
retransmission then takes place in a random slot within a short window of Nr
timeslots (r: random) after the period of the forbidden Nd timeslots, see Figure 74. Nr
is related to NSLOTST as shown in Table 27; Nr is the value reported to the MS and
is related to Nd according to Table 28 (the mapping of table 2 is valid for phase 2
MSs only; for phase 1 MSs there is no Nr, and Nd is always fixed to 41 (0.35 s) for
combined BCCH and to 55 (0.25 s) for uncombined BCCH.
166 Id:0900d8058052e376 A50016-G5100-B556-04-7620

unsuccessful retransmission in
transmission random (1..6) slot
RACH timeslots
Nd = 163 Nr = 6
waiting window: no retransmission retransmission window
Figure 74 Retransmission of unsuccessful channel request on RACH
NSLOTST 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Nr 3 4 5 6 7 8 9 10 11 12 14 16 20 25 32 50
Table 27 Mapping of NSLOTST to RACH timeslot number Nr
Nr RACH timeslots Nd RACH timeslots Nd RACH timeslots

(combined BCCH) (uncombined BCCH)
3, 8, 14, 50 41 (0.35 s) 55 (0.25 s)
4, 9, 16 52 (0.45 s) 76 (0.35 s)
5, 10, 20 58 (0.50 s) 109 (0.50 s)
6, 11, 25 86 (0.75 s) 163 (0.75 s)
7, 12, 32 115 (1.00 s) 217 (1.00 s)
Table 28 Mapping of RACH timeslot numbers Nr and Nd
Configuration hints:
If the Abis connection is realized via satellite link, it is strongly recommended to set
the NSLOTST to 14 as this represents the longest possible RACH retransmission
cycle that can be executed by phase 2 mobiles. This avoids unnecessary retrans-
missions that lead to additional SDCCH seizures and thus to a decrease of the
Immediate Assignment Success Rate (or even to SDCCH congestion).
If the value of NSLOTST is to be decreased in case of high traffic density on the
RACH, it should be done in small steps with close observation of the load situation
on the RACH in order to prevent RACH overload. NSLOTST values with a large Nd
may extend the duration of location update, a value with a small Nd might cause
sporadic RACH overload even with few MSs roaming in the cell.
8.2 Paging
Paging is a procedure to find and contact a MS, to which a call shall be directed, within
its location area (LA; this is also true in case of PS paging where the routing area (RA)
represents a sub area of the location area). Thereby it is indicated to the MS that a radio
connection shall be established. The basic paging procedure includes the following
steps (see Figure 75):
A50016-G5100-B556-04-7620 Id:0900d8058052e376 167

-3 "43 "3# -3#
0AGING
0AGING#OMMAND
0AGING2EQUEST
0#(
#HANNEL2EQUEST #HANNEL2EQUIRED
2!#(
#HANNEL!CTIVATION3$##(
)MMEDIATE!SSIGNMENT )MMEDIATE!SSIGN#OMMAND
!'#(
3!"-0AGING2ESPONSE
3$##( %STABL)ND 0AGING2ESPONSE
5NNUMBERED!CKNOWL 0AGING2ESPONSE
3$##(
#ONTINUATIONOF#ALL3ETUP
Figure 75 Paging messages within mobile terminated call setup

Request and broadcast phase:
1. The MSC knowing the location area of the requested MS informs the BSC which
controls the cells of the desired location area by sending the PAGING message.
2. The BSC then sends PAGING COMMAND messages to the affected cells/BTSs.
The BSC takes care of the Mobile Station’s paging group, as specified in the GSM
05.02 Recommendation (the paging group determines which CCCH blocks the MS
shall monitor for incoming paging messages).
In case of 8.2.1 Hierarchical paging the PAGING COMMAND BTS message
replaces PAGING COMMANDs and the BTS site manager (BTSM) distributes the
paging messages to the subordinate cells/BTSs.
3. The BTSs having received the PAGING COMMAND messages broadcast PAGING
REQUEST messages, which include the identity of the requested MS, on the paging
sub-channel of the CCCH.
In cases where more than one paging request are to be sent at the same time for
the same paging group, the BTSs are able to include up to four Mobile Station’s
identifications within the same message.
Response phase:
In idle mode, the MS listens to the paging sub-channel for the paging group the MS
belongs to.
1. As soon as the affected MS has got the PAGING REQUEST message, it requests
an SDCCH for building up a signalling connection to the network.
168 Id:0900d8058052e376 A50016-G5100-B556-04-7620

2. When the SDCCH has been established, the MS sends the SET ASYNCHRONOUS
BALANCED MODE message including the PAGING RESPONSE to the BTS.
3. The PAGING RESPONSE information is forwarded from the BTS to the BSC via the
ESTABLISH INDICATION message.
4. The MSC gets the PAGING RESPONSE message from the BSC and terminates the
paging procedure.
8.2.1 Hierarchical paging

Hierarchical Paging uses the BTS site manager (BTSM) as broadcasting element for
paging messages: In case paging messages have to be delivered to several cells
belonging to a BTSM, the BSC sends only one specific paging command (PAGING
COMMAND BTSM) to the BTSM which then distributes this command to the cells (see
Figure 76). This feature avoids multiple sending of almost identical PAGING
COMMAND messages on the Abis interface and thus avoids waste of Abis resources
(without this feature the BSC has to send one PAGING COMMAND for each single cell).
Additionally the load on the BSC’s PPXL board (concerning the peripheral processor) is
reduced.
Merging of several PAGING COMMAND messages that actually represent the same
paging but for different cells of one BTSM requires that:
– The cells/BTSs of the BTSM belong to the same location area (same LAC; this is the
typical but not a mandatory configuration).
– The cells/BTSs have the same CCCH configuration (e.g. combined or uncombined
BCCH and SDCCH) and the same NBLKACGR value (see chap. 8.2.5).
Paging BCCH
Request Cell 3
Paging Paging
Request Request
BCCH BCCH
Cell 1 Cell 2
C1
BTSM
Paging Command BTSM

C2
LAPD connection C1: Cell 1
C3
C2: Cell 2
C3: Cell 3
BSC BTS
Figure 76 Hierarchical paging

Hierarchical Paging is executed automatically – if possible; no configuration is required.
If Hierarchical Paging is not possible (e.g. different CCCH configurations in the cells) or
only one cell is concerned, the BSC just sends individual PAGING COMMANDs to the
cells/BTSs concerned.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 169

The Hierarchical Paging feature is supported by all types of BTSs (current BTSs and
legacy BTS1s).
g “BTS” is used in two different ways:
– BTS as hardware or Network Element (NE). In this case the BTS represents a
machine providing radio equipment. Such a BTS can include the equipment for
several cells (e.g. the cells of one site).
– BTS as Managed Object (MO). In this case the BTS represents one cell.
Within the BTS NE, the BTSM controls the different cells (BTS MOs). So the BTSM
is hierarchically positioned between the BSC and the BTS MOs.
Details
With Hierarchical Paging the BSC does not send individual PAGING COMMAND
messages to all affected cells within a BTSM area via Abis interface, but only one
PAGING COMMAND BTSM message to the BTSM. The PAGING COMMAND BTSM
message has the same format as a usual PAGING COMMAND message, but contains
an additional Information Element called “BTSM Broadcast Info” which indicates the
addressed cells/BTSs and for each of them the relevant addressing data of the paging
channel (channel number, paging group, TEI of the BCCH TRX). The BTSM then regen-
erates the PAGING COMMAND messages and distributes them to the affected
cells/BTSs. So, for slender paging on the Abis interface, the BTSM is used as an addi-
tional element, hierarchically positioned between BSC and BTS.
Example:
Individual pagings from the BSC to N cells (N > 1) of a BTS requires N PAGING
COMMAND messages on the Abis interface resulting in an Abis load of 20 · N octets,
whereas Hierarchical Paging needs only one PAGING COMMAND BTSM message with
22 + 3 · N octets. For a 3-cell site, i.e. N = 3, the Abis load for Hierarchical Paging is 31
octets compared to 60 octets without Hierarchical Paging, which means a reduction of
nearly 50 %.
8.2.2 Intelligent selective paging

The Intelligent Selective Paging feature allows to send a paging request to the cell
where the MS is expected and to its adjacent cells within the same location area (instead
of sending paging requests to all cells of the MS’s location area). This functionality
improves the reachability in very crowded areas where the MSs usually do not move sig-
nificantly (e.g. in a stadium). Intelligent selective paging reduces the signalling load for
paging on the Um interface (and on Abis interface if hierarchical paging is not applied).
As a precondition, the MSC must support Intelligent Selective Paging.
Main steps:
1. When the Intelligent Selective Paging feature is active, the MSC keeps ready the
Cell Identity (CI) of the last recorded cell where the MS has been (camping cell), and
the BSC pre-determines the adjacent cells related to the CI within the location area.
2. When paging to the MS is required, the MSC includes the recorded CI for this MS in
the “Cell Identifier List” IE which also indicates that the Location Area Code (LAC)
and the Cell Identity (CI) is to be used by the BSS to confine the cells which shall
broadcast PAGING REQUESTs. The “Cell Identifier List” IE is packed into the
PAGING message and sent to the BSC.
170 Id:0900d8058052e376 A50016-G5100-B556-04-7620

3. The BSC sends PAGING COMMAND messages to the BTS related to the cell with
the reported CI and to the BTSs related to the adjacent cells which have been deter-
mined before. These BTSs then broadcast the PAGING REQUESTs.
4. In case the MSC does not receive the paging response within the expected time
limit, it starts a further paging with the whole location area as paging target.
Attributes
Intelligent Selective Paging can be enabled within the BSS by setting bit 57 of the
MNTBMASK (“maintenanceBitMask“) attribute to 1.
8.2.3 Paging tasks and capacity of the BSC

The PAGING messages, which the BSC receives from the MSC, contain a subscriber
Identity, a paging group number and a LAC. When the BSC receives PAGING
messages from the MSC, it generally distributes them in transmission queues first, one
per LAC and CCCH configuration (on which the number of available paging blocks at
the BTS depends regarding radio transmission). For each of the paging queues, the
paging delivery rate (i.e. transmission rate of PAGING COMMAND messages to the
BTSs) is adapted to the CCCH configuration of the affected cells (e.g. lower delivery rate
to a BTS with less paging blocks per multiframe).
More in detail, when a PAGING arrives from the MSC, the BSC analyzes the 'Cell Iden-
tifier List' Information Element (IE) in order to identify the type of paging that was
received. The following results are possible:
• The “Cell Identifier List” IE is missing, the paging is to be delivered to all cells of the
BSC and the paging is queued in all the controlled queues.
• The “Cell Identifier List” IE contains:
– a RACODE (can happen if a CS paging is received from the Gb interface) or
– a Location Area Code (LAC) only or
– a Location Area Identity (LAI, consisting of MCC, MNC and LAC)
In this case the paging is queued in all the involved queues whose loads are under
the related threshold.
• The “Cell Identifier List” IE contains:
– a BVCI (can happen if a CS paging is received from the Gb interface) or
– a Cell Identity (CI) only or
– a LAC and CI or
– a Cell Global Identity (CGI, consisting of MCC, MNC LAC and CI)
In this case the paging is sent directly towards the indicated cell without any queuing
(CI included).
Technically the BSC applies a two-level queuing concept (see Figure 77):
– The “receive” paging queue temporarily buffers the PAGING messages received
from the MSC (1 buffer per PAGING message).
– The “transmit” queues sort the PAGING messages according to LAC and CCCH
configuration and are used to control the scheduled transmission of the PAGING
COMMANDs to the BTSs with the suitable paging delivery rate (one buffer per
queue).
The maximum number of buffers is 360 for all queues together. If e.g. two different LACs
and and two delivery rates per LAC are used, then the number of buffers reserved for
A50016-G5100-B556-04-7620 Id:0900d8058052e376 171

the transmit queues is 2 LACs · 2 delivery rates = 4. Consequently, the remaining

number of buffers for storage of PAGING message in the receive queue is:
360 – 4 = 354
Paging (PG) messages

PG (LAC-2, CI-5)
MSC
Receive
queue
PG (no LAC)
PG (LAC-2)
PG (LAC-1)
PG (LAC-1)
LAC-1 LAC-2
queues queue
CCCH-1
CCCH-2
CCCH-1
Transmit
queues
BSC
Paging rate 1 Paging rate 2 Paging rate 1 Paging rate 1
BTS B BTS E
CCCH-2 BTS D CCCH-1
BTS A CCCH-1 CI-5
CCCH-1
LAC-1 LAC-2
BTS C BTS F
CCCH-1 CCCH-1
CCCH-1: CCCH configuration 1 LAC-1: Location Area Code 1

CCCH-2: CCCH configuration 2 LAC-2: Location Area Code 2
Figure 77 Principle of basic BSC queuing and distribution for pagings
Paging rates
The paging delivery rate from the BSC to the BTS, which depends on the CCCH config-
uration at the BTS, can be influenced by the CCCHOVLTH (“cCCHOverloadThreshold”)
attribute, see the following tables. Maximum rate refers to CCCHOVLTH = per130
(130 %, this is the default value), medium rate 1 to CCCHOVLTH = per120, medium
rate 2 to CCCHOVLTH = per110, normal rate to CCCHOVLTH = per100. More than 9
paging blocks per multframe can be achieved by configuring a further channel as
BCCH+CCCH.
172 Id:0900d8058052e376 A50016-G5100-B556-04-7620

No. of BSC1 paging Max. BSC1 queuing BSC1 paging

paging times for every capacity for every messages per hour per
blocks LAC/RAC LAC/RAC LAC/RAC
1 90.00 ms 11 40 000
2 45.00 ms 22 80 000
3 30.00 ms 33 120 000
4 22.50 ms 44 160 000
5 17.50 ms 57 205 714
6 15.00 ms 67 240 000
7 12.50 ms 80 288 000
8 10.00 ms 100 360 000
9 and > 9 10.00 ms 100 360 000
Table 29 Maximum rate: paging delivery rates and queue capacity

1 100.00 ms 10 36 000
2 50.00 ms 20 72 000
3 33.33 ms 30 108 010
4 25.0 ms 40 144 000
5 20.00 ms 50 180 000
6 16.66 ms 60 216 086
7 15.00 ms 67 240 000
8 12.50 ms 80 288 000
9 and > 9 10.00 ms 100 360 000
Table 30 Medium 1 rate: paging delivery rates and queue capacity

1 106.66 ms 10 33 752
2 53.33 ms 18 67 504
3 35.00 ms 28 102 857
4 26.66 ms 37 135 033
Table 31 Medium 2 rate: paging delivery rates and queue capacity
A50016-G5100-B556-04-7620 Id:0900d8058052e376 173


5 20.00 ms 50 180 000
6 17.50 ms 57 205 714
7 15.00 ms 67 240 000
8 13.33 ms 75 270 067
9 and > 9 10.00 ms 100 360 000
Table 31 Medium 2 rate: paging delivery rates and queue capacity (Cont.)

1 116.66 ms 10 30 858
2 60.00 ms 18 60 000
3 40.00 ms 28 90 000
4 30.00 ms 37 120 000
5 23.33 ms 50 154 307
6 20.00 ms 57 180 000
7 16.66 ms 67 216 086
8 15.00 ms 75 240 000
9 and > 9 12.50 ms 100 288 000
Table 32 Normal rate: paging delivery rates and queue capacity
Paging overload at BSC

In case the paging queues in the BSC are full so that a PAGING message arrived from
the core network cannot be delivered to any BTS, the BSC declares overload to the
MSC and to the user only if in the next second the percentage of paging requests dis-
carded with respect to the total number of paging requests received is greater than the
PAGQOVLIND (“pagingQueueOverflowIndication”) attribute related to the BSC object.
174 Id:0900d8058052e376 A50016-G5100-B556-04-7620

8.2.4 Paging blocks on CCCH and interplay between PCH and AGCH
The PAGING REQUEST messages are sent from BTS to MS via the Paging Channel
(PCH) which is a part (dynamically assigned) of the DL CCCH. The other part of the DL
CCCH ist the Access Grant Channel (AGCH) (Notification Channel, NCH is neglected
here). Regarding the transmission on a physical channel, the radio resources for the
CCCH are several radio blocks on a signalling multiframe which consists of 51 TDMA
frames. PCH shares the CCCH resources with AGCH on a block by block basis
(4 TDMA frames build one radio block). Generally the assignment of a CCCH block to
PCH or AGCH is done dynamically, so the MS has to find out the usage type of a
received CCCH radio block by extracting the message type after it has de-interleaved
and decoded the message within the radio block.
The total number of CCCH blocks within a multiframe depends on the CCCH configura-
tion: CHANTYPE = MAINBCCH provides 9 CCCH blocks per multiframe, while
CHANTYPE = MBCCHC provides only 3 CCCH blocks per multiframe (see chap. Chan-
nels). 3GPP TS 44.018 defines 3 paging request types leading to different maximum
rates for sending PAGING REQUEST messages. If all available CCCH blocks are used
for paging, the maximum paging rates of Table 33 are achieved.
Paging CHTYPE = MAINBCCH CHTYPE = CCCH CHTYPE = MBCCHC

Req. (9 paging blocks per (9 paging blocks per (3 paging blocks per
type multiframe) multiframe) multiframe)
1 275 257 275 257 91 752
2 412 886 412 886 137 629
3 550 515 550 515 183 505
Table 33 Maximum paging capacity of a BTS (messages per hour)
Several CCCH blocks can statically be reserved for AGCH usage only, thus reducing
the number of available radio blocks shared for PCH and AGCH.
The MS has to listen only to a small fraction of radio blocks shared for PCH and AGCH
in order to get the PAGING REQUEST messages addressed to the MS (discontinuous
reception): Only one certain radio block within a multiframe can contain a relevant
PAGING REQUEST message for a certain MS and such a message only can occur
every (N+1)th multiframe where N is a small configurable integer number (N:
NFRAMEPG). The radio blocks to be monitored in the sequence of signalling multi-
frames are denoted by the paging group which the BSC and the MS calculate from the
IMSI, the used CCCH configuration and the number N in the current cell. By just moni-
toring a subset of the CCCH blocks for paging the MS can save battery capacity.
Figure 78 shows an example of sharing CCCH resources on the BCCH carrier config-
ured for 9 CCCH blocks and with 2 CCCH blocks reserved for AGCH. With
NFRAMEPG = 1, between two multiframes which can address a certain MS, there is
one multiframe which can not contain a paging message for this MS, so there are 14
paging groups, seven on the first multiframe and seven on the second. The third multi-
frame addresses the same MSs as the first one.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 175

2 CCCH Blocks CCHTYPE = MAINBCCH

reserved for AGCH Paging Paging (9 CCCH blocks, used as AGCH or PCH)
(NBLKACGR = 2) Group 1 Group 2
PCH / PCH / PCH / PCH / PCH / PCH / PCH /

F S BCCH AGCH F S AGCH
AGCH
FS
AGCH AGCH F S AGCH AGCH
FS
AGCH AGCH
1 Multiframe between Paging
1 2 3 4 5 6 7 8 9
(NFRAMEPG = 1)

AGCH
FS
FS
AGCH AGCH

AGCH
FS
FS
AGCH AGCH

AGCH
FS
FS
AGCH AGCH
Signalling multiframe with 51 TDMA frames
F: FCCH S: SCH
Figure 78 Example for CCCH resource sharing between PCH and AGCH
Scheduling of paging requests and AGCH requests

The BTS does not immediately serve PCH requests and AGCH requests arriving from
the BSC, but puts them in queues first. The decision if a shared CCCH block is used for
a paging request or for an AGCH request then depends on the loads of the queues.
The BTS keeps for each paging group one paging queue with two queue places. Each
queue place can contain one PAGING REQUEST message, which in turn can contain
up to 4 subscriber identities. In correspondence with the paging group and the type of
subscriber identity the BTS assembles the PAGING REQUEST messages by combining
the subscriber identities of up to 4 PAGING COMMANDs into one PAGING REQUEST
message.
On the other hand the BTS also provides an AGCH queue with 16 places, where each
IMMEDIATE ASSIGNMENT COMMAND or (in case of SDCCH blocking) IMMEDIATE
ASSIGNMENT REJECT requires one place.
The following scheduling principle is applied: If the AGCH queue load is too high (and –
in some cases – the delays for serving AGCH requests become too high), the BTS
dynamically priorizes the AGCH messages higher than the paging messages. Three
states of the AGCH queue are defined resulting in different preemption behaviours:
• Low AGCH queue load:
Less than 12 of the 16 AGCH queue places are occupied and AGCH delays are
acceptable.
In this case PCH messages have a higher priority than AGCH messages. This
implies that the IMMEDIATE ASSIGNMENT messages waiting for delivery in the
AGCH queue are delivered on a non-reserved block only if no PAGING REQUEST
message is pending in the paging queue.
176 Id:0900d8058052e376 A50016-G5100-B556-04-7620

• Medium AGCH queue load:

Less than 12 of the 16 AGCH queue places are occupied, but the AGCH delays
become unacceptable. Two preemption possibilities occur:
– If the paging queue related to the CCCH block to be filled is full, the paging
request is preempted (because there is a risk of paging request overload for this
paging group which would result in discarding of paging requests).
– If the paging queue related to the CCCH block to be filled is only half full, the
AGCH request is preempted.
Figure 79 illustrates these preemption mechanisms.
• High AGCH queue load:
12 or more of the 16 AGCH queue places are occupied.
In this case AGCH requests have absolute precedence over PCH ones until the
number of AGCH requests pending in the queue drops again below 12.
Priorizing paging message higher than AGCH messages would not make sense as
a paging procedure can only lead to the successful setup of a connection, if AGCH
resources are available for the SDCCH assignment, which is a precondition for the
transmission of a paging response.
16
15
14
Access Grant Queue
13
12
11 ImAss ImAss: Immediate Assignment

PagReq: Paging Request
10 ImAss PG: Paging Group
F: FCCH
9 ImAss S: SCH
8 ImAss
7 ImAss Paging Queues (one for each Paging Group)

6 ImAss
PG 1 PG 2 PG 3 PG 4 PG 5 PG 6 PG 7
5 ImAss
4 ImAss PagReq PagReq PagReq
3 ImAss PagReq PagReq PagReq PagReq PagReq PagReq
2 ImAss wait wait wait
1 ImAss

F S BCCH AGCH F S AGCH FS AGCH F S AGCH FS -
AGCH AGCH AGCH AGCH AGCH
reserved reserved AGCH PCH pre- AGCH PCH pre- AGCH PCH pre-
for AGCH for AGCH preempted empted preempted empted preempted empted
Figure 79 Example for scheduling of AGCH and PCH requests

When the CCCH block of a particular PCH group was preempted for transmission of an
AGCH request, the BTS suspends the AGCH preemption for this paging group for the
next paging group cycle, i.e. when the same paging group is scheduled again for trans-
A50016-G5100-B556-04-7620 Id:0900d8058052e376 177

mission over Um, the 'shared' CCCH blocks messages cannot be preempted for AGCH
again. This is done in order not to delay the Um delivery of a paging message for one
paging group via the Um interface for too long. CCCH blocks of other paging groups may
be preempted independently of this suspension, but, of course, the same principles
apply for all paging groups.
Special and advanced scheduling sub-functionalities:
• The BTS treats IMMEDIATE ASSIGNMENT COMMAND messages that include the
TBF starting time with a higher priority to ensure they arrive before their TBF starting
time expiry at the MS. To achieve this, a separate AGCH queue has been imple-
mented and the policy for the enqueuing of new AGCH messages as well as the
policy of reading out athe queues has been modified.
• When the (normal) AGCH queue is full, the BTS treats incoming IMMEDIATE
ASSIGNMENT messages with higher priority than already queued IMMEDIATE
ASSIGNMENT REJECT messages. These messages are discarded from the queue
to make room to the incoming IMMEDIATE ASSIGNMENT messages.
• In the two phase packet access procedure for (E)GPRS, when also the TBF starting
time is provided, the “TBF Starting Time” field is taken into account to evaluate if the
BTS is able to send the message to the MS in time. In the negative case the
message is not inserted into the AGCH queue (and is therefore not transmitted on
the Um interface).
Attributes and configuration

• NBLKACGR (“noOfBlocksForAccessGrant”): This attribute specifies the number of
CCCH blocks to be reserved for AGCH during one multiframe (51 TDMA frames).
This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 3) in the
“Control Channel Description” IE.
The setting of NBLKACGR refers to each CCCH timeslot created in a cell. In other
words, if in a cell two CCCHs have been created (e.g. one MAINBCCH on timeslot
0 and an additional CCCH on timeslot 2 of the BCCH TRX (with 9 CCCH blocks
each) and NBLKACGR has been set to 2, in both CCCHs the BTS reserves two
blocks for AGCH, while the 7 remaining ones remain “shared” for PCH and AGCH
in either CCCH.
In correspondence with the GSM specification, the blocks that are reserved for
AGCH are located in adjacent CCCH blocks at a specific position within the
BCCH/CCCH multiframes (235 ms). This means that NBLKACGR should not be set
to a too high value, as this would – in periods of high paging load – have the effect
that, due to the resulting reduction of paging groups and the priority of paging in the
non-reserved CCCH blocks, paging is performed mainly in the non-reserved CCCH
blocks, while AGCH messages can only be transmitted on the reserved blocks. As
these are grouped at adjacent positions within the BCCH/CCCH multiframes, the
burst-wise receipt of more than 4 IMMEDIATE ASSIGNMENT messages within a
very short time period could result in an overflow of the BTS AGCH queue and thus
to AGCH overload.
• NFRAMEPG (“noOfMultiFramesBetweenPaging“): This attribute defines the
number of multiframes between two transmissions of a paging message to mobiles
of the same paging group (NFRAMEPG specifys N in the general description above.
Setting NFRAMEPG to a higher value results in an increase of the number of paging
groups (that are sent on the Um with a lower frequency as the Um capacity remains
the same), and thus to an extension of the buffer space which is available in the BTS
for the PAGING REQUESTs that are to be transmitted. Thus, with a higher value of
178 Id:0900d8058052e376 A50016-G5100-B556-04-7620

NFRAMEPG the incoming paging traffic is distributed over a greater number of

paging groups (paging queues) and thus the BTS can manage temporary paging
peaks in a better way than with a small value of NFRAMEPG. The smaller the value
of NFRAMEPG, the earlier the BTS will run into congestion of single paging queues,
which results in “extended paging” or/and “paging reorganization”.
On the other hand, the higher the value of NFRAMEPG, the longer the time distance
between pagings of the same paging group. This increases the average call setup
time for MSCs (from point of view of the calling party).
8.2.5 (E)GPRS network mode of operation for paging

The network may provide coordination of paging for circuit switched (CS) and packet
switched (PS) services. Paging coordination means that the network sends paging
messages for CS services on the same channel as used for PS services. Therefore the
MS monitoring only one channel at any time can get both CS and PS paging messages.
The Network Mode of Operation determines which type of channel the MS has to
monitor for paging messages and if there is paging coordination.
• Network Mode of Operation I:
The network sends CS and PS paging messages for (E)GPRS attached mobiles on
the same channel – i.e. PPCH if configured, otherwise PCH – in case the MS is in
packet idle mode (no PDCH assigned). In case the MS is in packet transfer mode
(PDCH assigned), the network sends CS paging messages on this PDCH. Thus, the
MS receives CS pagings even if it is in packet transfer mode. CS and PS paging are
coordinated.
• Network Mode of Operation II:
The network sends both CS and PS pagings on the PCH. CS paging continues on
the PCH when the MS has been assigned a PDCH. As a consequence, a MS in
packet transfer mode (PDCH assigned) monitoring only one channel at any time
does not receive CS pagings. CS and PS paging are only coordinated for an MS in
packet idle mode.
A PBCCH must not be created in a cell in network mode of operation II.
• Network Mode of Operation III:
If the PPCH is available, the network sends PS pagings on PPCH and CS pagings
on the PCH, so in this case (and MS in packet idle mode) there is no coordination
for PS and CS paging and the MS must monitor both paging channels in order to
receive paging messages for both CS and PS services. As in network mode of oper-
ation II no CS pagings are provided on the PDCH for the MS in packet transfer mode
(no coordination). Only if no PPCH is available, CS and PS paging messages are
both sent on the PCH to be received by an MS in packet idle mode.
Network mode Paging channels used for PS and CS pagings

of operation
PPCH and PCH available Only PCH available
I CS and PS pagings on PPCH CS and PS pagings on PCH
(MS in packet idle mode) (MS in packet idle mode)
CS pagings on PDCH CS pagings on PDCH
(MS in packet transfer mode) (MS in packet transfer mode)
Table 34 Paging channels used for PS and CS pagings
A50016-G5100-B556-04-7620 Id:0900d8058052e376 179

Network mode Paging channels used for PS and CS pagings

of operation
PPCH and PCH available Only PCH available
II – CS and PS pagings on PCH
III CS pagings on PCH CS and PS pagings on PCH
PS pagings on PPCH
Table 34 Paging channels used for PS and CS pagings (Cont.)
Attributes
The NMO (“networkModeOfOperation“) parameter determines the network mode of
operation. It can assume the values NMO_1, NMO_2, NMO_3 according to the three
network modes of operation.
g For proper operation the Network Mode of Operation should be the same in each
cell of a routing area. The NMO value is broadcast in the SYSTEM INFORMATIONs
on the BCCH/PBCCH.
PAGCOORCLB (“pagingCoordinationClassB”): This parameter enables/disables
paging coordination for MS of class B (MS not capable to handle CS and PS connec-
tions simultaneously). With this feature the MS in packet transfer mode can be paged
for CS connection with the PACKET PAGING REQUEST message sent via PACCH.
8.3 Immediate downlink repetition of FACCH messages

This feature allows to repeat downlink FACCH messages under critical radio conditions
immediately: The BTS transmits a FACCH message twice in immediate succession thus
adding redundancy to the information sent on FACCH.
Usually call drops occur only if the coverage is so poor that the bit error rate on the traffic
channels does no longer allow an undisturbed communication. As long as standard
speech codecs (EFR, FR and HR) are used, the robustness of the signalling channels
(FACCH and SACCH) corresponds to the one of the speech codec, which means that
the call drop is related with an unacceptable quality of service (QoS). In AMR networks,
however, AMR call drops may happen due to degraded signalling performance although
on the TCH the communication is still possible with an acceptable QoS. The vast
majority of call drops occur during handover signalling where handover information is
sent via FACCH. So, FACCH message repetition directly reduces the call drop rate for
AMR calls. In other words, FACCH message repetition adapts the performance of the
FACCH signalling to the robustness of the AMR speech codecs.
When the repetition of a FACCH message (R-FACCH) is applied, the receving MS has
three successive chances to decode the FACCH message – assumed the MS has
appropriate capabilities: First the MS tries to decode the first message, second it tries to
decode the repeated message, third it tries a joint decoding (“chase combining”) of both
messages. If both messages can be successfully decoded, the repeated one is dis-
carded, if the decoding of only one of the two FACCH messages fails, the MS takes the
successfully decoded one.
g FACCH message repetition is combined with temporary overpower (if enabled), see
chap. Temporary overpower.
180 Id:0900d8058052e376 A50016-G5100-B556-04-7620

a) Full rate CS speech
Timeslots: 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3
„even“ ... ...

„odd“ ... ...
Initial FACCH block Repeated FACCH block Speech
b) Half rate CS speech
Timeslots: 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3
„even“ ... ...

„odd“ ... ...
Initial FACCH block Repeated FACCH block

Sub-channel 0 Overlap
Sub-channel 1 initial / repeated
FACCH block
= (Normal burst)
„even“ „odd“
Figure 80 FACCH block repetition
MS capabilities for decoding repeated FACCH messages

The BSS derives the capability of the MS to support decoding of repeated FACCH
messages from uplink signalling: The MS signals its R-ACCH capability (R-ACCH com-
prises R-FACCH and R-SACCH, see 8.4.2 Repetition of SACCH blocks) via the 1-bit
flag “Repeated ACCH Capability” (RACCH_CAP) which is part of the “Classmark 3”
Information Element sent in the CLASSMARK CHANGE message.
With respect to the R-FACCH capabilities, the MSs can be divided into the following
groups:
• Mobiles older than 3GPP Release 6:
These mobiles are not capable of the joint decoding of the pair of original and
repeated FACCH message. The receipt of original and repeated FACCH message
simply means the receipt of two separate FACCH messages without any logical
relation between both messages. Nonetheless the double transmission of the
FACCH message increases the probability that one of the two can correctly be
decoded. If both the first and the second FACCH message are correctly received,
the MS answers the second one with a LAPDm REJ frame (as the BTS is informed
about the MS's R-ACCH capabilities, it knows how to manage this answer).
Some legacy mobiles can cope only with repeated FACCH messages of the types
ASSIGNMENT COMMAND and HANDOVER COMMAND (embedded in a LAPDm
A50016-G5100-B556-04-7620 Id:0900d8058052e376 181

“I-frame”, used in acknowledged mode). Therefore the operator has the possibility
to enable R-FACCH only for these cases.
• Release 6 mobiles with RACCH_CAP = 0:
These mobiles are capable of joint decoding but they support the reception and
management of repeated FACCH messages only for LAPDm “command frames” (I-
frames or UI-frames, UI-frames are used in unacknowledged mode), not for LAPDm
“response frames” (UA-frames, RR-frames, DM-frames). The operator can enable
R-FACCH for all LAPDm command frames (I-frames or UI-frames), including I-
frames that contain layer 3 messages other than ASSIGNMENT COMMAND or
HANDOVER COMMAND.
• Release 6 mobiles with RACCH_CAP = 1:
These mobiles are capable of joint decoding and they support the reception and
management of repeated FACCH messages for all types of LAPDm frames, i.e. both
LAPDm command frames (I-frames or UI-frames) and LAPDm response frames
(UA-frames, RR-frames, DM-frames).
R-FACCH activation trigger

If the R-FACCH feature is enabled, an immediate downlink FACCH message repetition
is triggered by a timer or event depending on the type of message to be sent on FACCH:
• For LAPDm I-frames (used in acknowledged mode and containing e.g. ASSIGN-
MENT COMMAND, HANDOVER COMMAND), the usual trigger is the expiry of the
LAPDm timer 200, attribute: T200 (T200 usually determines the waiting time for a
LAPDm frame acknowledgement; if the acknowledgement from the MS is not
received within T200, the transmission of the frame is repeated and T200 restarted).
• For LAPDm UI-frames (used in unacknowledged mode and containing e.g. the
PHYSICAL INFORMATION message), the trigger is the expiry of the timer 3105,
attribute: T3105 (T3105 is started when the BSS sends the PHYSICAL INFORMA-
TION message and is usually used for the repetition of the PHYSICAL INFORMA-
TION message during the handover procedure).
• For LAPDm UA-frames the trigger is the repeated reception of an SABM message.
Parameters and configuration for FACCH message repetition

The R-FACCH feature can separately be enabled for the different types of traffic
channels (e.g. with or without AMR) and also separately for the different kinds of LAPDm
frames. The parameters provided for R-FACCH are effective on cell level (command
SET BTS).
• ERFACCHCMDF (“enableRFacchOnCmdFrames“): This attribute enables R-
FACCH on LAPDm I-frames of kind ASSIGNMENT COMMAND or HANDOVER
COMMAND for legacy mobiles (i.e. mobiles of an older generation) and those
Release 6 mobiles that indicate their R-ACCH capability with R-ACCH_CAP = 0 (no
or restricted R-ACCH capability). ERFACCHCMDF provides a list of TCH / codec
types (e.g. TCH_EFS, TCH_FS, TCH_HS) which can be selected and combined.
• ARFACCHACMDF (“applyRFacchOnAnyCmdFrame“): This attribute is effective
only when ERFACCHCMDF is enabled and it extends R-FACCH on the codecs
selected with ERFACCHCMDF to all LAPDm command frames (I-frames or UI-
frames) for those MSs that have not signalled R-ACCH_CAP = 1 (those types of
MSs include legacy MSs and Release 6 MSs that have signaled R-ACCH_CAP = 0).
• ERFACCHALPDMF (“enableRFacchOnAnyLapdmFrame”): This attribute enables
R-FACCH on all LAPDm frames for Release 6 compliant mobiles that indicate their
182 Id:0900d8058052e376 A50016-G5100-B556-04-7620

R-ACCH capability with R-ACCH_CAP = 1 (full R-ACCH capability). ERFAC-

CHALPDMF provides a list of TCH types / codec types (e.g. TCH_EFS,TCH_FS,
TCH_HS) which can be selected and combined.
In order to enable R-FACCH for MSs older than 3GPP Release 6 and to restrict the
immediate FACCH message repetition to the ASSIGNMENT COMMAND and
HANDOVER COMMAND messages only, the operator shall set
ERFACCHCMDF = ENABLE and ARFACCHACMDF = FALSE.
If no problems with MSs older than 3GPP Release 6 are expected and R-FACCH shall
be deployed as much as possible for Release 6 MSs indicating R-ACCH_CAP = 0 (no
or restricted R-ACCH capability), the operator shall set ERFACCHCMDF = ENABLE
and ARFACCHACMDF = TRUE.
ERFACCHALPDMF is effective only for Release 6 MSs indicating R-ACCH_CAP = 1
(full R-ACCH capability) and is independent from the parameter ERFACCHCMDF. Thus
different configurations can be applied for MSs signalling different R-ACCH capability.
g Application of R-FACCH is not possible for BTS1s (BS-20/21/22/60/61).
8.4 Repetition and modified scheduling of SACCH messages

The following improvements of error protection for SACCH messages on ongoing voice
calls (or related SDCCHs during call establishment) have been introduced:
• Modified scheduling of the transmission of system information messages and mea-
surement report/information messages on SACCH in downlink direction in such a
way that the total time to receive all messages which are existential for the call (or
handover) is minimized.
• Repetition of a SACCH block transmission after failed SACCH decoding and possi-
bility of subsequent combined decoding of a pair of SACCH blocks. This functionality
is applied to GMSK modulated TCHs and SDCCHs and can be performed in uplink
and downlink direction.
The repetition of SACCH block and pair decoding functionality reduces the number of
dropped calls due to radio link failure observed in both interference and coverage limited
scenarios for repeated SACCH capable MSs. This increases the system capacity and
improves the grade of service in GERAN networks. The handover and power control
network performance is increased.
The “Repeated SACCH and Modified Scheduling of SACCH Messages” feature can be
applied when the MS has got a dedicated channel (TCH or SDCCH).
8.4.1 Modified scheduling of messages on SACCH

SI messages and MI messages on SACCH
After the MS has got a dedicated channel (SDCCH or TCH) the network conveys the
connection specific system information (SI) in SI5, SI6 and optionally SI5bis and SI5ter
messages on the downlink SACCH of the respective main channel. Based on this infor-
mation the MS is able to perform measurements on the BCCH carriers of the neighbor
cells for handover purposes. More in detail, the BTS informs the MS via SI5 about the
BCCH frequencies of the neighbor cells, which is especially important after a handover
since the SI2 on the new cell cannot be received by the MS (SI2 is received in idle mode
only). SI5bis and SI5ter are used as an extension to SI5 and essentially contain the
BCCH frequencies of DCS1800, PCS1900 and GSM900 with extended band. SI6
A50016-G5100-B556-04-7620 Id:0900d8058052e376 183

conveys the parameters of the current serving cell. The SI5bis message is sent, if and
only if the EXT IND bit in the Neighbor Cell Description information element in both the
SI5 and SI5bis messages indicates that each information element carries a part of the
BCCH allocation list only. The SI messages are of vital importance for a call.
In addition, the network may send measurement information (MI) messages which may
order the MS to use enhanced measurement reports (EMR). MI messages may also
contain a combination of information for e.g. 3G neighbor cell description, real time dif-
ferences, BSICs, reporting priority, measurement parameters or 3G measurement
parameters. If not all information fits into one message block, the remaining information
will be sent in other instances of this message. A maximum of 16 instances is possible.
Current scheduling concept

Up to release BR9.0, SI and MI messages are scheduled for transmission according to
the following sequence: First, the basic set of SI messages – i.e. SI5, SI5bis (if required),
SI5ter (if required), SI6 – is sent twice (in order to have a good chance that the MS can
decode the SI information correctly); afterwards the MI messages are sent one after the
other (max. 16), along with the basic set of SI messages in-between. This scheduling
with MI messages between SI messages leads to a longer time than necessary until all
vital SI messages are successfully received by the MS – especially in case the decoding
of several SI messages fails.
New scheduling
With the “Repeated SACCH and Modified Scheduling of SACCH Messages” feature, the
following modified scheduling scheme is applied:
1. After a determined starting situation has occurred (see below), the BTS sends the
set of SI messages – i.e. SI5, SI5bis (if required), SI5ter (if required), SI6 – once in
successive SACCH blocks.
2. In case the MS cannot decode SI5 or SI5bis, it indicates to the BTS that confirmation
is not possible. After the set of SI messages has been sent, the BTS repeats the
complete sequence of SI messages from the beginning once.
In case the MS has confirmed successful reception of SI5 and SI5bis, the BTS (indi-
rectly) checks if SI5ter and SI6 should have been successfully received by the MS
(see below); if possibly not, the SI5ter and SI6 messages are re-scheduled once,
otherwise successful reception of the complete set of SI messages by the MS is
assumed and the BTS proceeds with the next step.
3. The BTS proceeds with sending the set of MI messages followed by the set of SI
messages (confirmation not required any more) and so on. Depending on previous
decoding failures at the MS, the single messages are immediately repeated once,
or not.
g Further scheduling modifications (e.g. re-scheduling) are possible in combination
with SACCH block repetition, see Initial transmission of SI messages (DL) in chapter
8.4.2 Repetition of SACCH blocks.
184 Id:0900d8058052e376 A50016-G5100-B556-04-7620

SACCH block Confirmation failed Confirmation successful

480 ms Repetition
SI_5 SI_5_bis SI_5_ter SI_6 SI_5 SI_5_bis SI_5_ter SI_6
MI #0 MI #1 MI #2 ............ MI #14
Confirmation not required
SI_5 SI_5_bis SI_5_ter SI_6 Confirmation not required
MI #0 MI #1 MI #2 ............ MI #14
SI_5 SI_5_bis SI_5_ter SI_6 . . . . . . . . . . . .. . . . . . . . . . . .
Figure 81 Scheduling of SI and MI messages
Confirmation of successful SI reception

The MS confirms the successful reception of the SI5 and SI5bis messages (before the
BTS begins to send MI messages) with the help of the measurement report as follows:
– The MEAS_VALID flag is set to 0, i.e. the measurements are valid.
– The value of the NO_CELL_M field (number of neighbor cells) is not equal to 7
(= 111 in bit format, implying that neighbour cell information is not available for the
serving cell).
– The entry in the BA_USED field is equal to the BA_IND(SACCH) entry sent by the
BTS on SI5 and SI5bis (BA_IND: BCCH allocation sequence number indication).
If the MS sends an enhanced measurement report instead of an usual measurement
report, this also indicates successful SI5/SI5bis reception if again the entry in the
BA_USED field is equal to the BA_IND(SACCH) entry in SI5 and SI5bis.
Vice versa, the MS indicates unsuccessful reception of a SI message by not confirming
as described above.
The confirmation via measurement report or enhanced measurement report by the MS
does not reflect successful or failed reception of SI5ter and SI6 messages. Therefore
the BTS estimates successful reception by the MS indirectly: If the value of the
RXQUAL_SUB_SERVING_CELL field in the measurement report message is equal or
A50016-G5100-B556-04-7620 Id:0900d8058052e376 185

below 6 (corresponding to a BLER on SACCH of less than 10%), successful reception

is assumed, otherwise not.
Starting points for the scheduling scheme

The following situations determine the starting point for the scheduling scheme:
– An IMMEDIATE ASSIGNMENT COMMAND message has been sent to the MS; in
this case an SDCCH is assigned to the MS and the scheduling scheme is applied
on this SDCCH.
– An ASSIGNMENT COMMAND message has been sent to the MS; in this case a
TCH is assigned to the MS and the scheduling scheme is applied on this TCH.
– A HANDOVER COMMAND message has been sent to the MS; in this case the MS
switches to the new TCH and the scheduling scheme is applied on this TCH.
– An inter-cell or intra-cell handover to a new TCH has been completed.
– Update of the SI message with change of the BA_IND information element.
If a scheduling scheme is ongoing when one of the previous situations occurs, it is inter-
rupted and the scheduling scheme is started again from the beginning.
Modification of scheduling scheme for common dedicated VGCS and VBS

channels
MI messages are not scheduled for ASCI calls.
Since most of the MSs allocated on the VGCS or VBS channel are in listening mode, no
acknowledgment of the SI messages is possible. An MS becoming the ‘talker’ can be
assumed to have already read all necessary system information when having been in
idle mode. Therefore only a static scheduling scheme is applied which consists of the
repetition of the following message sequence: SI5, SI5bis, SI5ter, SI6, SI10#0, SI10#1,
…, SI10#15}. The SI10 message provides information for cell re-selection in group
receive mode. Up to 16 instances of SI10 are possible.
Modification of scheduling scheme regarding VBS/VGCS notifications

The following applies to MSs which are in normal dedicated mode (performing normal
voice call) and which in addition want to receive notification messages for voice broad-
cast calls (VBS) or voice group calls (VGCS) and which aim at reducing the reception
load.
The rest octets in the SI6 message from the BTS provide the NLN (notification list
number) parameter and the NLN status parameter. The NLN parameter is a modulo 4
counter. A change of NLN indicates that new notifications are provided on the NCH. The
NLN status is a single bit field which indicates the status of the content of the notifica-
tion/NCH messages for a particular NLN value. A change of the NLN status field indi-
cates a change of information on the NCH which is not related to new calls (e.g. there
may have been a release of a previous notified call, etc.).
An MS can detect new notifications on NCH via a change of the NLN values in the SI6
message on SACCH and can thus avoid to continuously read the NCH. The network
shall ensure that the MS receives a change of the NLN value reliably and as early as
possible. Hence, if the BTS receives a new SI6 from the BSC and if the basic set of SI
messages has already been received and acknowledged by the MS (as described
above), the new SI6 message is scheduled once at the next possible instant where a SI
or MI message is scheduled.
186 Id:0900d8058052e376 A50016-G5100-B556-04-7620

8.4.2 Repetition of SACCH blocks

Principle
The SACCH block repetitions and subsequent SACCH block decodings work both in
uplink and downlink direction, the same basic mechanism is applied in both directions.
Figure 82 shows the principle for the case that the BTS repeats SACCH blocks.
The following phases can be distinguished:
Initiation:
The decision to apply SACCH block repetitions is taken by the BTS after SACCH
decoding failures have appeared:
• Downlink direction: If the MS could not decode a received SACCH block, it sets the
SRR (SACCH Repetition Request) flag in the next uplink SACCH message to 1
thereby requesting downlink SACCH block repetitions. The BTS then decides –
depending on the configuration – to repeat SACCH blocks.
In case no SACCH decoding problems occur for a downlink SACCH message, SRR
in the next uplink SACCH message is set to 0.
• Uplink direction: If the BTS could not decode a received SACCH block and decides
– depending on the configuration – that SACCH block repetition shall be applied by
the MS, it sets the SRO (SACCH Repetition Order, analogous to SRR) flag to 1 in
the next SACCH message thereby instructing the MS to repeat SACCH blocks.
Repetition:
Each SACCH block related to SAPI = 0 (i.e. unacknowledged mode) is a repetition can-
didate. After the decision for SACCH block repetition, the BTS/MS transmits such a rep-
etition candidate twice in consecutive SACCH blocks (serial repetition). Then the next
SACCH message of the set of messages is transmitted in the same way, i.e. with serial
repetition in case of SAPI = 0, and so on, until the decision is taken to stop SACCH block
repetition.
A SACCH message related to SAPI = 3 is not repeated. If a SACCH message with SAPI
= 3 is scheduled to be sent after a SACCH message with SAPI = 0, which shall be
repeated, the SAPI = 3 message is delayed by one SACCH block period to make room
for the repetition.
Decoding
When a new SACCH block is received, the MS/BTS first attempts to decode it as usual
(single block decoding). The repetition of a SACCH block increases the probability that
the content can be correctly extracted at least once.
Additionally SACCH block repetition allows for combined decoding of a SACCH block
pair comprising the regular and the repeated SACCH block (double block decoding). If
the regular and the repeated SACCH block could not be decoded in the usual way
(single block decoding), then soft decision combining applied on the two SACCH blocks
gives another chance to obtain the correct content.
It is not indicated, if a SACCH block is a regular or a repeated one, therefore the double
block decoding has to be executed in “blind” mode. As a preparation, the received
SACCH blocks are temporarily stored. When the MS/BTS fails to decode the current
SACCH block by single block decoding, it fetches the previous SACCH block from the
memory and applies double block decoding on this previous and the current SACCH
block. Of course, the double block decoding is only promising, if the current SACCH
block is a repetition of the previous one. Else the results are just discarded.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 187

Reporting and decision making for continuing/stopping SACCH block repetition

The MS reports to the BTS, if single SACCH block decoding was successful by sending
SRR = 0 in the next available uplink SACCH block. If the single block decoding failed,
SRR = 1 is reported. The decision of the BTS to stop or continue DL SACCH block rep-
etition depends on the configuration and the kind of message to be transmitted to the
MS (e.g. one successful decoding of a DL SACCH block is not enough to stop SACCH
block repetition for time critical SI messages of vital importance, see below).
In case the BTS successfully decodes UL SACCH blocks and decides to stop SACCH
block repetitions (again depending on the configuration), it orders the MS to transmit
SACCH messages without repetition by sending SRO = 0 within the next SACCH block.
BTS regular repeated

SACCH Indication of SACCH
blocks successful block ...
Message 1 Message 2 Message 3 Message 3
sent to single block repetition
MS decoding activated
(SRR =
SACCH SRR = 0 SRR = 1
Repetition Meas. Rep. Meas. Rep.
Request)
MS SACCH Single
Single block Single block
blocks decoding block
Message 1 ### decoding ### §§§
received successful decoding
from BTS failed failed
Double
??? Message 3 block
decoding
discarded
a) UL messaging in case of successful b) Activation of DL SACCH c) Double block decoding in case

decoding of a DL SACCH block block repetition of SACCH block repetition
Figure 82 Downlink SACCH block repetition and related SACCH block decoding
Initial transmission of SI messages (DL)

After channel activation not related to an inter-cell handover, the transmission of the SI
messages starts without SACCH block repetition. Figure 83 shows an example where
failed decoding of the SI5bis message by the MS initiates SACCH block repetition. The
BTS gets the MS’s SACCH message indicating this failure by SRR = 1 in the next uplink
SACCH block, and begins SACCH block repetition immediately with the next DL
SACCH block (thus containing a repetition of the SI5ter message). The SI5bis message,
which the MS could not decode, is re-scheduled in repetition mode at the end of the SI
sequence.
In case of channel activation related to an inter-cell handover, the SI5 message at the
beginning of the SI set is scheduled twice (due to time critical content and probable bad
receive quality at the cell edge). If the MS correctly decoded the regular and the
188 Id:0900d8058052e376 A50016-G5100-B556-04-7620

repeated SI5 message as well, the BTS stops SACCH block repetition (beginning with
SI5bis), until it receives the first SRR = 1 in an uplink SACCH message.
The next step depends on wether the transmission of the SI message set was success-
ful or not (see Confirmation of successful SI reception in chapter 8.4.1 Modified sched-
uling of messages on SACCH). In case of success Transmission of MI messages and
of subsequent SI messages (DL) is applied, see below, otherwise the transmission of
the complete set of SI messages is repeated once according to the modified scheduling
concept, but with SACCH block repetition from the beginning.
BTS No Activate No Continue SI message repetition

SACCH SACCH Decision (because of vital importance)
repetition repetition repeated,
regular regular regular repeated regular repeated re-scheduled re-scheduled
SACCH
blocks SI_5 SI_5_bis SI_5_ter SI_5_ter SI_6 SI_6 SI_5_bis SI_5_bis
sent to
MS
SRR = 0 SRR = 1 SRR = 0 SRR = 0 ............

Meas. Rep. Meas. Rep. Meas. Rep. Meas. Rep.
SACCH
blocks
SI_5 ??? SI_5_ter SI_5_ter ............ SI_5_bis
received
from BTS
Decoding Decoding Decoding Decoding

MS successful failed successful successful
Figure 83 SACCH block repetition and re-scheduling in case of SI messages
Transmission of MI messages and of subsequent SI messages (DL)

The transmission of the MI message set followed by the SI message set and so on in
alternation starts, when it can be assumed that the MS has successfully received the set
of SI messages or after one repetition of the SI message set (as described in chapter
8.4.1 Modified scheduling of messages on SACCH). Depending on previous decoding
failures, the single messages are immediately repeated once or not. Since these trans-
missions are not as critical for call holding as the initial transmission of the set of SI mes-
sages, the decision rules to stop or begin SACCH block repetition are less stringent.
Preparation:
The basis for the decision to keep or change the current SACCH block transmission
mode (with/without repetition) is an internal counter parameter which counts the differ-
ence between the number of successful decodings of SACCH messages by the MS
(indicated by SRR = 0) and the number of unsuccessful decodings (SRR = 1). This has
already been done from the beginning of the initial transmission of the SI messages.
After the initial SI set transmission, the counter value is limited to a range between 0 and
a maximum value determined by the “repSacchTimeOutDL” attribute: Negative values
are set to 0, values greater than the “repSacchTimeOutDL” value are set to the “repSac-
A50016-G5100-B556-04-7620 Id:0900d8058052e376 189

chTimeOutDL” value. Then each time the MS receives a SACCH block, the counter is
updated: It is incremented by 1 in case of successful SACCH block decoding if the “rep-
SacchTimeOutDL” value is not reached yet; it is decremented by one in case of unsuc-
cessful SACCH block decoding if the 0 value is not reached yet. In the following the
counter is denoted by “diff_succ_fail”.
Selection of SACCH block transmission mode:
The following rules for keeping or changing the current SACCH block transmission
mode are applied:
– At start of sending the first MI message, the same transmission mode is applied as
for the previous SACCH message (which is a SI message).
– Repeated SACCH block transmission is kept, if the “diff_succ_fail” counter is below
the “repSacchTimeOutDL” value (i.e. not enough successful SACCH block decod-
ings compared to the failures).
– Repeated SACCH block transmission is stopped, if the “diff_succ_fail” counter
reaches the “repSacchTimeOutDL” value (i.e. sufficiently more successful SACCH
block decodings than failures).
– SACCH block transmission without repetition is kept, if the “diff_succ_fail” counter
value is greater than 0 (indicating a surplus of successful SACCH block decodings).
– SACCH block transmission without repetition is changed to repeated mode, if the
“diff_succ_fail” counter value reaches the 0 value (too much failed SACCH block
decodings).
Roughly speaking the SACCH block transmission without repetition is applied, if there
are sufficiently more successful SACCH block decodings than decoding failures; vice
versa, the repetition mode is applied if there is no sufficient surplus of successful
SACCH block decodings.
Example:
At the starting point, the initial transmission of the set of SI messages has ended with
repeated SACCH mode and there is a surplus of 4 successful SACCH block decodings
compared to decoding failures; “repSacchTimeOutDL” has been set to 3. The MI
messages MI0, MI1, MI2, and MI3 are to be sent next.
Then the “diff_succ_fail” counter value is cut to 3 and MI0 is sent twice (SACCH block
repetition mode kept at the beginning of the MI transmission). If the decoding of the first
and the second MI1 message is successful, then “diff_succ_fail” = 3 is kept. The SACCH
block repetition is stopped (because of “diff_succ_fail” = “repSacchTimeOutDL”) and
MI1 is sent without repetition. If the decoding of MI1 fails, then “diff_succ_fail” = 2, which
is updated at the BTS just when MI2 is sent. Since “diff_succ_fail” still exceeds the 0
value, the transmission mode is kept, MI2 is not repeated and MI3 is sent immediately.
Transmission of SACCH messages in UL direction

The algorithms for keeping or switching the SACCH block transmission mode in UL
direction are the same as for the transmission of MI messages and subsequent SI
messages in DL direction. Again an internal counter is provided which counts the differ-
ence between the number of successful decodings of SACCH messages by the BTS
and the number of unsuccessful decodings and which is limited between 0 and a
maximum value determined by the “repSacchTimeOutUL” attribute. “repSacchTime-
OutUL” plays the same role in UL direction as “repSacchTimeOutDL” in downlink direc-
tion. The same decision rules (with “repSacchTimeOutUL” instead of
“repSacchTimeOutDL”) are applied.
190 Id:0900d8058052e376 A50016-G5100-B556-04-7620

Additional criteria triggering SACCH block repetition

DL SACCH block repetition is always applied in the following cases:
– The DL receive level reported in the RXLEV_SUB_SERVING_CELL field in the DL
measurement report (from MS) is lower than the threshold determined by the “rep-
SacchRxLevDL” attribute.
– The measured UL receive level is lower than the threshold determined by the “rep-
SacchRxLevUL” attribute.
– DL FACCH repetition has been required.
UL SACCH block repetition is always applied in the following cases:
– The DL receive level reported in the RXLEV_SUB_SERVING_CELL field in the DL
measurement report (from MS) is lower than the threshold determined by the “rep-
SacchRxLevDL” attribute (the same criterion as for DL SACCH block repetition).
– The measured UL receive level value is lower than the threshold determined by the
“repSacchRxLevUL” attribute (the same criterion as for DL SACCH block repetition).
– An uplink SACCH block can not be decoded during scheduling of the initial trans-
mission of the DL SI messages (after channel activation).
The criteria based on the received signal level are provided to cope with rapidly
emerging coverage problems (experienced for example when a mobile enters a building
or moves around a street corner in a city).
8.4.3 Parameters

Parameters of the BTS Managed Object
ERSACCHDL enableRSacchDL The SACCH block repetition in DISABLE ENABLE/
downlink direction and the possibility DISABLE
for subsequent double block
decoding at the MS can be
enabled/disabled by this attribute.
Enabling or disabling is done via
checkboxes.
ERSACCHUL enableRSacchUL The SACCH block repetition in uplink DISABLE ENABLE/
direction and the possibility for sub- DISABLE
sequent double block decoding at the
BTS can be enabled/disabled by this
attribute. Enabling or disabling is
done via checkboxes.
RSACCH- repSacchTimeOutDL This attribute defines the maximum 4 0 ... 10
TODL timeout period after which the
SACCH block repetition mode in
downlink direction is deactivated.
Table 35 Parameters for repeated SACCH and modified scheduling of SACCH messages
A50016-G5100-B556-04-7620 Id:0900d8058052e376 191


RSACCH- repSacchTimeOutDL This attribute defines the maximum 4 0 ... 10
TOUL timeout period after which the
SACCH block repetition mode in
uplink direction is deactivated.
RSACCHRX- repSacchRxLevDL This attribute defines the receive 10 0 ... 25
LDL level threshold for activation of the
SACCH block repetition mode in both
uplink and downlink direction.
RSACCHRX- repSacchRxLevUL This attribute defines the receive 7 0 ... 25
LUL level threshold for activation of the
SACCH block repetition mode in both
Parameters of the SCANBTSE Managed Object
MEASLST measureList The Repeated SACCH Supervision - SACCHSUP
measurement can be added to the ... (list of mea-
SCANBTSE scanner via this attri- sures)
bute. Adding or removing is done via
selecting of SACCHSUP from the list
of measurements.
Table 35 Parameters for repeated SACCH and modified scheduling of SACCH messages (Cont.)
8.5 GSM call release
8.5.1 Radio link timeout

Radio link failures are indicated with the help of radio link counters (also called “Missing
SACCH” counter or “S” counter). Such counters are provided for the MS and for the
BTS. A radio link counter starts with a specified initial integer value after a radio connec-
tion has been established. Unsuccessful decoding of a SACCH message by the
MS/BTS leads to a decrease of the counter by 1, successful decoding to an increase by
2. If the radio link counter reaches 0, the MS/BTS regards the dedicated radio connec-
tion as failed and stops any further transmission on the dedicated channel.
Parameters
• RDLNKTO (“radioLinkTimeout”): The value of this parameter is the starting value for
the radio link counter in the MS and it also determines the maximum value of the
radio link counter which is 4 + 4 · RDLNKTO. The RDLNKTO value is sent on the
BCCH (SYSTEM INFORMATION TYPE 3 message) or on the SACCH (SYSTEM
INFORMATION TYPE 6 message) in the “Cell Options” IE.
g If Call Re-Establishment (parameter CREALL) is enabled, a low value of
RDLNKTO increases the number of call re-establishments because radio link
failures are declared earlier.
The radio link timeout configuration can separately be done for different service
types using the parameters SGxxPCPAR (command SET PWRC).
192 Id:0900d8058052e376 A50016-G5100-B556-04-7620

• RDLNKTBS (“radioLinkTimeoutBs”): The value of this parameter is the starting

value for the radio link counter in the BTS and it also specifies the maximum value
of the radio link counter which is here RDLNKTBS.
g The current value of the radio link counter in the BTS is also checked in the
scope of the base station power control (see chap. Power control): If the radio
link counter is more than 2 below RDLNKTBS (i.e. either at least three SACCH
reports in a row were missed or the current SACCH report is missing and addi-
tional SACCHs were missing before), then a normal BTS power increase will be
commanded.
An expiry of the radio link counter in the MS also indirectly leads to the radio link timeout
in the BTS, as in this case the MS stops any transmission activity on the dedicated
channel. This leads to unsuccessful decoding of UL SACCH frames in the BTS (as the
MS does not send any SACCH frames anymore) and thus to the continuous decrease
of the BTS radio link counter.
8.5.2 Channel release in case of MS inactivity

A mechanism is provided to release a radio channel when the duration of the related call
exceeds certain thresholds and there are no hints of activity such as handovers, so the
callers most probably do not use the radio resource any more. There is a basic algorithm
applicable for Phase 1 and Phase 2 Mobile Stations and an advanced algorithm for
Phase 2 Mobile Stations as described below.
• Basic algorithm:
The release of a probably inactive call connection is determined by an internal audit
system (not configurable by the operator), operating on speech and data calls. A call
is usually released after 8 h of duration when there are no handovers and other hints
for call activity. For GSM-R the time period until release of a stable call (no han-
dovers) can be set to 100 h.
• Advanced algorithm:
The classmark interrogation procedure is used to check, if a long running call on the
MS is still active: When the audit timer related to call release indicates 1 h of call
duration, the BSS sends the CLASSMARK ENQUIRY message to the MS. Two prin-
ciple reactions are possible:
– If the call on the MS is still active, the MS shall answer with the CLASSMARK
CHANGE message which is the usual response to the CLASSMARK ENQUIRY.
Required information of the CLASSMARK CHANGE message is included in the
“Mobile Stations Classmark” Information Element. In case the MS has
answered, the timer is reset and the call can continue for another hour until the
next CLASSMARK ENQUIRY – if needed – and so on. So the call connection
can be kept allocated for an infinite time, if there is traffic activity on the channel.
– If there is no answer from the MS, a second CLASSMARK ENQUIRY message
is sent to the MS after a few minutes. If no answer comes from the MS, it is
assumed that the call is no longer active and the related channel is released.
This procedure requires Phase 2 MSs, which are capable of the classmark interro-
gation procedure, Phase 1 MSs are not. The algorithm first checks, if the MS is a
Phase 2 one. If not, the basic algorithm is applied.
Configuration
By default the basic algorithm for release of a long running call is applied. The advanced
algorithm, which is effective for Phase 2 MSs only (not for Phase 1 MSs), can be
A50016-G5100-B556-04-7620 Id:0900d8058052e376 193

enabled by setting bit 47 of the MNTBMASK (“maintenanceBitMask“) attribute to 1.

bit 47 = 1 also sets the audit timer threshold for GSM-R calls in case of Phase 1 MSs to
100 h. Table 36 summarizes the possible audit timer thresholds.
MNTBMASK Audit timer threshold

setting
Phase 1 MS Phase 2 MS
bit 47 = 0 8h 8h
bit 47 = 1 8 h (in general) 1h
100 h (for GSM-R)
Table 36 Audit timer thresholds
8.6 Call re-establishment

With a call re-establishment procedure the MS tries to set up a new radio connection to
the BSS directly after a call drop (which might have occurred e.g. due to sudden loss of
a radio path in e.g. a tunnel). Depending on the radio conditions, the MS might set up
the new call in a different BTS. For this, the MS sends a CM REESTABLISHMENT
REQUEST message (instead of a CM SERVICE REQUEST message) to the network.
It is then a task of the anchor MSC (i.e. the MSC which served the dropped call) to
quickly recognize the old call context and to interconnect the new radio path to the
existing connection before the call is terminated by the end users or by expiry of call
supervision timers. Whether a call reestablishment can be attempted or not, depends on
the call control state, as described in GSM Recommendation 04.08, section 5.5.4.
Inhibiting call reestablishment is a possibility to reduce the load in the cell since call rees-
tablishment causes considerable signalling load on the network.
Parameter
CREALL (“callReestablishmentAllowed”): This attribute indicates whether call re-estab-
lishment is allowed in the cell.
This parameter is sent on the BCCH (SYSTEM INFORMATION TYPE 1, 2 , 3 and 4) in
the “RACH Control Parameters” IE.
8.7 CCCH and PCCCH for GPRS/EGPRS signalling

GPRS/EGPRS common signalling can be performed either on already existing CCCHs
(shared CCCHs) or on GPRS/EGPRS-dedicated CCCHs, i.e. PCCCHs. Shared CCCH
is a mandatory feature for GPRS/EGPRS.
Figure 84 shows the (E)GPRS signalling message flow within the BSS system and for
a BSC1.
a) PCCCH: The DL signalling messages are carried in PCU frames via 16 kbit/s Abis
sub-slots to the physical PDCHs on Um interface on which the PCCCH is mapped.
The processing wihin the BSC is done within the PPXU (Peripheral Packet Control
Unit (replaced by the UPM board in the eBSC)).
b) Shared CCCH: The GPRS signalling messages are carried on LAPD channels
related to the BTSE. The messages of such a channel are routed via the switching
matrix to a PPXL board where the LAPD protocol is executed. The extracted
messages are forwarded to the TDPC (Telephony and Distributor Processor Card;
194 Id:0900d8058052e376 A50016-G5100-B556-04-7620

replaced by the AP board in the eBSC) via Telephony System Bus. In the TDPC the
messages are analyzed: GPRS/EGPRS-related messages are sent to an appropri-
ate PPXU where they are processed.
System Bus
PCU / PPXU
GPRS
PCCCH timeslot PCU frame
Switching TDPC
CCCH LAPDm frame
Telephony
LAPD
timeslot
PPXL
Um BTS Abis BSC
Figure 84 GPRS signalling message flow in the BSC1

Using PCCCHs for (E)GPRS signalling has the following positive effects:
• On the air interface CCCH performances for normal GSM traffic are not reduced by
GPRS/EGPRS messaging.
• On the Abis interface the capacity of the LAPD link is not reduced for GSM traffic.
• The TDPC performances are not reduced by analyzing GPRS/EGPRS messages.
Routing between PPXLs and TDPC (including additional load on the Telephony
System Bus) is avoided.
The shared CCCHs are usefull in any case to provide the first access when no
GPRS/EGPRS channel is allocated.
It is recommended to use PCCCHs as soon as the GPRS/EGPRS traffic exceeds a
certain threshold in order to avoid that the GPRS/EGPRS signalling load significantly
disturbes the GSM signalling on "normal" CCCHs.
8.8 GPRS TBF establishment

This chapter comprises basic information about TBF establishment only. For further
information please refer to the GPRS global description manual.
A GPRS connection between MS and BSS requires the establishment of a TBF. The
request for a TBF can be initiated by the MS (e.g. the MS requests for uplink packet data
transmission) or by the network (the MS is the terminating point of the connection).
8.8.1 MS initiated TBF establishment

The TBF establishment can be executed as one phase access or two phases access.
In the following, the two phases access is described first, since the one phase access is
a short version of it.
Figure 85 shows the message flows performed for a two phases and a one phase TBF
establishment initiated by the MS.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 195

MS BSS MS BSS
Channel Request Packet Channel Request

RACH PRACH
Immediate Assignment Packet Uplink Assignment

AGCH PAGCH
Packet Resource Request RLC Data Block

PACCH PDTCH
......
Packet Uplink Assignment
PACCH
RLC Data Block Packet Uplink Ack

PDTCH PACCH
......
RLC Data Block

PDTCH
......
Packet Uplink Ack
PACCH
RLC Data Block

PDTCH
Two phases access One phase access

started on CCCH started on PCCCH
Figure 85 MS initiated TBF establishment
Two phases TBF establishment

The following main steps are executed (successfull TBF establishment is assumed;
alternative messages in brackets in case usual GSM control channels (CCCHs) are
used for the first two of the following steps):
1. The MS sends the PACKET CHANNEL REQUEST message with the establishment
cause to the BSS via PRACH (or the CHANNEL REQUEST message via RACH).
The PACKET CHANNEL REQUEST message (or the CHANNEL REQUEST
message) can contain the request for two phases TBF establishment.
2. The BSS answers with the PACKET UPLINK ASSIGNMENT message on PAGCH
(or with the IMMEDIATE ASSIGNMENT message on AGCH).
In case of two phases TBF establishment this message comprises only one radio
block (implicitly indicating “two phases”).
3. The MS responds with the PACKET RESOURCE REQUEST message on PACCH
which includes the number of radio resources required.
196 Id:0900d8058052e376 A50016-G5100-B556-04-7620

4. The BSS allocates appropriate radio resources and reports them to the MS with the
PACKET UPLINK ASSIGNMENT message on PACCH. It includes information
about:
– USF
– TFI
– Time slot numbers
– Channel coding scheme
– ARFCN
– Timing advance attributes (optionally)
5. The MS seizes the assigned packet data traffic channel (PDTCH) and sends data
(one radio block in four bursts, the content of a radio block corresponds with a RLC
block).
6. The BSS informs the MS about successfull PDTCH establishment with the PACKET
UPLINK ACK message on PACCH.
One phase TBF establishment

In the one phase TBF establishment process the PACKET CHANNEL REQUEST
message from the MS indicates also the number of resources required. In the following,
the PACKET RESOURCE REQUEST (from the 2 phases process) is omitted and the
PDTCH(s) are directly allocated and then reported to the MS with the PACKET UPLINK
ASSIGNMENT message on PAGCH (or IMMEDIATE ASSIGNMENT message on
AGCH). This PACKET UPLINK ASSIGNMENT message comprises more than one
radio block, of course.
A one phase access requires a PACKET CHANNEL REQUEST with 11 information bits
(see chap. 8.8.1.1).
TBF establishment related to EDGE

For establishing a TBF for EGPRS services the EGPRS PACKET CHANNEL
REQUEST message is provided replacing the PACKET CHANNEL REQUEST
message. Again a one phase access or a two phases access is possible. The EGPRS
PACKET CHANNEL REQUEST requires the access burst type for 11 information bit.
Contention resolution
Collision problems may occur when two (or more) mobile stations in the same cell
transmit identical PACKET CHANNEL REQUESTs in the same (P)RACH with the same
random identity number. Such collision problems are resolved by a mechanism called
contention resolution which includes the exchange of the TLLI (temporary logic link iden-
tity, identifying a MS) between MS and network, the MS derives its TLLI from its P-TMSI
allocated by the SGSN, or the TLLI is built by the MS (the P-TMSI identifies the MS for
location purposes, whereas the TLLI identifies the MS from the packet data transfer
point of view):
In case of a one phase access the MS sends the TLLI to the network in the first UL RLC-
MAC data blocks after the MS has got the PACKET UPLINK ASSIGNMENT message
from the network and has established an UL TBF. The network then decodes the MS’s
message containing the TLLI, identifies the mobile station from the TLLI, and sends
back the PACKET UPLINK ACK message also containing the TLLI. If the MS receives
the acknowledgement message from the network soon enough, it continues with the UL
data transmission, now not including the TLLI in the UL radio blocks any more. Other-
wise the UL transmission is stopped.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 197

In case of a collision (two mobiles have transmitted identical PACKET CHANNEL

REQUESTs in the same (P)RACH timeslot), the network may be able to decode one of
the two PACKET CHANNEL REQUEST messages and to assign UL resources and
send a PACKET UPLINK ASSIGNMENT message. The following cases can occur:
• Both mobile stations may decode the PACKET UPLINK ASSIGNMENT message
and regard the assignment as their own and access the assigned uplink PDCH. The
MSs start an UL TBF each and begin with data transmission. The UL RLC/MAC
radio blocks sent to the network include the TLLIs of the MSs. The network cannot
decode these two simultaneous receptions at the same time and therefore does not
send acknowledgements towards the MSs. Subsequently both mobiles release the
TBFs.
• If only one of the mobile stations has started a TBF after having received the
PACKET UPLINK ASSIGNMENT message, then the network decodes the MS’s UL
radio blocks containing the TLLI, identifies the mobile station from the TLLI, and
sends back the PACKET UPLINK ACK message as soon as possible also contain-
ing the MS’s TLLI. Both mobile stations receive this message. The mobile station
receiving the wrong TLLI discards the first request and must try another PACKET
CHANNEL REQUEST.
In case of a two phases access the network replies to the PACKET CHANNEL
REQUEST with a PACKET UPLINK ASSIGNMENT message. The mobile station
accesses the assigned PDCH and sends a PACKET RESORCE REQUEST which
includes the TLLI of the mobile station. The mobile station then listens to the PACCH for
a PACKET UPLINK ASSIGNMENT message. The network identifies the mobile station
from the TLLI sent in the PACKET RESORCE REQUEST message and returns the TLLI
in the PACKET UPLINK ASSIGNMENT message. When both the network and the
mobile station have received the same TLLI, any possible ambiguity is removed and the
contention resolution procedure is complete.
Uplink access control on PRACH

The uplink access procedure on PRACH is started by the MS sending a PACKET
CHANNEL REQUEST (respectively EGPRS PACKET CHANNEL REQUEST) message
to the BTS. Here, the MS chooses one of the four TDMA frames within the selected
PRACH block randomly with a uniform probability distribution. Several attempts of
sending the PACKET CHANNEL REQUEST message might be necessary because of
possible collisions with other MSs sending on the same PRACH timeslot. The following
mechanism is implemented taking into account the radio priority of the TBF to be estab-
lished:
A persistence level P(i) is defined depending on the radio priority i (i = 1...4) of the TBF.
For each attempt, the MS draws a random value R with uniform probability distribution
in the set {0, 1, …, 15}. Now, the MS is allowed to transmit a PACKET CHANNEL
REQUEST message if P(i) is less than or equal to R. If for example P(1) has a high
value, the probability of a network access is low for a TBF with radio priority 1.
After each (unsuccessful) attempt, the successive attempt follows after minimum S and
maximum S + T TDMA frames (belonging to the PRACH on the PDCH) where S and T
are configurable parameters. More exactly the number of related TDMA frames between
the two attempts is a random value drawn with uniform probability distribution in the set
{S, S + 1, …, S + T – 1}.
Attributes:
198 Id:0900d8058052e376 A50016-G5100-B556-04-7620

• PERSTLVPRI<n> (“persistenceLevelPriority<n>”), n = 1...4: This parameter speci-

fies the access persistence on PRACH for TBFs with radio priority i, i.e. P(i) in the
description above. PERSTLVPRI corresponds with the 3GPP parameter
PERSISTENCE_LEVEL.
• GS (“gprsSlot”): This parameter determines the minimum number of GPRS
timeslots between two PRACH access attempts, i.e. S in the description above.
3GPP also denotes this parameter as S.
• GTXINT (“gprsTxInterval”): This parameter defines the number of GPRS slots to
spread transmission of the random access attempts on PRACH. GTXINT is T in the
description above and corresponds with the 3GPP parameter TX_INT.
• GMANRETS (“gprsMaxNumberRetransmission”): This parameter indicates for each
priority level 1 to 4 the maximum number of retransmissions allowed on the PRACH.
The parameter value consists of 4 fields, each field indicates the maximum number
of retransmissions allowed for the affected priority level. Priority 1 represents the
highest priority. GMANRETS corresponds with the 3GPP parameter
MAX_RETRANS.
The parameters of PRACH access control are included in the “PRACH control parame-
ters” information element and are broadcast to the MS via. e.g. the PACKET SYSTEM
INFORMATION TYPE 1 message.
During the PDP Context activation an MS is assigned a Radio Priority. If the network
indicates that e.g. only prio 1 accesses are allowed, all mobiles having prio 4 assigned
do not perform a network access. GMM/SM procedures are not affected. The GPATH
(“gprsPriorityAccessThreshold”) parameter indicates whether or not a mobile station of
a certain priority class is authorised to do a random access in order to request for GPRS
services. This parameter corresponds to the 3GPP parameter
PRIORITY_ACCESS_THR.
8.8.1.1 Channel requests and access bursts with 8 or 11 information bits

Packet channels can be requested by the MS with the following messages and formats:
– CHANNEL REQUEST sent on the RACH; this message always contains 8 informa-
tion bits.
– PACKET CHANNEL REQUEST sent on the PRACH; two message formats are
available, one containing 8 information bits, the other 11 information bits.
– EGPRS PACKET CHANNEL REQUEST sent on the PRACH; this message always
contains 11 information bits.
The 8 bit request message is the traditional one. It is used in case of channel requests
due to paging response, cell update, MM procedures and in all cases where the MS has
to send no more information than its class and priority, but it does not allow to widely
specify the needed resources.
The 11 bit request message is used in all cases described for 8 bit requests, but with
additional information to be carried in the access phase for example an enhanced
random reference number leading to a lower probability of MSs collision when trying to
establish an uplink TBF. A channel request of 11 bit type has the following main advan-
tages:
– It allows a one phase access instead of a two phases access.
– It speeds up the call set-up and decreases the signalling load.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 199

Accordingly, two types of access bursts are defined, one for requests with 8 information
bits, the other for requests with 11 information bits. Figure 86 shows the coding process
of the 11 bit access burst.
11 information bits
+ 1/2
6 bits 36 encrypted
6 parity bits Convolutional
puncturing bits
+ coder
4 tail bits
Access Burst
Tail Synchronization Sequence Information bit Tail Guard Period
36 bits
Figure 86 11 information bits access burst coding

The possibility of using the message type for 8 or 11 information bits depends on the
network settings; the capability of the network to receive 8 or 11 bit channel request
messages is broadcast via SYSTEM INFORMATION TYPE 13 messages. The purpose
of the access has also an influence on whether the MS uses an 8 bit or 11 bit request
message and the associated access burst (e.g. a request for user data transfer in RLC
unacknowledged mode is served by a two phases access, see 3GPP TS 44.060).
11 bit access bursts for EGPRS PACKET CHANNEL REQUESTs are allowed not only
on EDGE capable TRXs (i.e. on ECU, FlexCU), but also on non-EDGE TRXs. This is
important if the PBCCH/BCCH used for signalling is on a non-EDGE TRX; thus, also in
this case 1-phase EGPRS access is possible on EDGE TRXs.
Attributes
• The ABUTYP (“accessBurstType“) parameter corresponds to the 3GPP parameter
ACCESS_BURST_TYPE and indicates the type of access burst used on the uplink
PDCH (PACCH or PRACH). The value ACBU8BIT means that the 8 bit access burst
shall be used by the MS, and ACBU11BIT means that 11 bit access bursts shall be
used by the MS.
The ABUTYP setting also indicates which type of access burst (8 or 11 bit) must be
sent for PACKET CONTROL ACKNOWLEDGMENT messages, formatted as four
access bursts, and for messages in the PTCCH, for the continuous Timing Advance
estimation.
• The EEGPKTCHRQ (“enableEgprsPackedChannelRequest”) attribute allows to
enable/disable the access mode based on the EGPRS PACKET CHANNEL
REQUEST. This functionallity is available since many MSs have problems in
handling EGPRS PACKET CHANNEL REQUEST messages.
200 Id:0900d8058052e376 A50016-G5100-B556-04-7620

8.8.2 Network initiated TBF establishment

The network initiated TBF establishment procedure includes the paging for the terminat-
ing MS, the responding of the MS to the paging message and the DL TBF allocation.
Figure 87 shows the message flow for the network initiated TBF establishment.
MS BSS
Packet Paging Request

PPCH
Packet Channel Request

PRACH
Packet Uplink Assignment

PAGCH
Packet Paging Response

PACCH
Packet Downlink Assignment

PAGCH
RLC Data Block

PDTCH
......
Packet Downlink Ack

PACCH
Figure 87 Network initiated TBF establishment

The following main steps are executed (successfull TBF establishment is assumed, the
MS is in idle state (standby) at the beginning):
1. In order to initiate a downlink packet transfer, the network sends to the MS one or
more PACKET PAGING REQUEST messages on the PPCH.
2. The MS reacts by initiating a mobile originated packet transfer as described in chap.
8.8.1 MS initiated TBF establishment (PACKET CHANNEL REQUEST from MS on
PRACH, PACKET UPLINK ASSIGNMENT from network on PAGCH, etc.) and –
after having established an uplink TBF – sending the PACKET PAGING
RESPONSE message to the network on PACCH. This message consists of one or
A50016-G5100-B556-04-7620 Id:0900d8058052e376 201

more RLC/MAC data blocks (sent in unacknowledged mode (UI-frames)) containing

an arbitrary LLC frame.
3. The network changes the MM (Mobility Management) state of the MS from standby
to ready, assigns radio resources and reports them to the MS via the PACKET
DOWNLINK ASSIGNMENT message on PAGCH including following information:
– TFI
– Time Slot numbers
– ARFCN
– Timing advance attributes (optionally)
– for EGPRS MSs, the EGPRS window size (optionally)
4. Then the network begins to send data on the assigned PDTCH(s).
5. The MS acknowledges that it has seized the PDTCH(s) via the PACKET UPLINK
ACK message sent on PACCH.
g If the MS is already in the MM state READY, the SGSN knows the exact cell where
the MS camps on; then the SGSN omits sending the the PACKET PAGING
REQUEST message and immediately sends the PACKET DOWNLINK ASSIGN-
MENT message on PAGCH.
Establishing a concurrent DL TBF

If the PACKET PAGING RESPONSE message (sent after reception of the PACKET
UPLINK ASSIGNMENT message) fits in one RLC/MAC block, the related UL TBF block
has to be finished afterwards, thus the subsequent PACKET DOWNLINK ASSIGN-
MENT message must be sent on PAGCH (not on associated PACCH which is finished,
too), and a new DL TBF (not a concurrent one) has to be opened for DL data transmis-
sion. This case occurs with high (modulation and) coding schemes, e.g. MCS6.
Else, if several RLC/MAC blocks are necessary for transmission of the PACKET
PAGING RESPONSE message, the UL TBF can be kept open for a longer time, thus
the subsequent PACKET DOWNLINK ASSIGNMENT message can be sent on the
associated PACCH and a concurrent DL TBF is opened for DL data transmission. This
takes a shorter time than opening a new not-concurrent TBF (on PAGCH). This case
occurs with low (modulation and) coding schemes, e.g. (M)CS1.
The MSs can be ordered to send the first UL RLC/MAC blocks after the reception of the
PACKET UPLINK ASSIGNMENT message with CS1/MCS1 applied, thus allowing to
keep the UL TBF open for a time period long enough to establish a DL TBF for DL data
transmission as a concurrent one. The first UL RLC/MAC blocks are those which carry
the TLLI (necessary for contention resolution) in the RLC data block header.
Attributes:
CS1/MCS1 usage for the UL RLC/MAC blocks carrying the TLLI is ordered by the fol-
lowing attributes:
• EGTLLIBLKCHC (“enableGprsTLLIBlockChannelCoding”) in case of GPRS
• EEGTLLIBLKCHC (“enableEgprsTLLIBlockChannelCoding”) in case of EGPRS
These attributes allow to set the TLLI_BLOCK_CHANNEL_CODING bit in the PACKET
UPLINK ASSIGNMENT and the IMMEDIATE ASSIGNMENT message to 0.
g Since a radio block encoded with CS1 or MCS1 carries about 20 octets data, the
application of EGTLLIBLKCHC and EEGTLLIBLKCHC prolongs the lifetime of an
UL TBF also for other UL messages which carry more than 20 octets data and which
202 Id:0900d8058052e376 A50016-G5100-B556-04-7620

are sent after reception of the PACKET UPLINK ASSIGNMENT and the IMMEDI-
ATE ASSIGNMENT message.
Suspending discontinuous reception

Discontinuos reception means that a MS in idle mode listens only to a certain fraction of
radio blocks on CCCH or PCCCH channels (particulary regarding paging messages,
see paging groups in chap. 8.2.4). In case an MS changes into idle mode after packet
data transfer (so the MS is already in the MM state READY and can get a PACKET
DOWNLINK ASSIGNMENT message on PAGCH without paging before), the discontin-
uos reception can be suspended for a short time period via the DRXTMA (“discontinous-
ReceptionTimerMax”) attribute. DRXTMA indicates the maximum time allowed for the
mobile station to request for Non-DRX mode after packet transfer mode. Each MS
selects the value that it prefers and forwards this information within the ATTACH
REQUEST message (MM message) towards the SGSN. DRXTMA corresponds to the
3GPP parameter DRX_TIMER_MAX and is broadcast on the BCCH/PBCCH within the
PSI1 and (P)SI13 messages.
8.9 Messaging for TBF control

The PACKET UPLINK ACK/NACK message, sent from the BTS to the MS in case of an
active UL TBF, and the analogous PACKET DOWNLINK ACK/NACK message, sent
from the MS to the BTS in case of an active DL TBF, are used to check the connection
between MS and the network. These messages are sent both in RLC acknowledged and
unacknowledged mode:
• In case of RLC acknowledged mode the PACKET ACK/NACK message is sent with
a repetition rate configurable by the user (NRLCMAX parameter for GPRS, several
other parameters for EGPRS depending on the number of allocated timeslots).
• In case of RLC unacknowledged mode (no RLC block retransmission) the repetition
rate is fixed: 64 radio blocks are received by the MS/BTS before receiving the next
PACKET ACK/NACK message.
The reception of a PACKET ACK/NACK message is responded with a PACKET
CONTROL ACK message.
The transmission of PACKET ACK/NACK and PACKET CONTROL ACK messages is
associated with several timers and counters:
• Uplink TBF:
If the MS does not receive a PACKET UPLINK ACK/NACK message, it starts the
T3182 timer (if a PACKET UPLINK ACK/NACK message is received before T3182
expires, the timer is stopped). After expiry of T3182 the MS aborts all the UL TBFs
in progress and its associated resources. Then, in case of RLC unacknowledged
mode, the MS returns to the CCCH or PCCCH and initiates the establishment of a
new UL TBF. In case of RLC acknowledged mode the behaviour after TBF release
depends on the N3102 counter: If the value of this counter is greater than 0, the MS
returns to the CCCH or PCCCH and initiates the establishment of a new UL TB (as
in unacknowledged mode). Otherwise the MS performs an abnormal release with
cell reselection. The N3102 counter indicates if the success rate of receiving
PACKET UPLINK ACK/NACK messages is sufficient for establishing a new UL TBF
in the same cell. N3102 is increased by a configurable value when a PACKET
A50016-G5100-B556-04-7620 Id:0900d8058052e376 203

UPLINK ACK/NACK message is received and it is decreased by another configu-

rable value when the T3182 timer has expired.
On the other side, if the network does not receive the PACKET CONTROL ACK
message from the MS as answer to the previous PACKET UPLINK ACK/NACK
message, it retransmits the PACKET UPLINK ACK/NACK message and increments
the N3103 counter by one. If this counter exceeds a configurable maximum value,
the networks waits a time period defined by T3169 and then releases the USF and
TFI values of the UL TBF, which is assumed to be broken, for other usage.
(Another counter on the network side is N3101 counting the number of failed recep-
tion of RLC/MAC blocks in a row. If this counter exceeds a configurable maximum
value, the PCU considers the TBF lost, stops scheduling RLC/MAC blocks for this
USF and starts the T3169 timer.)
• Downlink TBF:
If the BSS does not receive a PACKET UPLINK ACK/NACK message, it increments
the N3105 counter by one. If this counter exceeds a configurable maximum value,
the communication with the MS is assumed to be broken and the TBF is released.
a) Regular messaging b) Packet Uplink Ack/Nack c) Packet Control Ack

messages missing messages missing
MS BSS MS BSS MS BSS
RLC data block N3102 = Packet Uplink Ack/Nack RLC data block
N3102 +
PDTCH PKTNINC
PACCH PDTCH
......
......
(T3182
NRLCMAX
stopped, if Packet Uplink Ack/Nack

running)
PACCH
RLC data block T3182 Packet Uplink Ack/Nack Packet Control Ack N3103 =
PDTCH started N3103 + 1
missing missing
......
Packet Uplink Ack/Nack Packet Uplink Ack/Nack

PACCH PACCH
Packet Control Ack Packet Uplink Ack/Nack Packet Control Ack N3103 =
PACCH N3103 + 1
missing missing
if N3103 = max.
T3169 started
......
RLC data block T3182

expired
PDTCH TBF release
N3102 =
N3102 -
......
T3169
PKTNDEC expired
Reuse of
TFI, USF
Figure 88 Uplink TBF control (RLC acknowledged mode)
204 Id:0900d8058052e376 A50016-G5100-B556-04-7620

Attributes
Parameters determining the rate of PACKET UPLINK ACK/NACK and PACKET
DOWNLINK ACK/NACK messages during packet transfer in case of RLC/MAC
acknowledged mode:
• NRLCMAX (“numberRlcMax“): This parameter specifies the rate of PACKET
ACK/NACK messages for GPRS in the following way.
– During UL TBFs: After each reception of NRLCMAX UL data blocks the PCU
issues a PACKET UPLINK ACK/NACK message. This applies under all circum-
stances for the currently supported MS multislot classes 1 – 10 (max. 2 UL
timeslots).
– During DL TBFs: In average every NRLCMAX-th DL data block is polled to
request a PACKET DOWNLINK ACK/NACK from the mobile station. This
behaviour applies for DL transfers with 1 or 2 timeslots allocated. In case the DL
TBF is allocated on 3 timeslots, the effective polling distance is defined by
(NRLCMAX – 5). In case the DL TBF is allocated on 4 timeslots, the effective
polling distance is defined by (NRLCMAX – 12). This reduced polling period is
required to optimize the throughput under field conditions. Faster polling allows
the quick retransmission of not acknowledged blocks and therefore helps to
avoid a stall condition on RLC/MAC layer.
• EGPLGPONETS (“egprsPollingPeriodOneTimeSlot”): This parameter specifies for
EGPRS the polling period to be used if one timeslot is assigned. Its value is given in
units of RLC blocks; e.g. 16 means that every 16th DL data block is polled. This
results in a polling period of 320 ms in case a single PDCH is allocated and only 40
ms in case 8 PDCHs are allocated to that TBF. The polling period is a decisive factor
in case RLC/MAC acknowledged mode is used. The more often the network polls
the mobile for acknowledge messages, the earlier it can retransmit not acknowl-
edged RLC/MAC blocks. This generally helps to increase the data transfer speed
under real network conditions (BLER > 0).
• EGPLGPTWOTS (“egprsPollingPeriodTwoTimeSlot”): This parameter specifies for
EGPRS the polling period to be used if two timeslots are assigned.
• EGPLGPTHREETS (“egprsPollingPeriodThreeTimeSlot”): This parameter specifies
for EGPRS the polling period to be used if three timeslots are assigned.
• EGPLGPFOURTS (“egprsPollingPeriodFourTimeSlot”): This parameter specifies
for EGPRS the polling period to be used if four timeslots are assigned.
• EGPLGPFIVETS (“egprsPollingPeriodFiveTimeSlot”): This parameter specifies for
EGPRS the polling period to be used if five timeslots are assigned.
• EGPLGPSIXTS (“egprsPollingPeriodSixTimeSlot”): This parameter specifies for
EGPRS the polling period to be used if six timeslots are assigned.
• EGPLGPSEVENTS “(egprsPollingPeriodSevenTimeSlot”): This parameter speci-
fies for EGPRS the polling period to be used if seven timeslots are assigned.
• EGPLGPEIGHTTS “(egprsPollingPeriodEightTimeSlot”): This parameter specifies
for EGPRS the polling period to be used if eight timeslots are assigned.
Timer and counter parameters:
– T3169: This timer defines the waiting time to reuse the respective TFI and USF
values after the thresholds N3101 and N3103 were reached.
– N3103: This parameter defines the threshold for not received PACKET CONTROL
ACK as response to PACKET UPLINK ACK/NACK messages. N3103 is a counter
on the network side.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 205

– N3105: This parameter defines the threshold for not received RLC/MAC control
message as response to a polled RLC/MAC data block. N3105 is a counter on the
network side. If the network receives a valid RLC/MAC control message from the
TBF, N3105 is reset.
– PKTNINC (“packetNumberIncrement”): This parameter defines the step size to
increase counter N3102 in case a PACKET UPLINK ACK/NACK message was cor-
rectly received by the MS. N3102 cannot exceed the value set by PKTNMA.
– PKTNDEC (“packetNumberDecrement”): This parameter defines the step size to
decrease counter N3102 in case T3182 expires without having received a PACKET
UPLINK ACK/NACK message from the network.
– PKTNMA (“packetNumberMax”): This parameter defines the maximum value for the
counter N3102 used on MS side. N3102 is set to PKTNMA at each cell reselection
of the MS. In case N3102 reaches the value 0 or below, the mobile station shall
perform an abnormal release with cell reselection.
8.10 GPRS call release

Uplink TBF release
The release of resources is normally initiated from the MS by counting down the last
RLC data blocks to be sent. The MS sends the countdown value (CV) in each uplink
RLC data block thus indicating to the network the absolute BSN (Block Sequence
Number) of the last RLC data block of the UL TBF (BSN = 0 in the last block). The same
acknowledgement messages are used as for usual TBF control. The following steps are
performed:
1. Once the MS transmits a countdown value different from 15, the MS will not queue
any new RLC data blocks, and any data that arrives after this commencement of the
countdown process will be sent within a future TBF.
The first countdown value different from 15 is determined by the BSCDVMA
(“bsCountdownValueMax“) attribute indicating the number of RLC data blocks to be
sent until the UL TBF is completed.
Example: BSCDVMA = 10 results in the following countdown value sequence: 15,
15, …, 15, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0.
2. In the final RLC data block transmitted in the TBF the countdown value is 0.
3. If all RLC data blocks have been correctly received at the network, it acknowledges
by sending the PACKET UPLINK ACK/NACK message to the MS.
(The BSC delays sending the final PACKET UPLINK ACK/NACK message by a
fixed time period (400 ms) in order to have time in case a new downlink packet data
unit arrives from the SGSN just after the reception from the MS of the last RLC data
block (with countdown value 0). In this case, the BSC can open the DL TBF as a
concurrent case, which is faster than the normal procedure (where normal means
assignment messages sent on the control channel.)
4. The MS responds with the PACKET CONTROL ACK message.
5. Upon reception of the acknowledgement, the network can reuse the TFI and USF
values.
The same timers and control mechanisms are used as for usual TBF control: The MS
starts the T3182 timer while waiting for the PACKET UPLINK ACK/NACK message for
the last RLC data block. If the T3182 timer expires, before the MS receives the PACKET
UPLINK ACK/NACK message, then the MS aborts all TBFs in progress and its associ-
ated resources, returns to the CCCH/PCCCH and it initiates the establishment of a new
206 Id:0900d8058052e376 A50016-G5100-B556-04-7620

UL TBF. If the network does not receive the PACKET CONTROL ACKNOWLEDGE-
MENT message in the radio block indicated by the RRBP field, it increments the N3103
counter and it retransmits the PACKET UPLINK ACK/NACK message. If the counter
N3103 exceeds its limit, the network starts the T3169 timer. When the T3169 timer
expires, the network may reuse the TFI and USF resources. The network clears the
N3103 counter when receiving the PACKET UPLINK ACK/NACK message.
Attribute:
The BSCDVMA (“bsCountdownValueMax“) attribute indicates the number of RLC data
blocks to be sent at the beginning of the countdown process (countdown value different
from 15) until the UL TBF is completed.
Downlink TBF release

The network initiates the downlink TBF release by terminating the DL data transfer and
polling the MS for a final PACKET UPLINK ACK/NACK message. The following steps
are performed:
1. The network indicates the last DL RLC data block by setting the Final Block Indicator
(FBI) bit to 1 within this data block.
2. After having received a RLC data block with FBI = 1, the MS transmits a PACKET
DOWNLINK ACK/NACK mesage with the Final Ack Indicator set to 1.
3. The TBF is released.
The downlink TBF release procedure is associated with the T3191 and T3193 timers on
the network side and the T3192 timer on the MS side:
• After having sent the last RLC data block to the MS, the network starts the T3191
timer. If this timer expires while the network still waits for the PACKET DOWNLINK
ACK/NACK message, the last RLC data block has to be re-transmitted (in RLC
acknowledged mode).
• When the MS receives the last RLC data block, the MS starts the T3192 timer;
whenit expires, the MS abandons the TBF.
• Upon the reception of the final PACKET DOWNLINK ACK/NACK message (with
Final Block Indicator = 1) from the MS, the T3193 timer is started on the network side
(and the T3191 timer is stopped). When T3193 expires, the current assignment
becomes invalid for the network, and the TFI can be reused by the network.
Delayed downlink TBF release:
A delay in the downlink TBF release can be applied in order to avoid continuous inter-
ruptions of data flow due to the frequent establishments and releases of TBFs, which
reduce the performances of many TCP/IP based applications. After the last actual DL
RLC data block has been sent, the BSC waits for the expiration of a timer before sending
a block with Final Block Indicator = 1. During this time, the BSC keeps the DL TBF open
and sends dummy LLC frames included in RLC blocks with the polling bit (RRBP) set
to 1.
Attributes:
• T3191: This timer defines the waiting time for reuse TFI after having sent the last
RLC block. It is started with the last DL data block sent in a TBF (Final Block Indica-
tor = 1) and stopped with the reception of the final PACKET DOWNLINK ACK/NACK
(or PACKET CONTROL ACK) message. On expiry the network releases the TFI
allocated to that TBF.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 207

• T3193: This timer defines the time to wait for a reuse of the TFI after reception of the
final PACKET DOWNLINK ACK/NACK message from the mobile station. On expiry
the TFI resources are released.
T3193 shall be greater than T3192 (default for T3192 is 500 ms) in order to make
sure that the MS has already abandoned the TBF before the network releases it.
Setting T3193 to the value 4 (= 400 ms) still fulfils this rule due to system-internal
propagation times.
• TIMEDTBFREL (“timeDelayTBFRelease“): This attribute is used to delay the
release of a downlink Temporary Block Flow. TIMEDTBFREL = 0 means no delay.
• EDTBFRELGMMSM (“enableDelayedTBFReleaseDuringGMMAndSM”): This attri-
bute allows to enable/disable the delayed TBF release during Mobility Management
and Session Management procedures.
Delayed release of physical channels

When the activities of a TBF have come to the end, i.e. the last RLC/MAC blocks of a
connection have been transmitted, the timer TEMPCH (“timerEmptyChannel”) is started
specifying the delay time for the release of the related allocated PDCH(s) (typically
90 s). As long as TEMPCH is running, the allocated PDCH(s) for the “released” TBF are
still regarded as allocated even if they are not used for the transfer of payload. The
purpose of this timer is to avoid continuous channel allocation requests from the PCU to
the TDPC and the associated CHANNEL ACTIVATIONs and IMMEDIATE ASSIGN-
MENT procedures which would happen in periods of high GPRS/EGPRS traffic if the
allocated resources were directly released after the stop of the TBF activities on the allo-
cated TCHs.
Attributes:
• TEMPCH (“timerEmptyChannel”): This timer specifies the delay time for the release
of an allocated PDCH if there are no TBF activities.
• TEMPPDT (“timerEmptyCPDT”): This parameter is the equivalent to TEMPCH (see
above) for PDT resources allocated on the PCU (PDT: Packet Data Terminal; a PDT
is the equivalent of an Abis timeslot at the PCU (terminating (E)GPRS protocols)).
TEMPPDT is used to avoid continuous requests for Abis resources from the PCU to
the TDPC. The value of TEMPPDT must be in any case smaller than the value of
TEMPCH.
8.11 Extended uplink Temporary Block Flow

The Extended Uplink Temporary Block Flow feature allows to keep an uplink Temporary
Block Flow even in case of short inactivity of the uplink traffic. The main benefit is a
reduction of the number of new establishments of TBFs in the uplink direction, thus
avoiding delays.
Messaging
A Mobile Station signals the support of the extended uplink TBF feature by its “Mobile
Station Classmark 3” Information Element (Mobile Station Radio Access Capability and
Mobile Station Radio Access Capability 2 by indicating the support of “GERAN Feature
Package 1”). The BSC can retrieve this information from:
• The PACKET RESOURCE REQUEST message, if the message contains the
Mobile Station Radio Access Capability 2
208 Id:0900d8058052e376 A50016-G5100-B556-04-7620

• A downlink TBF for the same MS/TLLI (TLLI: Temporary Logical Link Identifier), if
the MS Radio Access Capabilities are stored for the downlink TBF
• The BSS context for the same MS/TLLI. In case the BSC is not able to retrieve this
information (for example at one-phase packet access the Mobile Station Radio
Access Capabilities might not be available), the TBF should be operated in non-
extended Uplink TBF mode.
The BSC signals the support of the Extended Uplink TBF per cell on the BCCH/PBCCH.
The GPRS Cell Options are contained in the messages: PACKET SYSTEM INFORMA-
TION 1, 13 and 14 and in the SYSTEM INFORMATION TYPE 13 rest octets.
Procedure
When both the Mobile Station and the BSS signal the support of the Extended Uplink
TBF mode, this mode is used for each uplink TBF without further negotiation.
The Extended Uplink Temporary Block Flow feature makes an appearance in case the
MS has no more RLC data blocks to send; the TBF is not released immediately (which
would happen without Extended Uplink TBF). Instead the release of the TBF is triggered
by the expiration of the timer TEXTULTBF. The following procedure is applied:
1. The Mobile Station signals that it has no more RLC data blocks to send (the MS
includes the Countdown Value CV in each uplink data block to indicate the last Block
Sequence Number (BSN = 0) that is sent in the UL TBF; the last data block is trans-
mitted with CV = 0).
2. The BSS checks if all the RLC data blocks have been received correctly (in RLC
acknowledged mode only); if yes, the procedure goes on and the BSS starts the
timer TEXTULTBF.
3. While the timer TEXTULTBF is running, the TBF is kept and the scheduler continues
to schedule USF tasks as before. The procedures for timing advance and power
control are also kept running. The link adaptation is suspended due to the fact that
dummy uplink control blocks could be sent on the PACCH using coding scheme
CS1 and this coding scheme may be different from the one used during the data
transfer of the uplink TBF.
4. When the Mobile Station receives a valid USF flag, it sends a RLC/MAC control
block (for example the RLC/MAC Packet Uplink Dummy Control Block).
5. When the timer TEXTULTBF expires, the BSS initiates the release of the TBF via
the PACKET UPLINK ACK/NACK message with FAI (Final Ack Indicator) set to 1.
The handling of this message and its acknowledgement is identical to the handling
in non-extended UpLink TBF mode (e.g. for the support of the establishment of a
new TBF). Additionally the BSC may use the PACKET TBF RELEASE message to
release the TBF in “abnormal” cases (e.g. if the PDCH/PDT release is requested by
the TDPC (AP for the eBSC) processor (a PDT is the equivalent of an Abis timeslot
at the PCU (terminating (E)GPRS protocols)).
When the Mobile Station receives a valid USF flag and has new data to send (with the
same QoS and PFI as the already sent data), it sends an RLC/MAC data block. After
the reception of this block, the BSS stops the timer “TEXTULTBF” and the Extended
Uplink TBF procedure.
When the Mobile Station wants to send new data with different QoS or PFI (Packet Flow
Identifier), it sends a PACKET RESOURCE REQUEST message. Then in the BSS two
different procedures are possible:
A50016-G5100-B556-04-7620 Id:0900d8058052e376 209

• If the PFI priority or peak throughput class changes, the BSS keeps the TBF and
changes its properties by a Packet Uplink Assignment or Packet Timeslot Reconfig-
uration. This procedure is identical to the procedure in the non-extended Uplink TBF
mode.
• If the RLC mode changes, the BSS releases the existing TBF by sending a PACKET
UPLINK ACK/NACK message with FAI = 1. When the Mobile Station acknowledges
the release by a PACKET CONTROL ACK message, the BSS waits for a new MS
request.
In both cases the timer TEXTULTBF is stopped.
Attributes
• The attribute “Nw_Ext_Utbf” of the BSC object, GPRS Cell Options, enables
(“Nw_Ext_Utbf” = 1) or disables (“Nw_Ext_Utbf” = 0) the Extended UL TBF feature.
• The TEXTULTBF (“timeExtendedUplinkTBF“) attribute determines the time period,
how long an uplink TBF can be kept allocated, if there are no radio blocks to be sent.
• EXTULTBFI (“extendedUplinkTBFImpr”): Setting this attribute to TRUE avoids that
an MS being in Extended UL TBF mode and having no RLC/MAC data to be sent
(MS RLC buffer is empty) has to transmit PACKET UPLINK DUMMY CONTROL
BLOCK messages towards the network. Thus MS battery consumption and interfer-
ence in the cell can be reduced.
8.12 Establishment of dual transfer mode

Dual transfer mode (DTM, see chap. Dual transfer mode) can be established when an
MS is already in dedicated mode (CS service established) or in packet transfer mode
(PS service established). The procedures to be applied are a bit different.
DTM establishment in case the MS is in CS dedicated mode

The details of the procedure depend on the BSC decision whether the current CS
resources are kept for DTM or have to be changed.
• Figure 89 shows the messaging in case the MS requests DTM and the CS resources
have to be changed for DTM. The following steps are performed:
1. The mobile requests a PS resource via the DTM REQUEST message. The
message contains a description of the requested PS resources (if PFC proce-
dures are supported by the MS, the MS always has to include PFI in the DTM
REQUEST, irrespective to the network support of PFC procedures).
2. The BSC checks the DTM capability of the MS (if DTM is possible) and searches
for suitable radio resources taking into account the requested PS resources.
Resource reservation has to be performed in CS domain as well as in PS
domain (i.e. both TDPC and PCU of the BSC are involved).
3. Activation of channels in the BTS is performed via the CHANNEL ACTIVATION
and the CHANNEL ACTIVATION ACK messages. Here it is assumed that a new
TCH is necessary for the CS transmission. The CHANNEL ACTIVATION
message also includes information about PDCH activation.
4. The BSC sends the DTM ASSIGNMENT COMMAND message to the MS con-
taining the necessary allocation information for PS and CS resources.
5. The MS switches to the new resources and answers to the BSS with an
ASSIGNMENT COMPLETE message on the main DCCH of the new resource.
210 Id:0900d8058052e376 A50016-G5100-B556-04-7620

6. MS and BSS are in dual transfer mode, the MS simultaneously transmits RLC
data blocks on the allocated TBF and CS speech data on the CS connection
(here only the uplink data transfer is considered, because it was the MS which
requested DTM).
MS BTS BSC
CS dedicated mode
CS speech / data
TCH
DTM Request
FACCH
Check of DTM
capability
Um resource
negotiation *
Channel Activation (CS / PS)
Channel Activation Ack. (CS / PS)
DTM Assignment Command (CS / PS)

FACCH
Switch to new
RF resources
Assignment Complete
FACCH
Dual transfer mode
TCH CS speech / data
PDTCH RLC blocks
* : TCH reassignment assumed
Figure 89 DTM establishment from dedicated mode with TCH reassignment

The procedure is analogous for the case that the DTM request comes from the
network (same messaging steps within the radio access network after the DTM
request).
• In case the CS resources need not to be changed for establishing DTM, the follow-
ing steps are performed after the BSC has received the DTM REQUEST message,
has checked the DTM capability of the MS and has identified the required PS radio
resources; here it is assumed that all required PDCHs are already activated (other-
wise channel activation of PDCH would be necessary):
A50016-G5100-B556-04-7620 Id:0900d8058052e376 211

1. The BSC and BTS exchange MODE MODIFY and MODE MODIFY ACK
messages (instead of CHANNEL ACTIVATION and the CHANNEL ACTIVA-
TION ACK messages in case the CS resources are changed).
2. The BSC informs the MS about the PDCH(s) to be seized via the PACKET
ASSIGNMENT message (instead of the DTM ASSIGNMENT COMMAND
message in case the CS resources are changed).
3. MS and BSS are in dual transfer mode, the MS continues with the CS call and
transmits/receives RLC data blocks on the allocated TBF simultaneously.
DTM establishment in case the MS is in packet transfer mode

The following procedure is applied in case “Enhanced DTM Establishment” (see chap.
Dual transfer mode) is applied, and the MS requests for DTM:
1. The MS in packet transfer mode triggers the enhanced DTM establishment by
sending the PACKET CS REQUEST message to the BSS.
2. Receiving this message, the BSC checks the DTM capability of the mobile and allo-
cates suitable Um resources for both CS and PS connection.
3. The BSC activates the selected channel in the BTS and sends the DTM ASSIGN-
MENT COMMAND inside the PACKET CS COMMAND container message to the
MS via PACCH.
(The DTM ASSIGNMENT COMMAND can be used to re-allocate the TBF(s)
assigned to the MS (the description of the TBF has to be included in the DTM
ASSIGNMENT COMMAND); in case the MS shall retain the same already allocated
TBF(s), no Packet Channel Assignment description is included in the DTM ASSIGN-
MENT COMMAND.)
4. The TCH is established between MS and BTS via exchange of the SABM layer 2
message and the UA layer 2 message.
5. Dual transfer mode is reached.
The voice call is established with further messaging between MS and BSC (CLASS-
MARK CHANGE from MS to BSC, CHANNEL MODE MODIFY from BSC to MS,
CHANNEL MODE MODIFY ACK from MS to BSC).
The procedure is analogous for the case that the DTM request comes from the network.
In case “Enhanced DTM Establishment” is not available (legacy case), basic (legacy)
DTM establishment is applied: The MS simply abandons the existing PS TBF (thus
leaving packet transfer mode) and starts a CS call establishment (thus entering dedi-
cated mode). Once in dedicated mode, the mobile requests transition to DTM and the
DTM establishment is performed from dedicated mode as described above in DTM
establishment in case the MS is in CS dedicated mode.
212 Id:0900d8058052e376 A50016-G5100-B556-04-7620

8.13 Authentication
Authentication of a subscriber’s MS has to be performed during location registration
(first access in a PLMN, a TMSI is not provided yet from a VLR), location update (TMSI
already available) and the establishment of a call connection. In case the TMSI is
already available, the authentication process can be shortened.
The basic principle of the authentication procedure is that the MS calculates the SRES
number (signature response number) specific for the subscriber and the current ses-
sion/process. This SRES value is compared with the corresponding SRES value stored
in the VLR. If both SRES values are identical, the authentication was successful.
The MS generates the SRES value with its individual subscriber authentication key Ki
and a random number RAND which feed the generator algorithm A3. Ki is provided
(together with the IMSI) by the network operator after the subscription, RAND is calcu-
lated in the authentication center (AuC) and is transmitted to the MS via HLR and VLR.
MS BSS, VLR HLR AuC

MSC
IMSI IMSI IMSI
Auth.
TMSI check TMSI
Keynr Keynr IMSI
IMSI
IMSI RAND Ki
RAND
RAND
Ki RAND
Auth. RAND RAND

RAND
SRES RAND
SRES
check RAND
SRES RAND
SRES
A3 SRES SRESKc SRESKc SRES
SRES A3
Kc Kc SRES
Kc Kc
Kc
Kc Kc A8
A8 Kc Kc Kc
Kc
encrypt.
data
A5 A5
AuC: Authentication Center Ki: Individual Subscriber Authentication Key

HLR: Home Location Register Kc: Cipher Key
VLR: Visited Location Register RAND: Random Number
A3/5/8: Ciphering Algorithm 3/5/8 SRES: Session Key / Signature Response
Figure 90 Components for authentication and ciphering

The BSS or MSC cannot calculate the SRES itself because it has no access to the Ki
for security reasons. Instead the AuC which possesses the subscriber’s Ki, calculates
the SRES value by the same generator algorithm A3 as the MS and with the same
RAND sent to the MS. In fact the AuC creates a whole series of SRES values for each
subscriber (identified by IMSI) and delivers sets of SRES values, related RAND values
and Kc cipher keys (necessary for ciphering) via HLR to VLR.
Authentication via the SRES procedure may be avoided in case the keynr sent by the
MS during a registration phase is already known at the VLR. The RAND number is
changed for every new connection. Ki and RAND are also important for ciphering.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 213

MS BSS/MSC VLR HLR AuC
Location Update Request

Update Location Area
Auth. Parameter Request
(IMSI, LAI)
(IMSI, LAI)
(IMSI)
Auth. Info
Authenticate
Authentication Request
(IMSI, Kc, RAND, SRES)
(RAND)
(RAND)
Ki RAND Auth. Info Request
A3 & A8 (IMSI)
Kc SRES Auth. Info

SRES (IMSI, Kc, RAND, SRES)
Auth. Response
Auth. Response
(SRES) =
(SRES) Update Location
(IMSI, MSRN)
Generate
TMSI
Start Ciphering
Insert Subscriber Data
(Kc)
(IMSI)
Forward New TMSI

Ciphering Mode Command Subscr. Data Insert. Ack.
(TMSI)
Kc M (Message data)
Location Update Accept
Location Update Accept
A5
(IMSI)
Mc (ciphered M)
Ciphering Mode Complete
Mc
Kc Mc
A5
TMSI Reallocation
Figure 91 Message flow for authentication within the location registration procedure
214 Id:0900d8058052e376 A50016-G5100-B556-04-7620

8.14 Classmark information

The network can get information about special capabilities of the MS (such as DTM,
Repeated ACCH, A5/3 ciphering, UMTS, Location Services) via CLASSMARK
CHANGE messages sent from the MS to the network. The CLASSMARK CHANGE
message carries the “Mobile Station Classmark 2/3” Information Element including the
relevant information (see Messages for radio resource management).
The “Mobile Station Classmark 2/3” Information Element is included in the CM
SERVICE REQUEST message and the PAGING RESPONSE; in other cases (for
location updates and for information about ciphering capabilities of the MS) the MSC ini-
tiates the transmission of the CLASSMARK CHANGE message from the MS by sending
a CLASSMARK ENQUIRY message to the BSC which then informs the MS via the
CLASSMARK REQUEST message. The resulting CLASSMARK CHANGE message
from the MS is received by the BSC and is then forwarded to the MSC in the CLASS-
MARK UPDATE message. In some cases the BSC autonomously sends the CLASS-
MARK REQUEST message to the MS without initiation of the MSC in order to get the
CLASSMARK CHANGE message from the MS. This can happen e.g. when an MS,
which was handed over from 2G to 3G and returns to the 2G network by a 3G-2G han-
dover, and if in this case, the HANDOVER REQUEST message does not contain the
suitable 3G radio capability data in the 'Old BSS to new BSS Information' IE.
Early classmark sending

The MS can be instructed to send a CLASSMARK CHANGE message immediately after
each first “transaction” request message (e.g. CM SERVICE REQUEST, PAGING
RESPONSE, LOCATION UPDATE REQUEST) to provide the network with additional
classmark information. This “Early classmark sending” can be enabled by setting the
EARCLM (“enableEarlyClassmark“) attribute to TRUE. As a result a flag in the “SI 3 Rest
Octets” Information Element in the SYSTEM INFORMATION TYPE 3 message is
changed instructing the MS to execute the “Early classmark sending” procedure auto-
matically for every call transaction. “Early classmark sending” is of course, only possible
for those MSs that support this feature. The 'Controlled Early Classmark Sending' option
must be implemented in MSs that support e.g. multi-band mode or HSCSD ('multislot
capability'). Thus the flag simultaneously enables/disables multiband handovers.
A50016-G5100-B556-04-7620 Id:0900d8058052e376 215

Radio channel allocation Radio network management
9 Radio channel allocation

Since the radio resources are limited in a GSM network, one of the most important tasks
is to exploit the resources efficiently while keeping an acceptable transmission quality.
This chapter describes the different strategies used for the allocation of radio channels
as well as the configuration and handling of the resources.
Chap. 9.1 Allocation due to radio channel quality informs about the grouping and prior-
itizing of idle TCHs for allocation via evaluation of interence measurements.
Chap 9.2 Layer and service oriented channel allocation describes the basic concept
applied for radio resource allocation.
Chap. 9.3 Strategies for handling congestion situations explains the various features for
optimizing the exploitation of the radio channels in case of high traffic loads (e.g. Pre-
emption and Priority concepts, Queuing, Downgrading of multislot calls, Enhanced
Pairing of Half Rate traffic channels, Cell load dependent Activation of HR channels).
Chap. 9.4 Request management, resource re-allocation and waiting list management
describes how incoming and pending requests are handled, embracing the features of
the previous chapter.
Chapter 9.5 DMA admission control describes a soft blocking mechanism applied for
DMA call requests before the radio channel allocation algorithm is performed.
g The radio resources are shared between CS (Circuit Switched) and PS (Packet
Switched) services, so the radio channel allocation strategy integrates CS and PS
calls and the following descriptions include the basic (E)GPRS considerations. For
more details on the (E)GPRS radio channel allocation management, please refer to
section (E)GPRS radio channel management.
9.1 Allocation due to radio channel quality

If the interference classification feature is enabled, the BTS permanently performs inter-
ference measurements on the idle TCHs and idle TCH/SDs in the uplink and reports the
measurement results in form of RFRESIND (“RF resource indication”) messages via
Abis to the BSC. In the RFRESIND messages the measured TCHs are assigned to so-
called interference classes. An interference class is represented by an interference
band limited by an upper and lower interference level, each class/band represents a
certain radio quality. There are 5 interference bands: Band 1 contains channels with the
lowest interference level (high quality), whereas band 5 contains channels with a high
interference level (low quality). A traffic channel which has just become idle is classified
as band 5 channel (e.g. the results of the interference level are not yet available).
If no Layer and service oriented channel allocation is applied, the BSC – having grouped
the free TCHs into the interference classes – allocates the TCHs in the lowest interfer-
ence class first. Only if all TCHs in the best interference class are busy, the BSC allo-
cates those with a worse interference class to an incoming TCH request. TCHs in the
same interference class are allocated cyclically, i.e. the BSC starts the TCH allocation
by selecting the first TCH of the affected interference class (e.g. timeslot 2 on TRX:0),
the subsequent TCH request is served by the next TCH (e.g. timeslot 3 on TRX:0) and
so on. In case the Layer and service oriented channel allocation is applied, the allocation
due to interference classification is subordinate: In a group of free TCHs which have the
same priority regarding the layer criterion, the TCHs in the best interference band are
considered first for allocation.
216 Id:0900d8058052e662 A50016-G5100-B556-04-7620

Radio network management Radio channel allocation
Parameters
• INTCLASS (“enableInterferenceClass”): This attribute defines whether the interfer-
ence classification of idle traffic channels is enabled or disabled.
• INTAVEPR (“interferenceAveragingProcess”): This attribute specifies the interfer-
ence bands and an averaging period, too. It contains the following parameters:
– averPeriod (“averagingPeriod”): defines the number of SACCH multiframes
(480 ms = 4 multiframes, the interleaving function distributes the SACCH info
over 4 bursts) over which values are averaged (value 1..31).
– intThrBou<N> (“interferenceThresholdBoundaries<N>“) with <N> = 1, 2, 3, 4:
These values set the limits of four interference bands for the idle timeslots. The
threshold values represent uplink RXLEV values that are measured and
averaged by the BTS and then mapped to the interference bands.
• RFRSINDP (“rfResourceIndicationPeriod”): This attribute defines the sending rate
of the radio signalling message RFRESIND to the BSC.
9.2 Layer and service oriented channel allocation

The radio resource management strategy is guided by the two main goals, that the
limited radio resources are exploited effectively and that the transmission quality fulfills
the needs of the requested services. Therefore the radio channel allocation process
takes in consideration not only the varying quality of the radio channels but also the
quality requirements of the requested service (different services need different radio
qualities). This is done by grouping the radio channels in layers according to their
expected radio quality and by dynamically relating these groups of radio channels to
requested services via Service Layer Lists (SLLs), see chap. Service Layer Lists.
General procedure of resource allocation

When the BSC receives a channel request for a particular service type, it first checks if
for the requested service an SLL is defined. If yes, it looks inside the SLL defined for the
requested service type, and takes the layer that has the highest priority within the SLL.
If a resource (TRX/channel), related to this preferred layer, can be found, the channel is
allocated (in case of several free equivalent TCHs in the layer, the first one in the best
interference band is selected). If no free channel can be found on the TRX(s) belonging
to the preferred layer of the SLL, the BSC searches the next (lower) layer for resources
and so on.
If several Service Layer Lists are possible to satisfy a request, priority rules are applied
as described in chap. 9.2.1.
With new incoming requests and channel releases, the current resource allocation could
become suboptimal, may not match the best layer choice with reference to SLL. There-
fore a re-allocation procedure is periodically performed to move calls or services in more
appropriate layers as soon as possible. If the requested resource is not available in any
of the layers assigned to the service, specific procedures are applied to satisfy the
resource request, e.g. Directed Retry, Queueing, Preemption for CS calls or Downgrade
for PS multislot calls. For further information on the management of such processes
please refer to chap. 9.3 Strategies for handling congestion situations.
This layer and service based resource allocation feature maintains the compatibility with
former releases where the concept of layers was not supported. Configurations without
layers are mapped to the layer concept by assigning all the available TRXs to the same
layer and including this common layer in all Service Layer Lists required.
A50016-G5100-B556-04-7620 Id:0900d8058052e662 217

Example
A request for an enhanced full rate speech call is received for a cell with the following
configuration (see Figure 92).
– TRX:0 is related to layer LY_00,
TRX:1 is related to layer LY_01,
TRX:2 is related to layer LY_01, too,
TRX:3 is related to layer LY_02.
– The Service Layer List for Circuit Switched Speech calls is affected, containing the
layers LY_01 and LY_00 in descending priority order:
CRTSWSPELLPRM = LY_01 and LY_00
The BSC searches for free resources in the layer LY_01 (TRX:1 and TRX:2) first. If no
idle TCH resources can be found in layer LY_01, the BSC checks the next layer of the
SLL, i.e. LY_00 (TRX:0). TRX:3 is no candidate for the request because it is not related
to the affected SLL.
TRX:0 TRX:1 TRX:2 TRX:3
Layers: LY_00 LY_01 LY_01 LY_02
SLL Signalling SLL CS Speech SLL GPRS
LY_00 LY_01 LY_02

LY_00
Request Request Request

for for for
SDCCH TCH/EFR GPRS
Allocation Candidate: Allocation Candidates: Allocation Candidate:

TRX:0 1. TRX:1 and TRX:2 TRX:3
2. TRX:0
Figure 92 Example for resource allocation with service layer lists
9.2.1 Special priority rules

Special priority rules regarding layers within a SLL
The radio resource allocation according to the order of the layers in a Service Layer List
can compete with other interests; therefore the following priority rules are provided:
• CS multislot requests: The search for radio resources within the related SLL is done
in respect of high throughput. Thus the call can be served in e.g. the second or third
layer, even if the first one is not congested.
218 Id:0900d8058052e662 A50016-G5100-B556-04-7620

• In the CRTSWSPELLPRM Service Layer List (for CS FR/HR/EFR speech) the first
layer with free resources offers only FR channels, but the “Cell load dependent allo-
cation of HR channels” feature indicates to allocate a HR channel: In this case an
FR channel is allocated even if in the following layer with less priority a HR channel
is available.
Dedicated layers for PS services and CS data multislot services shall have the highest
priority in the relevant Service Layer List.
Special priority rules regarding SLLs

Several Service Layer Lists can satisfy a request (e.g. the SLL for AMR FR and the SLL
for AMR HR). The priority rules applied are described in the following, the cell type
specific rules are gathered in own topics.
AMR call requests:
AMR call requests can be served by the Service Layer Lists CS speech AMR FR, CS
speech AMR HR and (if no radio resources are available in the aforementioned SLLs)
CS speech EFR/FR/HR. If FR is preferred (e.g. MS´s preference, no HR channel indi-
cation by the “Cell load dependent allocation of HR channels” feature), the CS speech
AMR FR SLL is searched first, then the CS speech AMR HR SLL and at last (if neces-
sary) the CS speech EFR/FR/HR SLL.
GPRS/EGPRS requests:
• If the MS has EGPRS capability and EGPRS is supported in the cell or cell area (in
case of extended cell), the radio resource is searched first in the SLL of the EGPRS
service. If no appropriate resource is available there, the SLL of the GPRS service
is searched afterwards.
• If the MS has GPRS capability only, the radio resource is searched only in the SLL
of the GPRS service.
SLL priority rules specific for concentric cells

Usually there are Service Lists for both areas of a concentric cell, one for the primary
area (here the complete area) and another for the complementary area (here the inner
area). The following rules describe the order in which the SLLs related to primary and
complementary area are searched for radio resources.
Circuit-switched services: If the Mobile Station can operate in both the primary and com-
plementary area with respect to the radio conditions, the radio channels are searched
first in the SLL of the complementary/inner area; in case all layers of this area are con-
gested, channels are searched in the primary/complete area.
EGPRS/GPRS: Only one Service Layer List, the one for the primary area, has to be con-
figured for the GPRS service, because GPRS is only supported in the complete area of
a concentric cell. The same is valid for the EGPRS service.
Other services: The area, which resources are searched at first, depends on the
downlink average received level and additionally – if configured – on the current BTS-
MS distance (the uplink conditions on the same band are not important, because the
mobile is not affected when the call is handed over between the two areas inside the
cell). The BTS needs to consider also the power class of the mobile in order to take its
decisions. Information about the power class is included in the “Classmark 3” informa-
tion element and is already received by the BTS in the Abis proprietary message: MS
RF POWER CAPABILITY.
A50016-G5100-B556-04-7620 Id:0900d8058052e662 219

SLL priority rules specific for extended cells

Usually there are Service Lists for both the areas of an extended cell, one for the primary
area (here the far area) and one for the complementary area (here the near area). The
following rules describe the order in which the SLLs related to primary and complemen-
tary area are searched for radio resources.
Circuit-switched services: If the Mobile Station can operate in both the primary and com-
plementary area with respect to the radio conditions, the radio channels are searched
first in the SLL of the complementary/near area; in case all layers of this area are con-
gested, channels are searched in the primary/far area.
EGPRS/GPRS: Only one Service Layer List, the one related to the Service List for the
area of interest, is considered for the GPRS service; in case the resources are not avail-
able in the area of interest no change of the area is foreseen at the moment. The same
is valid for the EGPRS service.
Other services: The area, which resources are searched in, depends on the Timing
Offset (TO) derived from the position of the MS or on the availability of information
related to the position of the MS:
• Uplink request:
– If the Timing Offset is 0 (the MS is not far away from the TRX), the SLL for com-
plementary/near area is used.
– If the Timing Offset is greater than 0 (the MS is far away from the TRX), the SLL
for primary/far area is used
• Downlink request:
– If there is a concurrent uplink request, the Service Layer List already used for
the uplink direction is selected
– If there is no concurrent uplink request, the SLL for the primary/far area is used
In case a concurrent uplink request shall be established after having allocated resources
for a downlink request, the resources for both the uplink and the downlink request will
be allocated in the area of the uplink direction, possibly inducing a re-allocation of the
downlink allocation (if e.g. the downlink resource is allocated in the far area and then a
concurrent uplink connection is established in the near area, the downlink is re-config-
ured in the near area).
9.2.2 Direct TCH assignment

Direct TCH Assignment means assignment of a TCH without previous assignment of an
SDCCH. If Direct TCH Assignment is enabled, the TCH is first of all assigned by an
IMMEDIATE ASSIGNMENT (not by ASSIGNMENT COMMAND!) and the FACCH asso-
ciated to the TCH is used as main DCCH for the call setup control messages. When the
setup phase of the call is completed, the TCH is put into service by a CHANNEL MODE
MODIFY message.
Direct TCH Assignment can be applied in order to avoid SDCCH bottlenecks.
If Direct TCH Assignment is enabled, the SLL associated to signalling is used for allo-
cation. This SLL should be defined by the operator in such a way that the TRXs with less
SDCCHs and more TCHs are listed at the top. For call setups with direct TCH assign-
ment, the TCHs are first searched in the SLL defined for signalling (SLLPRM) and, if the
allocated channel does not perfectly match the service type requested in the ASSIGN-
MENT REQUEST message, the channel is changed after receipt of this message (as it
is done during normal change from SDCCH to TCH).
220 Id:0900d8058052e662 A50016-G5100-B556-04-7620

Interdependencies
Cell load dependent activation of half rate TCHs does not work when Direct TCH Assign-
ment is enabled, because of the following reason: the BSC has to decide about the TCH
type (FR, HR) when it receives the CHANNEL REQUIRED message. The only informa-
tion about the MS’s speech version capability which is available at this point of time is
included in the 'Establishment cause' IE within the included CHANNEL REQUEST
message. This information is very restricted with respect to the grade of detail and the
MS capabilities and preference (see GSM04.08 for details). At this point of time the BSC
does not check the current TCH load in the cell to decide about the allocation of FR or
HR but assigns a TCH type in correspondence with the 'establishment cause' value
received in the CHANNEL REQUIRED message.
In some cases the 'establishment cause' values contained in the CHANNEL REQUEST
messages do not allow a clear distinction between calls (that require a TCH) and signal-
ing procedures (for which an SDCCH is sufficient). This can happen, depending on the
type of MS, e.g. for an IMSI DETACH INDICATION (which is sometimes indicated with
the same establishment cause like MOC) or for SMS-MT (the BSS cannot distinguish
SMS-MT from normal MTCs as the very first signalling messages are exactly the same
for both procedures). In other words: It happens that the BSC assigns a TCH for signal-
ing procedures, although these procedures could be processed using an SDCCH only.
Moreover, several mobile types cause problems, when Direct TCH Assignment is
enabled, especially when it is enabled for the establishment cause 'answer to paging'.
Enabling direct TCH assignment

The Direct TCH Assignment feature can be enabled by the DIRTCHASS (“directTchAs-
signment”) attribute subordinate to the BTS object. Setting DIRTCHASS to SDCCHMS
means that direct TCH assignment is enabled, but disabled for the cause 'answer to
paging – any channel' of the CHANNEL REQUIRED message (since SDCCH-only-MSs
may be supported by the network). Setting DIRTCHASS to NOSDCCHMS means that
direct TCH assignment is enabled also for the cause 'answer to paging – any channel'
of the CHANNEL REQUIRED message (since SDCCH-only-MSs are not supported by
the network).
9.3 Strategies for handling congestion situations

Overview
In case no radio resources can immediately be allocated for incoming Circuit Switched
call requests, the following processes are provided to handle the requests:
• Preemption: Provides traffic channel resources for high priority traffic channel
requests by forcing handovers to lower priority calls
• Directed Retry: Tries to execute a handover from a SDCCH in one cell directly to a
traffic channel in a neighboring cell during the call setup
• Queuing: Traffic channel requests which can not served immediately must not be
dropped, but can be put in a Queuing List on a per cell basis taking into account the
priority of calls. If new resources are available the queued requests are served
according to their position in the Queuing List.
• Downgrading: A HSCSD multislot call request can be downgraded to a 1-timeslot
request. Also already active multislot calls (HSCSD or GPRS/EGPRS) can be down-
A50016-G5100-B556-04-7620 Id:0900d8058052e662 221

graded (under certain conditions) in the cell to release resources for a new CS
request.
These processes are described more in detail in the next chapters.
Two other features are applied on CS calls in case of congestion situations, described
in the chapters 9.3.6 Enhanced pairing and 9.3.7 Cell load dependent activation of half
rate TCHs.
Preemption and priority concepts are also available for Packet Switched requests (but
executed from a different management instance), the basics of these features are
described in chap. 9.3.5 Preemption and priority concept for packet switched calls.
With GPRS/EGPRS and CS multislot services the Waiting List has been introduced
complementing the Queuing List. The Waiting List keeps the pending requests which
are not submitted to usual Preemption and Queuing (applied for 1 timeslot CS TCH
requests). The entries in the Queuing List take priority over those in the Waiting List (so:
“waiting”). The process manager for the Waiting List applies features such as preemp-
tion for (E)GPRS calls, several downgrading and forced handover possibilities, see
9.4.3 Waiting list manager.
The combination and interaction between the different features is described in chap.
9.4 Request management, resource re-allocation and waiting list management. The
Preemption, Directed Retry and Queueing procedures are executed by the Request
Manager (see chap. 9.4.1 Request manager).
9.3.1 Preemption
The Preemption process provides TCH resources for a high priority single timeslot TCH
request in case the radio resources are exhausted by performing a forced handover (or
even a forced release if necessary) of an ongoing lower priority call – presumed that
appropriate priority information is available.
Priority Information Element

The messages ASSIGNMENT REQUEST and HANDOVER REQUEST, sent to the
BSC during a TCH request, optionally contain the “Priority” Information Element. This
element carries parameters relevant for the Preemption and the Queuing procedure and
has the following entries:
• The Preemptive Capability Indicator (PCI): PCI indicates whether the preemption
procedure shall be applied; PCI = 1 enables the Preemption functionality, PCI = 0
disables it.
• The Preemptive Vulnerability Indicator (PVI): PVI indicates whether the radio
resource / connection for the related call may become a target of subsequent forced
handover (or even forced release) due to preemption; PVI = 1 indicates a call as vul-
nerable due to preemption, PVI = 0 inhibits that another call can be prioritized in
respect of the call request.
• The Queuing Allowed Indicator (QA): QA determines if Queuing shall be applied or
not; Queuing is allowed with QA = 1; QA = 0 inhibits Queuing.
• The Priority Level (PL): 14 priority levels are available; level 1 has the highest prior-
ity, level 14 the lowest.
If no “Priority” Information Element is provided together with a TCH request, the BSC
assumes the following parameter values: PCI = 0, PVI = 0, QA = 1 and PL = 14. So no
Preemption is applied, Queuing is applied, but with the lowest priority.
222 Id:0900d8058052e662 A50016-G5100-B556-04-7620

Procedure
Figure 93 shows the algorithm executed for the Preemption procedure.
TCH Request (1 timeslot, CS)
no
Preemption
allowed (PCI = 1)? Directed Retry
yes
Request with yes

PCI=1 and equal/higher prio. Directed Retry
in Queue?
no
Active vuln- no
erable call (PVI = 1) with lower Directed Retry
priority?
yes
Try forced handover for the call

with lower priority
Forced yes
Handover successful?
no
Forced release of the call Allocation of the free TCH

with lower priority for the request
Figure 93 Preemption procedure
g In case of Full Rate TCH requests, the Preemption is applied only to vulnerable calls
allocated on Full Rate channels. In this case no Preemption of Half Rate calls is per-
formed. This restriction is due to the impossibility, with actual implementation, to be
sure that after the Preemption procedure the second part of the paired Half Rate
channel is still available.
The following main steps are carried out:
A50016-G5100-B556-04-7620 Id:0900d8058052e662 223

1. The ASSIGNMENT REQUEST or HANDOVER REQUEST message for the new

call request is checked for the “Priority” Information Element and for the applicability
of the Preemption functionality (enabled by PCI = 1, disabled by PCI = 0).
If PCI = 0, the request is committed to the Directed Retry procedure; else the Pre-
emption procedure goes on.
2. The priorities of the requests in the Queue (containing pending 1 timeslot CS
requests) – if there are any – are compared with the priority of the new request.
If the new call request has not a higher priority than the most prioritized call request
in the Queue (also having the right to preempt an active call), the Preemption
process is stopped (because it can be concluded that all the active calls have higher
priority than the call requests in the queue) and the new call is immediately commit-
ted to the Directed Retry procedure. Else, the next step of the Preemption procedure
takes place.
3. The active calls with PVI = 1 (preemption vulnerability enabled) are considered and
their priority levels are compared with the priority level of the new TCH request:
If there is no active call with PVI = 1 and a lower priority, the new request is imme-
diately committed to the Directed Retry Procedure. Else, a candidate for the next
step of the Preemption procedure exists.
4. A forced handover (BSC or MSC controlled) for the active call with PVI = 1 and lower
priority level than the new TCH request is tried. In case of more than one active calls
with the same priority, the youngest (shortest) call is selected. In case no resources
are available at the neighbor cell, the handover task is not queued in order to limit
the whole Preemption time; instead a forced release for this call with cause “preemp-
tion” is then performed.
5. The forced handover or forced release of an active call with lower priority leads to a
new free radio channel. This channel is now allocated for the new TCH request.
Attributes
EPRE (“enablePreemption”): The Preemption mechanism is enabled by setting this
attribute to ENABLED.
EPREHSCSD (“enablePreemptionHSCSD”): If HSCSD is enabled (ENHSCSD =
ENABLED) and if this attribute is set to TRUE, HSCSD calls may preempt other calls.
HSCSD calls themselves can never be preempted.
9.3.2 Directed retry

The Directed Retry procedure tries to execute a handover from an SDCCH (established
during the call setup) in one cell directly to a TCH in a neighboring cell in case of
exhausted TCH resources. It is applied to ASSIGNMENT REQUESTs only. Directed
Retry is a forced handover with cause “Directed Retry” and avoids call rejection due to
congestion in one cell.
Procedure
The algorithm executed for the Directed Retry procedure contains the following main
steps:
1. The BSC starts the Directed Retry procedure by sending a FORCED HANDOVER
REQUEST to the BTS.
2. The BTS responds by sending back the INTERCELL HANDOVER CONDITION
INDICATION message. This message contains a list of target cells for the handover
(for details and configuration see 12.6 Generation of the target cell list) that the BTS
224 Id:0900d8058052e662 A50016-G5100-B556-04-7620

has determined by evaluating the measurement reports sent uplink by the MS during
the SDCCH phase.
3. The BSC checks the list with target cells from the BTS (the BTS sends such a list in
any case; if there is no suitable target cell, the list is empty). If no suitable neighbour
cell is present or if the target cell does not lie inside the BSC area, the BSC forwards
the TCH request to the Queuing procedure – if allowed. Else the Directed Retry pro-
cedure goes on.
4. In case a suitable neighbour cell in the BSC controlled area is present, the BSC
looks for a free TCH in this target cell:
– If a free TCH is available, the new traffic channel is assigned internally by the
BSC, the BSC internal handover is performed and an ASSIGNMENT
COMPLETE message (containing the Cell Identifier of the new cell) is sent to
the MSC. A HANDOVER PERFORMED message is not sent in this case
because the equivalent information is already provided by the ASSIGNMENT
COMPLETE message.
– If no free TCH is available, an inter-BSC (MSC controlled) Directed Retry is tried
(if allowed and enabled).
Attributes
The Directed Retry feature is enabled by setting the following attributes (subordinate to
the BSC object):
• ENFORCHO (“enforceHo“): This attribute enables/disables the sending of FORCED
HANDOVER REQUEST messages for running SDCCH connections. It is used to
enable/disable Directed Retry. It should be set to DISABLED if in a network the MSC
which the BSS is connected to or other adjacent BSSs do not support the prevention
of Handover Fallback.
• EISDCCHHO (“enableInterSdcchHo“): This attribute allows to enable/disable inter-
BSC (MSC-controlled) Directed Retry. It simply prevents the sending of
HANDOVER REQUEST messages for SDCCH connections to the MSC. If it is set
to DISABLED, the BSC skips all Cell Identifiers of the target cell list of the INTER-
CELL HANDOVER CONDITION INDICATION message which belong to another
BSC area. The flag should be set to DISABLED, if the MSC does not support
Directed Retry.
Other attributes concerning details of the handover (e.g. prevention of back-handovers,
controlling the target cell list generation) are described in the Handover chapter.
9.3.3 Queueing
The Queuing procedure allows the temporarily keeping of pending TCH requests in a
list and serving the requests later (when new TCH resources are available) taking into
account the priority of calls (provided in the “Priority” Information Element, see
9.3.1 Preemption). The BSC can queue TCH requests associated to normal cells, con-
centric cells and extended cells without differences between them.
Queuing principles
Each cell of the BSC has a queue, i.e. a list of pending requests sorted with decreasing
priority order (1..14, 1 the highest, 14 the lowest priority). A request with a higher priority
ha a higher position in the list than a request with lower priority. Requests with equal pri-
orities are sorted according to the first-in, first-out principle.
A50016-G5100-B556-04-7620 Id:0900d8058052e662 225

g There is one queue for usual TCH requests, the public queue, and another regard-
ing WPS (Wireless Priority Services) TCH requests, the WPS queue. The descrip-
tions below are applicable to both queues if the kind of queue is not specified.
Depleting the queue:
When a TCH becomes available (e.g. after a call release), the first entry in the queue
(with the highest priority) has to be analyzed: if the available TCH is compatible with the
request, the TCH is allocated and the request is removed from the queue. Otherwise the
BSC proceeds to the next request in the queue and so on. Special cases regarding com-
patibility between request and available resource:
• In case a TCH becomes available in a concentric cell, the BSC allocates the TCH
only if the TRX area (complete/inner) related to the TCH is compatible with the
request.
• In case a TCH becomes available in an extended cell, the BSC allocates the TCH
only if the TCH’s timeslot length (normal or double) is compatible with the request.
• In case a Half Rate TCH becomes available, it is assigned to the first Half Rate
request in the queue, even if Full Rate requests with higher priority are available. If
a Dual Rate channel, used as a Full Rate channel, becomes available and the first
request in the queue is a Half Rate one, then one half of the Dual Rate channel, to
be used as Half Rate channel, is assigned to this request and a second Half Rate
request will be looked for in the queue.
Full queue:
If the queue is full and an incoming TCH request has a higher priority than the lowest
queued one, then the request at the last position of the queue is excluded from the list,
this request is rejected (and an ASSIGNMENT FAILURE message is sent to the MSC)
and the new request is sorted into the queue.
If the queue is full and the new TCH request is of lower priority than the lowest queued
one, the new request is rejected by means of an ASSIGNMENT FAILURE message to
MSC.
Queuing procedure
The Queuing procedure is executed with the following major steps:
1. The BSC checks, if Queuing is allowed for the assignment request or handover
request from the MSC. If QA = 0 (Queuing not allowed for the request) in the “Prior-
ity” information element sent with the request, the request is forwarded and put into
the Waiting List (subsequently handled by the Waiting List Manager, see
9.4.3 Waiting list manager). Else (QA = 1), see next step.
2. The BSC puts the request into the queue (sorted according to the priority), sends the
QUEUING INDICATION message to the MSC and starts the related queuing timer.
If a TCH request can not be placed in the Queue (all places are occupied by equal
or higher priority calls), the BSC rejects the request and sends an ASSIGNMENT
FAILURE or HANDOVER FAILURE message to the MSC (with cause “No radio
resources available”). The ASSIGNMENT FAILURE or HANDOVER FAILURE
message is also sent if, for some reason, the channel activation has not taken place.
3. The BSC waits for TCHs becoming available. When an appropriate free TCH is
found, an assignment of this TCH takes place (according to the queuing principle),
the affected request is immediately removed from its queue and the relevant timer
is stopped. Additionally an ASSIGNMENT COMPLETE or a HANDOVER
ACKNOWLEDGE message is sent to the MSC.
226 Id:0900d8058052e662 A50016-G5100-B556-04-7620

4. If the queuing timer expires without assignment of a channel to a request, the

request is removed from the queue and the BSC sends to the MSC an ASSIGN-
MENT FAILURE or HANDOVER FAILURE message with the cause report "No radio
resources available".
Attributes
The Queuing feature is enabled by setting the EQ (“enableQueuing“) attribute to
ENABLED.
Timer attributes:
– BSCT11PUB (“bscTimer11Public”): This attribute defines the maximum allowed
queueing time for assignment requests in the Public queue.
– BSCT11WPS (“bscTimer11WPS“): This timer determines the maximum allowed
queuing time for assignment requests in the WPS queue. This parameter is only
relevant if the feature “Wireless Priority Service” is applied.
– BSCTQHOPUB (“bscTimerQueueHoPublic”): This attribute defines the maximum
allowed queueing time for handover requests in the Public queue.
– BSCTQHOWPS (“bscTimerQueueHoWPS”): This timer determines the maximum
allowed queuing time for TCH requests due to incoming handover in the Public
queue. This parameter is only relevant if the feature “Wireless Priority Service” is
applied.
9.3.4 Downgrading
Downgrading is the reduction of the number of timeslots for an ongoing multislot call or
for a multislot call request. Downgrading applied to an active multislot call releases radio
resources for other calls (without service interruption of the ongoing call), downgrading
of a multislot call request reduces the demand for radio resources.
Downgrading of circuit switched multislot calls

A HSCSD call (or call request) is downgraded to one timeslot or to the maximum down-
grade level.
If an intra-BSC inter-cell handover request (including the target cell list) comes from the
BTS and if all the cells on the target cell list are congested, the downgrade of active
HSCSD calls is started from the first cell of the list.
GPRS/EGPRS downgrading
The downgrade of multislot packet resources is executed as follows:
1. The BSC looks if there are channels in the cell used as PDCHs for GPRS/EGPRS
services.
2. The PDCHs not-reserved as GPRS/EGPRS channels are downgraded in order to
free resources to be used by CS services.
Configuration of the downgrading strategy

To avoid GPRS/EGPRS downgrading, the user can use the GMANPRES attribute.
The following downgrade strategies on active multislot calls are possible and can be set
via the DGRSTRGY (“downGradeStrategy”) attribute:
– Downgrade of HSCSD calls first
– Downgrade of GPRS/EGPRS calls first
A50016-G5100-B556-04-7620 Id:0900d8058052e662 227

– Downgrade of HSCSD calls only

– Downgrade of GPRS/EGPRS calls only
– No Downgrade
When downgrading of GPRS/EGPRS/HSCSD calls is performed, the following rules are
obeyed:
• For the HSCSD service the downgrade is executed only if the number of used
timeslots is greater than one (i.e. at least one timeslot must remain allocated for
HSCSD calls).
• For the GPRS/EGPRS service there are two possibilities:
– If no channels of the cell are statically reserved to GPRS/EGPRS, the down-
grade can reduce the number of used timeslots to zero.
– If any channel is statically defined for GPRS/EGPRS, the downgrade can reduce
the number of used timeslots to the number of channels reserved to (E)GPRS.
Besides:
– before downgrading a GPRS/EGPRS call on a TRX where CS calls are pre-
ferred, a free channel on TRXs not preferred for CS calls is searched first;
– independently on the value of the attribute: DGRSTRGY, if there are some
empty channels (for example PDCHs for which the PDCH empty timer is run-
ning), they are used to serve the CS call; if no empty channels exists, then the
rules defined by the attribute: DGRSTRGY are followed to free resources for the
CS call. The downgrade of the PDCHs is applied, until the number of the
reserved channels for PS services is reached in the cell (reserved PS channels
cannot be downgraded).
9.3.5 Preemption and priority concept for packet switched calls

A preemption and priority concept for packet-switched call requests in case of conges-
tion of radio resources is implemented by the Allocation Retention Priority feature
(ARP). This feature applies downgrading (according to the downgrading strategy, see
9.3.4 Downgrading) for allocated PS calls with low priority to release radio resources for
incoming CS calls from Mobile Stations with higher priority – presumed that appropriate
priority information is provided. Queuing is not foreseen; the release of a Packet Flow
Context does not occur.
The BSC directs the PDCH preemption orders to the PCU as follows:
1. First to PDCHs with the ‘PDCH empty timer’ still active; the “PDCH empty timer” can
be defined setting the TEMPCH attribute.
2. Then to PS dynamic channels.
The preemption of some PDCHs can result in the re-configuration of some TBFs (also
partially allocated on “residual” PDCHs) and in the release of some other TBFs (com-
pletely allocated on the preempted PDCHs).
Preemption and priority information from SGSN

The BSC receives the Allocation Retention Priority information from the SGSN node and
if the BSC supports the feature, the priority levels and the preemption indicators of the
incoming and allocated Packet Flow Contexts are used to evaluate whether the Packet
Flow Context assignment shall be performed. More in detail the SGSN requests to the
BSC the creation or the modification of a Packet Flow Context with a dedicated message
containing the “Allocation Retention Priority” Information Element. The BSC establishes
228 Id:0900d8058052e662 A50016-G5100-B556-04-7620

or modifies allocated resources according to the following values of the “Allocation

Retention Priority” IE:
• The Preemptive Capability Indicator (PCI): Indicates whether the preemption proce-
dure shall be applied; PCI = 1 enables the Preemption functionality, PCI = 0 disables
it.
• The Preemptive Vulnerability Indicator (PVI): Indicates whether the radio resource /
connection for the related call may become a target of subsequent preemption;
PVI = 1 indicates a call as preemption target, PVI = 0 inhibits that another call can
be prioritized in respect of the call request.
• The Queuing Allowed Indicator (QA): Queuing is not applied by the Allocation
Retention Priority feature. If the requested Packet Flow Context is allowed for
queuing and a queuing condition occurs, the BSC rejects it immediately with a
specific message.
• The Priority Level (PL): Assigns the priority between highest and lowest priority.
In case the BSC receives the request for the creation of a Packet Flow Context PDU for
an existing Packet Flow Context with different Allocation Retention Priority setting, the
values of the last received preemption vulnerability and priority level Information
Element are considered.
In case the “Allocation Retention Priority” Information Element is not given in the request
of Packet Flow Context PDU creation (because the “Allocation Retention Priority” Infor-
mation Element is optional), the allocation request does not trigger the preemption
process and the connection is preempted with the lowest value as priority level.
Pre-defined Packet Flow Indicators

In case the Packet Flow Context procedure is supported and Packet Flow Indicators are
predefined, i.e. when there is no negotiation between the BSC and the SGSN, the Allo-
cation Retention Priority feature uses the priority, the preemption capability and the pre-
emption vulnerability indicators configured by the user. This configuration is done within
the following 4 pre-defined Packet Flow Indicators:
– BSEPRIPFC (“bestEffortPriorityPFC“): This attribute is related to the Best Effort type
of service.
– SMSPRIPFC (“smsPriorityPFC“): This attribute is related to the SMS type of service.
– TOM8PRIPFC (“tOM8PriorityPFC“): This attribute is related to the TOM8 type of
service.
– SIGPRIPFC (“signallingPriorityPFC“): This attribute is related to the Signaling ser-
vices.
Each of the 4 attributes contains the following subset of indicator attributes:
– Allocation Priority: This indicator shows the priority level of an allocation
request.Validity range: 1..3.
– Preemption Capability: This indicator triggers the preemption procedure and applies
to the allocation of resources for an event. Validity range: 0..1.
– Preemption Vulnerability: This indicator shows if the connection is a target of the
preemption procedure. Validity range: 0..1
The attribute EARP (“enableAllocationRetentionPriority“) permits the user to enable/dis-
able the Allocation Retention Priority feature. Validity range: TRUE/FALSE. This attri-
bute can be set to TRUE, if the related feature license has been installed and if the
attribute PFCSUP related to all the configured CPCU Managed Objects is set to
ENABLED.
A50016-G5100-B556-04-7620 Id:0900d8058052e662 229

Example: In case the user assigns medium priority to the best effort type of service, to
preempt an existing allocation with the related allocation request and to configure the
existing connection as not preempted by another allocation request, the user sets the
BSEPRIPFC attribute to the value 2 1 0.
9.3.6 Enhanced pairing

Principle
This feature moves unpaired Half Rate traffic channels to other unpaired Half Rate traffic
channels (“Pairing”) thereby releasing new Full Rate traffic channels and so optimizing
the existing network resources. The enhanced pairing allows allocation of Full Rate
traffic channels (e.g. for data services or for Mobile Stations not supporting Half Rate
channels) even in situations with high traffic load. The enhanced pairing is performed by
the Resource Re-allocator (see 9.4.2 Resource re-allocator).
Example:
The 8 timeslots of a TRX shall have been configured to allow both Full Rate and Half
Rate transmission. After various assignments and releases of channels a situation shall
occur where there is no possibility to allocate a Full Rate TCH although three sub-
timeslots are free for Half Rate TCHs, see Figure 94, a). Now, Enhanced Pairing moves
a Half Rate TCH which adjacent sub-timeslot is free, to another free sub-timeslot which
neighbour sub-timeslot is allocated. As result a full timeslot is available which provides
a Full Rate TCH, see Figure 94, b).
FORCEDHANDOVER
A

FREE
4#((2
43 43 43 43 43 43 43 43
B
ALLOCATED
4#((2

43 43 43 43 43 43 43 43
Figure 94 Example for enhanced pairing
Procedure
Enhanced Pairing is performed by an automatic process within the operation of the
Resource Re-allocator. Every 500 ms the Resource Re-allocator checks the percentage
of idle Full Rate TCHs: If this rate is under a predefined threshold (defined by the user)
and if there are at least two Half Rate TCHs not paired, the Half Rate Pairing procedure
is started.
The moving of Half Rate TCHs during the Enhanced Pairing procedure is done by forced
intra-cell handovers.
Enhanced Pairing is also provided for Adaptive Multi Rate (AMR) calls.
230 Id:0900d8058052e662 A50016-G5100-B556-04-7620

g – In case of Concentric cells the handover because of Enhanced Pairing can be

performed only between channels belonging to the same area (from complete
to complete area or from inner to inner area).
– When the flexible Abis allocation strategy is used, the Enhanced Pairing for the
Radio Interface also takes into account the Abis interface congestion state.
Parameters
To enable the “Enhanced pairing for TCH/H channels” feature the user must set the EPA
attribute (“EnablePairing”), which belongs to the BSC object, to TRUE. Enabling of EPA
is not permitted in the far area of extended cells due to radio problems. With EPA
enabled the ENFOIAHO (“Enable Forced Intra-cell Handover”) attribute is meaningless.
The threshold attribute to be used for triggering the Enhanced Pairing feature depends
on the cell type:
– EPAT1 (“EnhancedpairingThreshold1”): Used in case of a Standard cell or the
Complete area of a Concentric cell.
– EPAT2 (“EnhancedpairingThreshold2”): Used in case of Inner area of a Concentric
cell or the Near area of an Extended cell.
The threshold attributes belong to the BTS object.
The thresholds are set as percentage values. If the percentage of idle Full Rate traffic
channels in the group of radio resources specified for the required service by the corre-
sponding Service Layer List falls under the related threshold value, the Enhanced
Pairing is started.
9.3.7 Cell load dependent activation of half rate TCHs

This feature allows the allocation of Half Rate traffic channels instead of requested Full
Rate traffic channels during high peak traffic load in a cell in order to increase the
number of available traffic channels. During low traffic periods the traffic channels are
assigned according to the preferences delivered by the MSC (“Full rate preferred” or
“Half rate preferred”, in the ASSIGNMENT REQUEST message) and the preferences of
the Mobile Station, particularly Full Rate traffic channels for providing higher speech
quality.
The Cell Load Dependent Activation of HR TCHs is performed by the Request Manager
(see 9.4.1 Request manager).
Cell Load Dependent Activation of HR TCHs can also be applied to Adaptive Multirate
(AMR) calls.
Figure 95 shows how the Cell Load Dependent Activation of HR TCHs feature works.
When the feature is enabled and the MSC has sent an ASSIGNMENT REQUEST
message for an incoming call to the BSC, the BSC calculates the percentage of busy
TCHs in the group of radio resources specified for the required service and then
compares this value with a threshold set by the user.
If the percentage of busy TCHs exceeds the threshold or the threshold is set to 0, the
MSC preference is changed to (or kept as) “Half rate preferred” – presumed the Mobile
Station supports Half Rate TCHs – and a Half Rate TCH is allocated.
Otherwise, if the percentage of busy TCHs is below the threshold, the MSC/MS prefer-
ence regarding allocation of a Full Rate or a Half Rate TCH is respected.
When the flexible Abis allocation strategy is used, the Cell Load Dependent Activation
of Half Rate TCHs also takes into account the Abis interface congestion state.
A50016-G5100-B556-04-7620 Id:0900d8058052e662 231

ASSIGNMENT
REQUEST
Cell load dependent

activation of Half_Rate
is enabled?
Allocation of Half_Rate Y Threshold set by operator

traffic channel is equal to 0?
Y The percentage of busy

Allocation of Half_Rate
TCH is > Threshold set by
traffic channel
operator?
Allocation of Required
traffic channel
Figure 95 Algorithm for the cell load dependent activation of HR channels

Special features for concentric and extended cells:
In case of concentric/extended cells, when in the inner/near area a Half Rate traffic
channel is required and in the inner/near area there are no more available channels, a
Half Rate traffic channel of the complete/far area is allocated, without checking again
the percentage for this area. The same is applied when a Full Rate traffic channel is
requested in the inner/near area and no resources are available.
g Suppose that a Half Rate TCH request arrives for the inner/near area where the
timeslots have been configured for Full Rate only (so the preference is set to “Full
rate preferred”) and no TCH is available in this area. Then a Full Rate TCH is
assigned in the complete/far area, even if in this second area the timeslots have
been configured for both Full Rate and Half Rate.
Calculation of the percentage of busy traffic channels

The percentage of busy traffic channels is calculated taking into account not only the
busy channels but the total number of channels not available for new calls (including
TCHs which are e.g. locked, failed, in call, not downgradeable):
Percentage_of_busy_TCHs =
Number_of_busy_TCHs · 100 / Number_of_configured_TCHs
Counters, parameters and attributes

The following counters are used for the calculation of the number and percentage of
busy channels; these counters are internal to the system and not visible to the user:
232 Id:0900d8058052e662 A50016-G5100-B556-04-7620

– a counter to indicate how many FULL_RATE channels are available;

– a counter to indicate how many FULL_AND_HALF_RATE channels and TCH/SD
channels, with mixed pool or TCH pool, are available; the counter is updated for
each available sub-channel;
– a counter to indicate how many FULL_RATE channels are busy;
– a counter to indicate how many HALF_RATE channels are busy;
– a counter to indicate how many FULL_AND_HALF_RATE channels and TCH/SD
channels, with mixed pool or TCH pool, are busy and used as FULL_RATE channels
The counters are updated when a channel is being assigned or released.
The following parameters are foreseen inside the BSS system, belonging to the BTS
object:
• Enabling of the Cell Load Dependent Activation of HR TCHs is done with the
EHRACT (“enableHrActivation”) attribute belonging to the BTS object:
g Half Rate TCH allocation must have generally been enabled in the BSC which
is determined by the HRSPEECH attribute.
• Thresholds:
To avoid fractional values, the threshold indicating the critical ratio of busy TCHs is
expressed not in multiples of 100 (which would mean percentage values), but in mul-
tiples of 10 000; so the range is from 0 (which means that Half Rate channels shall
be allocated) to 10 000 (which means that the MSC/MobileStation preference is
respected).
– For standard CS calls two thresholds indicating the critical ratio of busy TCHs in
the cell are defined in order to serve dual area cells; for standard cells only the
first threshold is meaningful:
“hrActivationThreshold1” – HRACTT1: used in case of Standard cell, Complete
area of a Concentric cell and Far area of an Extended cell
“hrActivationThreshold2” – HRACTT2: used in case of Inner area of a Concen-
tric cell and Near area of an Extended cell
– For Adaptive Multirate calls two additional thresholds are defined in the same
way as for standard CS calls:
“hrActivationAmrThreshold1” – HRACTAMRT1: used in case of Standard cell,
Complete area of a Concentric cell and Far area of an Extended cell
“hrActivationAmrThreshold2” – HRACTAMRT2: used in case of Inner area of a
Concentric cell and Near area of an Extended cell
The default value of all these thresholds is 6000, which means 60% busy TCHs.
9.4 Request management, resource re-allocation and waiting

list management
The management of incoming calls and the dynamic optimization of the service depen-
dent channel allocation is shared between three main management processes,
executed at the BSC and described in the following sub-chapters:
• Request Manager
• Resource Re-allocator
• Waiting List Manager
In a few words the Request Manager is responsible for the initial management of all the
incoming TCH requests (in form of e.g. ASSIGNMENT REQUESTs or HANDOVER
A50016-G5100-B556-04-7620 Id:0900d8058052e662 233

REQUESTs from the MSC). Requests which can not be served and shall not be dropped
are put in a Queuing List handled by the Request Manager itself (see 9.3.3 Queueing)
or are forwarded into a Waiting List which the Waiting List Manager is responsible for
(the requests in the normal Queuing List take priority over those in the Waiting List in
case free resources become available; the Waiting List Management is different from
Queuing). The Resource Re-allocator optimizes the exploitation of the radio resources
by periodically trying to re-allocate radio channels in a more appropriate way. Each time
the re-allocation procedure is completed, and resources have successfully been
released, these resources are immediately used from the Request Manager and the
Waiting List Manager.
9.4.1 Request manager

The Request Manager is responsible for the initial management of the incoming TCH
requests. The handling is different for 1 timeslot CS requests, multislot CS requests and
PS requests. The following topics describe the procedures executed by the Request
Manager.
1 timeslot TCH requests

Figure 96 shows the algorithm applied by the Request Manager for serving a 1 timeslot
TCH request (CS).
The following main steps are performed:
1. The “Cell load dependent activation of Half Rate” procedure is applied (if the proce-
dure is enabled by the user), see 9.3.7 Cell load dependent activation of half rate
TCHs.
2. The available resources of the BTS are examined. The following main situations can
occur:
– An appropriate TCH is available to serve the request:
If in this case the Waiting List is empty, the TCH is allocated (successfully termi-
nating the procedure). Else, the request is put into the Waiting List in order to
allow that pending requests with higher priority in this list can be preferred (which
is managed by the Waiting List Management process).
– No resources are available for serving the request:
Assignment and Handover Requests are forwarded (see next step), requests
with other causes are again put into the Waiting List.
3. Preemption is applied if allowed. In case of success, a TCH is allocated thus satis-
fying the request (end of the procedure).
4. Directed Retry is applied if allowed. In case of success, a TCH is allocated thus sat-
isfying the request (end of the procedure).
g No Directed Retry is applied for Handover Requests!
5. It is checked if Queuing is allowed. If not, the request is put into the Waiting List.
6. Queuing is applied if allowed. The BSC sends a QUEUE INDICATION message to
the MSC, in order to indicate a delay in the assignment of the required TCH. Either
the request can be satisfied within a maximum time period (timer) and with respect
to the priorities of other requests in the Queuing List or the request is dropped.
234 Id:0900d8058052e662 A50016-G5100-B556-04-7620

TCH Request
(1 timeslot)
Apply Cell Load Dependent

Activation of HR procedure
BTS yes yes successful

Assignment or Try Preemption
congested? HO Request?
no no not allowed
or failed
no successful
Waiting List Try Directed Retry
empty?
not allowed
yes
or failed
no Queuing
Allocate channel Put in Waiting List allowed?
yes
successful
Insert Request in Queue
List, Queuing procedure
no success,
timer expired
Drop Request Allocate channel
Figure 96 Management of 1 timeslot TCH requests

If all processes (which are allowed and have been enabled) end without success, no
channel can be allocated for an ASSIGNMENT REQUEST / HANDOVER REQUEST
and the BSC sends an ASSIGNMENT FAILURE message (with cause “No radio
sources available”) / HANDOVER FAILURE message to the MSC.
g The resources the Resource Re-allocator process releases are used first by the
Queueing process and only later on by the Waiting List Manager process. So the
pending requests in the Queue have priority in respect to those in the Waiting List.
Multislot TCH requests

Figure 97 shows the algorithm applied by the Request Manager for serving a multislot
TCH request (CS).
A50016-G5100-B556-04-7620 Id:0900d8058052e662 235

TCH Request
(multislot HSCSD)
no optimal resources Resources no no

Is downgrade
available? possible?
yes yes
Alloc. yes no
possible with forced Waiting List Downgrade to 1 timeslot
HO? * empty?
no yes
Is downgrade no
Allocate channel Put in Waiting List Drop Request
possible?
yes
Downgrade to 1 timeslot
Resources no
available? Put in Waiting List
yes
Allocate channel
* : Forced handover of an ongoing 1 timeslot CS call
Figure 97 Management of multislot TCH requests

First the Request Manager checks if the request can be satisfied by the available
resources. Three results are possible leading to different reactions as described in the
following:
• Appropriate radio resources are available to serve the request completely:
If in this case the Waiting List is empty, the resources are allocated (successfully ter-
minating the procedure). Else, the request is put into the Waiting List in order to allow
that pending requests with higher priority in this list can be preferred (which is
managed by the Waiting List Management process).
• No resources are available for serving the request:
If in this case a downgrade of the multislot request is allowed, the multislot request
is downgraded to a 1 timeslot request and then put in the Waiting List. Else, the
request is dropped.
• Resources are available for the request, but not optimal ones:
In this case it is checked, if a forced intra-cell handover of an ongoing 1 timeslot CS
call could make available enough additional resources to fully satisfy the multislot
236 Id:0900d8058052e662 A50016-G5100-B556-04-7620

request. If yes, the request is put into the Waiting List (without downgrading); else,
a downgrade of the multislot request to a 1 timeslot request is tried.
If the downgrade was possible and there is an appropriate TCH available, the TCH
is allocated, else the request is put in the Waiting List.
PS requests
PS requests, i.e. requests concerning (E)GPRS services, are also (partly) handled by
the Request Manager. For details about PS request management, please refer to chap.
GPRS Radio Channel Management.
If radio resources for allocation are available, the procedure is similar as for CS TCH
requests (allocation if Waiting List is empty, else inserting the request in the Waiting
List). If there are no appropriate resources, the requests are put in the Waiting List –
possibly after downgrading if applicable –, no Queuing as for CS requests is applied.
The Waiting List usually contains both CS and PS requests which are treated in the
same way.
g Upgrade requests (the PS connection is already established and the PCU requests
for additional timeslots) are rejected in case of congestion.
9.4.2 Resource re-allocator

The Resource Re-allocator is responsible for the periodic reorganization of the radio
channel allocations, in order to optimize the resource usage, and can be configured
according to the user preferences. This kind of “resource reworking” is triggered each
time an internal timer expires; the value of the timer parameter is between 0.4 and 0.8 s;
this timer is not set by the user.
The resource re-allocation process is executed on already active calls, and it includes
three types of reorganization:
– Moving of speech and single slot data calls from the current TRX to the preferred
TRX
– Upgrading of HSCSD calls
– Pairing of unpaired Half Rate channels
These reorganization types are described in the following topics.
Moving of speech and single data calls from the current TRX to the preferred TRX
When the internal timer expires, the BSC examines the priority of the layer, in which a
call is active, in the related Service Layer List. If the current layer is not the first one (the
best one) in the Service Layer List, the BSC evaluates the possibility to move the call
onto a more preferred layer, i.e. onto a more preferred TRX. If such a re-allocation is
possible, it is performed via forced intra-cell handover. For each call not more than 2
intra-cell handovers will be performed to move it onto the preferred TRX (in case of Con-
centric and Dual Band cells the forced intra-cell handover is allowed only in the same
area (inner or complete)).
If a call has been allocated on a combined TCH/SDCCH, the moving procedure tries to
re-allocate the call on a TCH, even if the target channel belongs to a less preferred layer.
Upgrading of HSCSD calls

When the internal timer expires, the BSC checks, if there are active calls originally
requested for HSCSD service, but actually transmitted downgraded, i.e. with single slot
A50016-G5100-B556-04-7620 Id:0900d8058052e662 237

transmission. If downgraded HSCSD calls are running, the BSC tries to assign the initial
requested numbers of channels to the calls. First, additional channels and reuse of the
already allocated channel is tried, then a search on the whole Service Layer List is done.
In the latter case a re-allocation includes a forced intra-cell handover. If the original
request cannot be served at all, the upgrade is not executed.
Pairing of unpaired Half Rate channels

The procedure moves unpaired Half Rate TCHs to other unpaired Half Rate TCHs
(“Pairing”) thereby releasing Full Rate TCHs (for further information concerning the
pairing of Half Rate TCHs, please refer to 9.3.6 Enhanced pairing). When the resource
re-allocation procedure is started, the number of idle Full Rate TCHs is tested. If this
number is under a predefined threshold (defined by the user) and if there are at least
two Half Rate TCHs not paired, the pairing of the Half Rate TCHs is performed. This
includes a forced intra-cell handover.
Parameters
Moving of calls to the preferred TRX and upgrading of HSCSD calls is enabled by setting
the EMPROSDCA (“enableMovingProcedureSDCA”) attribute to TRUE.
Since the processes require forced intra-cell handovers, this handover type has to be
enabled, i.e. the ENFOIAHO attribute (“enableForcedIntracellHo”) must be set to TRUE.
For the parameters related to Enhanced Pairing, please refer to chap. 9.3.6 Enhanced
pairing.
9.4.3 Waiting list manager

The Waiting List Manager is responsible for the management of the requests in the
Waiting List (the requests which could not be assigned an appropriate resource to imme-
diately and which could not be put in the normal queue). The manager is activated by a
timer.
g The Waiting List is different from the Queuing List managed by the Queuing proce-
dure, see chap. 9.3.3 Queueing; accordingly the Waiting List Management is differ-
ent from Queuing.
In case new free resources become available, the pending requests in the usual
Queuing List (related to Queuing) have priority over the requests in the Waiting List.
So the BSC first tries to allocate resources for requests in the Queuing List. After
that or if the Queuing List is empty, the Waiting List Manager becomes active and
acts on the requests in the Waiting List.
To summarize, the following GPRS/EGPRS calls are put in the Waiting List:
a) GPRS/EGPRS requests that arrive when the cell is congested and no GPRS calls
are present in the cell; these calls are downgraded to one timeslot before being
inserted in the Waiting List;
b) GPRS requests that arrive when other calls are present in the Waiting List or in the
Queuing List (related to the Queuing procedure);
c) GPRS requests that must wait for intra-cell handovers.
CS requests are put in the Waiting List under the following conditions:
a) The BTS is congested, the request can not be satisfied (even not with Preemption
and Directed Retry) and Queuing is not enabled or not allowed (QA = 0 in the “Pri-
ority” Information Element).
238 Id:0900d8058052e662 A50016-G5100-B556-04-7620

b) No Abis resources are available in the BTSM that manages the BTS.
c) The BTS is not congested and the Waiting List is not empty.
The Waiting List Manager can perform the following actions:
1. Use of the resources released by the Resource Re-allocator;
2. Forced downgrade of empty packet resources in order to free resources for the
queued request
3. Forced downgrades of already established HSCSD multislot calls to release
resources for the pendent requests in the Waiting List
4. Forced downgrades of already established PS multislot calls to release resources
for pendent CS requests in the Waiting List; such downgrades are not done to free
resources for incoming GPRS/EGPRS calls.
5. Forced intra-cell handovers of already established CS calls in order to free timeslots
for GPRS requests
In case a resource request can be satisfied by the actions described above, the found
resource is allocated.
Waiting List Management also includes the application of the allocation retention priority
feature, see 9.3.5 Preemption and priority concept for packet switched calls.
Forced intra-cell handover must be enabled by setting the ENFOIAHO (“enableForced-
IntracellHo“) attribute related to the BSC object to TRUE. The downgrade strategy can
be configured according to the needs of the operator (see 9.3.4 Downgrading).
9.5 DMA admission control

DMA Admission Control provides a mechanism for blocking of resources in the DMA
layer (DMA: Dynamic MAIO Allocation), when the traffic load is high and an unaccept-
able decrease of transmission quality is expected, if more calls would be accepted.
Thereby resources can be blocked even though there are still free resources. This
behaviour is called soft blocking (while hard blocking means that call requests are
blocked only if there are no free resources).
DMA Admission Control is applied in case Dynamic MAIO Allocation (see chap.
Dynamic MAIO Allocation) is enabled, both in single band and dual band networks and
to CS speech calls only (e.g. EFR, FR, HR, AMR FR, and AMR HR). Usually DMA and
DMA Admission Control refers to high capacity networks with a high number of TRXs
installed in each cell, a small number of available frequencies on the site and the reuse
of the same frequencies in the cells and hopping TRXs. In such a network in case of high
traffic load the interference level caused by direct neighbour cells may become critical
before all channels have been allocated.
The DMA Admission Control includes forced intra-cell handovers in respect of the re-
organization procedure for moving the request to the preferred layer and for enhanced
pairing purpose. All the other types of handovers (e.g. handovers requested by the
BTS/MSC, (not-)imperative handovers) are not concerned.
The benefit of the DMA access control feature is achieving maximum capacity at an
acceptable quality based on continuous supervising of both the system load and the
speech quality in the cell. Moreover it enables the possibility to control the perceivable
quality in the network by adjusting the relevant thresholds. This fact is very important for
the network operation, network planning, network optimization and customer care.
A50016-G5100-B556-04-7620 Id:0900d8058052e662 239

DMA Admission Control is not implemented for both Dual Band and Single Band con-
centric cells, as well as for extended cells, since DMA has not been foreseen for those
types of cells.
Calculation of the soft blocking limits

The soft blocking limit depends on a Bad Quality Probability (BQP) criterion and on the
Effective Fractional Load (EFL).
• The Bad Quality Probability Criterion is evaluated as follows:
1. The BTS gathers the Frame Erasure Rates (FERs) for speech samples.
The scanning procedure is applied on all the busy speech channels of all the
TRXs on the DMA layer with enabled DMA Admission Control. The speech
samples usually comprise 4 SACCH periods (4 · 480 ms), due to the bursty
nature of FER occurrence. A longer sampling period would result in a BQP value
associated with a worse speech quality.
2. The BQP is calculated as the percentage (probability) of speech samples with
FER (Frame Erasure Rate) over a user defined threshold (expressed in %). If
the threshold is set appropriately (e.g. 5 %), the speech sample shows a bad
speech quality.
3. The mean BQP is calculated by averaging BQP values over a certain time inter-
val.
4. The mean BQP is compared with a user defined threshold (expressed in %). If
the mean BQP exceeds the threshold, the soft blocking limit is reached and the
Soft Blocking Qualifier SBQ is set to TRUE (otherwise SBQ is set to FALSE).
Different BQP values regarding the uplink and downlink direction can be calculated
depending on the Admission Control Link Type (parameter ACLNKTYP), configu-
rable by the user: Either UL and DL samples are collected and evaluated separately
or UL and DL samples are merged and commonly evaluated or only UL samples are
collected and evaluated.
The SBQ value is forwarded to the soft blocking decision part, see below.
• Effective Fractional Load (EFL) criterion:
The Effective Fractional Load EFL represents the 'Traffic volume (Erlang) per
hopping frequency' and is calculated by the following formula:
EFLDMA [%] = 100 · (Mean number of busy TCH on DMA layer) / (8 · Total number
of hopping frequencies on DMA layer)
Then the EFLDMA value is compared with a user defined threshold (expressed in %).
If the EFLDMA value exceeds the threshold, the soft blocking limit is reached.
Example for blocking limit estimations regarding traffic volume:
Assuming we have a QoS with 2% blocking and an offered traffic of 30 Erlang, the
Erlang-B table tells us that 39 channels are necessary. Each TRX installed in a radio
cell provides 8 FR (Full Rate) or 16 HR (Half Rate) channels. Assuming that only FR
channels are used and taking into account 3 channels for signaling the minimum
required number of TRXs is 6. The cell is to be equipped with 48 channels because
of the granularity of 8 channels per TRX instead of the required 39 + 3 = 42 chan-
nels. Thus, in terms of hard blocking the actually installed capacity is 35.6 Erlang,
which means that increasing traffic up to this level would not violate the QoS of 2%
blocking.
The BTS performs the evaluation of the parameters for DMA Admission Control for each
DMA layer configured in the cell.
240 Id:0900d8058052e662 A50016-G5100-B556-04-7620

Blocking decision
The admission control decision algorithm in the BTS checks the EFL and SBQ (BQP)
conditions as indicated in the table:
Effective fractional load Soft blocking qualifier

SBQ = FALSE SBQ = TRUE
EFLDMA ≤ min_EFLDMA Call request is admitted independent of the SBQ value
EFLDMA ≤ DMA layer is not soft- DMA layer is soft-blocked
max_EFLDMA blocked
EFLDMA > max_EFLDMA Call request is rejected independent of the SBQ value
Table 37 Soft blocking decision
Explanations:
– If the EFL is lower than or equal to the configurable minimum EFL threshold, the new
call setup on the DMA layer is admitted in any case.
– If the EFL is higher than the configurable maximum EFL threshold, the new call
setup on the DMA layer is rejected in any case.
– If the EFL is lower than or equal to the configurable maximum EFL threshold but
higher than the minimum EFL threshold, the new call setup on the DMA layer is only
allowed if the BQP (SBQ) criterion is fulfilled.
The soft blocking decision is forwarded via the soft blocking flag.
TCH allocation with DMA Admission Control

When the BSC receives a TCH request during a call setup procedure for a particular
DMA layer, it checks the received soft blocking flag for the affected DMA layer. If the pre-
ferred DMA layer is soft-blocked – indicated by the soft blocking flag –, the TCH request
is not served on the preferred DMA layer. Then the following actions are performed:
The BSC attempts to allocate a TCH on a different service layer where speech is
allowed.
If the BSC either does not find any other service layer supporting speech services or if
it finds a suitable layer but no suitable TCH, the request is not rejected, but the usual
procedures for handling congestion situations are applied (preemption, directed retry,
queuing, downgrade).
Further actions by the BSC (if necessary) follow the usual Resource Allocation and Re-
Allocation process; forced intra-cell handovers for moving the request to the preferred
layer and for enhanced pairing purpose is included. As long as no (first) message has
been received at all from a particular cell, the BSC assumes that the cell is able to accept
new calls on the DMA layer. Whenever the BSC receives an ADMISSION CONTROL
message containing “invalid information”, the currently valid BSC information is used.
DMA Admission Control information from the BSC

The BSC sends the SET ATTRIBUTE Abis message to the BTS which has to be
informed about the DMA Admission Control feature. This message includes the follow-
ing attribute:
• “DmaCFHSyId”: This attribute specifies, whether the DMA is used on that particular
TRX, and indicates the associated frequency hopping system.
A50016-G5100-B556-04-7620 Id:0900d8058052e662 241

– “DmaCFHSyId” = CFHSY0: DMA is enabled and the frequency hopping system

CFHSY0 is used (see chap. Configuring frequency hopping);
– “DmaCFHSyId” = CFHSY1: DMA is enabled and the frequency hopping system
CFHSY1 is used (see Configuring frequency hopping)
DMA Admission Control information from the BTS

The BTS periodically (in time intervals equal to the sampling period) reports the Admis-
sion Control evaluation results to the BSC via the ADMISSION CONTROL message.
This message comprises the following data:
– “DmaCFHSyId”: indicating, if DMA is enabled and which frequency hopping system
is applied; Values CFHSY0 and/or CFHSY1
In an EXT900 and Dual Band Standard Cell with DMA enabled on both hopping
systems CFHSY0 and CFHSY1, the BTS sends to the BSC only one single ADMIS-
SION CONTROL message containing information for CFHSY0 and/or CFHSY1.
– “enableSoftBlocking”: Values FALSE or TRUE
– “mean_BQP_UL”: The Bad Quality Probability in uplink direction [%];
– “mean_BQP_DL”: The Bad Quality Probability in downlink direction [%];
– “mean_BQP_UD”: The Bad Quality Probability in UL&DL direction [%];
– “EFL_DMA”: The Effective Fractional Load on the DMA Layer of the cell [%].
The valid value range of the parameters “mean_BQP_UL”, “mean_BQP_DL”,
“mean_BQP_UD” and “EFL_DMA” reach from 0% to 100% and they are provided with
an accuracy of 2 decimal digits. These values are mapped on integer values
[0…10 000], for example 555 representing 5.55%. If there is no information available at
all by the end of the Admission Control Period, the ADMISSION CONTROL message is
sent to BSC or it is filled with “invalid values”.
Attributes
DMA Admission Control is enabled/disabled by the EAC (“enableAc“) attribute.
The following thresholds can be set:
– ACFERMAX: Admission Control FER max, this attribute determines the maximum
FER value which is used for the calculation of the BQP value [in %]
– ACBQPMAX: Admission Control BQP max, this attribute defines the maximum tol-
erated BQP in a DMA layer [in %]
– ACMAXEFLDMA: Admission Control maximum EFL on DMA, this attribute the
maximum EFL on the DMA layer of a cell [in %]
– ACMINEFLDMA: Admission Control minimum EFL on DMA, this attribute the
minimum EFL on the DMA layer of a cell [in %]
The ACLNKTYP (“acLinkType“, Admission Control Link Type) attribute determines
which samples are used for the BQP calculations.
242 Id:0900d8058052e662 A50016-G5100-B556-04-7620

Radio network management GPRS radio channel management
10 GPRS radio channel management

g GSM and (E)GPRS share the same general radio channel allocation strategy which
is described in the section Radio channel allocation. This chapter contains detailed
descriptions of additional and special (E)GPRS features.
Chap. 10.1 Horizontal and vertical allocation and 10.2 Dual carrier in downlink direction
introduce the general strategies used to distribute (E)GPRS calls on the available radio
resources.
Chap. 10.3 (E)GPRS radio resource allocation is the main part of this section and
describes the basic mechanisms for allocation of GPRS radio resources.
Chapter 10.4.1 Improved downlink resources allocation and 10.4.2 Uplink balanc-
ing/unbalancing describe additional features of GPRS radio resource management.
10.1 Horizontal and vertical allocation

A PS connection between a MS and a BTS can require more than one PDCH/timeslot
and different connections (for different MSs) can be multiplexed on the same
PDCHs/timeslots if the minimum transmission rate requirements are satisfied: One
timeslot can transmit 50 radio blocks per second. So, if a data call requires that e.g. 20
radio blocks are transmitted per second and if a timeslot is already partly occupied by
another data call requiring 25 radio blocks per second, both calls can be multiplexed on
this timeslot.
Safety Margin
50 Radio Blocks per second
Free Capacity
Used Capacity
TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
Figure 98 Capacity of GPRS PDCHs/timeslots

The BSC provides two different allocation strategies to assign packet switched data
channels:
• Vertical Allocation (VA): Before assigning a new slot to the GPRS/EGPRS service,
the already used slots are filled as much as possible (which means multiplexing of
TBFs on the same timeslots).
• Horizontal Allocation (HA): The incoming GPRS/EGPRS calls are distributed on all
the available PDCH channels.
The BSC switches from Horizontal Allocation to Vertical Allocation in case of high traffic
load in the cell and congestion in order to serve as much (E)GPRS requests as possible;
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 243

GPRS radio channel management Radio network management
vice versa the BSC switches from Horizontal Allocation to Vertical Allocation in case of
low traffic load in order to maximize the throughput. The switching points from VA to HA
and vice versa depend on the special configuration and on the availability of both the
Abis and radio resources (see chap. 10.1.3).
10.1.1 Vertical allocation (VA)

With the Vertical Allocation (VA) algorithm the maximum number of Mobile Stations is
multiplexed on each GPRS/EGPRS channel, before assigning a new PDCH.
Additionally the BSC tries to multiplex, in a fair way, the mobile requests, using “flat dis-
tribution”: The requests are spread on all the already assigned timeslots, on all the
TRXs. Flat distribution leads to better system performances in terms of TBF throughput.
Example
If two Mobile Stations (with multislot capability) perform 3 DL + 1 UL GPRS/EGPRS
calls, the BSC assigns them the timeslots number 2, 3 and 4. In this way, timeslots from
5 to 7 remain free, because the BSC multiplexes the 2 mobiles on the same 3 PDCHs,
as represented in Figure 99 (without flat distribution all the 3 Mobile Stations would be
multiplexed in the same timeslot).
BCCH TRX bcch sdcch
MS1DL MS1DL MS1DL

MS1UL
MS2DL MS2DL MS2DL

MS2UL
Figure 99 Example of vertical allocation strategy
10.1.2 Horizontal allocation (HA)

The Horizontal Allocation (HA) algorithm distributes the incoming GPRS/EGPRS calls
on all the available PDCHs. In this way not too many Mobile Stations are multiplexed on
the same PDCH increasing the data transfer throughput for all the involved Mobile Sta-
tions.
When a new request for PDCHs arrives at the BSC and many radio channels for sup-
porting the GPRS service are available (empty), the BSC assigns new radio channels
to the GPRS/EGPRS mobiles instead of increasing the number of mobiles multiplexed
on the already busy channels.
Example
If two Mobile Stations perform 3 DL + 1 UL GPRS/EGPRS calls, the BSC assigns
timeslots number 2, 3 and 4 to the first call, then the timeslots number 5, 6 and 7 to the
second call.
In this way each timeslot is used for a lower number of calls and the throughput is better
than for the vertical allocation strategy, as represented in Figure 100.
244 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

BCCH TRX bcch sdcch
MS1DL MS1DL MS1DL MS2DL MS2DL MS2DL

MS1UL MS2UL
Figure 100 Example of the horizontal allocation algorithm
10.1.3 Switching between vertical and horizontal allocation

The BSC switches from Horizontal Allocation to Vertical Allocation in case of high traffic
load in the cell and congestion in order to serve as much (E)GPRS requests as possible;
vice versa the BSC switches from Vertical Allocation to Horizontal Allocation in case of
low traffic load in order to maximize the throughput. The switching points from VA to HA
and vice versa depend on the special configuration and on the availability of both the
Abis and radio resources
Most of the following descriptions refer to the radio interface only; for completeness the
relations to the Abis conditions and the availability of PDTs at the PCU are included (a
PDT is the equivalent of an Abis timeslot at the PCU).
Calculations for the switching decision

The percentage of idle channels not statically reserved for PS services or for signalling
in the whole cell together with two user defined threshold values determine the switching
from one allocation type to the other. If the calculated percentage of idle slots exceeds
the upper threshold value, the system switches from vertical to horizontal allocation;
else if the calculated percentage of idle slots is lower than the lower threshold value, the
system switches from Horizontal to Vertical Allocation (the current allocation type is kept
when the percentage of idle slots lies between the two threshold values). The percent-
age of idle slots in the cell is calculated with respect to the number of available channels
in the cell; slots containing GSM signalling, such as BCCH or SDCCHs slots, and also
slots statically reserved to GPRS/EGPRS are not considered.
Formulas:
Percentage of idle channels = Idle channels / Available channels
with:
Available channels = Total number of configured channels – Number of OUT OF
SERVICE channels – Number of GPRS/EGPRS static channels – Number of GSM sig-
nalling channels
The evaluated percentage value is truncated, so the decimals are not taken into
account. If e.g the percentage of idle channels in the cell is calculated as 10.9%, then
the value compared with the user defined thresholds is 10% and not 11%.
g A switching from horizontal to vertical allocation also takes place when the number
of channels assigned to the GPRS/EGPRS users reaches the overall number of
channels configured for the PS services.
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 245

Attributes related to the radio conditions

The following attributes belonging to the PTPPKF Managed Object contribute to the
switching between VA and HA:
• The attribute GASTRTH (“gprsAllocationStrategyThresholds”) manages the follow-
ing thresholds used to activate the Horizontal/Vertical Allocation:
– “ThresholdIdleChannelHV”: triggers the switching from the Horizontal Allocation
to the Vertical Allocation;
– “ThresholdIdleChannelVH”: triggers the switching from the Vertical Allocation to
the Horizontal Allocation.
– ThresholdIdleChanEU”; this field defines the threshold above which the upgrad-
ing of radio resources (see chap. 10.3.6 Upgrade of radio resources) is enabled.
ThresholdIdleChanHV has to be lower than ThresholdIdleChanVH,
ThresholdIdleChanVH has to be lower than or equal to ThresholdIdleChanEU.
The difference between the two thresholds should not be too high. Otherwise it could
happen that, when the Vertical Allocation (VA) is used, a return back to the Horizon-
tal Allocation (HA) is applied only when the cell is completely idle, and this is not a
real hysteresis behavior.
The difference between the two thresholds should not be too small in order to avoid
frequent changes between Horizontal and Vertical Allocation.
• The maximum numbers of statically reserved PDCHs are taken into account by the
attributes:
– GMANPRESPRM (“gprsMaxNumberPDCHResPrimary”)
– GMANPRESCOM (“gprsMaxNumberPDCHResComplementary”)
– EMANPRESPRM (“edgeMaxNumberPDCHResPrimary”)
– EMANPRESCOM (“edgeMaxNumberPDCHResComplementary”)
• The percentage of dynamically available PDCHs is taken into account by:
GPDPDTCHA (“gprsPercentageOfDynamicPdtchAvailable”)
Example
A cell with 5 configured TRXs is configured as follows (see Figure 101):
GDCH = GDCH =
PBCCH PCCCH
PBCCH+ Configured for

TRX:0 BCCH SDCCH PS/CS PS/CS PCCCH PS/CS PS/CS
PCCCH CS/PS service
Configured for
TRX:1 SDCCH CS CS CS CS CS CS CS
CS service only
Configured for
CS/PS service
Configured for
CS/PS service
Configured
TRX:4 PS PS PS PS PS PS PS PS
for GPRS only
TS 0 TS 1 TS 2 TS 3 TS 4 TS 5 TS 6 TS 7
Figure 101 Example of a cell configured with five TRXs
246 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

• TRX:0 contains 4 shared channels allocatable as PDCHs; the GSM signalling

channels BCCH and SDCCH as well as the statically reserved 2 PCCCHs do not
contribute to the number of channels allocatable as PDCHs.
• TRX:1 does not support GPRS/EGPRS.
• TRX:2 and TRX:3 support GPRS/EGPRS.
• TRX:4 is reserved for GPRS/EGPRS usage exclusively and does not contribute to
the percentage of idle channels.
• The thresholds of the GASTRTH attribute are set as follows:
– “ThresholdIdleChannelHV” = 30%, for the change from HA to VA;
– “ThresholdIdleChannelVH” = 40%, for the change from VA to HA.
Each timeslot for a traffic channel is counted as 2 as if it is used in half rate (HR) mode.
So there are (4 + 7 + 8 + 8 + 8) · 2 = 70 HR traffic channels. From these 70 HR channels
16 which are statically reserved for (E)GPRS are subtracted, so 54 HR channels remain
as available channels.
• If Vertical Allocation is currently applied, the system switches to Horizontal Alloca-
tion when the number of idle channels increases and reaches the value 22:
Idle channels / Available channels > 0.40 –> Idle channels > 21.6.
• If Horizontal Allocation is currently applied, the system switches to Vertical Alloca-
tion when the number of idle channels decreases and reaches the value 16:
Idle channels / Available channels < 0.30 –> Idle channels < 16.2.
Switching between vertical allocation and horizontal allocation in relation to the

Abis interface
Considering the Abis interface the following two thresholds related to the Horizontal and
Vertical Allocation have been introduced:
• “thresholdIdleAbisHV”: Defines the percentage of idle Abis subslots of the BTSM
(over the available Abis subslots of the BTSM) under which the Vertical Allocation is
activated on the radio interface. The Vertical Allocation activation is useful for re-use
of the already allocated Abis subslots, slowing down the allocation of new Abis
resources.
• “thresholdIdleAbisVH”: Defines the percentage of idle Abis subslots of the BTSM
(over the available Abis subslots of the BTSM) over which the Horizontal Allocation
is activated on the radio interface – if the thresholds on the radio resources (on a cell
basis) allow that.
The user can set these thresholds configuring the attribute GASTRABISTH (“gprsAllo-
cationStrategyAbisThresholds”) of the BTSM Managed Object.
The thresholds have to satify the relationship:
“ThresholdIdleAbisHV” < “ThresholdIdleAbisVH”
Dependencies on the availability of PDTs on the PCU

The switching to the Vertical or Horizontal Allocation is also driven by the availabil-
ity/unavailability of PDTs on the PCU (with the BSC/72, BSC/120 the maximum number
of GPRS channels manageable by the single PCU, for example the maximum number
of PDT manageable by the single PCU, is fixed to 256):
– In case the percentage of busy PDTs on a PCU is 100%, then the VA is applied.
– In case the percentage of busy PDTs on a PCU is less than 100%, then the alloca-
tion type (HA/VA) is determined by the GASTRTH and GASTRABISTH thresholds.
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 247

Summary
In cells belonging to a BTSM with Dynamic Abis Management, the following situations
are possible during the allocation of radio resources, according to different contexts:
a) Horizontal Allocation in a cell is used if at the same time the following conditions are
verified:
– There is no radio scarcity in the cell, for example the percentage of idle air
timeslots in the cell is greater than the “ThresholdIdleChannelHV” field of the
GASTRTH attribute.
– There is no Abis resources scarcity, for example the percentage of idle Abis
subslots of the BTSM managing the cell is greater than the “thresholdIdleA-
bisHV” field of the GASTRABISTH attribute.
– There is no PDT exhaustion for the PCU which manages the cell.
b) Starting from the Horizontal Allocation, if there is radio scarcity, for example the per-
centage of idle air timeslots in the cell becomes lower than the “ThresholdIdleChan-
nelHV” field of the attribute GASTRTH, then the Vertical Allocation is triggered.
c) Starting from Horizontal Allocation, if there is Abis scarcity, e.g. the percentage of
idle Abis subslots in the BTSM becomes lower than the “ThresholdIdleAbisHV” field
of the attribute GASTRABISTH, then the Vertical Allocation is triggered; the PCUs
that are handling the cells belonging to the impacted BTSM are informed.
d) Starting from the Horizontal Allocation, if there is PDT exhaustion in the PCU, then
the Vertical Allocation is triggered.
e) If the Vertical Allocation is applied in the cell due to radio scarcity only and the per-
centage of idle radio slots in the cell becomes greater than the “ThresholdIdleChan-
nelVH” field of the GASTRTH parameter, then Horizontal Allocation is triggered.
f) If the Vertical Allocation is applied in the cell due to Abis scarcity only and the per-
centage of idle Abis subslots in the BTSM exceeds the “ThresholdIdleAbisVH” value
of the GASTRABISTH attribute, then the Horizontal Allocation is triggered; the PCUs
that are assigned to cells belonging to the impacted BTSM are informed.
The allocation strategy is supported by the TDPC (Telephony and Distributor Processor
Card in BSC1; AP in the eBSC). The TDPC informs the PCU about the used strategy
via the allocation flag (Horizontal/Vertical Allocation). This flag is updated each time the
TDPC replies to the PCU requests for resources.
To avoid possible misalignment between the TDPC and the PCU, as regards the allo-
cation flag, a mechanism has been implemented for which an audit, running every 10 s
for each equipped PCU being in service, is sent to communicate to the PCU the current
allocation strategy used on TDPC side.
10.2 Dual carrier in downlink direction

When deploying EDGE, it is possible to allocate physical radio channels for the downlink
transmission for a single TBF (temporary block flow) on two different TRXs / carrier units
which have different carrier frequencies and are capable of EDGE. Thereby the number
of timeslots allocated for one TBF in downlink direction and consequently the downlink
transmission rate can be increased compared to the usual allocation of physical
channels on one TRX. Also the flexibility in timeslot allocation is improved, e.g. if a
requested DL bandwidth is not available on one TRX, the bandwidth can be available
combining the free resources of two TRXs.
248 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

The two branches of the split TBF point to the same TFI (temporary flow identity).
Regarding the uplink direction, the MS does not transmit when receiving, and timeslots
for uplink transmission are allocated on one of the two carriers only.
A maximum numer of 12 timeslots can be allocated in downlink direction (depending on
the multislot capabilities of the MSs, of course). Allocation of two carriers in downlink
direction for one TBF is supported by BSC1 and eBSC.
Figure 102 shows an example of a dual carrier allocation with two assigned DL timeslots
on carrier 1 and one on carrier 2; one timeslot is allocated in uplink direction.
Downlink: 3 allocated timeslots
TDMA frame N TDMA frame N+1
TRX:1 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
TRX:2 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 downlink
3 timeslots delay
Uplink: 1 allocated timeslot
TDMA frame N TDMA frame N+1
TRX:1 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
uplink
Figure 102 Dual carrier allocation in downlink direction (example)

The following allocation rules are applied for each MS to be engaged in a dual carrier
connection:
1. In downlink direction different timeslots on the two carriers are preferred, but the
same timeslots on the two carriers are also allowed.
2. Uplink timeslots are allocated completely on carrier 1 or completely on carrier 2, but
not on both carriers at the same time (once the carrier for uplink allocation has been
selected, no subsequent alteration from one carrier to the other is provided).
3. An uplink physical channel (on carrier 1 or carrier 2) can only be allocated on an
uplink timeslot which does not overlap with an allocated downlink timeslot (no simul-
taneous transmission in both direction). The UL TDMA frames are delayed by 3
timeslots relative to the DL TDMA frames. so if e.g. timeslot 5 on carrier 2 is allo-
cated in downlink direction, then timeslot 2 is forbidden for uplink allocation both on
carrier 1 and carrier 2.
4. If there is a gap of one or several timeslots between the allocated DL timeslots on
the two carriers, no UL timeslot within the gap is allocated. This avoids unnecessary
switches from DL transmission to reception and back. If e.g. timeslots 1 and 2 on
carrier 1 and timeslot 5 on carrier 2 are allocated in downlink direction, then timeslot
1 is not allocated for uplink transmission (the 3 timeslots delay of the UL transmis-
sion is taken into account).
Attributes and configuration

• EDLDC (“enableDLDC”): This attribute subordinate to the BSC managed object
allows to generally enable/disable the support of dual carrier in downlink direction.
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 249

• EDC (“enableDualCarrier”): This attribute subordinate to the PTPPKF managed

object allows to enable/disable the support of dual carrier in downlink direction on
cell level.
10.3 (E)GPRS radio resource allocation

General GPRS/EGPRS channel allocation principles
A cell supporting GPRS/EGPRS may allocate resources on one or several physical
channels in order to support the packet switched data traffic. The physical channels
(PDCHs), shared by GPRS/EGPRS Mobile Stations, are taken from the common pool
of physical channels available in the cell. The allocation of physical channels is done
according to the following principles:
• Capacity on demand: GPRS/EGPRS does not require permanently allocated
PDCHs. The allocation of capacity for these services is based on the needs for the
packet transfers.
• Optimized allocation of radio resources: In case of low cell load the MS’s throughput
is maximized by preferrably allocating empty or idle PDCHs, in case of high cell load
as many user requests are served as possible by multiplexing as many MSs on the
same PDCHs as possible.
Dynamic re-allocation is provided regarding changing radio conditions.
• Guaranteeing Quality of Service: Different user applications (web browsing, stream-
ing services, real time audio, video conferences, and other real time applications
etc.) require specific transmission bitrates. The (E)GPRS channel allocation algo-
rithm searches for allocations serving the required throughput. A quality control unit
makes sure that the actual transmission rate is in line with the negotiated transmis-
sion rate according to QoS requirements; dynamic reallocation is provided.
• Contiguous timeslots: Regarding the BSC, allocations with contiguous timeslots
prevent a lot of allocations/releasings of timeslots; regarding the MS, allocation of
contiguous timeslots is a strategy to cope with the rules of GSM 05.02.
• EDGE/GPRS discrimination: The radio resources allocation algorithm takes into
account the availability of EGPRS service and the presence of EDGE capable
mobiles and TRXs. EDGE is preferrable if MS and TRX both support EDGE because
of higher data rates (even in case GPRS and EGPRS data rates are comparable,
better performance is expected with EGPRS due to specific retransmission rules
and incremental redundancy).
g The Radio Resource Management supports the Dual Transfer Mode, if enabled.
Entities of the (E)GPRS resource management and their basic functions
Figure 103 shows the main entities performing the Radio Resource Management. Addi-
tionally the interplay with the schedulers is shown.
• Admission Control is a starting point and prooves the feasibility of an allocation
request. If a request is feasible from the Admission Control view it is forwarded to
the Channel Allocation Algorithm.
• The Channel Allocation Algorithm (CAA) section is the heart of the resource man-
agement selecting appropriate resources and allocating the resources: CAA also
manages dynamic re-allocation of resources and takes into account Improved
downlink resources allocation and Uplink balancing/unbalancing.
250 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

• Link Adaptation dynamically changes the coding scheme and net transmission rate
and so influences the amount of required timeslost (see chap. Coding and transmis-
sion modes).
• The Service Dependent Channel Allocation unit provides the CAA with information
which TRXs are configured for (E)GPRS transmission (see chap. Radio channel
allocation).
• The Overheating Manager takes care that no multislot allocations are assigned
which could cause overheating in the MS.
• Allocation Retention Priority is a preemption mechanism for packet switched calls
and is applied in case of congestion.
• The Quality Control Function makes sure that the actual transmission rate is in line
with the negotiated transmission rate according to QoS requirements; dynamic real-
location is initiated in case of degradation of the transmission data rates.
• In case of multiplexing of different TBFs on one PDCH, the TBF scheduler distrib-
utes the radio blocks of the different TBFs according to their weights.
• The PFC Scheduler is described in chap. Coding and transmission modes.
• Considerations about Packet Flow Management exceed this manual.
Thus, the radio resource allocation proceeds from Admission Control to the Channel
Allocation Algorithm to the TBF Scheduler. The other entities mainly support the
Channel Allocation Algorithm.
2ADIO2ESOURCE-ANAGEMENT 3CHEDULER
0ACKET&LOW ,INK !DMISSION 0&#

-ANAGER !DAPTATION #ONTROL 3CHEDULER
#HANNEL
1UALITY
!LLOCATION 4"&
#ONTROL
!LGORITHM 3CHEDULER
&UNCTION
#!!
3ERVICE$EP !LLOCATION
/VERHEATING
#HANNEL 2ETENTION
-ANAGER
!LLOCATION 0RIORITY
Figure 103 Radio resource management entities and interplay with scheduler
The following sub-chapters describe the Admission Control for QoS requests, details of
the Channel Allocation Algorithm in connection to Admission Control, the TBF scheduler
and Overheating Management. For further comprehensive information about (E)GPRS
Resource Management please refer to the GPRS global description manual.
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 251

10.3.1 Admission control

The main task of Admission Control is to check the following for incoming realtime
service requests:
• Have the MS and the network sufficient capabilites to keep the transfer delay under
the requested value when transmitting/receiving with the required bitrate?
• Has the MS enough capacity to satisfy the required service?
(e.g. can the MS manage the requested guaranteed transmission rates (multislot
capability), and do other services, already running on the MS, leave enough capacity
for the requested service?)
Admission control also checks if both tasks can be satisfied simultaneously and if not
too many PFCs are already open. No reservation or pre-allocation of PDCHs is done by
Admission Control and the overall congestion situation of the cell is not considered.
In case the checks on the network’s and the MS’s capability and capacity have been
successful, the incoming service request is admitted and forwarded to the Channel Allo-
cation Algorithm. Otherwise the request is rejected and the Packet Flow Management
procedures can be started to re-negotiate the QoS parameters for the request.
The Admission Control mechanism has effect on realtime services only.
Details
The checks in the Admission Control take into account the QoS parameters in the ABQP
message of the PFC (Packet Flow Context), the Allocation Retention Priority parameter,
a reference C/I value, a reference coding scheme and the MS multislot class.
• Transfer delay regarding MS capabilities: The transfer delay depends on the coding
scheme, C/I (or BLER) and number of timeslots to be allocated for the required net
data bitrate. Taking a reference C/I, coding scheme, the required throughput and the
maximum allowed time delay, Admission control determines via a table the minimum
number of timeslots to be allocated. If the MS multislot class is compatible with this
minimum number of timeslots and required MS configurations are possible, the
request is passed, otherwise the request is rejected.
Example: Table 38 shows the transfer delays in dependency on BLER values and
numbers of timeslots (for a certain reference coding scheme (one table for each
scheme)). Assuming a BLER of 25 % on the radio path and with a maximum trans-
mission delay of 200 ms in the allocation request, the table indicates that 3 timeslots
are necessary.
BLER Number of timeslots

1 2 3 4
0% 100 ms 60 ms 40 ms 40 ms
10 % 250 ms 145 ms 110 ms 105 ms
20 % 280 ms 200 ms 130 ms 120 ms
30 % 380 ms 220 ms 160 ms 140 ms
40 % 500 ms 280 ms 200 ms 170 ms
Table 38 Transfer delays for selected BLER values and numbers of timeslots
252 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

• MS capacity: The algorithm calculates the minimum number of timeslots necessary

to satisfy the guaranteed (minimum) transmission rate to be guaranteed for the
service. The calculations are done for appropriate coding schemes and BLER rates,
and the results (i.e. the minimum timeslot numbers) are compared with the MS mul-
tislot capabilities again.
If a part of the MS capacity is already occupied by other services, the Admission
Control algorithm also checks if there is still enough free capacity for the MS regard-
ing the new request. Therefore the number of used radio blocks on each timeslot of
the TRX communicating with the MS is considered.
At last, Admission Control checks if the maximum number of PFCs manageable by the
system would exceed the maximum number.
Final reporting
In case the request has to be rejected, the Admission Control unit returns the Rejection
Reasons Capability report, which indicates the reason of rejection:
– Inability to fulfill transfer delay requirements
– Inability to fulfill bandwidth requirements
– Too many PFCs already open
In case the request is admitted, the Admission Control unit returns the Feasibility Con-
dition record which contains for all CS/MCS enabled the MS multislot configurations
compliant with the requested service and the minimum number of timeslots required.
These configurations can be used by the subsequent channel allocation algorithm.
10.3.2 Channel allocation algorithm

The details of the channel allocation algorithm (CAA) depend on the kind of request
(streaming TBF or not, re-allocation) and if a TBF has already been allocated for the MS.
For the sake of clarity the following description is focused on a new realtime TBF
request. Other cases can be viewed as simplifications or slight modifications of this
case.
CAA proceeds with the following main steps:
1. Selection of the service (EGPRS or GPRS)
2. Creation of a ranked list of possible MS configurations (i.e. number of DL/UL slots)
3. Creation of a list of possible TRX configurations for the best MS configuration (e.g.
absolute numbers of timeslots)
4. Ranking of the TRX configuration list
5. Selection of the best configuration and allocation of resources
If there are no appropriate resources for the best solution in the MS or TRX configuration
list, the next best MS solution is selected and so on.
Selection of the service

The EDGE capability of the MS is checked. If the MS has EDGE capability, EDGE
service is preferred to GPRS service. In this case the procedure checks if a EGPRS
Service Layer List is available in the cell/area and if at least one TRX is available to
support the EGPRS service, otherwise GPRS service is selected.
Creation of a ranked list of possible MS configurations

The following steps are executed:
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 253

1. The bitrates for the DL and the UL direction necessary to satisfy the request are
determined (i.e. the minimum transmission rates which have to be guaranteed).
Then the number of timeslots needed to achieve these bitrates is calculated taking
into account the modulation and coding scheme (MCS) to be used and a reference
block error rate (BLER), simplified formulas:
Guaranteed DL bitrate
Number of TS in DL = ----------------------------------------------------------------------------------------------------------------------------------------
Single TS bitrate MCS_DL_Ref ⋅ ( 1 – BLER DL_Ref )
Guaranteed UL bitrate
Number of TS in UL = ---------------------------------------------------------------------------------------------------------------------------------------
-
Single TS bitrate MCS_UL_Ref ⋅ ( 1 – BLER UL_Ref )
The values of the right sides of the equations are rounded to the upper integer.
g If Packet Flow Control (PFC) is switched off or if the MS does not support PFC,
the calculation of the required number of timeslots is done with the required peak
throughput instead of the guaranteed bitrate. Required peak throughput infor-
mation is usually set to “high values” independently from the requested applica-
tion, so more timeslots than required could be allocated in UL and even in DL
direction, which means a waste of resources.
2. The MS configurations providing at least the minimum DL and UL bitrates are taken
and ranked. More in detail, MS configurations mean numbers of timeslots and
timeslot combinations for DL and UL (e.g. 3 DL TSs + 2 UL TSs), and the configu-
rations the MS is capable of are taken from the MS multislot class mask. All MS con-
figurations fulfilling at least the minimum required (i.e. guaranteed) bitrate are
considered in the ranking step where the numbers of timeslots for UL and DL are
related to the required bitrates. This is done with a minimum square method; the
lower the value of the following expression, the higher is a configuration ranked:
(guar. DL bitrate – MS_conf. DL bitrate)2 + (guar. UL bitrate – MS_conf. UL bitrate)2
where “MS_conf. DL bitrate” is the number of DL timeslots of the MS configuration
multiplied with the bitrate of a single timeslot with the referenced DL MCS.
3. The ranked MS configurations, beginning with the best one, are stored in the
MS_Configuration_List.
4. The MS_Configuration_List is filtered: Improper configurations are removed regard-
ing EDA (Extended Dynamic Allocation) support and overheating.
Example:
A multislot class 33 Mobile Station requests a service with 64 kbit/s DL and 8 kbit/s UL
minimum bitrates.
The modulation and coding scheme MCS6 shall be applied in DL and UL resulting in a
DL and UL bitrate of 29.6 kbit/s. BLERDL_ref = BLERUL_ref = 0.1 shall be assumed and
only 95 % of a timeslot shall be allocateable keeping 5 % as safety margin.
Table 39 shows the MS Multislot Class 33 Mask. Only the MS configurations 5, 6, 7, 10,
11, 14 satisfy the bitrate requirements. Table 40 shows the MS_Configuration_List after
ranking.
254 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

MS multislot Number of Number of

class 33 mask DL timeslots UL timeslots
1 1 1
2 2 1
3 1 2
4 2 2
5 3 1
6 3 2
7 3 3
8 1 3
9 2 3
10 4 1
11 4 2
12 1 4
13 2 4
14 5 1
Table 39 Example of MS multislot class mask
MS configura- Number of Number of

tion list DL timeslots UL timeslots
5 3 1
10 4 1
6 3 2
11 4 2
14 5 1
7 3 3
Table 40 Example of MS configuration list
Creation of a list of possible TRX configurations

Here a TRX and timeslots of this TRX are searched which match a MS configuration.
The best ranked MS configuration is taken from the MS_Configuration_List.
Possible TRX resource allocations for this MS configuration are searched regarding the
related Service Layer List and the available radio blocks of the affected TRX.
The available radio blocks of a TRX are represented in terms of “weight” (see below).
The required minimum radio block transmission rate for the TBF to be allocated (and all
other TBFs) is also expressed with the help of its weight (“TBF weight”).
Weight:
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 255

The weight of a PDCH or a TBF is a number which is proportional to the number of radio
blocks per second allocated (PDCH) or guaranteed (TBF). A complete PDCH/timeslot
has a weight of 32 corresponding to a capacity of 50 radio blocks per second and
several TBFs can be multiplexed on a PDCH as long as the sum of the TBF weights
does not exceed 32 (other multiplexing restrictions are neglected here). The maximum
weight of a TBF is set to 32 according to the full capacity of one PDCH/timeslot (so, a
realtime service requiring a full timeslot should have a weight of 32 and no other TBF
will then be multiplexed on the same timeslot). A weight of 16 is associated with half of
the full capacity as minimum transmission rate and so on. If. e.g. two TBFs with weights
of 8 each are already multiplexed on a PDCH, then half of the capacity of the PDCH is
already reserved and the other half of the capacity can be used for multiplexing further
TBF(s) with maximum weight of 16 onto the PDCH (actually, as long as a third TBF is
not multiplexed on the PDCH, the two TBFs with weights of 8 get more radio blocks per
second as guaranteed, see 10.3.4 TBF scheduler).
TBFs for not-realtime services are related to low weights. Different weights can be
assigned via attributes in order to reflect a priority order.
Table 41 shows how different TBF weights correlate with minimum radio block transmis-
sion rates. In case a few radio blocks shall not be allocated in order to have a safety
margin, the minimum transmission rates are slightly reduced.
TBF weight Minimum transmission rate in radio

blocks per second (no safety margin)
1 1.56
2 3.12
4 6.25
8 12.5
16 25
Table 41 Minimum transmission rates for selected TBF weights
All sufficient allocation possibilities are stored in the Allocation_List.
Ranking of the TRX configuration list and allocation

The Allocation_List is sorted according to the allocation criteria described below.
1. Maximize the throughput of the TBF.
2. Maximize the reuse of pre-allocated channels.
3. In case of Vertical Allocation mode minimize the number of idle timeslots.
(The order of step 2. and step 3. can be changed by setting a flag.)
4. Minimize the overall weights of the affected PDCHs.
5. If the TBF requests EGPRS service, do not prefer EDGE BCCH TRXs when this
TRX only supports GMSK modulation.
6. If the allocation requires some new timeslots, then maximize the number of adjacent
GPRS timeslots.
The best ranked solution of the Allocation_List is allocated. If the Allocation_List is
empty, the next MS configuration is taken from the MS_Configuration_List and the pro-
cedure goes on with the creation of a new Allocation_List for this MS configuration.
Remarks:
256 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

Pre-allocated channels (step 2.) are the channels still in packet transfer mode (due to
delayed release of physical channels) after the last related TBF has been released.
These are the channels for which the TEMPCH timer is running and has not expired.
Step 2. and step 3. are necessary if step 1. leads to several suggestions differing in the
type of empty channels (pre-allocated for (E)GPRS or idle).
Step 4. leads to a balanced distribution of the weights of the affected PDCHs. With min-
imized weights the single TBFs can get more radio blocks per second than the required
minimum transmission rate (see 10.3.4 TBF scheduler).
Figure 104 illustrates main lines of the channel allocation algorithm after the
MS_Configuration_List has been created.
MS Configuration N
available in
MS_Configuration_List ?
Get the MS Configuration (Concurrent) TBF

from the top of the already established?
MS_Configuration_List
Y N
Remove Determine all possible

MS Configuration from allocations for MS configuration
N
MS_Configuration_List with Service Layer List and with Service = EGPRS ?
free TRX capacity and store
these in the Allocation_List
Y
Set Service = GPRS
Y
Empty Allocation_List ? ARP Algorithm ?
N
to service selection block
Rank Allocation_List
according to Y N
allocation criteria
Select the Allocation Retention New allocation

best allocation Priority Algorithm not accomplished
Figure 104 Flow diagram of the second part of the channel allocation algorithm
There is no guarantee that the initial target throughput is really achieved by the selected
allocation solution because the actual throughput depends on several factors: radio con-
ditions, C/I, Link Adaptation, multiplexing factor, availability of Abis and PDT resources,
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 257

etc. In particular, in cases of Abis/PDT resources scarcity it is not guaranteed that the
resource assignment will result in the best solution in terms of throughput.
Special situations and examples:
• When the initial throughput (depending on BLER and CS/MCS) per PDCH on GPRS
TRXs is slightly better than the initial throughput requirement per PDCH on EDGE
TRXs, solutions allocating N radio resources on EDGE TRXs are preferred to solu-
tions allocating also N radio resources on GPRS TRXs, because better perfor-
mances are expected from EGPRS specific retransmission rules and incremental
redundancy. This situation can occur, for example, when the MCS and CS used are
homologous (e.g. CS4/MCS4).
For example, 3 radio timeslots in EGPRS TBF mode are preferable to 3 radio
timeslots in GPRS mode, in case the initial MCS in the cell is MCS4 (data rate 17.6
kbit/s) and the initial GPRS CS in the cell is CS4 (data rate 20.8 kbit/s).
• For an EGPRS TBF, when the multislot capability of a mobile is high, and if the radio
resources are insufficient on EDGE TRXs and available on non-EDGE TRXs, a non-
EDGE TRX could be preferable. In fact the most important criteria in the radio
resource research is trying to maximize the throughput.
Example: It is considered a request at the BSC for establishing a TBF with the fol-
lowing characteristics:
Required throughput = 80 kbit/s, multislot capability = 4 timeslots
The BSC finds two solutions; the first using 2 timeslots on an EDGE TRX with MCS9,
the second using 4 timeslots on a non EDGE TRX with CS4.
The best solution is to allocate 2 radio timeslots on the EDGE TRX, because the
throughput is supported with the minimum number of radio resources.
• The calculation and allocation of the required number of timeslots refers to data
transmission (for user applications), but the allocated channels are used for signal-
ling, too. This usually means a waste of radio resources on air interface during sig-
nalling which requires only a small amount of data to be transmitted. Therefor the
number of timeslots allocated in the signalling phase before beginning the user data
transmission can be restricted to 1 timeslot which is done with the ESTSGMMSM
(“enableSingleTSForGMMAndSM”) attribute. Here, “signalling phase” refers to both
GPRS Mobility Management and Session Management.
10.3.3 Background: Interplay between PCU and TDPC

The radio resource assignment to a Mobile Station requiring an uplink or a downlink TBF
establishment is performed under BSC control, through the co-operation between the
PCU (Packet Control Unit, realized by PPXU in the BSC1, by UPM in the eBSC) and the
TDPC (Telephony and Distributor Processor Card in the BSC1; functionality located in
the AP in the eBSC).
For simplicity, in the following, the term TDPC is used for both BSC1 and eBSC.
General rules for resource assignment:
– The PCU is the starting point for the (E)GPRS resource management. The TDPC
takes over the request only in case the PCU cannot complete it and finishes the allo-
cation (if possible). The PCU gets the result of the TDPC’s actions; if the TDPC could
not allocate (enough) resources, the PCU can initiate a further allocation attempt.
– Channels already busy for GPRS/EGPRS services are assigned only by the PCU
(for the TDPC a channel is either empty or full but not partly exploited, since the
TDPC is not capable of multiplexing different TBFs on one channel).
258 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

– Idle channels are assigned only by the TDPC (this allows to consider impacts of
pending PS requests and CS requests – handled by the TDPC only –, e.g. via prior-
itization and waiting list management).
– Pre-allocated channels can be assigned by PCU (1. attempt) or TDPC (2. attempt).
– In case of conflicting situations (e.g. there are some resources on busy GPRS
channels but idle channels are additionally needed to satisfy the request), the TDPC
assigns the resources.
g Pre-allocated channels are the channels still in packet transfer mode (due to
delayed release of physical channels) after the related TBF has been released.
These are the channels for which the TEMPCH timer is running and has not expired.
Functions of the PCU:
When a GPRS/EGPRS request arrives at the BSC, the PCU calculates the amount of
radio resources. Then the PCU searches for appropriate resources. In case an appro-
priate set of channels is already available at the PCU (e.g. channels already allocated
to GPRS calls which the requested call can be multiplexed on), the PCU can immedi-
ately assigns the resources. Otherwise the PCU commits the request to the TDPC
together with suggestions for allocating resources and other information.
Functions of the TDPC:
The TDPC tries to satisfy the allocation suggestions sent by the PCU as much as pos-
sible. If other resources (radio and Abis) are needed, the TDPC searches for them itself
and allocates them in case of success. The actions to be performed if no appropriate
resources are found depend on the congestion state, the type of the request etc. Usually
the requests are put into a waiting list (pending requests in this queue are managed by
the Waiting list manager). In adverse situations certain requests have to be rejected.
Afterwards the TDPC informs the PCU about successfull allocation or rejection.
Packet channel
request BSC
Calculate required
PDCH resources
(Abis)
Sufficient PDCH
resources New (empty) request Find new
on busy PDCHs (empty)
PDCHs required PDCHs
PDCH
Allocate setup Allocate
resources PDCHs
on PDCHs (if possible)
Packet uplink
assignment
PCU TDPC
(Abis)
Figure 105 PCU – TDPC interplay in case of PDCH allocation (simplified example)
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 259

10.3.4 TBF scheduler

The Temporary Block Flow scheduler distributes several active TBFs (from the same or
other MSs) onto the physical resources, especially schedules the multiplexing of TBFs
onto shared PDCHs (which have been allocated by the channel allocation algorithm).
More in detail the TBFs to be multiplexed on the same PDCH have a weight represent-
ing the priority or the required (guaranteed) minimum radio block transmission rate of
the TBF. In previous releases the weight was assigned according to the desired priority;
services with higher priority got a higher weight. In the current release the weight is
associated with the minimum transmission rate of radio blocks to fullfill the requested
QoS. The different interpretations of the weight are not contradictory: Usually a service
with higher priority requires a higher minimum transmission rate. Now, the basic idea is
to share the resources of a PDCH between several TBFs according to their weights. The
heavier a TBF is, the more radio blocks it gets relative to the other TBFs. Actually, the
scheduler determines the number of radio blocks per second for each TBF via the
weight, and distributes the radio blocks for all TBFs in the current timeslot, then the
same for the next timeslot and so on.
A TBFi multiplexed on a timeslot with other TBFs gets the following number of radio
blocks per second N_RBi:
N_RBi = (50 – SFM) · Weight of TBFi / (Sum of all Weights allocated on the PDCH)
where SFM (Safety Margin) is the number of radio blocks per second not allocated for
safety margin reasons and (50 – SFM) is the maximum number of radio blocks per
second available for allocation.
So, if the Radio Resource Management has allocated several TBFs on a PDCH in the
way that the PDCH is fully exploited (minus safety margin) – i.e. the overall sum of the
weight of the TBFs allocated on the PDCH has the maximum value for a PDCH –, each
TBF gets just the required minimum radio block transmission rate. Else, if the PDCH is
not fully exploited by the channel allocation, all TBFs get higher transmission rates via
the TBF scheduler and the PDCH again is fully exploited.
g Realtime requests are treated in the same way as not realtime requests.
Example
a) The Channel Allocation Algorithm has allocated 3 TBFs on a PDCH with a safety
margin of 4 radio blocks per second (46 radio blocks per second remain for data
transmission), the TBFs have the following properties:
– TBF1: for realtime service with weight 12 (guaranteed 18 radio blocks / second)
– TBF2: not realtime service, weight 8
– TBF3: not realtime service, weight 4
The timeslot is shared in proportion to the TBF weights: 12 : 8 : 4. With 46 available
radio blocks per second (rbps) this results in 23 radio blocks per second for TBF1,
15 for TBF2 and 8 for TBF3 (23 : 15 : 8 with truncation). Since the sum of the TBF
weights is lower than the maximum weight, all TBFs get more than the required
minimum radio block transmission rate.
b) Then a fourth TBF has been allocated on the same timeslot:
– TBF4: not realtime, weight 8
The timeslot is shared in the following proportions 12 : 8 : 4 : 8. Since the sum of the
TBF weights reach the maximum for the timeslot, all TBFs just get the minimum
radio block transmission rate: 18 radio blocks per second for TBF1, 11 for TBF2, 6
for TBF3 and 11 for TBF4 (18 : 11 : 6 : 11 with truncation).
260 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

Figure 106 illustrates the TBF scheduling for this example.
TBF Weights
a) 3 TBFs b) 3 TBFs + 1 TBF
8 TBF4
Maximum overall Weight = 32
TBF3 4 4 TBF3
TBF2 8 8 TBF2
TBF1 12 12 TBF1
Radio Block Distribution on Timeslot

a) 3 TBFs a) 3 TBFs b) 3 TBFs + 1 TBF
23 4 15 8 23 4 15 8 18 4 11 6 11
50 Radio Blocks per second Safety Margin
Figure 106 Example for TBF scheduling
10.3.5 Mobile Station overheating management

A Mobile Station may not be able to consistently operate at its maximum permissible
output power while the maximum number of timeslots has been assigned for uplink
operation, due to possible overheating of the transmitter circuitry. This factor may limit
the ability for the MS to take full advantage of its power class and/or multislot class and,
as consequence, the maximum uplink data rate is limited.
For solving the overheating problem, the maximum number of timeslots allocateable to
a MS for uplink data transfer is adapted to the distance between MS and BTS: Larger
MS-BTS distances require the MS to send with higher power on each timeslot, thus the
number of allocated timeslots should be lower than for a small MS-BTS distance, and
vice versa.
The determination of the allowed maximum number of uplink timeslots for a MS is not
solely based on the MS-BTS distance, but takes into account the following items, too:
– MS power class
– Frequency band in use
– Modulation mode in use
– MS multislot power profile
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 261

– Path loss conditions in the cell, e.g. “urban” or “rural” (good transmission conditions
allow lower transmission power than bad conditions for a given MS-BTS distance)
For handling the relation between the maximum number of timeslots for a certain MS
and the MS-BTS distance, a set of tables is provided for the various MS and transmis-
sion conditions.
When a Packet Flow Context / Temporary Block Flow is already allocated to a MS, the
MS-BTS distance is periodically calculated via the TA (Timing Advance) value with a
period of a few seconds (2 – 5 s). Then the appropriate table for the maximum number
of uplink timeslots is accessed and the current actual number of allocated timeslots is
compared with the allowed maximum number. In case the number of currently allocated
timeslots exceeds the maximum number given in the table, a downgrade request is sent
to the Radio Resource Management system. In case the number of current timeslots is
lower than the maximum number in the table, an upgrade request is sent.
When a Packet Flow Context / Temporary Block Flow shall be allocated, the maximum
number of timeslots for the affected MS is determined as described above and consid-
ered by the Radio Resource Management system for the allocation.
For more details about the overheating management feature please refer to the GPRS
global description manual.
10.3.6 Upgrade of radio resources

An upgrade of radio resources means that additional radio resources (timeslots) are
added to an ongoing TBF. More than one timeslot can be added to a call within one
upgrade procedure and the added resources can be provided from a different TRX. The
choice between the available upgrade timeslot candidates is done with the same criteria
used in the initial allocation of the radio resources for a TBF (e.g. the additional radio
resources shall be adjacent to the radio resources already assigned to the TBF).
An upgrade of radio resources for an already established (E)GPRS call is only possible,
if the following conditions are fulfilled simultaneously:
– Horizontal Allocation is in progress.
– The MS’s multislot class allows more timeslots than already allocated.
– The number of idle radio timeslots in the cell is higher than a user defined threshold.
Upgrade requests for already established (E)GPRS calls can arrive at the BSC from a
Mobile Station or the SGSN or can be indicated by changed radio conditions.
The upgrade algorithm is very similar to the algorithm for the initial radio resource allo-
cation for a new TBF.
When the radio conditions are worsening, simultaneous upgrading of (E)GPRS calls
(incrementing the number of timeslots) and downgrading of the CS/MCS coding scheme
(selecting a more robust coding scheme) and possibly the Abis/PDT (related to Link
Adaptation) would be helpfull. In fact the downgrading of CS/MCS is managed, before
the (E)GPRS calls are upgraded. The upgrading of radio resources will be started in
such cases only when the downgrading of the CS/MCS coding scheme is completed.
In case radio resources are missing and the upgrade is not possible, the upgrade
request is dropped. The upgrading will be attempted again, if the upgrade conditions are
still fulfilled.
262 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

Upgrade conditions
The events triggering the upgrading of the radio resources for an already established
(E)GPRS call (upgrading conditions) are:
• Increased throughput requirement
– While an uplink TBF is in progress, the Mobile Station can request a change of
the required throughput submitting a PACKET RESOURCE REQUEST
message and specifying a different value for the throughput in the “Channel
Request Description” Information Element.
– While a downlink TBF is in progress, the SGSN can request a change of the
required throughput specifying a different value for the throughput in the “QoS
Profile” Information Element of the “DL-UNITDATA” Information Element.
In both cases (and in DL/UL direction), the variation of the required throughput is
taken into account only if a throughput value higher than the currently managed
value (in the same UL or DL direction) is specified.
• Decreased maximum sustainable throughput
If the maximum sustainable throughput falls below a user defined percentage of the
required throughput due to the worsening of radio conditions, an upgrade is initiated.
Single TS throughput CS_A · (1 – BLER) · #TS < (1 – ACCEPTGDEGR) · Required
throughput
whereCS_A is the actual coding scheme, the expression on the left side of the
equation is the maximum sustainable throughput, and ACCEPTGDEGR defines the
percentage of the acceptable degradation of the required throughput.
A check of the maximum sustainable throughput is periodically performed.
• Loss of radio resources due to preemption or O&M commands
10.3.7 Attributes
Channel allocation
EDASUP (“eDASupport”): This attribute set to ENABLED enables the “Extended
dynamic allocation” feature which allows to allocate more than 2 timeslots in UL.
Support of multislot classes 30 – 33

MSs of multislot classes 30 – 33 allow the allocation of up to 6 timeslots (maximum 5 DL
timeslots) and multiplexing of realtime TBFs with other TBFs. The following attributes
have been introduced to enable the support of these classes and to control multiplexing:
• EMSC3033 (“enableMSC3033”): This parameter enables the support of the mul-
tislot classes 30 – 33 in case it is set to TRUE. In case EMSC3033 is set to FALSE,
the classes 30 – 33 are mapped als follows to lower classes:
30-33 source class Target class

30 8
31 10
32 11
33 12
Table 42 Mapping of multislot classes 30-33 to lower classes
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 263

• SFMDL (“sMFDownlink“): The percentage of timeslot downlink capacity used as

safety margin. The Safety Margin cannot be allocated for a new TBF/PFC, but it is
used to maintain (by providing additional capacity) the ongoing TBFs in case of dete-
rioration of radio conditions.
• SFMUL (“sMFUplink“): Percentage of timeslot UL capacity used as safety margin.
• MAXWDL (“maxWeightDL“): 1/MAXWDL determines the fraction of the capacity of
1 timeslot which a TBF of weight 1 can get at maximum. A TBF of weight m can get
m times this fraction at maximum. If there is a new TBF request, which QoS
demands (regarding the bitrate to be guaranteed) exceed the maximum capacity
determined by the desired weight and by MAXWDL, the TBF will be rejected.
More in detail, the maximum number of radio blocks per second (RBps) which a TBF
with weight 1 can get is calculated as follows (50 radio blocks per second are avail-
able on one timeslot, SFM is the safety margin):
RBps_max_for_TBF_with_weight_1 = (50 – SFM) / MAXWDL
This leads to the following hypothecical DL maximum data rates for TBFs of given
weights, assumed that SFM =0 and MAXWDL = 32 (default value):
TBF Weight = 1 corresponds to 1.56 RBps
TBF Weight = 16 corresponds to 25 RBps
Higher values of the MAXWDL parameter are equivalent to lower numbers of radio
blocks per weight unit (especially TBF weight = 1 means very low throughput) and
more TBFs can be multiplexed on the same timeslot. So MAXWDL controls the mul-
tiplexing level for downlink direction, the highest MAXWDL values generally allow
major TBF multiplexing (but TBF requests with high throughput demands could be
rejected). Vice versa, low values of MAXWDL allow generous allocation of
resources to TBFs and reduce multiplexing (too low values of MAXWDL can also
cause the rejection of TBF requests).
• MAXWUL (“maxWeightUL“): The counterpart of MAXWDL for the uplink direction.
• RTMUXBACCOM (“rtMuxingBackwardComp“): This parameter defines the realtime
multiplexing backward compatibility in the following way:
– RTMUXBACCOM = 0 : Multiplexing is allowed for a realtime TBF and other
TBFs belonging to the same or other MSs.
– RTMUXBACCOM = 1 : Multiplexing is not allowed for a realtime TBF and other
TBFs belonging to other MSs, only allowed for realtime TBF and other TBFs of
the same MS.
Timers for pre-allocated channels

• The attributes for reserving and limiting channels for (E)GPRS usage are described
in chap. Configuring channels for (E)GPRS usage.
• TEMPCH (“timerEmptyChannel“): This timer specifies the delay time for the release
of an allocated PDCH if there are no TBF activities. The TEMPCH timer is started
on the stop of the last TBF on a PDCH and keeps the allocated PDCH activated to
serve possible new TBFs, i.e. when the last MS associated to a PDCH is released
(no TBF is ongoing on the PDCH anymore) the “virtual” assignment of the PDCH
persists for the duration of the timer TEMPCH. The purpose of this timer is to avoid
immediate channel allocation requests from the PCU to the TDPC after a PDCH
becomes empty. This behaviour reduces the allocation time and TDPC load in case
of high (E)GPRS traffic.
264 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

• TEMPPDT (“timerEmptyPDT“): This timer is the equivalent to the parameter

TEMPCH for Packet Data Terminal (PDT) resources allocated on the PCU.
TEMPPDT determines the delay time for the release of an allocated PDT with
subframe counter > 0 if the related PDCH does not require this PDT anymore (e.g.
due to a downgrade of the used coding scheme). The timer TEMPPDT is used to
avoid continuous requests for Abis resources from the PCU to the TDPC.
Example: An MCS9 DL TBF is allocated on 2 radio timeslots (PDCH). Each of the
PDCHs has five 16 kbit/s Abis subslots allocated – in total 10 PDTs are in use on
PCU side. Assuming a sudden downgrade of the coding scheme to MCS6 (due to
bad radio conditions), as soon as the coding scheme MCS6 is applied from the PCU,
only 3 of the previously 5 Abis subslots (and PDTs) are necessary to transport the
user data for each PDCH. TEMPPDT is started at that moment for the 2 + 2 affected
PDTs (with subframe counter 3 and 4) – and if no upgrade to a higher coding
scheme occurs within the runtime of TEMPPDT (or another MS using MCS9 is ver-
tically allocated, etc.) these 4 Abis resources are released.
Field applications have shown that a careful reduction of the timer TEMPPDT to
values smaller than the default value can help to overcome TBF blocking situations.
While the timer TEMPCH is started for the PDTCH (GPRS radio timeslot) and one asso-
ciated PDT (Abis timeslot), the timer TEMPPDT can only be started for all additional
PDTs (i.e. at the maximum all but one). For this reason the value of TEMPPDT must be
in any case smaller than the value of TEMPCH.
Scheduling weights
With Packet flow control (PFC) the weights for TBFs to be allocated are derived from
required minimum transmission rates. In case PFC is switched off or the MS does not
support PFC (preRel99 MSs), weights can be influenced by the following parameters.
SCHWEIPRI1 (“schedulingWeightOfPriority1”), SCHWEIPRI2, SCHWEIPRI3,
SCHWEIPRI4: These parameters relate priorities of TBF requests to scheduling
weights. Thereby, if more than one MS is allocated on a PDCH (vertical allocation), the
relative importance of an MS (TBF) compared to another one with differerent priority can
be determined. Four different priorities are internally distinguished.
Example:
SCHWEIPRI1 = 8; SCHWEIPRI1 = 4; SCHWEIPRI1 = 2; SCHWEIPRI1 = 1 leads to the
relations between internal TBF priority and TBF weight as shown in Table 43.
DL precedence UL radio priority Internal priority Weight

1 1 1 8
2 2 2 4
3 3 3 2
4 4 1
Table 43 Scheduling: relations between priorities and weights
The UL radio priority is present in the PACKET RESOURCE REQUEST message in

case of a two-phase access. In case of one-phase access, the default is 4. The DL pre-
cedence is assigned during the PDP context activation as part of the Q&S negotiations
and is included in each DL-UNITDATA PDU.
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 265

For 2 MSs sharing 4 timeslots and using the same coding scheme, MS1 with priority 1
(weight 8), MS2 with priority 4 (weight 1), MS1 gets 8/9 of the DL throughput, MS2 gets
1/9.
Overheating
The overheating management feature can be enabled (disabled) by setting bit 55 of the
maintenance bitmask (MNTBMASK) to 0 (1); default value is 0.
The path loss condition representing the typical propagation conditions in the cell and
used to determine the MS transmission power is set by the CSCE (“cellScenario”) attri-
bute; values: URBAN, SUBURBAN, RURAL_QUASI_OPEN, RURAL_OPEN.
Upgrade
The following attributes and flags are used for indicating upgrade possibilities and
thresholds:
• The “enableRadioUpgradingFlag” indicates, if an upgrade of resources shall be
tried. At system initialization this flag is set to DISABLED by default. The TDPC
receiving an upgrade request from the PCU checks, if an upgrade is allowed (includ-
ing the threshold criterion below). If yes, the flag is set to ENABLED. The TDPC adds
this flag to various messages, also informing the PCU about the upgrade possibility.
• The “thresholdIdleChanEnableUpgrade” field of the GASTRTH (“gprsAllocation-
StrategyThresholds“) attribute determines a threshold for executing an upgrade. If
the number of idle radio timeslots in the cell is higher than the value of the “thresh-
oldIdleChanEnableUpgrade” field, an upgrade is allowed from this side. “threshold-
IdleChanEnableUpgrade” = 100 inhibits upgrading (the number of idle timeslots is
calculated as described in the chapter 10.1.3 Switching between vertical and hori-
zontal allocation).
PDCHs already allocated to GPRS/EGPRS can be assigned to a TBF for upgrading
reasons no matter of the “thresholdIdleChanEnableUpgrade” value.
• The ACCEPTGDEGR (“acceptableGPRSDegradation”) attribute defines, in per-
centage (steps of 10 %, from 0% to 90%), the acceptable degradation of packet
service throughput (maximum sustainable throughput), before an upgrading of radio
resources (i.e. TCH resources on the Um) is attempted. When set to 0, no degrada-
tion is allowed and radio resource upgrading is always attempted as soon as the
upgrading condition is detected.
• The UPGRFREQ (“UpgradeFrequency“) attribute determines the time period for
checking the maximum sustainable throughput.
10.4 Control of the number of timeslots in case of peak

throughput based channel allocation
The following two features are applicable in the following cases:
– Packet Flow Context (PFC) is disabled.
– The MS is not compliant to release 99 or later (MS does not support PFC).
In these cases the channel allocation algorithm uses peak throughput information for
calculating the numbers of timeslots to be allocated in the downlink (DL) and uplink (UL)
direction. For other cases the features have no effect.
266 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

10.4.1 Improved downlink resources allocation

This feature avoids waste of DL resources in case of a multislot allocation which is
based on peak throughput information. "Improved Downlink Resources Allocation"
provides the following:
• Initial assignment of only one DL timeslot if the amount of data buffered in the BSC
to be sent in DL direction is under a certain threshold.
• Periodic checks of the amount of buffered data to be sent in DL direction, and
upgrade of allocated DL resources if this amount exceeds the threshold. These
checks take place if only one DL timeslot has been allocated and if the peak through-
put criterion has requested more than one DL timeslot.
(An analogous downgrade of DL resources is not provided for the case that the
amount of data to be sent DL falls under the threshold.)
Details
Peak throughput requirements are usually set to high values independently from the
requested application. Thus peak throughput information often results in too generous
DL timeslots assignments. Often 1 DL timeslot would provide sufficient DL capacity. In
order to avoid a waste of DL resources, the amount of data already buffered in the BSC
to be sent in DL direction is used to detect if 1 allocated DL timeslot should be enough
(in this case the buffer is not exhausted) or if the peak throughput criterion is to be
applied. This amount of buffered DL data is the length of the LLC queue in the BSC and
shall be denoted as “DL_RLC_octet_count” here (actually it is a BSS-internal parame-
ter).
Initial assignment:
The BSS allocates DL timeslots as follows:
• If the value of the “DL_RLC_octet_count” parameter is below the threshold defined
by the IDTRATH (“iDRAThreshold”) attribute, the minimum number of DL timeslots,
i.e. 1 timeslot, is allocated. This occurs for applications requiring a low throughput
rate.
• If the value of the “DL_ RLC_octet_count” parameter exceeds the IDTRATH value,
the number of allocated DL timeslots is determined by the peak throughput criterion,
which usually results in a DL multi-timeslot configuration.
Reconfiguration:
If only 1 DL timeslot has been allocated (and if the peak throughput criterion has
requested more than one DL timeslot), a timer is started at the beginning of the DL data
transmission. When this timer reaches the time period determined by the
IDRATSWITCH (“iDRATimerSwitch“) parameter, the amount of RLC data in the DL
transmission buffer is checked. If the “DL_RLC_octet_count” value exceeds the
IDTRATH threshold, a reconfiguration takes place allocating as much DL timeslots as
determined by the peak throughput criterion. Else (“DL_RLC_octet_count” value below
the IDTRATH threshold) no reconfiguration is executed. After the check and if still 1 DL
timeslot is allocated, the timer is restarted and triggers the next check after the same
time period, and so on.
No downgrade of a DL multi-timeslot allocation is provided in case the
“DL_RLC_octet_count” value falls below the IDTRATH threshold.
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 267

LLC buffer level
IDTRATH
Time
IDRATSWITCH IDRATSWITCH IDRATSWITCH
TIMEDTBFREL
Start Stop Start Stop

IDRA IDRATSWITCH IDRATSWITCH IDRA
Start Start TIMEDTBFREL Stop TIMEDTBFREL
IDRATSWITCH No reconfiguration No reconfiguration Reconfiguration
1 DL TS allocated 1 DL TS 1 DL TS 3 DL TSs
(3 DL TSs calculated allocated allocated allocated
via peak throughput)
IDRA: Improved Downlink Resources Allocation DL: Downlink TS: Timeslot
Figure 107 Improved downlink resources allocation
Attributes
• IDRAACT (“iDRAActive“): This attribute enables or disables the "Improved Downlink
Resources Allocation" feature.
• IDTRATH (“iDRAThreshold”): This attribute represents the threshold, expressed as
an octet number, above which a DL allocation reconfiguration (upgrade only) can
take place.
• IDRATSWITCH (“iDRATimerSwitch“): This attribute defines the time periods after
which it is checked if a 1 DL timeslot allocation should be reconfigured according to
information about required peak throughput.
10.4.2 Uplink balancing/unbalancing

This feature avoids waste of UL resources in case of a multislot resource allocation
which is based on peak throughput information. It provides the following:
• Initial assignment of only one UL timeslot if the amount of data indicated to be sent
in UL direction is under a certain threshold. This means prioritization of the DL direc-
tion or, in other words, an unbalanced UL/DL timeslot allocation.
• Switch from an unbalanced allocation to a balanced allocation after a configurable
time period, or switch from a balanced allocation to an unbalanced one (under
certain conditions).
Details
Peak throughput information, when used for determining the required number of
timeslots in UL and DL direction, often leads to too generous allocations, especially in
268 Id:0900d8058052ea4d A50016-G5100-B556-04-7620

UL direction (in general much more DL than UL capacity is necessary). The channel
allocation algorithm often finds several combinations of UL and DL timeslots (TSs) sat-
isfying the peak throughput requirements (e.g. 3 DL TSs + 2 UL TSs and 4 DL TSs + 1
UL TS). In order to avoid too generous UL assignments on expense of DL resources,
the downlink transmission can be preferred by allocating only 1 timeslot of a set of
timeslots for UL transmission and allocating the other timeslots for DL (unbalanced
timeslot allocation) in case there is not much data to be sent uplink. The amount of uplink
data to be transmitted is reported from the MS to the BSS with the “RLC_octet_count”
parameter. This parameter is part of the “Channel Request Description” Information
Element included e.g. in the PACKET RESOURCE REQUEST message and indicates
the number of RLC data octets the MS wants to transmit. The value 0 is reported to
indicate an open-ended TBF or not to specify any UL requirements.
In the call establishment phase the BSS distributes the timeslots to be allocated for UL
and DL as follows:
• If the value of the “RLC_octet_count” parameter exceeds the threshold defined by
the THSULBAL (“thresholdSwitchULBalanced”) attribute, a balanced UL/DL mul-
tislot configuration is assigned (e.g. 3 DL TSs + 2 UL TSs).
• If the value of the “RLC_octet_count” parameter is below the THSULBAL value but
is greater than 0, the downlink direction is preferred and only the minimum number
of UL timeslots is allocated (e.g. 4 DL TSs + 1 UL TS).
• If “RLC_octet_count” = 0, then the UL/DL balanced multislot allocation is applied.
If the UL TBF is still alive after a time period determined by the TSULBAL
(“timeSwitchULBalanced“) timer parameter, the BSC does the following:
• In case of an unbalanced UL/DL allocation, a reconfiguration to a balanced UL/DL
allocation is performed because 1 timeslot in UL direction seems not to be sufficient.
• In case of “RLC_octet_count” = 0 and balanced UL/DL allocation, a reconfiguration
to an unbalanced UL/DL allocation is performed in order to avoid that the balanced
mode is kept too long.
• Else, the current allocation is kept.
Attributes
• TSULBAL (“timeSwitchULBalanced“): This attribute defines the time after the initial
radio resource allocation after which the BSC decides about a switch between
UL/DL balanced and unbalanced allocation. TSULBAL = 0 disables the complete
feature.
• THSULBAL (“thresholdSwitchULBalanced”): This attribute represents the threshold
number of RLC octets to be sent in UL direction which determines if an UL/DL
balanced or unbalanced allocation is taken.
• EXTULTBFI (“extendedUplinkTBFImpr”): This attribute, enabling the "Extended
Uplink TBF Improvement" feature, must be set to TRUE in order to enable the
described handling of the case “RLC_octet_count” = 0.
• Additionally the peak throughput used for determining the number of required
timeslots can be controlled by bit 49 of the MNTBMASK attribute:
– bit 49 = 0: A standard high peak throughput is assumed for UL.
– bit 49 = 1: The required UL peak throughput is taken from the “Channel Request
Description” Information Element. The benefit is that low bitrate applications can
be provided with low Required Peak Throughput and therefor a low number of
timeslots can be be assigned (e.g. 1 timeslot for DL, 1 for UL).
A50016-G5100-B556-04-7620 Id:0900d8058052ea4d 269

GSM power control Radio network management
11 GSM power control

This part of the manual is organized as follows:
– Chap. 11.1 Basic functionality describes in general how power control works.
– Chap. 11.2 Functional sequence of the power control procedure explains the inter-
play between MS and BTS when performing a power control procedure.
– Chap. 11.3 Classic power control and 11.4 Adaptive power control give details
about the two types of power control available.
– Chap. 11.5 Attributes and configuration explains attributes and their usage to con-
figure power control.
– Chap. 11.6 Delayed power control for emergency calls, 11.7 Temporary overpower
and 11.8 Derived handover power management deal with special additional power
control features.
– Chap.11.9 (E)GPRS power control (complement to GSM power control) describes
basics of GPRS power control (for comparison with GSM power control).
11.1 Basic functionality

Principle
Power control allows the increase respectively reduction of the MS (uplink) and TRX
(downlink) transmit power during an ongoing radio connection to react to current radio
conditions. Power control is employed in order to minimize the transmit power to a level
required to just ensure an adequate speech/data quality over the radio path. Hence the
co-channel interference caused by other cells re-using the same radio frequencies, the
adjacent channel interference caused by other call connections in the same cell and the
average power consumption of the transmitter are reduced.
Power control can be triggered
• due to specific receive level conditions (measured by RXLEV): if the current RXLEV
is too low, power control increases the transmit power to ensure a proper receive
level on the receiving side and to prevent call drops;
• due to specific receive quality conditions (measured by RXQUAL and mapped to a
C/I value): if the current C/I is too low, power control increases the transmit power to
ensure a proper receive quality on the receiving side and to prevent call drops;
• due to a combination of both level and quality conditions.
On the other hand, if the level and quality conditions are very good, the BTS shall reduce
the power to suppress interference on the radio interface, the MS shall reduce its trans-
mitting power as well in order to reduce the power consumption and radiation.
Power changes can be done in steps of pre-defined sizes or in steps the sizes of which
are adapted to the radio conditions in order to get appropriate RXLEV and RXQUAL
conditions as fast as possible. The rate of power adjustments can – depending on the
configuration and radio conditions – be controlled either by a timer or the timer can be
avoided to allow immediate adjustments.
Both the uplink power control for the Mobile Station (MS power control) and the
downlink power control for the TRX (BTS power control) are independently imple-
mented in the BTS’s Carrier Unit (CU) / Baseband and Signalling Card (BBSIG) of the
respective TRX. Figure 108 shows the basic steps of the power control for both MS and
BTS power control forming a loop.
270 Id:0900d805805420ec A50016-G5100-B556-04-7620

Radio network management GSM power control
-3 "43
3ET -EASUREMENT
-30OWER 2EPORT 3!##(
-30OWER#ONTROL,OOP -EASURE %VALUATE

28,%6 -EASUREMENT
"430OWER#ONTROL,OOP 2815!, 2EPORT
%VALUATE -EASURE -30OWER "430OWER

0OWER#ONTROL 28,%6 #HANGE #HANGE
)NFORMATION 2815!, $ECISION $ECISION
0OWER#ONTROL
#OMMAND 3ET
3!##( "430OWER
3!##()NFOS
Figure 108 Power control loop for MS power control and BTS power control
The adjustment of the MS or TRX transmitting power is based on radio link measure-
ment results, i.e. uplink and downlink RXLEV and RXQUAL values, and the BTS
decides if the transmitting power shall be changed.
There are two variants of power control: CLASSIC and ADAPTIVE. These two power
control types can be enabled separately for MS power control and BTS power control in
a particular cell.
For each cell the BTS power control, which is a not mandatory feature according to GSM
Recommendations, can be enabled or disabled by the user.
Special cases
If a radio link failure warning occurs, the Mobile Station and the TRX use their maximum
transmit power (defined by the specified O&M attribute).
If the BTS power control is disabled, the maximum RF output power of the TRX (defined
by the specified O&M attribute) is used for all dedicated downlink channels.
If the Mobile Station power control is disabled for a particular cell, all the Mobile Stations
served by this cell on a dedicated channel use the maximum transmit power allowed in
this cell or the maximum peak power defined by their respective power classes.
g Power control is not allowed on the downlink BCCH carrier, where the maximum
radio frequency output power is used for all the dedicated channels.
Measurements for Power control

Regarding the TRX transmit power, the MS – while keeping a TCH or SDCCH connec-
tion – measures RXLEV and RXQUAL of received TRX bursts during SACCH periods
and sends the results as measurement reports to the TRX via SACCH. The reported
RXLEV and RXQUAL values inform the TRX if its transmit power is set accurately. One
measurement report is sent during one SACCH block which requires 4 TDMA frames.
A50016-G5100-B556-04-7620 Id:0900d805805420ec 271

In case of a TCH connection the SACCH TDMA frames are multiplexed onto 26-multi-
frames and 4 of these multiframes (i.e. 104 TDMA frames within 480 ms) are transmitted
for a complete SACCH block; in case of a SDCCH connection the SACCH TDMA frames
are multiplexed onto 51-multiframes and 2 of these multiframes (i.e. 102 TDMA frames
within 471 ms) are transmitted for a complete SACCH block. Regarding the MS transmit
power, the BTS measures RXLEV and RXQUAL of received MS bursts (indicating if the
MS power is set accurately).
If Voice Activity Detection / Discontinuous Transmission (VAD/DTX) is enabled, mea-
surements are made either on a subset or on a full set of TDMA frames of a SACCH
block, depending on the dynamics of VAD/DTX.
The received signal level over the full range of –110 dBm to –48 dBm is mapped to an
integer RXLEV value between 0 and 63, as defined in the GSM Recommendation 05.08.
The received signal quality is related to an equivalent average BER before decoding the
related channel. The range of the BER (between 0.2% and 12.8%) is mapped to an
integer value for signal quality between 0 and 7 (corresponding with 3 bits reserved for
the RXQUAL value in the “Measurement Results” IE), as defined in the GSM Recom-
mendation 05.08.
Averaging of measurement results

The downlink/uplink measurements provided by the Mobile Station and TRX are
averaged in such a way that rapid fluctuations in the observed variables due to fading
effects do not initiate power control decisions and also ensure that the process is not too
slow.
More in detail the averaging process includes a “gliding” averaging window: All mea-
surement samples inside the window are used to calculate the arithmetic average. The
averaging window is called “gliding”, as the window works as a queue: when a new mea-
surement is received, the oldest measurement is removed from the window.
The resulting average RXQUAL value is calculated with a resolution of two digits after
the comma (this is achieved by multiplying the RXQUAL values with 100 before averag-
ing). The resulting high-precision RXQUAL value is then mapped to an integer C/I value
according to Table 44.
RXQUAL C/I RXQUAL C/I

6.88 ... 7.00 1 3.88 ... 4.12 12
6.76 ... 6.87 2 3.38 ... 3.87 13
6.38 ... 6.75 4 2.88 ... 3.37 13
6.13 ... 6.37 5 2.63 ... 2.87 15
5.88 ... 6.12 6 2.13 ... 2.62 16
5.63 ... 5.87 7 1.63 ... 2.12 17
5.13 ... 5.62 8 1.13 ... 1.62 18
4.88 ... 5.12 9 0.38 ... 1.12 19
4.63 ... 4.87 10 0.00 ... 0.37 20
4.13 ... 4.62 11
Table 44 Mapping between RXQUAL and C/I values
272 Id:0900d805805420ec A50016-G5100-B556-04-7620

In case DTX is applied, the averaging process is adjusted including a DTX weighting
factor. Each sample value is filled in the average window once and the respective weight
factor is stored separately under the same index (consequently the time needed to fill
up the averaging window is always the same and it only depends on the length of the
averaging window). The total average value is then calculated by adding each sample
of the average window N times, where N denotes the related weighting factor, and even-
tually dividing the sum by the total weight which is the sum of all weighting factors.
Power control decision

The average values of the received signal quality RXQUAL and the received signal level
RXLEV are compared with a number of pre-defined thresholds (O&M attributes) and the
result of the comparison determines if and which power adjustment is to be performed.
Each decision in this threshold comparison process is based on a single average value.
The process is initiated as soon as the first average values are produced for RXLEV and
RXQUAL on the dedicated channel in question.
Under normal conditions, when measurement reports are available for each SACCH
block, the threshold comparison process is executed once per SACCH block. If the aver-
aging process has temporarily been suspended due to the non-availability of measure-
ment results, the power control decision process is also suspended during the related
SACCH blocks. In the GSM900/GSM1800 mobile network the following decision thresh-
olds are defined for uplink as well as for downlink:
– upper threshold value for the receive signal quality, denoted as high_qual_thresh
– lower threshold value for the receive signal quality, denoted as low_qual_thresh
– upper threshold value for the receive signal strength, denoted as high_lev_thresh
– lower threshold value for the receive signal strength, denoted as low_lev_thresh
The size of the requested change of the transmitting power depends on the configura-
tion and on the relation of the RXLEV, C/Iaveraged values to the thresholds.
These decision thresholds are configurable by the user by means of O&M commands
and on a cell-by-cell basis.
Interdependencies with handover

A handover indication may be triggered as soon as the maximum transmitting power has
been set. If street corner effects occur, the adapted step size can immediately reach the
maximum transmitting power allowed in that cell. Hence, the faster the power control,
the sooner the handover can follow, and call drops are avoided, see Figure 109. Fast
power adjustment can be achieved with adaptive power control.
Figure 109 Flexible power control steps
A50016-G5100-B556-04-7620 Id:0900d805805420ec 273

11.2 Functional sequence of the power control procedure

BTS power control
The BTS makes a power control decision based on the RXLEV and RXQUAL values
contained in the currently received MEASUREMENT REPORTs from the MS (averaged
RXQUAL mapped to C/Iaveraged) and increases or reduces the power for the affected
TRX and TCH. The requested power change is immediately regarded as executed and
adjusted (i.e. no further internal power control confirmation signalling takes place). Then
the BTS starts the delay timer for power control decisions (time to pass between two
consecutive power control steps) and suspends the BTS power control decision process
while the timer is running (the insertion of measurement samples into the averaging
window continues, but no power control decision is made).
g In case of adaptive power control, the delay timer is not applied for low RXLEV
values. Therefor the power change will take place much faster than with classic
power control.
When the delay timer – if applied – expires, the BTS resumes the power control decision
process. In this case, if the current RXLEV and C/Iaveraged conditions suggest it, the
power control decision process may suggest another power control step.
If no SACCH report was received in a particular SACCH period, no power control
decision is made for BTS power control.
MS power control
The following main steps are performed (see also Figure 110):
1. The BTS makes a power control decision based on the currently measured uplink
signals and instructs the MS to increase or reduce the power by sending the
demanded power level (“MS power level”) in the layer 1 header of the DL SACCH
message in the next SACCH period to the MS (“SACCH period 1”). The “MS power
level” is signalled in form of the power level values defined by GSM and determines
the absolute power level the MS shall use.
Simultaneously the BTS starts the timer for power control confirmation and
suspends the power control decision process until the timer expires or the power
control confirmation arrives.
2. The MS, having received the power control command via the layer 1 header in the
DL SACCH message (of “SACCH period 1”), adjusts its power as requested. The
change is executed in the next SACCH reporting period (“SACCH period 2”), usually
at the first TDMA frame.
3. The MS confirms the power level to the BTS in the next UL SACCH period (“SACCH
period 3”); more in detail, the MS confirms the last (absolute) power level that was
actually used in the last burst of the previous SACCH period.
g In case of adaptive power control it can happen that the power increase step
ordered by the BTS is bigger than the increase step the MS can execute within
one SACCH period. In this case the MS confirms only the power level which it
actually managed to reach in the last burst of the SACCH period.
Moreover, greater power increase steps will not be immediately mirrored by the
UL power measurements done by the TRX as the MS always needs some time
for the “ramp up”. Therefore, if the power increase step size was greater than
4 dB, the power control decision process is suspended for another additional
SACCH period (this is achieved by an “artificial” delay of the MS power confir-
mation by 1 SACCH period). This avoids another immediate power increase
274 Id:0900d805805420ec A50016-G5100-B556-04-7620

command from the BTS (which is in this case in fact not useful as the MS simply
did not have enough time to execute the ordered power increase step).
4. When the BTS has received the power confirmation from the MS in its MEASURE-
MENT REPORT, the BTS starts the delay timer for power control decisions (time to
pass between two consecutive power control steps). As long as this delay timer
runs, the BTS power control decision process remains still suspended (the insertion
of measurement samples into the averaging window continues, but no power control
decision is made).
g In case of adaptive power control, the delay timer is not applied for low RXLEV
values. Therefore the power change will take place much faster than with classic
power control.
5. When the delay timer – if applied – expires, the BTS resumes the power control
decision process. When the waiting timer for the power confirmation from the MS
has expired without receipt of a power confirmation confirming that the requested
power command was actually executed, the BTS immediately resumes the power
control decision process. In this case, if the current uplink RXLEV and RXQUAL con-
ditions suggest it, the power control decision process may trigger another power
control step.
BTS makes a
MS power control decision
Averaging: RXLEV_AV
RXQUAL_AV
BTS starts
Averaging window delay timer
RXLEV RXLEV RXLEV

RXLEV RXLEV RXLEV
RXQUAL RXQUAL RXQUAL
RXQUAL RXQUAL RXQUAL
BTS measures BTS sends new

RXLEV, RXQUAL MS power level
...
SACCH period SACCH period SACCH period 1 SACCH period 2 SACCH period 3
MS sends MS adjusts power MS confirms power

measurement report
Figure 110 Progress of MS power control in time
11.3 Classic power control

Classic power control applies linear power increase in constant steps in case of low
RXLEV values or poor receive quality conditions. The size of the power increase step
can be configured by the user (at least 2 dB). In case of good receive quality conditions
and high RXLEV values the transmit power is linearly reduced in steps of constant size
which can be configured by the user (at least 2 dB).
Figure 111 summarizes the classic power control decisions.
A50016-G5100-B556-04-7620 Id:0900d805805420ec 275

2ECEIVE
1UALITY STANDARDREDUCTIONSTEP
POWERINCREASE

GOOD
n n nPOWERREDUCTION
NOPOWERCHANGE
HIGH?QUAL?THRESH
MEDIUM
n
LOW?QUAL?THRESH
POOR
2ECEIVE
LOW MEDIUM HIGH ,EVEL
LOW?LEV?THRESH HIGH?LEV?THRESH
Figure 111 Classic power control decisions

The decisions if the measured (and averaged) RXLEV and/or C/I values require a power
increase or reduction is made by comparison of the RXLEV and C/I values with upper
and lower thresholds:
• If the received signal strength or signal quality does not attain its lower threshold,
then the transmitter power is increased by a power increase step of specified size.
• If the received signal strength exceeds its upper threshold and the signal quality
exceeds its lower threshold, then the transmitter power is reduced by a power reduc-
tion step of specified size. Similarly the transmitter power is also reduced, if the
received signal quality exceeds its upper threshold and the signal strength exceeds
its lower threshold more than one power reduction step.
• If RXLEV and C/Iaveraged both lie between the thresholds, then no power control
action is taken. This gives stability to the power control process and it guarantees
also an adequate speech quality.
• If C/Iaveraged exceeds the upper threshold and RXLEV exceeds the lower threshold
not more than one power reduction step, no power change action is taken.
A configurable delay timer determines the minimum time difference between two con-
secutive power control increase or reduction steps. In case of MS power control the time
difference between two consecutive power control steps is longer because of additional
messaging between MS and BTS.
11.4 Adaptive power control

Adaptive power control allows a faster power increase (and also faster power reduction)
under specific radio conditions.
Figure 112 summarizes the adaptive power control decisions.
276 Id:0900d805805420ec A50016-G5100-B556-04-7620

2ECEIVE
1UALITY STANDARDREDUCTIONSTEP
POWERINCREASE
n nn FAST
GOOD
STANDARD
ADAPTIVE DECREASE ADAPTIVE nPOWERREDUCTION
STEPSIZE" STEPSIZE STEPSIZE# nnFAST
HIGH?QUAL?THRESH
NOPOWERCHANGE

MEDIUM
ADAPTIVE
STEPSIZE"
LOW?QUAL?THRESH

POOR
STANDARD STANDARD
ADAPTIVE INCREASE INCREASE
STEPSIZE! STEPSIZE STEPSIZE 2ECEIVE
LOW MEDIUM HIGH ,EVEL
Figure 112 Adaptive power control decisions

The step size for the power increase is in this case not defined by a static parameter
setting but it is calculated on the basis of the configured power control thresholds and
the currently measured RXLEV and calculated C/Iaveraged values. The step size is deter-
mined in such a way that probably one power increase step is enough to achieve suffi-
cient RXLEV and C/Iaveraged values, so the power adjustment is performed in a “fast”
way. Moreover the configurable delay timer determining the minimum time difference
between two consecutive power control increase or reduction steps is not applied in
cases with low RXLEV values. This speeds up the power change much compared to
classic power control (in case of MS power control the time difference between two con-
secutive power control steps is longer because of additional messaging between MS
and BTS).
The following cases are distinguished:
• Low receive quality and medium or high signal strength:
In this scenario the bad quality is most probably caused by interference. A slow
(linear) power increase with steps of constant size is triggered (this is the same
behaviour as with classic power control).
• Medium receive quality and medium or high signal strength:
No power change action is performed (even not in case of high signal strength,
because the quality is only in medium but not in good figures).
• High receive quality and medium signal strength:
The same behaviour as with classic power control is implemented: If the signal
strength exceeds the lower threshold more than one power reduction step of speci-
fied size, a slow (linear) power reduction is performed, otherwise no power change
action is taken.
• Poor receive quality and low signal strength:
In this scenario the bad quality is most probably caused by poor coverage conditions
or problems on the radio path. This is the most critical case, therefor the most drastic
variant of fast power increase is applied. The increase step is calculated as the dif-
A50016-G5100-B556-04-7620 Id:0900d805805420ec 277

ference between the arithmetic mean of the upper and lower receive level thresholds
on the one hand and the current RXLEV value on the other hand (all values in dB):
Increase step A = 0.5 · (high_lev_thresh + low_lev_thresh) – RXLEV
For this scenario the delay timer is not applied (which contributes to “fast” power
increase).
• Medium or high receive quality and low signal strength:
In this scenario the medium/good quality is most probably possible due to excellent
interference conditions (very low interference). The fast power increase step is cal-
culated as the difference between the lower receive level threshold and the current
RXLEV value (all values:
Increase step B = low_lev_thresh – RXLEV
For this scenario the delay timer is not applied (which contributes to “fast” power
increase).
• High receive quality and high signal strength:
A fast power reduction is applied. First the “allowed maximum power reduction step
based on quality” (“qual_max_step”) and the “allowed maximum power reduction
step based on level” (“lev_max_step”) are calculated. Then the smaller of the two
values is taken as power reduction step size (Decrease step C), all values in dB:
– qual_max_step = C/Iaveraged – (high_qual_thresh + low_qual_thresh) / 2
(high_qual_thresh + low_qual_thresh) / 2 is the medium desired quality and
determines how much the power can be reduced without the quality dropping
below the medium desired quality.
– lev_max_step = RXLEV – high_lev_thresh
– Decrease step C = min (qual_max_step, lev_max_step)
For this scenario, it depends on the power reduction step size, if the delay timer is
applied:
– If the power reduction step is below 4 dB, then the delay timer is not applied
(which contributes to “fast” power reduction), even if the resulting transmit power
(after the reduction step) ends up in medium RXLEV and good receive quality.
– If the calculated power reduction step size is above 4 dB, then after having
received the MS power level confirmation, the (existing) power control delay
timer is started and further power control decisions are suspended until the timer
exceeds. During this time period the quality averaging window is completely
filled with new quality measurements to make sure that the next power control
decision is based on the quality measurement data that was caused by the latest
power level change (the consequences for the quality can not be anticipated
well; for example a call at the cell border suffers a more extreme quality drop
than a call close to the antenna with identical power level reduction).
In other words, the decision whether the delay timer is started (and thus applied
before the next decrease step) is made simultaneously together with the power
decrease decision.
Additionally, to improve the robustness against fast changing radio conditions a
mechanism is implemented which, after a prior decrease step, checks whether con-
ditions worsened so much that now an increase step would be ordered. This check
is executed for the first time after the confirmation of the new power setting (which
means: for BTS power control immediately and for MS power control after 3 SACCH
periods) and then as long as (and if) the power control delay timer is running. This
avoids the delay of a necessary power increase step especially in cases with high
power control delay timer values and radio conditions that worsen considerably in
278 Id:0900d805805420ec A50016-G5100-B556-04-7620

the meantime. Also this mechanism is implemented for adaptive power control mode
only.
11.5 Attributes and configuration

Power control is configured on cell (BTS) level. The attributes are gathered in the PWRC
object subordinate to the BTS object.
Enabling/disabling power control

MS power control for speech calls is enabled/disabled including the selection of the
variant of power control (classic or adaptive) by setting the EMSPWRC (“enableMSPow-
erControl“) attribute; accordingly BTS power control for speech call is enabled/disabled
including the selection of the type of power control by setting the EBSPWRC (“enableB-
SPowerControl“) attribute:
EMSPWRC = CLASSIC / ADAPTIVE / DISABLED
EBSPWRC = CLASSIC / ADAPTIVE / DISABLED
MS and BTS power control for data and signalling connections are enabled via the cor-
responding attributes in the related Service Groups (SG-1 and SG-2 for signalling, SG-
7 ... SG-10 for data). For service dependent configuration, see also specific topic below.
g Power control for data and signalling connections stay disabled, if not enabled in the
related Service Groups. Speech calls can commonly be enabled without Service
Group settings.
Thresholds and constant step sizes

Thresholds:
The following thresholds for RXQUAL and C/Iaveraged values are defined:
Thresholds Attributes for MS power Attributes for BTS power

control (uplink) control (downlink)
low_lev_thresh LOWTLEVU LOWTLEVD
high_lev_thresh UPTLEVU UPTLEVD
low_qual_thresh LOWTQUAU LOWTQUAD
high_qual_thresh UPTQUAD UPTQUAD
Table 45 Power control threshold attributes
These threshold parameters are also valid for AMR calls.

The level thresholds are entered as dB values from 0 to 63 (0 = less than –110 dBm,
63 = more than –48 dBm).
The values for the quality thresholds are entered as C/I values in dB (since the
measured and averaged RXQUAL values are mapped to C/I values, see Averaging of
measurement results).
Relations between power control and handover threshold parameter values:
Imperative handovers are only triggered if dynamic power control has changed the
transmission power to the maximum value. Therefor the power control thresholds have
to be set in such a way that power changes occur earlier than handover indications. This
A50016-G5100-B556-04-7620 Id:0900d805805420ec 279

behaviour is achieved by setting the power control thresholds to higher receive level and
better receive quality than the corresponding handover thresholds (see Figure 113 and
compare with Figure 112 and chap. Quality and level handover).
The following rules should be followed in terms of the power control and handover
threshold attributes:
HOLTHLVDL < LOWTLEVD < LOWTLEVD + 2 · PWREDSS < UPTLEVD
HOLTHLVUL < LOWTLEVU < LOWTLEVU + 2 · PWREDSS < UPTLEVU
UPTQUAD < LOWTQUAD < HOLTHQUDL
UPTQUAU < LOWTQUAU < HOLTHQUUL
2ECEIVE LOW?LEV?THRESH
QUALITY (/
#LASSICPOWERCONTROL
POWERINCREASE
)NTER CELLHANDOVERDUETOLEVEL
GOOD
n n nPOWERREDUCTION
NOPOWERCHANGE
HIGH?QUAL?THRESH0#
MEDIUM
n
LOW?QUAL?THRESH0#
LOW?QUAL?THRESH(/
POOR

)NTER CELLQUALITY )NTRA CELLQUALITYHANDOVER
HANDOVER IFNOTSKIPPED
2ECEIVE
LOW MEDIUM HIGH LEVEL
0# 0#
LOW?LEV?THRESH?INTRA
(/
0#POWERCONTROL (/HANDOVER
Figure 113 Relations between power control and handover threshold parameter
values
Step sizes for power change:
Constant power increase step size and power reduction step size are administered with
the following attributes (there are no such attributes for adaptive power control):
– PWRINCSS (“powerIncrStepSize“): determines the power increase step size (2 dB
/ 4 dB / 6 dB)
– PWREDSS (“powerRedStepSize“): determines the power reduction step size (2 dB
/ 4 dB)
These step size parameters mainly refer to classic power control; they are also applied
in case of adaptive power when the conditions for slow power changes are fulfilled.
PWREDSS also determines the standard reduction step with 2 · PWREDSS defining an
area without power change in case of medium receive level and good receive quality
(see Figure 111 and Figure 112).
280 Id:0900d805805420ec A50016-G5100-B556-04-7620

A parameter is introduced in order to limit the number of allowed reduction steps. The
limit is applied to those calls that are hopping over the BCCH. This is necessary for those
mobile stations that currently have gain control problems, especially when the receiver
sensitivity cannot be switched fast enough between bursts on non-BCCH TRXs and the
BCCH TRX.
Averaging
Averaging windows are controlled by the PAVRLEV and the PAVRQUAL attributes.
The PAVRLEV (“pcAveragingLev“) attribute contains two sub-attributes. The first one,
“size” defines the size of the gliding averaging window for the measured RXLEV values.
The size of the averaging window determines the number of measurement samples (a
new measurement sample is received every 480 ms from the MEASUREMENT
REPORTs from the MS) over which the BTS calculates the arithmetic average. The
second one, “weight“, is the DTX weighting factor determining how much more sample
values shall be weighted for radio measurement results measured over a period with
voice activity.
The PAVRQUAL (“pcAveragingQual“) attribute contains the two sub-attributes “size”
and “weight” according to the PAVRLEV attribute with corresponding meaning.
g In order to achieve a suitable accuracy of the RXQUAL average value for AMR calls,
it is recommended to use a minimum RXQUAL averaging window size of 4.
Timer and speed of power changes

g Delay timers for consecutive power control steps are defined differently for classic
and adaptive power control.
• In case of classic power control, the PCONINT (“powerControlInterval“) attribute
determines the minimum time difference between two consecutive power control
increase or reduction steps (this is the delay timer) in units of 2 SACCH multiframes;
e.g. PCONINT = 2 means a delay of 4 SACCH multiframes.
The PCONINT timer is started immediately when the BTS power level was changed
and in case of a MS power level change only after the MS has confirmed the new
power level. While this timer is running (there are independent timers for BTS and
MS power control) the power control algorithm continues to fill the respective level
and quality averaging windows with new measurement samples.
In order to allow for the most exact power control decisions, the averaging windows
should be filled completely with new measurement samples that reflect the state
after the power level change. Therefore the value of PCONINT should correspond
to the size of the level or quality averaging window (whichever is longer):
E.g. PAVRLEV/PAVRQUAL = 4 – x ... PCONINT = 2, wait 4 SACCH multiframes
(since the granularity of PCONINT is 2 SACCH multiframes the value should be
rounded to the next higher value in case the longest averaging window length has
an odd value).
Minimum time between two consecutive power control steps:
With the power control settings
PAVRLEV = 2 – 1, PAVRQUAL = 2 – 1, PCONINT = 2 and if continuous RXQUAL
or RXLEV conditions trigger a continuous power increase or reduction, a power
control decision appears
– every 4th SACCH period in case of BTS power control (because of
PCONINT = 2).
A50016-G5100-B556-04-7620 Id:0900d805805420ec 281

– every 7th SACCH period in case of MS power control (additionally it takes 3

SACCH periods until the BTS receives the confirmation of power control change
from the MS; only then the PCONINT timer is started).
• In case of adaptive power control the delay timer is determined by the length of the
power control averaging window for RXQUAL values which is configured by the
PAVRQUAL (“pcAveragingQual“) attribute (in SACCH periods). Slight differences
are applied for MS and BTS power control:
– BTS power control: delay timer value = PAVRQUAL + 1
(the extension of the delay timer was implemented because the BTS always has
to wait at least one SACCH period for MEASUREMENT REPORT which mirrors
the result of the last BTS power control order)
– MS power control: delay timer value = PAVRQUAL – 1
(the reduction of the delay timer was implemented because at the time the delay
timer is started (after having received the MS power level confirmation), the first
new quality measurement is already contained in the current measurement
report from the MS, so this can be subtracted from the waiting time)
Minimum time between two consecutive power control steps:
With the power control settings
PAVRLEV = 2 – 1, PAVRQUAL = 2 – 1 and if continuous RXQUAL or RXLEV con-
ditions trigger a continuous power increase or reduction, a power control decision
appears
– in consecutive SACCH periods in case of BTS power control together with
- low receive level, or
- medium receive quality and high receive level, or
- fast power decrease condition and the calculated power reduction step value
lower than 4 dB.
– every 3rd SACCH period in case of MS power control together with
- low receive level, or
- medium receive quality and high receive level, or
lower than 4 dB.
(3 SACCH periods delay due to confirmation of power reduction by the MS)
– every 3rd SACCH period in case of BTS power control together with
- low receive quality but medium or high receive level, or
- high receive quality and medium receive level, or
higher than (or equal to) 4 dB.
(delay timer value = PAVRQUAL + 1 = 3)
– every 4th SACCH period in case of MS power control together with
- low receive quality but medium or high receive level, or
- high receive quality and medium receive level, or
higher than (or equal to) 4 dB.
(3 SACCH periods delay due to confirmation of power reduction by the MS; addi-
tional delay timer value = PAVRQUAL – 1 = 1)
In case of MS power control the PWRCONF (“powerConfirm“) attribute defines the
maximum interval for confirmation from the MS that the power command has actually
been executed in units of two SACCH multiframes. The timer administered with
PWRCONF is started after a new MS power level was set. As long as this timer is
running the BTS compares the received MS power level with the requested power level.
282 Id:0900d805805420ec A50016-G5100-B556-04-7620

If the timer expires before the MS confirmed the requested power level the power control
decision process is resumed.
Special behaviour for adaptive power control:
With adaptive power control, all sample values in the RXLEV averaging windows are
corrected by the respective power level change as if they were already received with the
changed power. For MS power control new UL RXLEV samples in the averaging window
are corrected until the power change was confirmed by the MS. Thus there is no need
for a delay and power control can be resumed without suspension.
On the other hand, if very big power increase steps are ordered in case of adaptive MS
power control, it might happen that, due to the fact that the MS can only increase the UL
transmit power with a certain speed (e.g. one power level step of 2 dB every 60 ms), it
may happen that the power confirmation of the MS indicates a power increase which is
smaller than the ordered one. In this case, the last sample which is received after the
power confirmation (assuming a power confirmation interval of 4 SACCH periods,
PWRCONF = 2) is corrected by only half the ordered power increase level.
Example: If the MS power control orders a power increase of 10 dB in the UL direction,
the BTS immediately adds the 10 dB increase to all samples that are currently in the
averaging window for UL RXLEV samples. The increase of 10 dB is also added to all
new arriving measurement samples, as long as the MS has not yet confirmed the power
change.
If in the next power confirmation the MS only confirms less than the ordered increase
step (increase of e.g. 6 dB), the BTS corrects the subsequent last measurement sample
(assuming a power confirmation interval of 4 SACCH periods, PWRCONF = 2) by
adding only half of the ordered power increase step (i.e. in this case 5 dB).
Example for time behaviour of classic BTS power control:
The following scenario may give an idea about what happens during the measurement
preprocessing and the resulting power control decision (classic power control).
Settings: EBSPWRC = CLASSIC, PWRINCSS = DB6, PWREDSS = DB2,
PCONINT = 2, PAVRLEV = 4 – 3, LOWTLEVD = 20, UPTLEVD = 40
Assuming perfect quality and the RXLEV measurement samples as indicated in the
table below the following power control decisions will be made:
– A power increase by 6 dB is performed if the averaged DL receive level is below 20
dB.
– A power decrease by 2 dB is performed if the averaged DL receive level is lower
than or equal to 22 dB (LOWTLEVD + PWREDSS).
– No power change is performed if 20 ≤ DL receive level < 22.
The table below shows the chronological sequence of measurements, power control
decisions and the power change results.
A50016-G5100-B556-04-7620 Id:0900d805805420ec 283

Measurement DL RXLEV DL RXLEV BTS power Intervall timer Power control

result number (full value) averaged level decision
254 23 – 10 –
255 23 – 10 –
0 23 – 10 – –
1 23 23 11 3
2 21 23 11 2
3 21 22 11 1
4 21 22 11 0 –
5 21 21 12 3
6 19 21 12 2
7 19 20 12 1
8 19 20 12 0 0
9 19 19 12 0 +
10 20 19 9 3
11 25 21 9 2
12 25 22 9 1
13 25 24 9 0 –
14 25 25 10 3
15 23 25 10 2
16 23 24 10 1
17 23 24 10 0 –
18 23 23 11 3
19 21 23 11 2
20 21 22 11 1
21 21 22 11 0 –
22 21 21 12 3
23 19 21 12 2
24 19 20 12 1
25 19 20 12 0 0
26 19 19 12 0 +
... ... ... ... ... ...
Table 46 Time progression of measurement results, power control decisions and power change results
Enabling/disabling power control due to “radio link failure warning”

Power control can be enabled/disabled in case a “radio link failure warning” occurs by
setting the EPWCRLFW (“enablePowerControlRLFW“) attribute to TRUE/FALSE.
284 Id:0900d805805420ec A50016-G5100-B556-04-7620

A “radio link failure” occurs when too much SACCH blocks arrive which MEASURE-
MENT REPORTs could not successfully be decoded. More in detail for every dedicated
channel (TCH or SDCCH) there is a radio link counter (also called “missing SACCH
counter” or “S-counter”) which is initially set to the value determined by the RDLNKTBS
(“radioLinkTimeoutBs”) attribute. Unsuccessful decoding of uplink SACCH messages in
the BTS leads to a decrease of the counter by 1, successful decoding to an increase by
2. When the counter reaches the value 0, the BTS sends a CONNECTION FAILURE
INDICATION with cause “radio link failure” to the BSC which initiates the release of the
whole dedicated connection. A “radio link failure warning” is indicated earlier, namely
when the radio link counter goes below a warning threshold defined by the PCRLFTH
(“pcRLFThreshold“) attribute. In this case the BTS immediately increases the TRX and
MS transmit power to the maximum. Of course the RDLNKTBS value must be greater
than the PCRLFTH value.
Service group specific configuration of power control

For each type of service, e.g. circuit-switched calls or ASCI calls, Service Groups com-
prising sets of power control parameters have been introduced in order to allow individ-
ual settings for desired services (e.g. SG<n>PCPAR, where <n> denotes the service
group number, contains the fields “enableMSPowerControl”, “PcLowerThresholdLe-
vUL”, ...). There are 14 Service Groups and for each Service Group the power control
can be configured individually, thus overriding the common settings described in the
previous topics for this service (and only for this service). The service specific parame-
ters affect thresholds as well as enabling power control.
Group Circuit switched service type Attribute

SG-1 Signalling on hopping channel SG1PCPAR
SG-2 Signalling on non hopping channel SG2PCPAR
SG-3 CS speech FR/EFR/ASCI(VBS/VGCS) on hopping channel SG3PCPAR
SG-4 CS speech FR/EFR/ASCI(VBS/VGCS) on non hopping channel SG4PCPAR
SG-5 CS speech HR on hopping channel SG5PCPAR
SG-6 CS speech HR on non hopping channel SG6PCPAR
SG-7 CS data up to 9.6 kbit/s or HSCSD 9.6 kbit/s on hopping channel SG7PCPAR
SG-8 CS data up to 9.6 kbit/s or HSCSD 9.6 kbit/s on non-hopping channel SG8PCPAR
SG-9 CS data up to 14.4 kbit/s or HSCSD 14.4 kbit/s on hopping channel SG9PCPAR
SG-10 CS data up to 14.4 kbit/s or HSCSD 14.4 kbit/s on non-hopping channel SG10PCPAR
SG-11 CS speech AMR FR on hopping channels SG11PCPAR
SG-12 CS speech AMR FR on non hopping channels SG12PCPAR
SG-13 CS speech AMR HR on hopping channels SG13PCPAR
SG-14 CS speech AMR HR on non hopping channels SG14PCPAR
SG-15 CS speech AMR-WB FR GMSK on hopping channels SG15PCPAR
SG-16 CS speech AMR-WB FR GMSK on non hopping channels SG16PCPAR
Table 47 Service groups for power control purpose
A50016-G5100-B556-04-7620 Id:0900d805805420ec 285

g Power control for data and signalling connections stay disabled, if not enabled in the
related Service Groups. Speech calls can commonly be enabled without Service
Group settings.
g If one parameter in a Service Group has been set to a certain value (not NULL), the
other parameters of this Service Group become significant and override the
common (service independent) values. If the parameters of the Service Group shall
not be used any more, all subordinate parameter values have to be set to NULL.
Configuration hints
In case of classic power control it is reasonable to put more weight on increasing power
rather than on reducing power. Suitable methods to achieve this include:
– Judicious choice of upper and lower decision thresholds
– Setting the power increase step size to a higher level than the power decrease step
size
g The decision thresholds and the choice of the specified power control parameters
shall be selected very carefully in order to prevent oscillation of the control loop, for
example a power decrease decision for quality reasons is followed by a power
increase decision for signal level reasons.
Maximum power levels of Mobile Stations

The range which the Mobile Station is capable of varying its radio frequency output
power is from its maximum output to its minimum, in steps of nominal 2 dB.
The maximum RF output power is determined by the power class of the Mobile Station
according to GSM Recommendation 05.05, section 4.1.1.
For RF power control purposes in the GSM 900 mobile network 15 power levels are
defined, starting from level 15 (13 dBm) up to the maximum peak power level P, corre-
sponding to level 0 for GSM Mobile Station class 1 (20 W) or to level 5 for GSM Mobile
Station class 4 (2 W handheld).
For RF power control purposes in the GSM 1800 mobile network, 10 power levels are
defined, starting from level 10 (10 dBm) for class 1 or level 13 (4 dBm) for class 2, up to
the maximum peak power level P, corresponding to level 0 for Mobile Station class 1
and level 3 for Mobile Station class 2.
Maximum TRX power reduction

Basically the limit for the power reduction due to BTS power control is determined by the
lower power control threshold, i.e. BTS power control does not adjust the power to a
level lower than LOWTLEVD. The parameter PCMBSTXPRL, however, provides
another possibility for a limitation of TRX power reduction which is not related to an
absolute DL RXLEV value (like LOWTLEVD) but to the relative power reduction with
respect to the maximum possible DL receive level (that applied before start of power
reduction) for a call. PCMBSTXPRL (“pcMaxBsTxPowerRedLev“) determines the
maximum power reduction due to power control which may be applied to a call in the
cell. This maximum allowed power reduction affects all calls in the BTS for which BTS
power control is applied.
This reduction is applied in addition to the static power reduction that may have been set
by the parameter PWRRED. However, the sum of both static power reduction and power
reduction due to power control can never exceed the maximum possible power reduc-
286 Id:0900d805805420ec A50016-G5100-B556-04-7620

tion steps supported by the BTSE (related to the maximum nominal output power of the
used CU resp. PA), which depends on the type and generation of BTSE.
Linking between AMR compression/decompression handover and power control

The basic implementation of AMR compression/decompression handover and Power
Control are based on separate algorithms. More in detail, the compression/decompres-
sion handover takes into account only the current C/I ratio, regardless of the already per-
formed power reduction. This leads to the situation that best suited connections for
compression handover might not be selected for handover. As a consequence, the
capacity gain achievable by dynamically switching to AMR HR codec modes cannot be
fully exploited. In order to avoid the above bad situation, a linking between the algo-
rithms of power control and compression/de-compression handover for AMR has been
introduced: For the decision on compression/decompression handover, the power
reduction due to power control is added to the current average C/I value.
The following attributes are related to the HAND object:
– EADVCMPDCMHO: flag for activation/deactivation of the use of the new primary
conditions for compression/decompression handover;
– HOTHCMPLVDL: DL condition for triggering compression handover.
– HOTHCMPLVUL: UL condition for triggering compression handover.
– HOTHDCMLVDL: DL condition for triggering decompression handover.
– HOTHDCMLVUL: UL condition for triggering decompression handover.
BTS power control correction in case of frequency hopping involving the BCCH
TRX
Normally, if BTS power control is enabled, the MS is informed about this by the BS
PWRC flag with value “1” in the SYSTEM INFORMATION TYPE 6 (SI6) or in the MEA-
SUREMENT INFORMATION (MI) message. This flag makes the MS suppress mea-
surement reports derived from the BCCH carrier in order to avoid the measurements to
be falsified by the 'full power' part of the BCCH (power reduction must not be used on
the BCCH carrier).
If frequency hopping is configured for the TCHs but disabled, which can happen either
if hopping is manually disabled (HOPP = FALSE) or automatically disabled (e.g. due to
failure of a TRX involved in a baseband frequency hopping system) – a frequency redef-
inition procedure is started which instructs the MSs in a cell to change the hopping
system in such a way that hopping shall continue with one frequency only (which is
always that frequency which is assigned to the TRX by the TRXFREQ parameter). Calls
that are served by a radio TCH which belongs to the BCCH TRX hop in this case on the
BCCH frequency only. In this case all measurement reports are suppressed (or declared
'not valid') by the MS – which means that neither handover nor power control is possible
for these calls.
In this case full handover functionality is ensured by enabling a BTS power control cor-
rection via the EBSPWCR (“enableBSPwrCorrection”) attribute. Setting EBSPWCR to
TRUE has the following results:
a) The BS PWRC flag is permanently set to “0” (= disabled) in the SYSTEM INFOR-
MATION TYPE 6 even if the database parameter indicates the opposite
(EBSPWRC = CLASSIC or EBSPWRC = ADAPTIVE).
b) The MS thus provides valid measurement reports even for the BCCH carrier.
c) The BTS takes care that the 'full power' part from the BCCH carrier is correctly sub-
tracted from the DL RXLEV values reported in the MEASUREMENT REPORTs.
A50016-G5100-B556-04-7620 Id:0900d805805420ec 287

Remark:
The BTS power control correction is managed differently for AMR-calls and non-AMR
calls in correspondence with the following table:
PWRC flag in SI6 or MI

EBSPWRC EBSPWCR
non-AMR calls AMR calls
CLASSIC/ADAPTIVE TRUE 0 1
CLASSIC/ADAPTIVE FALSE 1 1
DISABLED TRUE 0 0
DISABLED FALSE 0 0
Table 48 BTS power control correction: PWRC flag for AMR/non-AMR calls
11.6 Delayed power control for emergency calls

This feature allows that a MS, which starts an emergency call, transmits with maximum
power during the location procedure according to the U-TDOA (Uplink Time Difference
Of Arrival) method. Therefore the uplink power control is delayed for a certain time
period.
The delayed power control (resulting in UL transmission with maximum power) improves
the accuracy of the U-TDOA positioning results.
The feature is configurable (enabling/disabling, delay timer) by the user.
Functional details
The trigger for UL power control delay is the set up of an emergency call (not the U-
TDOA location request). The feature is not applied to call set up scenarios resulting from
non-emergency reasons.
In case of direct TCH assignment the UL power control delay is applied to the initially
allocated TCH, whereas in case of subsequent TCH assignment (after direct SDCCH
assignment) it is applied to both the initially allocated SDCCH and the subsequently allo-
cated TCH. After the expiration of the delay timer, the BTS starts the usual uplink power
control towards the Mobile Station.
UL power control delay is terminated if the TCH is released, i.e. it is not applied to a
channel, which might be assigned afterwards.
Restriction: UL power control delay does not run during the execution of the Directed
Retry procedure and for any type of intra-BSC handover.
Signal flow
When the BSC receives the establishment cause “Emergency Call” which is included in
the CHANNEL REQUIRED message from the BTS (as content of the Random Access
Information field), it sends back the “UL Power Control Delay” IE within the CHANNEL
ACTIVATION message to the BTS.
Parameters
– ULPWRDSUP (“uplinkPowerDelaySupport”): This parameter enables/disables the
UL power control delay for emergency calls.
288 Id:0900d805805420ec A50016-G5100-B556-04-7620

– ULPWRD (“uplinkPowerDelay”): This parameter defines the time delay (in seconds)
for which UL power control is delayed in case of emergency calls.
11.7 Temporary overpower

The temporary overpower feature induces the temporary increase of the DL transmis-
sion power by 2 dB or 4 dB on SACCH and FACCH under critical radio conditions.
This feature can reduce call drops, especially in AMR networks, where the robustness
of the signalling channels against bad C/I conditions does not match to the considerably
increased robustness of the AMR speech codecs. Usually call drops should occur only
if the coverage is so poor that also the traffic channel does no longer allow an undis-
turbed communication. As long as standard speech codecs (EFR, FR and HR) are used,
the robustness of the signaling channels (FACCH and SACCH) corresponds to the one
of the speech codec, which means that the call drop reliably indicates an unacceptable
quality of service (QoS) in the user channel. In AMR networks, however, AMR call drops
may happen due to degraded signalling performance although on the TCH the commu-
nication is still possible with an acceptably good QoS.
Preconditions
Temporary overpower (TOP) is only applied if all of the following conditions are fulfilled:
• Static power reduction is applied for the TRXs.
The BTS must have some power reserves when it already operates at the maximum
DL transmit power, and this is only the case if static power reduction is applied in the
cell. Only if the setting PWRRED = 2 (= 4 dB static power reduction related to the
maximum DL TX power capability of the CU, ECU or FlexCU) is applied, the men-
tioned temporary power increase of 4 dB is possible. Obviously, if PWRRED = 1, the
temporary power increase is limited to 2 dB.
• The TCH is using a GMSK-modulated speech codec and hopping is active with
more than one frequency in the hopping pattern (if the TCH does not use frequency
hopping (FHSYID = 0) or frequency hopping is temporarily disabled (with ‘pseudo’-
hopping on one frequency only), TOP is not applied.
• The TCH does not belong to the BCCH TRX.
This limitation arises from the impact of overpower on the neighbour cell measure-
ments. Any involvement of the BCCH in the hopping pattern (only possible if
HOPMODE = BBHOP) disables TOP for the affected TCH.
TOP activation trigger events

TOP is activated in the following cases:
• A bad radio link quality is detected. The radio link quality is regarded as “bad” when
the average DL RXQUAL value (averaged over the complete handover quality aver-
aging window as defined by the parameter HOAVQUAL) has exceeded a hardcoded
threshold. When RXQUAL ≥ 6.25 in DL direction, an overpower of 2 dB is
applied on all DL FACCH and SACCH bursts.
• A TCH is activated, regardless of the activation reason (i.e. no matter whether the
TCH is activated for TCH assignment, inter-cell handover or intra-cell handover) an
overpower of 2 dB is applied on all DL FACCH and SACCH bursts.
• FACCH message repetition is requested (see chapter Immediate downlink repeti-
tion of FACCH messages). In this case an overpower of 4 dB is applied on all sub-
sequent FACCH and SACCH bursts in DL direction.
A50016-G5100-B556-04-7620 Id:0900d805805420ec 289

Attributes
TOP is enabled by setting the ETOP (“enableTOP“) attribute subordinate to the BTS
object. TOP can be enabled separately per speech codec.
11.8 Derived handover power management

The derived handover power feature allows the target BTS and the MS to execute the
handover procedure with the suitable and estimated transmission power immediately
when the MS has switched to the target cell, i.e. the MS/BTS transmission power is
reduced – if reasonable – and must not be set to the maximum power.
The derived handover power feature helps to reduce the interference level in a cell:
Formerly a Mobile Station had been forced by the BSS system to transmit at the
maximum power level during the execution of a handover procedure (which increases
the interference affecting the overall quality). When the handover had been completed,
the Mobile Station started the normal power control algorithm to reduce the transmit
power to the optimal value. The benefit of power reduction during a handover covers the
first few seconds after the switch of the MS to the new cell (afterwards the power control
governs the power reduction).
Usually the maximum BTS/MS transmit power is not necessary in the target cell after a
power budget (“better cell”) handover has been performed, especially when the
handover margin (HOM) is set to a positive value and the MS power was already
reduced due to power control in the originating cell.
Derived handover power can be enabled separately in uplink and downlink direction.
Functional details
By means of the MS neighbour cell measurements that were used to detect the neces-
sity of the handover from the serving cell to the target cell, the pathloss between the MS
and the target BTS is calculated. Adding some correction factors and taking into account
some tolerances, the optimized transmission power (both in UL and DL) is determined,
that might often be lower than the maximum transmission power usable in the cell.
The target cell uses the transmission power calculated by the derived handover power
algorithm and maintained by the target cell until the handover has been completed and
new measurement averaging results have been calculated by the usual power control
algorithm.
Message flow
No new messages are introduced, only new information elements within already existing
messages are used. Figure 114 shows the message flow for derived handover power
management applied in UL and DL direction (for more details about the handover
process, see chap. Handover).
290 Id:0900d805805420ec A50016-G5100-B556-04-7620

MS BTS BSC Target

BTS
Measurement Report
(RXLEVTarget BTS )
Handover Cond. Indication
(RXLEVTarget BTS )
Channel Activation
(RXLEVTarget BTS ) Calculation:

MS TX Power,
BTS TX Power
Channel Activation Ack.
(MS TX Power)
Handover Command Handover Command
MS
(MS TX Power) (MS TX Power)
MS Power Cap. Indication
Switch to new Radio Channel

Handover Access
Physical Information
= TX (Transmit) Power
(here: 3/4 of Maximum)
... ... ...
Figure 114 Message flow for derived handover power management

The following steps are performed:
1. The MS in dedicated mode sends regular neighbour cell measurements to the
serving BTS including the RXLEVDL values of the neigbour cell’s/BTS’s BCCH sig-
nalling.
2. If the BTS detects a handover reason (especially for power budget handover), it
adds the averaged RXLEVDL values (measured by the MS) per neighbour cell (only
for GSM cells) to the neighbour cell list and sends this information to the BSC within
the INTERCELL HANDOVER CONDITION INDICATION message (cause ”better
cell”).
3. The BSC selects a radio resource for the target BTS and sends the related RXLEVDL
value (measured by the MS) to the target BTS as part of the CHANNEL ACTIVA-
TION message. An indication in which direction (UL and/or DL) the derived
handover power shall be performed is also added to this message (EUL and/or EDL
flag set to 1 in the “Derived Handover Power Information” IE).
4. The target BTS calculates the resulting optimum uplink and downlink transmission
power levels (MS TX power, BTS TX power) and sends the UL value to the BSC as
part of the CHANNEL ACTIVATION ACKNOWLEDGE message.
No further messaging regarding the DL power is required.
A50016-G5100-B556-04-7620 Id:0900d805805420ec 291

5. The BSC sends the MS POWER CAPABILITY INDICATION message to the target
BTS which checks if the calculated resulting MS TX power matches with the MS
power class. If the MS is not able to send with the calculated transmission power,
the value has to be reduced accordingly.
6. The BSC sends the MS TX power calculated by the target BTS to the MS as part of
the HANDOVER COMMAND message.
7. When the MS switches to the new channel related to the target BTS, it transmits with
the MS TX power received in the previous step.
8. The BTS sends with the calculated BTS TX power and inserts the resulting MS TX
power as "Ordered MS Power Level" into the L1 header of the SACCH messages.
Applicability
Derived handover power is supported for the following Circuit Switched (CS) services:
– Speech services (FR / EFR / HR / AMR HR / AMR FR)
– Data services (both transparent and not transparent) including HSCSD
– Signaling services (SDCCH–SDCCH handover with power budget criterion)
– ASCI Services
The derived handover power does not reduce the TRX power (downlink) of the BCCH
TRX.
Intra-cell handovers and inter-BSC handovers do not support the derived handover
power feature.
The Dual Transfer Mode feature does not support the derived handover power.
GSM <–> UMTS handovers are always external to the BSC and therefore do not support
the derived handover power feature.
Operation and maintenance attributes

The following attributes are used to configure the derived handover power feature:
Attributes related to the ADJC object:
• EDLDERHOPWR (“enableDLDerivedHOPower“): enables/disables the derived
handover power feature for intra-BSC handovers in downlink direction.
• EULDERHOPWR (“enableULDerivedHOPower“): enables/disables the derived
handover power feature for intra-BSC handover in uplink direction.
The value of EDLERHOPWR and EULDERHOPWR shall be set to TRUE only if the
target cell (pointed by this ADJC Object) is internal to the BSC and if the Power Control
feature is enabled for this target cell.
Attributes related to the PWRC object (the BTS Managed Object instance has to be
created previously, otherwise the PWRC object does not exist):
• ADDPATHLDBC (“additionalPathLossDualBandCell“): used in dual band cells (con-
centric cell and dual band standard cell) to define the estimated pathloss difference
between the pathloss for the BCCH TRX and the pathloss for the TRX in the band
different from that of the BCCH; the ADDPATHLDBC attribute can be set only if the
related cell is a dual band cell, otherwise it is not processed by the algorithm.
• DERHOPWRSM (“derivedHOPowerSecMargin“): defines the security margin to
support the tolerances related to BTS/Mobile Station receiver accuracy, BTS and
the Mobile Station transmitter power. This value is added to the measured/calcu-
lated downlink pathloss to get best conservative result.
292 Id:0900d805805420ec A50016-G5100-B556-04-7620

• EBSPWRC (“enableBSPowerControl“): enables/disables the Power Control in the

BTS and specifies the used method.
• ESTDLINT (“estimateDLInterference“): permits to define the estimated downlink
interference in those cell’s areas where incoming better cell handover can occur.
The attribute shall be set to a value different from Null, if there is at least one ADJC
object that points to the target BTS superordinate to this PWRC object and with
EDLDERHOPWR = TRUE.
• MULPWRRED (“maxULPowerReduction“): defines the maximum power reduction
in uplink direction that is ordered via the Handover Command to the involved Mobile
Station.
• MDLPWRRED (“maxDLPowerReduction“): defines the maximum power reduction
in downlink direction that is ordered via the Handover Command to the involved
Mobile Station.
11.9 (E)GPRS power control (complement to GSM power

control)
(E)GPRS specific DL power control is not provided by the BSS.
(E)GPRS specific UL power control is performed by the MS based on the received signal
strength. The MS calculates the RF outpower PCH on each individual uplink PDCH by
the following formula:
PCH = min ( Γ 0 – Γ CH – α · (C + 48), Pmax)
with:
• Γ 0: A kind of maximum power value, i.e. 39 dBm for GSM900, 36 dBm for
GSM1800.
• Γ CH: An MS and channel specific power control parameter sent from the BSS to
the MS within an RLC control message.
• α : A system parameter broadcast on PBCCH or sent to MS in an RLC control
message.
• C: The normalised received signal level at the MS (see 3GPP 45.008). In case a
PBCCH is configured and a power reduction is applied on this channel, the power
reduction value is added to the measured received level to get C.
• Pmax: The maximum allowed UL RF output power in the cell.
Power levels are expressed in dBm.
When the MS receives either a new Γ CH or α value, the MS uses the new value to
update the PCH. The MS uses the same output power on all four bursts within one radio
block. When accessing a cell on PRACH or RACH and before receiving the first power
control parameters during the packet transfer on the PDCH channel, the MS uses the
output power defined by Pmax. If a calculated output power is not supported by the MS,
the MS uses the supported output power that is the nearest to the calculated output
power.
MS measurements for power control

In packet transfer mode, the MS continuously monitors all BCCH carriers as indicated
by the BCCH allocation list (BA list, for GPRS) and the BCCH carrier of the serving cell.
In every TDMA frame, a received signal level measurement sample is taken on at least
A50016-G5100-B556-04-7620 Id:0900d805805420ec 293

one of the BCCH carriers, one after another. The signal level measurements of the
BCCH carrier of the serving cell are filtered as follows:
Cn = (1 – b) · Cn – 1 + b · RXLEVn
with:
• RXLEVn: The nth received signal measured by the MS
• Cn: The filtered RXLEV value of the measurements with numbers 1 up to n.
• b = 1 / (6 · TAVG_T) with TAVG_T as a configurable filter period parameter; b is a “for-
getting” factor (a small value of b results in a slowly diminishing of the weight of
previous measurements).
In case the measurements refer to PBCCH and a power reduction is applied for this
channel, the power reduction value is added to the measured received levels to get the
C values.
Alternatively, the MS can be instructed to measure the received DL power level on the
PDCH. In this case a modified filtering formula is applied.
Besides, The MS also performs measurements for power control when in packet idle
mode. In this case another modified filtering formula is applied.
For more information, see the GPRS global description manual.
Attributes
• GAM (“gamma”): This parameter defines the Γ CH value applied in the PCH formula.
The default value of 6 dB means basically that the MS always transmits with the
maximum allowed output power (33/30 dBm) unless the normalized receive level at
the MS side (C-value) exceeds –48 dBm.
• ALPHA (“alpha”): This parameter defines α value applied in the PCH formula.
ALPHA determines the influence of the MS receive level on the MS output power
calculation. If e.g. ALPHA = 0, C has no influence on the MS power and PCH is
constant (no power control). If ALPHA > 0, the MS power depends on the C-value.
• GMSTXPMAC (“gprsMsTxPwrMaxCch”): This parameter indicates Pmax an MS may
use when accessing the system when the PBCCH exists. Else – if PBCCH does not
exist –, MSTXPMAXCH (“msTxPwrMaxCcch”) is used.
• PCMECH (“powerControlMeasurementChannel): This parameter defines if the MS
shall measure the received DL power level on the BCCH or on the PDCH. PCMECH
corresponds to the 3GPP parameter PC_MEAS_CHAN.
• PRPBCCH (“powerReductionOnPbcch”): This attribute indicates the power reduc-
tion value used by the BTS on PBCCH blocks, relative to the output power used on
BCCH. PRPBCCH corresponds to the 3GPP parameter Pb.
• TAVGT (“tAverageTime”): This parameter corresponds to the 3GPP parameter
TAVG_T and indicates the signal strength filter period for power control in packet
transfer mode.
• TAVGW (“tAverageWeight”): This parameter corresponds to the 3GPP parameter
TAVG_T and indicates the signal strength filter period for power control in packet idle
mode.
294 Id:0900d805805420ec A50016-G5100-B556-04-7620

Radio network management Handover
12 Handover
12.1 Introduction
The handover (HO) process maintains a call in progress while the mobile subscriber is
moving through the network. Particularly no service interruption occurs when the mobile
subscriber moves from one cell of the network to another one. Furthermore handovers
are performed to optimize the communication in the network regarding the following
aspects:
– Link quality
– Minimization of interference (co-channel and adjacent channel interference)
– Management/optimization of traffic distribution
Generally speaking, a Mobile subscriber should have his/her call established to the
cell/BTS with the best link regarding the radio transmission conditions, which is usually
the nearest one, having the lowest path loss. In case of congestion in a cell, handovers
of calls to other cells, which are not congested, can improve the system capacity as well
as the interference conditions.
Configuration of the handover process is of great importance, otherwise Mobile Stations
communicating with not optimized BTSs (in terms of radio parameters) would suffer
from poor link quality.
The following criteria are used to evaluate a handover decision:
– For maintaining the link quality: Receive quality and receive level of the downlink
signals at the MS as well as receive quality and receive level of the uplink signals at
the TRX
– For minimization of interference: the absolute MS-BTS distance and the transmis-
sion power of the MS
– For optimization of the traffic distribution: the congestion state of the current cell and
of the adjacent cells
12.1.1 General procedure and overview

The handover process comprises the following sequence of steps and is illustrated in
Figure 115:
1. Measurements of parameters related to handover, see 12.2 Measurements
2. Preprocessing of the measurements (including averaging processes) and neigbour
cell bookkeeping, see 12.3 Measurement preprocessing; the preprocessing is per-
formed in the BTS
3. Handover decision process, see 12.4 Handover indication
4. Generation of the target cell list in the BTS, target cell evaluation and new channel
selection in the BSC/MSC, see 12.6 Generation of the target cell list
5. Handover execution (MS/BTS/BSC/MSC), see 12.7 Handover execution
A50016-G5100-B556-04-7620 Id:0900d805805383c7 295

Handover Radio network management
MS Measurements
RXLEV (DL), RXQUAL (DL)
RXLEV_NCELL(n)
TA (Timing Advance)
Measurement Report
(on SACCH)
BTS A Measurements Preprocessing BTS B

RXLEV (UL)
Averaging
RXQUAL (UL)
(all TRXs) Neigbour Cell Bookkeeping
Power Control Handover Indication Process
Creation of Target Cell List
Handover Condition
Channel Indication (HO cause; Channel
Activation Target Cell List) Activation
BSC A Handover Decision Process

Intra-cell Handover Inter-cell, Inter-BSC Handover Inter-cell, Intra-BSC
Selection of a new Handover
radio channel Target Cell Selection,
Selection of a radio
channel
Handover Required
(including a Target Cell List)
MSC Searching for the Target BSC BSC B
Handover
Request
Figure 115 Overview of the handover process
12.1.2 Classification of handovers

Handover categories
Different handover categories can be distinguished with respect to a cell, a BSS area or
a MSC area. These categories are represented in Figure 116. The handover categories
can be enabled or disabled by attributes listed in Table 51 below.
296 Id:0900d805805383c7 A50016-G5100-B556-04-7620

-3#" "3#"
(/(ANDOVER
)NTER -3#(/
)NTRA CELL(/
)NTRA -3#(/ )NTRA "33(/
"3#!
"3#!
-3#!
Figure 116 Handover categories

Intra-MSC and Inter-MSC handovers are also called external handovers.
Inter-cell handover from the serving cell to an adjacent cell normally occurs either
when the handover measurements show low RXLEV and/or RXQUAL values in the
current serving cell and a better RXLEV value in a surrounding cell, or when a surround-
ing cell allows the communication with a lower transceiver power level. This typically
indicates that a Mobile Station is on the border of the cell area. Inter-cell handover
between cells using different frequency bands is allowed for a multiband Mobile Station.
Intra-cell handover from one channel/timeslot in the serving cell to another chan-
nel/timeslot in the same cell is normally executed if the handover measurements show
a low RXQUAL value but a high RXLEV value in the serving cell. This indicates a deg-
radation of the quality caused by interference even though the Mobile Station is within
the serving cell. The intra-cell handover provides a channel with a lower level of interfer-
ence and this can be either a different timeslot on the same carrier or a timeslot on a
new carrier.
If an inter-cell handover is indicated, the BTS generates a list of preferred target cells by
comparing the receive levels of the current cell and adjacent cells and by evaluating the
A50016-G5100-B556-04-7620 Id:0900d805805383c7 297

power budget criterion (e.g. for sorting of the target cell list). This list is used for the final
handover decision to be made in the BSC (intra-BSS handover) or MSC (intra/inter-
MSC handover). For an external handover, when the final decision is taken by the MSC,
an indication that a handover is required is signalled to the MSC. For an internal intra-
BSS handover, the handover is initiated without the MSC, and the BSC executes it
autonomously. The MSC is informed after the successful execution. The BSC also
executes the intra-cell handover and informs the MSC after the successful execution.
Types of handovers
Table 49 shows the types of handover provided. The communication between MS and
BTS is handled via FACCH within the TCH for all these handover types except for the
forced handover, which is handled via SDCCH. For detailed information about the con-
ditions that are necessary to initiate a handover of a special type please see the sub-
chapters of 12.4 Handover indication.
Handover type Handover category

Extended cell handover Intra-cell
Concentric cell handover Intra-cell
Quality handover Inter-cell or intra-cell
RXLEV handover Inter-cell
Fast uplink handover Inter-cell
Distance handover Inter-cell
Power budget handover Inter-cell
Speed sensitive power budget handover Inter-cell
Traffic handover Inter-cell
Forced handover Inter-cell
Compression/decompression handover Intra-cell
(with or without AMR)
Table 49 Handover types
The first 6 handover types in the table (from extended cell handover to distance han-
dover) are imperative handovers, i.e. the handover must be performed if the related
handover conditions (based on RXLEV and RXQUAL measurements) are fulfilled.
Regarding the other handover types, the indication that a handover is advantageous,
does not necessary lead to a handover.
TCH and SDCCH handovers

Usually a handover situation occurs while a traffic channel between MS and BTS is
established. Consequently the handover conditions are evaluated on FACCH within
TCHs.
In case no TCH is established, but a SDCCH is allocated for the communication
between the MS and the BTS, a SDCCH handover is not necessary, if the SDCCH is
allocated only for a short time (which is the normal case). However a SDCCH connection
can endure for a longer time period due to features like Queuing, OACSU (Off Air Call
Set Up), SCI (Subscriber Controlled Input), SMS (Short Message Service point-to-point)
298 Id:0900d805805383c7 A50016-G5100-B556-04-7620

or advanced features like packet transmission. Moreover a SDCCH handover from one
cell to another cell could be advantageous during the call establishment procedure as a
mean for providing a successful call establishment when no TCH resource is available
on the current serving cell. Therefore handovers from one SDCCH to another SDCCH
are provided. The evaluation of handover conditions for SDCCH handovers refers to the
radio conditions (level, quality, power budget), affecting the related handover types.
Extended cell handovers are not possible for SDCCHs since SDCCHs are always
assigned to the double timeslot configuration; concentric cell handovers are also impos-
sible for SDCCHs since SDCCHs are always assigned to the complete area.
SDCCH-to-SDCCH handovers usually are inter-cell handovers. A quality intra-cell
handover between SDCCHs is possible if the new SDCCH is allocated on a different
timeslot or a different TRX.
Handovers from a SDCCH in one cell to a TCH in a neigbour cell is provided with the
forced handover (which is triggered by the Directed Retry feature).
Ranking of handovers
It is possible that the condition for more than one handover criterion is fulfilled. Therefor
the handover types are put in a priority order. Table 50 shows the usual priority order of
the handover types (1 = highest priority). This table also distinguishes between TCH
handovers and SDCCH handovers. Forced handover and traffic handover are not
included in the table and haven’t been assigned a priority because they do not compete
with the other handover types.
Handover type Evaluated Evaluated Priority Priority

on TCH on SDCCH TCH SDCCH
Extended cell handover yes no 1
Concentric cell handover yes no 2
Quality inter-cell handover yes yes 3 1
RXLEV handover yes yes 4 2
Distance handover yes yes 5 3
Power budget handover yes yes 6 4
Quality intra-cell handover yes yes 7 5
Fast uplink handover yes yes 8 6
Table 50 Handover priorities
If a handover attempt of higher priority fails, the concerned handover type can be tem-
porarily skipped to enable handover attempts of lower priority (dynamic and automatic
setting of the system internal skip_flag, please refer to chap. 12.4 Handover indication).
12.1.3 Attributes enabling/disabling handover types

Table 51 shows the main attributes for enabling (value: TRUE) or disabling (value:
FALSE) the different handover types. The attributes are related to the HAND Managed
Object, subordinate to the BTS Managed Object.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 299

Attribute Meaning
INTERCH Flag to enable/disable all inter-cell handover classes and types for TCHs
INTRACH Flag to enable/disable intra-cell handovers for TCHs due to quality and to compres-
sion/decompression (intra-cell handovers triggered directly from the BSC; O&M han-
dovers, preferred TRX handovers, enhanced pairing and upgrade of multislot calls are
not affected by the setting of this parameter)
LOTERCH Flag to enable/disable a BSS-internal inter-cell handover, i.e. if disabled, the handover is
handled as an inter-BSS HO, even if the first cell in the target cell list belongs to the same
BSS as the serving cell; the inter-cell handovers are managed by MSC
LOTRACH Flag to enable/disable a BSS-internal intra-cell handover, i.e. if disabled, the BSC con-
trolled intra-cell handovers are not allowed and the intra-cell handovers are managed by
MSC
IERCHOSDCCH Flag to enable/disable all inter-cell handover classes and types for SDCCHs
IRACHOSDCCH Flag to enable/disable all intra-cell handover classes and types for SDCCHs
EISDCCHHO Flag to enable/disable MSC-controlled SDCCH handovers (Directed Retry)
EXTCHO Flag to enable/disable extended cell handover
CONCELL Flag to define a cell as concentric which automatically enables concentric cell handover
CCDIST Flag to enable/disable distance impact on concentric cell handover
RXQUALHO Flag to enable/disable inter-cell handover due to quality (RXQUAL)
EQINTRACHTCH Flag to enable/disable intra-cell handover due to quality (RXQUAL) for TCHs
RXLEVHO Flag to enable/disable inter-cell handover due to level (RXLEV)
DISTHO Flag to enable/disable inter-cell handover due to distance
PBGTHO Flag to enable/disable power budget handover
DTMPBGTHO Flag to enable/disable the DTM power budget handover
DPGTHO Flag to enable/disable speed-sensitive handover
ININHO Flag to enable/disable the intra-cell handover from inner to inner area (“enableInnerIn-
nerHo”)
ENFORCHO Flag to enable/disable forced handover (Directed Retry)
EFULHO Flag to enable/disable the fast uplink handover
TRFHOE Flag to enable/disable the traffic uplink handover
EADVCMPDCMHO Flag to enable/disable the advanced compression/decompression handover algorithm
EUHO Flag to enable/disable intersystem handovers from GSM to UMTS
Table 51 Attributes enabling/disabling the handover types
Basic considerations for configurations

A BSS internal handover has the following advantages compared to intra/inter-MSC
handovers:
1. Lower signalling load on the A-interface
2. Lower processing load in the MSC
300 Id:0900d805805383c7 A50016-G5100-B556-04-7620

3. Faster handover execution

The following considerations should be taken into account:
• The BSS area (the set of BSCs and related BTSs) shall be adapted to the traffic
flows to reduce the inter-BSS handover rate.
• Normally the intra-cell handover should be enabled in order to allow a handover from
a channel with high interference to another channel with less interference within the
same cell.
• If the random frequency hopping is applied, it can be reasonable to disable intra-cell
handover, since the interference is approximately the same on all channels and no
improvement can be achieved by an intra-cell handover.
• The distance handover should be switched on: Otherwise a Mobile Station could
widely exceed the planned cell boundaries in the case of favorable radio conditions
at the serving cell without causing a handover. As a consequence, neighboring cells
could suffer from an excessive interference caused by this Mobile Station. Further-
more, there is a risk that the link quality decreases very suddenly (e.g. when the MS
turns around a corner) and there is a risk of call drop.
• If the power budget handover is disabled, no handovers are performed to put a call
into a "better cell" (lower radio transmission power). The power budget is calculated
and evaluated for ranking neighbor cells within the target cell list, which also has to
be compiled for mandatory handovers.
12.2 Measurements
Measurements are carried out on single bursts; however, the measurement results are
compiled over a measurement period of 480 ms (referring to the time required for trans-
mission of a SACCH message).
Measurements in uplink direction

In uplink direction the TRX measures the signal strengths (RSSI), the Bit Errors Rate
(BERs) and the Burst Shifts (BS). The BTS maps the RSSI and the BER values to
RXLEV and RXQUAL values (see below) and determines the timing advance (TA) from
the BS value (see below).
For active TCHs, RSSI and BS values are sampled over all bursts of a multiframe of
480 ms duration. All bursts transmitted by the MS during discontinuous transmission –
bursts for SID frames (Silence Description frames) and SACCH messages – are
sampled separately. For idle TCHs, only RSSI values are sampled.
On SDCCHs, RSSI and BS values are sampled over eight SDCCH bursts and four
SACCH bursts of a multiframe. The location of these bursts within a multiframe is depen-
dent on the sub-channel number.
At the end of a measurement period the average values are calculated and stored. The
BER of the Class 1 bits within a radio block is evaluated. If a FACCH message (between
TCH data) substitutes one or more bursts of a block, the measurement is discarded. The
BER values within a multiframe are compiled and stored.
Measurements in downlink direction and measurement reports

In downlink direction the MS measures the signal strengths (RSSI) and the Bit Error
Rates (BERs) of the serving cell and maps them automatically to RXLEV and RXQUAL
values (see below). Additionally the MS records the RXLEV values of monitored BCCH
A50016-G5100-B556-04-7620 Id:0900d805805383c7 301

carriers of up to six neighbour cells. In the same way as for the uplink direction the mea-
surements recorded within one measurement period are averaged.
An MS in dedicated mode gets knowledge about the BCCH frequencies of the neighbour
cells to be monitored via the SYSTEM INFORMATION TYPE 5 message and – in case
of 3G adjacent cells – MEASUREMENT INFORMATION messages from the network
(the network derives the list of neighbour cells to be monitored from the entries in the
ADJC and ADJC3G objects, see chap. Adjacent cells). In case of radio access network
sharing, i.e. different network operators partly use the same network elements (BTSs,
BSCs), the potential handover target cells to be monitored by an MS can be restricted
according to the subscriber’s IMSI, see IMSI based handover.
The MS regularly sends its measurement results of the serving cell and the neigbour
cells to the network on SACCH via MEASUREMENT REPORT messages (Example for
SACCH messaging illustrates such a message).
Permitted NCCs for measurement reporting:
The neighbour cells included in the MEASUREMENT REPORTs can be restricted to the
cells with certain permitted NCCs (Network Color Code, part of BSIC). If e.g. there are
two cells in the geographical neighbourhood using the same BCCH frequency or directly
adjacent BCCH frequencies (which the MS might misinterpret as the signal of the
allowed BCCH frequency due to co-channel interference), the NCC condition allows that
the MS only reports the one with the correct NCC. The NCCs to be allowed are set via
the PLMNP (“plmnPermitted“) attribute: A decimal value has to be entered which is
transformed to a binary 8-bit string where each position is related to a NCC value and a
“1” in the string indicates the related NCC as permitted.
Example: PLMNP = 82 corresponds to the binary value 1010010.
“NCC permitted” 0 1 0 1 0 0 1 0
Allowed NCCs 7 6 5 4 3 2 1 0
Table 52 Example for PLMNP usage
Thus PLMNP = 82 means that the only neighbour cells with the NCCs 6, 4 and 1 will be
reported.
The PLMNP value is sent to the MS as binary 8-bit string “NCC permitted” on the BCCH
(SYSTEM INFORMATION TYPE 2, together with the list of the allowed neighbour cell
BCCH frequencies) or on the SACCH (SYSTEM INFORMATION TYPE 6).
(PLMNP has no influence on cell reselection, i.e. the MS might attempt a cell reselection
to a cell with an NCC which is not included in “NCC Permitted” field. “NCC Permitted” is
included in the SYSTEM INFORMATION TYPE 2 only in order to inform the MS early
enough which cells are allowed for measurement reporting when it switches to 'busy'
mode.)
Enhanced measurement reports:
The MS uses ENHANCED MEASUREMENT REPORT messages instead of MEA-
SUREMENT REPORT messages if this is indicated by the parameter REPTYP (“report-
Type“) and if at least one BSIC is allocated to each BCCH Allocation list frequency.
Enhanced measurement reporting is only supported by particular mobiles and com-
prises additional functionalities:
302 Id:0900d805805383c7 A50016-G5100-B556-04-7620

• Much more than 6 neighbour cells can be reported within one message (while only
6 neighbour cells can be reported within one MEASUREMENT REPORT message).
• Additional measurement values are provided such as the Bit Error probability (BEP)
of the serving cell channel and the number of correctly received downlink blocks,
which can be used to determine the downlink Frame Erasure Rate (FER) which is
monitored by suitable PM counters in the BTS.
• Reporting is possible for both 'valid' and 'invalid' BSICs.
For more information about the ENHANCED MEASUREMENT REPORT message see
Messages for RRM management.
Mapping of measured level and quality values

The RSSI values (in dBm) are mapped to RXLEV values between 0 and 63 according
to the following table (RXLEV = 0 indicates the lowest receive level, RXLEV = 63 the
highest receive level):
RXLEV value RSSI range

0 equal to or less than –110 dBm
1 between –110 and –109 dBm
: :
63 greater than –48 dBm
Table 53 RXLEV mapping
The BER values are mapped to RXQUAL values between 0 and 7 (eight quality levels,
corresponding with 3 bits for RXQUAL in the “Measurement Results” IE) according to
the following table:
RXQUAL value BER range

0 < 0.2 %
1 0.2 % ... 0.4 %
2 0.4 % ... 0.8 %
3 0.8 % ... 1.6 %
4 1.6 % ... 3.2 %
5 3.2 % ... 6.4 %
6 6.4 % ... 12.8 %
7 > 12.8 %
Table 54 RXQUAL mapping
Mapping of burst shifts to timing advance (TA) values

The burst shift is the delay of a burst expressed as a number of bits, and it is detected
by means of the training sequence of a burst. The burst shift is used to calculate the
Timing Advance (TA) parameter; in case of extended cells and if the far area is con-
A50016-G5100-B556-04-7620 Id:0900d805805383c7 303

cerned, the Timing Offset (TO) parameter complements the TA. The TA and TO values
are related to Burst Shifts as follows:
The TA value indicates the round trip delay time (delay after one downlink and one
uplink transmission, i.e. twice the delay of a unidirectional burst due to the distance
between MS and BTS) as a number of bit periods. E.g. TA = 1 means a round trip delay
of one bit period, which is 48/13 μ s, TA = 13 means a delay of 13 bit periods. The
maximum delay in a not-extended cell is TA = 63 (i.e. 63 bit periods which corresponds
to a MS-BTS distance of 35 km). In case of the far area of an extended cell the round
trip delay is greater than 63 bit periods. Therefore the TA parameter is set to 63 and the
additional delay is indicated by the TO parameter.
An initial burst shift and TA (and TO if required) value is determined with the help of the
access burst, before establishing a dedicated channel for the affected MS. When acti-
vating the SDCCH and later the TCH, the initial TA value is reported in the Layer 1
header of the affected downlink SACCH message; the initial TO is used within the BTS.
During a call the MS reports its actual TA value to the BTS via the corresponding uplink
layer 1 header information of an UL SACCH message. If the average of the deviations
between the TA determined by the BTS and the TA reported by the MS exceeds 1 bit
period, the BTS increments/decrements the TA value by one and orders the new TA via
the Layer 1 header in the downlink SACCH message.
Forwarding measurement results to the BSC

Since the preprocessing of measurement reports for handover decisions is done in the
BTS, normally no measurement reports are sent from BTS to BSC. In some cases,
however, it is useful to monitor the measurement reports in uplink direction “after” the
Abis interface (after the BSC, e.g. in an O&M center), e.g. for test purposes. For this
case the measurement reports from the MS and the BTS can be forwarded to the BSC
by setting the RADIOMR (“radioMeasRep”) attribute, subordinate to the TRX object, to
ON.
If RADIOMR is set to ON, the frequency of the transmission of the measurement reports
via Abis interface to the BSC can be configured by the RADIOMG (“radioMeasGran”)
attribute, subordinate to the TRX object, too. RADIOMG specifies the granularity period
for retrieval of the measurement reports in the unit of 1 SACCH multframe. The lower
the value for RADIOMG, the higher is the signalling load on the LPDLRs. If the Abis has
to be traced for radio diagnostic of handover performance diagnostic reasons it is rec-
ommended to set the radio measurement granularity to '1' because only in this case all
measurement reports from the MS and the BTS will be transmitted on the Abis.
12.3 Measurement preprocessing

Averaging
All measurements for handover pass an averaging algorithm. Parameters are provided
for determining the averaging period (or averaging window) for each type of measure-
ment, i.e. the number of measurement samples over which the BTS calculates the arith-
metic average (regarding measurements from the MS, the BTS receives a new
measurement sample every 480 ms from the MS’s MEASUREMENT REPORT via
SACCH; the measurement samples gathered by the BTS’s own measurements are also
available every 480 ms). The averaging algorithm can be described as a 'gliding' aver-
aging window: when the window is completely filled and a new measurement is
received, the new measurement replaces the oldest measurement in the window.
304 Id:0900d805805383c7 A50016-G5100-B556-04-7620

Further handover processing (handover indication etc.) is based on the averaged

values.
The following measurements are averaged:
• RXLEV values:
For power budget handovers and other handover types not concerning inter-cell
handover due to level, the averaging period (in number of SACCH message periods)
is determined by the HOAVPWRB (“hoPowerBudget”; range: 1...31) attribute.
For inter-cell handovers due to level (precondition: RXLEVHO = TRUE) the averag-
ing period (in number of SACCH message periods) is determined by the “size” field
of the HOAVLEV (“hoAveragingLev”) attribute (range of “size”: 1...31).
In case of discontinuous transmission (DTX) and during periods without speech, the
SUB values from the MEASUREMENT REPORT are averaged (not the FULL
values; the SUB values are determined via a subset of received TDMA frames).
Since the statistical reliability of the SUB values is lower than of the FULL values a
weighting factor is provided by the “weight” field of HOAVLEV. The “weight” value
determines the factor with which the FULL values for a period with voice activity are
multiplied compared to the SUB values in periods without voice activity (range of
“weight”: 1...3).
The measured values in the averaging window are multiplied with the related
weights and then added. Eventually the total weighted sum is divided by the total
weight (i.e. all “weight” values within the averaging window are added up), see
Figure 117.
Sample 1 2 3 4 5 6 7 One sample each SACCH period (480 ms)

Averaging window, size = 4
Measured
RXLEV 28 31 32 27 22 28 21
Weight 1 1 2 2 1 2 1 7 Total weight
28 RXLEV average value

Weighted
RXLEV 64 54 22 56 196 Total weighted sum
28 : RXLEV_FULL value with weight 2 22 : RXLEV_SUB value with weight 1
Figure 117 Averaging RXLEV measurements

g
– In the SDCCH phase there are no TCH speech frames. For this reason only
the SUB values (determined from the SACCH frames) are considered for the
handover decision which are – as usual – inserted into the averaging window
as single values only.
– The size of the averaging window does not determine the minimum time the
BTS needs to trigger a level handover at the very beginning of a call, as the
BTS can trigger a level handover even if the averaging window is not yet
completely filled with measurement samples. For each setting of the averag-
ing window size there is a fixed defined minimum number of measurement
samples that are necessary for a handover decision.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 305

Averaging period Minimum number of samples

1 1
2 2
3 – 12 3
13 – 20 4
21 – 31 5
Table 55 Minimum number of samples dependent on the averaging period
– The averaging window size for the neighbour cell DL RXLEV measurements
is determined by the parameter HOAVPWRB (see below).
• RXQUAL values: The averaging period (in number of SACCH message periods) is
determined by the “size” field of the HOAVQUAL (“hoAveragingQual”) attribute
(range of “size”: 1...31). The “weight” field determines the weighting factor regarding
DTX in the same way as for HOAVLEV.
g
– In the SDCCH phase there are no TCH speech frames. For this reason only
the SUB values (determined from the SACCH frames) are considered for the
handover decision which are – as usual – inserted into the averaging window
as single values only.
– The size of the averaging window does not determine the minimum time the
BTS needs to trigger a handover at the very beginning of a call, as the BTS
can trigger an imperative handover even if the averaging window is not yet
completely filled with measurement samples. For quality handovers, the
averaging window is initialized with values RXQUAL = 0. If the first samples
have been inserted into the window, the BTS can trigger a quality handover,
if the RXQUAL average exceeds the defined threshold, even if less samples
have been received than places are foreseen in the averaging window.
The RXQUAL averaging leads to real values between 0 and 7. These values are
mapped to C/I integer values between 0 and 20 as described in chap. Power control.
• TA values: The averaging period (in number of SACCH message periods) is deter-
mined by the HOAVDIST (“hoAveragingDistance”; range: 1...31) attribute.
• Downlink RXLEV values for neighbour cells: The averaging period (in number of
SACCH message periods) is determined by the HOAVPWRB (“hoPowerBudget”;
range: 1...31) attribute again; one result is obtained for each neigbour cell.
The averaging parameters are subordinate to the HAND object.
Neigbour cell bookkeeping

The BTS maintains a bookkeeping list for each possible adjacent cell in which the neigh-
bour cell measurements of the Mobile Station are stored. This bookkeeping list is the
basis for the evaluation of the power budget criterion, for the generation and for the
sorting of the target cell list. The Mobile Station’s neighbour cell measurements
comprise RXLEV samples of up to six monitored BCCH carriers and these samples are
identified by the BSIC and the BCCH’s frequency number (ARFCN).
306 Id:0900d805805383c7 A50016-G5100-B556-04-7620

Calculation of the MS-BS distance

The MS-BTS distance is calculated via the TA (timing advance) and TO (timing offset)
values by the following formula:
MS-BTS distance = v · t · TA / 2 (in case of not-extended cells)
MS-BTS distance = v · t · (63 + TO) / 2 (in case of extended cells and TO > 0)
with:
v = 3 · 108 m/s (velocity of light)
t = 48/13 μ s (1 bit period)
12.4 Handover indication

General considerations
Handover indications are based on radio conditions or on network criteria, see Table 56.
Radio conditions are controlled by thresholds configured via attributes of the HAND
object subordinate to the BTS object. The HAND object for a cell is automatically created
after the creation of the related BTS and the attributes of the HAND object get their
default values. These default values can be changed by applying the SET HAND
command.
Criterion Purpose Classification

Control by radio conditions
Receive quality
Maintain quality
Receive level Imperative handover
MS-BTS distance
Minimize interference
Power budget Power budget handover
Control by network
Traffic load Traffic handover
Directed retry Traffic management
Forced handover
Preemption
Table 56 Main criteria for handover indication
The following descriptions refer mainly to threshold considerations (except for forced
handover). For enabling handover types please refer to chap. 12.1.3 Attributes
enabling/disabling handover types.
Signal-noise discrimination regarding access bursts on FACCH

In the BTS a threshold for the received power level is used to discriminate between a
received valid access burst and received noise on the FACCH. Such an access burst
initiates e.g. an inter-cell handover. If the received power level exceeds the threshold,
the received signal is treated as a valid burst, otherwise the timeslot is declared empty.
The threshold is determined by the FACHBT (“fachBusyThreshold“) attribute subordi-
nate to the BTS object. A low dBm value for the FACCH threshold ensures a high uplink
A50016-G5100-B556-04-7620 Id:0900d805805383c7 307

sensitivity of the BTS for incoming handover messages on the FACCH and for ASCI
uplink access bursts. This supports a low handover failure rate.
g There is another and independent threshold for signal-noise discrimination on
RACH (relevant for channel requests) determined by the RACHBT (“rachBusyTh-
reshold“) attribute.
12.4.1 Extended cell handover

Extended cell handover is the intra-cell handover between a single timeslot channel and
a double timeslot channel and vice-versa.
The maximum propagation delay within usual one-timeslot channels allows a maximum
BTS-MS distance of 35 km. In extended cells, the user can configure the TCHs as
double timeslot channels where two subsequent timeslots are used for the transmission
in the far area of the cell (> 35 km) in order to allow longer propagation delays, see
Figure 118.
Extended cell
near area far area
up to 35 km up to 100 km
single timeslots
double timeslots
Figure 118 Single and double timeslots in an extended cell
Attributes
The EXTCHO (“enableExtendedCellHo“) attribute of the HAND object allows
enabling/disabling this type of handover.
The following threshold attributes have been introduced for the handover indication:
• HOMSTAM (“hoMsTaMax“): The maximum permitted distance for using a single
timeslot channel
• HOMRGTA (“hoMarginTa“): A hysteresis amount used to prevent handover oscilla-
tion when a MS leaves the extended area and enters the single timeslot area
Handover condition
If the averaged absolute MS-BTS distance exceeds the HOMSTAM threshold, the
handover from a single timeslot channel to a double timeslot channel is indicated. If the
MS-BTS distance subsequently falls under HOMSTAM – HOMRGTA, the handover
from double timeslots to single timeslots is indicated.
308 Id:0900d805805383c7 A50016-G5100-B556-04-7620

Note that in case of HOMRGTA > HOMSTAM (i.e. HOMSTAM – HOMRGTA < 0) no
handovers from double timeslots to single timeslots are ever indicated.
Skipping handover attempts

If an extended cell handover is requested, but it can not be performed due to a lack of
resources, the evaluation of the extended cell criteria is skipped the next time in order
to facilitate the evaluation of other handover criteria (e.g. quality, level etc.). If the sub-
sequent handover attempt is also unsuccessful or if no other handover type can be
detected, then the skipping is switched off and the extended cell handover indication
process is enabled again. This toggling is done by automatically changing the setting of
the system internal skip_flag from FALSE (no skipping, the extended cell handover
process is enabled) to TRUE (the extended cell handover process is skipped) and vice
versa.
Examples
The following configurations and conditions trigger an extended cell handover indication
from single timeslots to double timeslots:
– EXTCHO = TRUE
– DISTANCEMS–BTS > HOMSTAM
– skip_flag = FALSE
The following configurations and conditions trigger an extended cell handover indication
from double timeslots to single timeslots:
– EXTCHO = TRUE
– DISTANCEMS–BTS < HOMSTAM – HOMRGTA
12.4.2 Concentric cell handover

Concentric cell handover is the intra-cell handover between the inner area and the
complete area and vice versa.
Two areas are defined for concentric cells: the inner area and the complete area. The
distinguishing parameter between the inner area and the complete area is the maximum
permissible transmission power level, which is lower in the inner area.
Attributes
The concentric cell handover indication procedure is already enabled when the cell is
defined as concentric cell by setting the CONCELL attribute to TRUE.
The following threshold attributes are defined for the handover indication:
• HORXLVDLI (“hoRxLevDLinner“): The RXLEV threshold in downlink direction for an
intra-cell handover from the inner area to the complete area
• HORXLVDLO (“hoRxLevDLouter“): The RXLEV threshold in downlink direction for
an intra-cell handover from the complete area to the inner area
• CCDIST (“enableConCellDist“): allows to enable/disable the impact of distance on
the handover decision in addition to the HORXLVDLO attribute
• HOCCDIST (“hoConcentricCellDistance“): The distance limit between the inner and
complete area
A50016-G5100-B556-04-7620 Id:0900d805805383c7 309

Handover condition
The handover indication is based on the comparison of downlink RXLEV measurements
with thresholds, the TRX transmission power is also regarded; additionally the BTS-MS
distance can be taken into account by the attribute CCDIST (the value TRUE enables
the BS-MS distance impact, the value FALSE disables it). A concentric cell handover is
indicated, if the sum of the averaged downlink receive level and the TRX power reduc-
tion due to power control goes below the HORXLVDLI value or exceeds the HORX-
LVDLO value (the power reduction value is taken into account because the averaged
downlink receive level could be increased with the amount of power reduction by exploit-
ing the power control resource).
Additional considerations
The HORXLVDLO value must be greater than the HORXLVDLI value. Additionally the
difference between HORXLVDLO and HORXLVDLI attributes must be greater than the
difference between the maximum BTS transmit power in the inner and complete area
(assigned in dB).
If a concentric cell handover is requested, but it can not be performed due to a lack of
resources, the evaluation of the concentric cell criteria is skipped the next time in order
to facilitate the evaluation of other handover criteria (e.g. quality, level etc.). If the sub-
sequent handover attempt is also unsuccessful or if no other handover type can be
detected, then the skipping is switched off and the concentric cell handover indication
process is enabled again. This toggling is done by automatically changing the setting of
the system internal skip_flag from FALSE (no skipping, the concentric cell handover
process is enabled) to TRUE (the concentric cell handover process is skipped) and vice
versa.
Examples
The following configurations and conditions trigger a concentric cell handover indication
from the inner area to the complete area without regarding the BTS-MS distance:
– CONCELL = TRUE
– CCDIST = FALSE
– RXLEVDL, averaged + power_redUL, averaged < HORXLVDLI
from the inner area to the complete area including the BS-MS distance impact:
– CONCELL = TRUE
– CCDIST = TRUE
– RXLEVDL, averaged + power_redUL, averaged < HORXLVDLI or
DISTANCEMS–BTS > HOCCDIST
from the complete area to the inner area including the BTS-MS distance impact:
– CONCELL = TRUE
– CCDIST = TRUE
– RXLEVDL, averaged + power_redUL, averaged > HORXLVDLO and
DISTANCEMS–BTS < HOCCDIST
– skip_flag= FALSE
310 Id:0900d805805383c7 A50016-G5100-B556-04-7620

12.4.2.1 Inter-cell handover into a concentric cell

Under normal conditions any incoming handover to a concentric cell is always executed
to a TCH belonging to the complete area, even if the level and distance conditions allow
an assignment of a TCH belonging to the inner area of the target cell. In this case the
inter-cell handover to the complete area of the target cell is directly followed by a
complete-to-inner intra-cell handover within the target cell. Such unnecessary han-
dovers can be avoided by allowing handovers directly into the inner area of the target
concentric cell.
The following procedure is applied:
When an inter-cell handover is indicated, the BTS sends a HANDOVER CONDITION
INDICATION message to the BSC. In this message the BTS delivers a list of preferred
target cells. The BSC may decide in favor of handover into a concentric cell. In this case
and if the handover directly into the inner area of the target cell is enabled, the BSC
transmits the PREFERRED AREA REQUEST message to the BTS. This message
contains the global cell identifier of the chosen colocated neighbour target cell, threshold
values and the O&M parameters of the neighbour cell. Based on these thresholds and
the measured RXLEV value of the target cell, the BTS answers with a PREFERRED
AREA message which suggests either a 'complete' area TCH or an 'inner' area TCH. If
the BTS suggests an inner area TCH in the PREFERRED AREA message, the BSC
directly activates the target TCH on an inner area TRX (if available) and sends the cor-
responding TCH information to the MS in the HANDOVER COMMAND. (The handover
mechanism described here is equal to the algorithm used for concentric cell handover
except for the preferred area negotiations.)
Two cases are distinguished:
• Colocated concentric cells:
Figure 119 shows the principle of colocated concentric cells. A (sector) cell can be
colocated with two adjacent (sector) cells, the colocation is represented in the HAND
object of the cell by the CELL1 and CELL2 attributes. The two cells colocated to the
current cell can be target cells for the handover directly into the inner area.
3ECTOR 3ECTOR
/WNCELL #OLOCATEDCELL
)NNER TO INNER
HANDOVER
3ECTOR
#OLOCATEDCELL
Figure 119 Inner-to-inner-area handover between colocated concentric cells

• Only the target cell is concentric (no restriction regarding colocated concentric cells)
A maintenance attribute (bit 34 of the MNTBMASK attribute) allows to toggle between
the two cases. If the first alternative is enabled (inner area handovers in case of colo-
A50016-G5100-B556-04-7620 Id:0900d805805383c7 311

cated concentric cells), the second one is disabled (i.e. such handovers are allowed for
colocated concentric cells only); if the second alternative is enabled (only the target cell
is concentric for an inner area handover), the colocation conditions of the first alternative
are meaningless.
Attributes
The following attributes are used:
– ININHO (“enableInnerInnerHo“): allows to enable/disable handovers directly into the
inner area of a concentric target cell.
– HORXLVDLO (“hoRxlevDLouter”): defines the receive signal threshold level in
downlink direction. If the actual downlink receive level of the target concentric cell
exceeds the threshold value, the handover directly to the inner area of the target cell
is performed (this attribute is also used for intra-cell concentric cell handovers).
– CCDIST: allows to enable/disable the impact of distance on the handover decision
in addition to the HORXLVDLO attribute (this attribute is also used for intra-cell con-
centric cell handovers).
– HOCCDIST: determines the distance limit for the handover decision in addition to
the HORXLVDLO attribute. If the distance between the BTS of the concentric target
cell and the MS is lower than this distance limit, the handover can be performed (this
attribute is also used for intra-cell concentric cell handovers).
– Bit 34 of the MNTBMASK attribute: Allows to restrict this type of handover to colo-
cated concentric cells only or to avoid the restriction.
Remarks
HOM is used as a threshold to prevent repetitive handover between adjacent cells,
should the handover be caused by received signal level or power budget process.
Depending on the values of HOM, a subsequent handover into the inner area after a pre-
ferred area decision into the complete area could be performed: preferred area decision
for the adjacent cell is based on the averaged values. The averaged receive level of the
neighbour cell is always lower than the current value because the oldest (= lowest)
values reduce the average. After the handover execution to the adjacent cell, the previ-
ously highest value of the receive level is now the lowest and a complete-to-inner
handover may be indicated. There is no provision for back handover prevention after
handover chains.
12.4.3 Quality and level handover

Figure 120 shows the basic conditions indicating handovers due to quality and level, and
the interactions between quality and level handovers as well. It is assumed that inter-cell
and intra-cell handovers are enabled and possible.
The handover indication algorithm for handover due to quality or level contains the fol-
lowing main characteristics:
– In case of low receive level and receive quality an inter-cell handover due to quality
is indicated.
– In case of very low receive level, but sufficient receive quality an inter-cell handover
due to level is indicated.
– In case of bad receive quality, but sufficient receive level an intra-cell handover due
to quality is indicated, assumed that intra-cell handover is possible; if in this case an
intra-cell handover is not possible, an inter-cell handover due to quality is indicated.
312 Id:0900d805805383c7 A50016-G5100-B556-04-7620

– In case the receive level and receive quality are sufficiently high, no level or quality
handover is indicated. Other handover types are still possible, e.g. handover due to
power budget or traffic handover.
Receive
Quality
Inter-cell No handover
good
handover due to quality or level
due to
level (power budget handover etc. possible)
low_qual_thresh
Intra-cell handover due to quality
Inter-cell handover
poor
due to quality (inter-cell handover due to quality

if intra-cell handover is skipped)
very low low medium and high

Receive Level
low_lev_thresh low_lev_thresh_intra
Figure 120 Overview: quality and level handover

The following sub-chapters 12.4.3.2 Level handover and 12.4.3.1 Quality handover
describe the specific handover indications and provided parameters in detail.
12.4.3.1 Quality handover

Quality handover is an intra-cell or inter-cell handover caused by a bad radio transmis-
sion quality (high BER and RXQUAL values, low C/Iaveraged values).
Attributes
The RXQUALHO attribute of the HAND object allows enabling/disabling this kind of han-
dover. In case of an inter-cell handover, the INTERCH attribute has to be set to TRUE,
in case of an intra-cell handover, the INTRACH and the EQINTRACHTCH
(“enableQualityIntraCellHoTCH“) attribute have to be set to TRUE.
The following threshold attributes have been defined for the indication of an a quality
handover:
• HOLTHQUUL: The critical receive quality in uplink direction for inter-cell handover
• HOLTHQUDL: The critical receive quality in downlink direction for inter-cell
handover
• HOTULINT: The critical receive quality in uplink direction for intra-cell handover
• HOTDLINT: The critical receive quality in downlink direction for intra-cell handover
• MSTXPMAXGSM: The maximum allowed MS transmission power in the GSM fre-
quency band (or MSTXPMAXDCS or MSTXPMAXPCS in case the DCS or PCS fre-
quency band is used)
Handover condition
In case of inter-cell quality handover the evaluation of the handover condition is not per-
formed unless the capabilities of the power control have been exhausted (e.g. the
current transmit power of the MS / BTS has reached the maximum permitted value).
A50016-G5100-B556-04-7620 Id:0900d805805383c7 313

The quality handover is indicated, if the following conditions are fulfilled:

1. The averaged uplink receive quality and the averaged downlink receive quality, both
in C/I terms, fall below the relevant quality thresholds.
2. In case of inter-cell handover the maximum transmission power is reached.
If the averaged uplink receive level and the averaged downlink receive level are lower
than (or equal to) the relevant RXLEV thresholds for an intra-cell quality handover, an
inter-cell quality handover is indicated, otherwise (with sufficiently good receive level) an
intra-cell quality handover is indicated. A switching mechanism from intra-cell handover
indication to inter-cell handover indication is provided for the case that the intra-cell
handover condition is fulfilled but the first intra-cell handover attempt has failed (see the
topic below).
Examples
The following configurations and uplink conditions trigger an inter-cell quality handover
indication:
– INTERCH = TRUE
– INTRACH = TRUE (not required for inter-cell quality handover)
– RXQUALHO = TRUE
– EQINTRACHTCH = TRUE (not required for inter-cell quality handover)
– Current MS transmit power: MSTXPMAXGSM (or MSTXPMAXDCS or MSTXP-
MAXPCS)
– C/IUL, averaged < HOLTHQUUL
– RXLEVUL, averaged < HOTULINT (inter-cell handover condition)
The following configurations and downlink conditions trigger an intra-cell quality
handover indication:
– INTERCH = TRUE (not required for intra-cell quality handover)
– INTRACH = TRUE
– RXQUALHO = TRUE
– EQINTRACHTCH = TRUE
– C/IDL, averaged < HOLTHQUDL
– RXLEVDL, averaged > HOTDLINT (receive level high enough for intra-cell handover)
– skip_flag = FALSE (default value; intra-cell handover is not skipped; see below)
Automatic switching from intra-cell handover to inter-cell handover indication

In case intra-cell and inter-cell handovers are enabled (INTRACH = TRUE and
INTERCH = TRUE), the system internal (not administrable) skip_flag allows to switch-
from intra-cell handover indication to inter-cell handover indication as follows: The
skip_flag is basically set to FALSE for every busy TCH. When an intra-cell handover due
to quality is indicated, the skip_flag is automatically set to TRUE for the used TCH. If the
handover is successfully completed, the TCH is released and the skip flag has no rele-
vance anymore. However, if the call remains on the same TCH (which means that the
handover attempt could not be successfully completed) and another quality handover
decision is made while the skip_flag is TRUE, the BTS indicates an inter-cell handover
(quality) and not an intra-cell handover.
314 Id:0900d805805383c7 A50016-G5100-B556-04-7620

12.4.3.2 Level handover

The level handover is an inter-cell handover due to detection of a low downlink receive
level mainly.
Attributes
The RXLEVHO (“enableRxLevHo“) attribute of the HAND object allows enabling/dis-
abling this kind of handover. Because the RXLEV handover is an inter-cell handover,
the INTERCH attribute has to be set to TRUE.
The following threshold attributes have been defined for the indication of an RXLEV han-
dover:
• HOLTHLVUL (“hoLowerThresholdLevUL“): The critical receive level in uplink direc-
tion
• HOLTHLVDL (“hoLowerThresholdLevDL“): The critical receive level in downlink
direction
Handover conditions
A level handover is indicated when all of the following conditions are fullfilled:
1. The averaged uplink receive level falls under the HOLTHLVUL threshold or the
averaged downlink receive level falls under the HOLTHLVDL threshold.
2. The received quality is sufficient not to trigger the indication of a quality handover
(see 12.4.3.1 Quality handover).
3. The transmit power of the MS and BTS is at the maximum permitted or possible
value (level handover is not performed unless the capabilities of the power control
have been exhausted).
Examples
The following configurations and downlink conditions trigger a level handover indication:
– INTERCH = TRUE
– RXLEVHO = TRUE
– Current BTS transmit power: 0 (i.e. maximum)
– RXLEVDL, averaged < HOLTHLVDL (low RXLEV values mean low receive signal
strength)
– C/IDL, averaged > HOLTHQUDL (no quality handover)
The following configurations and uplink conditions trigger a RXLEV handover indication:
– INTERCH = TRUE
– RXLEVHO = TRUE
– Current MS transmit power: MSTXPMAX (i.e. maximum)
– RXLEVUL, averaged < HOLTHLVUL
– C/IUL, averaged > HOLTHQUUL (no quality handover)
12.4.4 Distance handover

Distance handover is an inter-cell handover to a target BTS with lower distance to the
MS than the current BTS.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 315

Attributes
The DISTHO (“enableDistanceHo“) attribute of the HAND object allows enabling/dis-
abling the handover due to the distance between the MS and the BTS.
Because the distance handover is an inter-cell handover, the INTERCH attribute has to
be set to TRUE.
The following threshold attributes are defined for the handover indication:
• HOTMSRM (“hoThresholdMsRangeMax“): The maximum permitted distance
between the MS and the current BTS
• HOTMSRME (“hoThresholdMsRangeMaxExt“): The maximum permitted distance
between the MS and the current BTS in the case of an extended cell
The limit for the distance handover shall be lower than the limit for call release for the
excessive distance (the call release criterion has a higher priority than any handover cri-
terion).
Handover condition
If the averaged absolute MS-BTS distance exceeds the relevant threshold, the distance
handover is indicated.
Example
The following configurations and conditions trigger a distance handover indication:
– INTERCH = TRUE
– DISTHO = TRUE
– DISTANCEMS–BTS > HOTMSRM (for not extended cells) or
DISTANCEMS–BTS > HOTMSRME (for extended cells with double timeslots only)
12.4.5 Power budget handover

The power budget handover is a non-imperative handover for changing to a cell with a
better power budget (“better cell”). Roughly speaking the power budget is determined
by the ratio between maximum allowed/possible UL transmit power and DL receive level
(in dB terms the ratio becomes a difference). The power budget is lower in case of a
better cell allowing for minimizing transmitter power levels and interference.
Attributes
• PBGTHO (“enablePowerBudgetHo“): This attribute (subordinate to the HAND
object) enables/disables (PBGTHO = TRUE/FALSE) power budget handover. Since
this kind of handover is an inter-cell handover, the INTERCH attribute has to be set
to TRUE.
• HOM (“hoMargin“): This parameter defines a threshold for the power budget han-
dover. The main purpose of the handover margin is to prevent back-and-forth
handover repetitions between adjacent cells ('ping pong handover'), e.g. if a MS
moves along a boundary between two cells. Therefore the application of HOM is
associated with a timer (see 12.8 Handover prevention procedures). Different
adjacent cells can be assigned different handover margins in order to control the
handover flow.
• RXLEVMIN (“rxLevMinCell”): The minimum received signal level which the adjacent
cell must have to be regarded as a suitable target cell for handover. It is the minimum
RX level required for a MS to perform the handover to the adjacent cell.
316 Id:0900d805805383c7 A50016-G5100-B556-04-7620

For a hierarchical cell structure the following priority parameters have been defined:
– PL (“priorityLayer”): the priority layer of the serving cell (0: highest priority; 15: lowest
priority, PL is related to the HAND object).
– PLNC (“priorityLayerNCell”): the priority layer of the neighbour cell (0: highest prior-
ity; 15: lowest priority, PLNC is related to the ADJC objects).
Handover conditions
The indication/decision for a power budget handover is made always after the handover
decisions for imperative handovers (level handover, quality handover, distance han-
dover) have been deployed.
A power budget handover is indicated if all of the following criteria are fullfilled:
– The power budget condition is fulfilled: PBGT(n) > HOM(n) (n indicates the neigh-
bour cell n, see below).
– Appropriate target cells are available (regarding the receive level), i.e. the following
condition for including the neighbour cell n in the target list is fulfilled (sufficiently
high power level of the received BCCH signals of a neighbour cell n):
RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max(n) – PWRMS, max)
For explanations please refer to 12.6 Generation of the target cell list.
– In case of a hierarchical cell structure the priority of the neigbour cell n is equal or
higher than the priority of the current cell s (PLNC(n) ≤ PL(s)).
Power budget condition

For each of n monitored neigbour cells one power budget difference value is calculated,
denoted as PBGT(n). The PBGT(n) value compares the UL/DL power/RXLEV condi-
tions between the MS and the current cell with the corresponding conditions between
the MS and the neigbour cell n. The following formula is applied:
PBGT(n) =
(min(PWRUL, max(s), PWRMS, max) – RXLEVDL, averaged(s) – power_redDL,averaged(s))
– (min(PWRUL, max(n), PWRMS, max) – RXLEVDL, averaged(n))
• RXLEVDL, averaged(n): The averaged RXLEV value of the neighbor cell n received by
the MS
• RXLEVDL, averaged(s): The averaged downlink RXLEV value of the current cell s
• power_redDL,averaged (s): Dynamic power reduction, i.e. the averaged difference
between the maximum downlink RF power supported in the cell and the current
downlink power due to power control
• PWRUL, max(s) (related to the BTS object): The maximum transmission power that a
Mobile Station is permitted to use on a traffic channel in the serving cell s.
The value of PWRUL, max(s) is specified by:
– MSTXPMAXGSM in case the GSM 900, GSM850 or GSMR frequency band is
used
– MSTXPMAXPCS in case the PCS 1900 frequency band is used
– MSTXPMAXDCS in case the DCS 1800 frequency band is used
• PWRUL, max(n) (related to the n-th TGTBTS object): The maximum transmission
power that a Mobile Station is permitted to use on a traffic channel in the adjacent
cell n
• PWRMS, max: The maximum transmission power capability of the Mobile Station.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 317

The power budget condition (in the basic form) for a handover to the neigbour cell n is
fulfilled, if PBGT(n) > 0.
In order to allow prevention of repetitive and back handovers between adjacent cells,
the HOM(n) attribute (subordinate to the ADJC object) tightens the power budget con-
ditions, thus making it more difficult to fulfill the power condition. The power budget con-
dition then is:
PBGT(n) > HOM(n)
The application of HOM is associated with a timer, see 12.8 Handover prevention pro-
cedures.
Discussion of the PBGT formula:
• min(PWRUL, max, PWRMS, max) means – roughly speaking – the maximum allowed MS
transmission power the MS is capable of.
• min(PWRUL, max(n), PWRMS, max) – RXLEVDL, averaged(n) is the difference (dB terms!)
between the maximum UL transmit power and the DL receive level for the neigbour
cell n. The lower this difference is, the lower the transmit power costs can be con-
sidered for maintaining a sufficient radio level (this explains the naming power
budget).
• While the RXLEV values of the neigbouring cells are measured via their BCCHs
which TRXs are operated with full power, the RXLEV value of the current cell is
measured on the current traffic channel which DL transmitting power can be reduced
(dynamically by the power_redDL,averaged value) due to power control. In order to
allow to compare the measurements on the current traffic TRX with the measure-
ments on the BCCH TRXs of the neigbour cells, the power_redDL,averaged has to be
subtracted for the serving cell.
• The power budget condition equation can be related with path losses: The first part
of the formula (without regarding the power_redDL,averaged value and simplifying the
min(...) part here) is a measure of the path loss of the radio transmission for the
current connection (e.g. PWRMS, max(s) – RXLEVDL, averaged(s) = 10 means that the
max. allowed/possible MS transmission power is 10 times stronger than the current
downlink receive level (because the values are given in terms of dB, which refers to
a logarithmic measure), PWRMS, max(s) – RXLEVDL, averaged(s) = 20 means that the
max. allowed/possible MS transmission power is 100 times stronger than the current
downlink receive level, which indicates a much higher pathloss; the higher the dif-
ference value, the higher the pathloss; the formula includes that a cell which allows
a higher MS transmission power (and correspondingly a higher TRX transmission
power) requires a correspondingly higher downlink receive level for indicating the
same path loss).
The second part determines the same for the neigbour cell n. Now, if the path loss
for the neighbour cell n is lower than for the current cell, the neigbour cell is more
appropriate than the current cell regarding the power conditions (“better cell”), and
this case is simply indicated by PGBGT > 0.
In case the same maximum MS transmission power is allowed for the current and
the adjacent cells and neglecting the BSS power reduction because of the max.
power control, the formula becomes much more transparent: Then PGBGT(n) > 0,
if RXLEVDL, averaged(n) > RXLEVDL, averaged (s).
Figure 121 illustrates the behaviour of the power budget formula and how it determines
the “better cell”.
318 Id:0900d805805383c7 A50016-G5100-B556-04-7620

cell A cell B
MS 1
MS 2
(TX_PWR A - RXLEV A) < (TX_PWR B - RXLEV B)

=> cell A is the „better cell“ for both MS1 and MS 2
allowed MS_TX_PMAX
allowed MS_TX_PMAX actual MS_TX_PMAX
RXLEV A TX_PWR A TX_PWR B RXLEV B

(in dB) of MS 1 (in dB) (in dB)
actual MS_TX_PMAX allowed MS_TX_PMAX

allowed MS_TX_PMAX
RXLEV A TX_PWR A TX_PWR B RXLEV B

(in dB) of MS 2 (in dB) (in dB)
MS_TX_PMAX: max. MS transmission power

TX_PWR A: minimum of allowed/actual MS_TX_PMAX to cell A
RXLEV A : receive level at BTS A
Figure 121 “Better cell” with respect to power budget considerations
g The power budget condition is also evaluated for other handover types regarding
12.6 Generation of the target cell list (including modifications for e.g. traffic han-
dovers where the HOM parameter is replaced by the TRFHOM attribute resulting in:
PBGT(n) > TRFHOM(n)).
Summary
The following configurations and conditions trigger a power budget handover indication
from the serving cell s to target cell candidate n:
– INTERCH = TRUE
– PBGTHO = TRUE
– RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max(n) – PWRMS, max)
– PBGT(n) > HOM(n)
– Only in case of a hierarchical cell structure:
HIERC = TRUE
PLNC(n) ≤ PL(s)
A50016-G5100-B556-04-7620 Id:0900d805805383c7 319

12.4.6 DTM power budget handover

DTM power budget handover is a modification of power budget handover for MSs oper-
ating in DTM mode (or establishing DTM mode) and in case of hierarchical cell structure
with cells preferred for CS services and PS services. It uses DTM specific priorities and
specific handover margins for the cells. In this way MSs can be kept on DTM preferred
cells and a power budget handover from a PS preferred cell (where a DTM connection
shall be established) to a CS preferred cell can be suppressed.
Attributes
The following attributes are provided:
• DTMPBGTHO (“dTMPowerBudgetHandover”): This parameter determines whether
handover due to DTM power budget is enabled. This flag is only relevant if inter-cell
handover is enabled in the cell (INTERCH = TRUE).
• SERVICEPREF (“servicePreference”): This parameter indicates whether PS or CS
is preferred on a cell and is only valid if DTM power budget handover is enabled.
• DTMHOM (“dTMHandoverMargin”): This parameter defines the DTM handover
margin supressing the satisfaction of the power budget condition while the MS is in
DTM mode or the timer related to DTMHOMT has not expired.
• DTMPL (“dTMPriorityLayer”): This parameter determines the DTM priority layer of
the serving cell. This priority is only relevant in case hierarchical cell handover is
enabled (HIERC = TRUE).
• DTMHOMT (“dTMHandoverTimer”): This attribute determines the time period for
applying DTMHOM (instead of HOM) and DTMPL when the MS has switched to the
target cell (or after a FORCED HANDOVER REQUEST which is relevant for target
cell generation).
Handover condition
A DTM power budget handover is indicated if the following conditions are fulfilled
(compare with the usual power budget condition):
For an MS in DTM status, and for an MS establishing DTM within 0 < t < DTMHOMT (t
starts when the MS switches from the current cell s to the target cell n or has received
a FORCED HANDOVER REQUEST):
– PBGT(n) > DTMHOM(n)
– DTMPL(n) < DTMPL(s) in case of hierarchical cell structure
For an MS establishing DTM and t ≥ DTMHOMT the usual power budget conditions
apply:
– PBGT > HOM
– PLNC(n) < PL(s) in case of hierarchical cell structure
After any handover an MS first establishes the CS part of a DTM connection and is thus
in dedicated mode only, before establishing DTM. So the application of the DTMHOM
offset and the DTM priority during a time period of DTMHOMT (a few seconds) avoids
the application of the usual power budget condition thus preventing the MS from being
moved onto a CS preferred cell in the first seconds after having performed a handover
to a PS preferred cell.
The same conditions are evaluated and the same attributes are used for the
12.6 Generation of the target cell list for this handover type.
320 Id:0900d805805383c7 A50016-G5100-B556-04-7620

12.4.7 Speed sensitive power budget handover

Speed sensitive power budget handover is a special kind of power budget handover
avoiding multiple handovers when a MS quickly moves between a macro-cell and an
embedded micro-cell.
In a mixed-cell environment with large and small cells and micro-cells, fast moving
Mobile Stations allocated in micro-cells would cause too much handovers; moreover the
residence time in a micro-cell could be too small for performing a successful handover.
Therefore the speed of a mobile station is estimated and the power budget criterion has
been modified.
Functional principle
The speed sensitive handover functions as follows: Within a micro-cell a minimum time
is defined during which a MS has to be located within the cell boundaries for the sepa-
ration of the fast-moving MSs from the slow-moving MSs. During this time period the
power budget handover detection is suppressed.
• If the mobile leaves the cell within the minimum time interval, the mobile is defined
as fast-moving; no power budget handover is performed.
• If the mobile is still located within the cell after the minimum time interval has expired,
the mobile is defined as slow-moving and the power budget handover detection is
no longer suppressed.
Speed sensitive handover is realized by starting a timer, when the mobile enters the cell
and a power budget handover cause is indicated (e.g. PBGT > HOM in case HOM is
applied). As long as the timer does not exceed the maximum time determined by the
HOMDTIME attribute, a power budget handover is penalized by adding a penalization
value (attribute HOMSOFF) to the PBGT equation and – in the case of a hierarchical cell
structure – the cell priority is changed. After timer expiry, the power budget penalization
is reduced (attribute HOMDOFF; if HOMDOFF = HOMSOFF, the penalization is fully
compensated) and the cell priority is restored to the previous value (as result e.g. for a
slowly moving mobile a power budget handover into the affected cell is made possible),
see Figure 122. The timer is reset, if the usual power budget handover condition is no
longer satisfied (PBGT < HOM).
(ANDOVER-ARGIN
(/-(/-3/&&
(/-$/&&
(/-3/&&
(/-$/&&
(/-
4IME
(/-$4)-%
STARTOFTIMER EXPIRYOFTIMER
POWERBUDGETCONDITIONFULFILLED
Figure 122 Handover margin for speed sensitive power budget handover
A50016-G5100-B556-04-7620 Id:0900d805805383c7 321

Attributes
The following attributes have been introduced to support the speed-sensitive handover:
• DPBGTHO (“enableDelayPowerBudgetHo“): This parameter determines whether
speed sensitive handover is active. The parameter is only relevant if power budget
handover is enabled (PBGTHO = TRUE).
• HOMDTIME (“hoMarginDelayTime”): The time period during which a power budget
handover is penalized.
• HOMSOFF (“hoMarginStaticOffset”): Offset for the power budget equation in order
to penalize the power budget handover indication; HOMSOFF is added to HOM.
• HOMDOFF (“hoMarginDynamicOffset”): Offset for the power budget equation
reducing the penalization by HOMSOFF; the HOMDOFF value is subtracted from
the HOMSOFF value.
• PPLNC (“penaltyPriorityLayerNCell”): The priority used for micro-cells for which the
speed-sensitive handover timer is currently running.
Handover condition
A speed sensitive power budget handover from current cell s to a potential target cell n
is indicated if the following conditions are fulfilled (compare with the usual power budget
condition):
For t < HOMDTIME (t starts when PBGT exceeds the HOM value):
– PBGT > HOM + HOMSOFF
– PPLNC(n) < PL(s) in case of hierarchical cell structure
For t ≥ HOMDTIME:
– PBGT > HOM + HOMSOFF – HOMDOFF
(reduction/compensation of “+ HOMSOFF” by “– HOMDOFF”)
– PLNC(n) < PL(s) in case of hierarchical cell structure
12.4.8 Fast uplink handover

The fast uplink handover is similar to the level handover for the uplink direction, but it
provides other thresholds, another signal strength averaging process and a different
algorithm. Thereby the fast uplink handover is faster than the normal level handover,
which helps to avoid dropping of calls when the radio transmission conditions change
fast (e.g. rapid moving of the MS at the cell boarder or special environments like street
corners, tunnels, indoor/outdoor/shadowed areas).
The fast uplink handover is triggered in less than 3 s; whilst the standard level handover
indication process requires at least 4 s, which can be too slow (normally, small but not
very small averaging window sizes are used (e.g. 4 SACCH multiframes wich last about
2 s) and is only triggered after the power control algorithm (if enabled) has adjusted the
transmit power to the maximum).
Attributes
The EFULHO attribute of the HAND object allows enabling/disabling of the fast uplink
handover. Because the fast uplink handover is an inter-cell handover, the INTERCH
attribute has to be set to TRUE.
322 Id:0900d805805383c7 A50016-G5100-B556-04-7620

The following attributes are provided for the fast uplink handover detection:
• EFULHO (“enableFastUpLinkHo“): Allows to enable/disable the inter-cell fast uplink
handover
• THLEVFULHO (“thresholdLevFastULHo“): The receive signal strength threshold for
an inter-cell fast uplink handover decision
• ALEVFULHO (“averagedLevFastULHo“): Contains two averaging parameters for
signal strength measurements used for the fast uplink handover decision:
– aLevFuHo: size of the averaging window, defining the number of SACCH frames
which are used for averaging (range: 1...31)
– wLevFuHo: Weighing factor (range: 1...3)
Handover condition
The evaluation of the fast uplink handover is not performed unless the capabilities of the
power control have been exhausted. Prevention of back handover is not applied for this
handover type.
A fast uplink handover is indicated, if the averaged receive level in uplink direction falls
under the threshold THLEVFULHO. Additionally the AKEVFULHO averaging window
should be completely included within the HOAVPWRB averaging window.
When the THLEVFULHO attribute has nearly the same value as the RXLEV handover
threshold HOLTHLVUL and both handover conditions are fulfilled, then the fast uplink
handover algorithm is triggered, because it is faster than the other one.
Example
The following configurations and conditions trigger a fast uplink handover indication:
– INTERCH = TRUE
– RXLEVHO = TRUE
– ALEVFULHO < HOAVPWRB
– RXLEV_UL < THLEVFULHO
12.4.9 Forced handover

Forced handover is a handover triggered by the BSC due to Directed Retry (handover
from a SDCCH in one cell to a TCH in another cell during the call setup) or Preemption;
especially a forced handover is not determined by the evaluation of radio network criteria
in the BTS. The BSC initiates the forced handover via the FORCED HANDOVER
REQUEST message (cause: “directed retry” or “preemption”). The BTS processes this
handover type as if an inter-cell handover condition had been detected.
If the FORCED HANDOVER REQUEST is received, before the neighbor cell measure-
ments are available from the MS, the handover indication is stored internally, until two
neighbor cell measurements can be evaluated by the MS or more than seven measure-
ment reports have been received from the MS since the call establishment.
Forced intra-cell handover due to upgrade of originally downgraded multislot calls or due
to moving of a call onto a preferred layer are described in chap. Resource re-allocator.
Attributes
Forced handover can be enabled/disabled by the ENFORCHO (“enforceHo“) attribute.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 323

For inter-BSC Directed Retry and inter-cell SDCCH to SDCCH handovers the additional
attributes EISDCCHHO (“enableInterSdcchHo“) and the IERCHOSDCCH (“enableInter-
CellHoSdcch“) are provided.
12.4.10 Traffic handover

A traffic handover moves a call from a cell with a high number of busy channels to an
adjacent cell with a lot of free radio channels. Such handovers allow to set up new con-
nections and to maximize the number of users.
High Traffic Cell Low Traffic Cell
Handover from BTS A to BTS B
BTS A BTS B
BSC
Figure 123 Traffic handover

The handover for traffic reason can be performed only between cells belonging to the
same BSC (this restriction is required because it is impossible for the serving BSC to
control the channel occupancy of an adjacent cell belonging to another BSC and
because on the A interface the cause traffic reason is not foreseen) and has the lowest
priority (e.g. power budget handover is evaluated before traffic handover). Besides, the
connections moved for traffic handover are chosen near to the ideal cell border whilst a
connection moved for Directed Retry could be very far from the ideal cell border.
Attributes
The TRFHOE (“trafficHandoverEnable”) attribute of the HAND object allows to
enable/disable the traffic handover in the BTS.
The following attributes are provided for the traffic handover condition indication:
• TRFHITH (“trafficHighThreshold”, subordinate to the HAND object): The high traffic
level threshold for triggering the traffic handover indication (a low traffic level thresh-
old attribute, TRFLTH, also exists which is used during the handover execution, see
topic inter-cell/intra-BSC handover in chap. 12.7 Handover execution)
• TRFCT (“trafficControlTimer”, subordinate to the BSC object): Establishes for each
BTS the period of time to wait before evaluating the traffic level
324 Id:0900d805805383c7 A50016-G5100-B556-04-7620

Handover condition
If the percentage of busy TCHs in a cell is higher or equal to the threshold determined
by the TRFHITH attribute, the cell is regarded as a high traffic level cell and a handover
cause due to traffic is indicated. In order to correctly evaluate the percentage of busy
channels in the case of a cell with FR and HR channels, the FR channels are considered
with weight 2 and the HR channels with weight 1.
Further attributes are provided for determining the handover target cells and the execu-
tion of the traffic handover.
Functional details
The BSC evaluates the traffic level for the cells where the handover for traffic is enabled
in time periods given by the TRFCT value. If there is a transition in the traffic level from
low (high) to high (low) in respect to the previous evaluation, the BSC sends to the BTS
the indication that the handover due to traffic reason has to be started (ended) in the
specific cell. The BTS has to acknowledge the command.
12.4.11 Compression/decompression handover

Compression handover is the intra-cell handover from a full rate traffic channel to a half
rate traffic channel, vice versa decompression handover is the intra-cell handover from
a half rate traffic channel to a full rate traffic channel.
The compression handover helps to increase the maximum number of simultaneous
calls in a cell in case of high traffic load and good radio conditions; decompression
handover can improve the quality of transmitted speech data (thus avoiding call drops
due to bad transmission quality) and allows higher transmission rates. Compression and
decompression handover are available for both AMR and not-AMR calls; the same prin-
ciples are applied (handover conditions, best call selection criteria).
In case wideband AMR is applied, also compression/decompression handovers
between wideband AMR calls on full rate traffic channels and narrowband AMR calls on
half rate traffic channels are available.
g Compression and decompression handovers for AMR calls can be executed even
if the Link Adaptation phase is completely exhausted.
Generally, if wideband AMR is used for the encoding of speech data for a TCH, the
operation with wideband AMR codecs is held until the TCH is released. In a few
cases transitions between wideband AMR on full rate TCHs and narrowband AMR
on half rate TCHs may be useful, e.g. for traffic load reasons, so these transitions
are supported and can be configured.
Compression handover
Handover conditions:
1. The traffic loads in the cell or on Abis interface exceed configurable thresholds.
2. Candidate calls for compression handover satisfy one (or both) of the following con-
ditions in downlink and uplink direction:
2.1 The sum of the carrier-to-interference ratio and the average power reduction
exceeds a threshold (e.g. hoThres_Compr_DL) (the average power reduction is
related to the maximum power at call setup applied by the power control algo-
rithm). For the uplink direction:
C/IUL, averaged + power_redUL, averaged > hoThres_Compr_UL
A50016-G5100-B556-04-7620 Id:0900d805805383c7 325

2.2 The receive level (RXLEV) exceeds a threshold (e.g. hoThres_Compr_Lev_DL)

and the carrier-to-interference ratio in uplink/downlink direction exceeds or
reaches a maximum C/I value. For the uplink direction:
RXLEVUL, averaged > hoThres_Compr_Lev_UL and C/IUL, averaged ≥ C/Imax
This supplementary condition is applied to avoid delayed compression handover
in the transient phase.
g The compression handover criteria described above are called “advanced”. A
simpler compression handover criterion, called “standard”, can be applied compar-
ing only the measured C/I values with thresholds without considering power reduc-
tion values. Compression handover is indicated if:
C/IUL, averaged > hoThres_Compr_UL and C/IDL, averaged > hoThres_Compr_DL
For configuration of the “standard” criterion, see below.
Best call selection for compression handover:
Only the best suited connection from the previous step is selected for the compression
handover. In the basic variant, this is the one with the highest value of the sum of the
carrier-to-interference ratio and the average power reduction (uplink and downlink
values are added). Formula for the sum (denoted as QI) for any call:
QI = C/IUL, averaged + power_redUL, averaged + C/IDL, averaged + power_redDL, averaged
In case of AMR calls an offset, specific for the kind of AMR call, can be added in order
to favour the compression handover of related AMR full rate calls.
Decompression handover
1. If the radio conditions degrade, decompression handover from half rate to full rate is
immediately triggered. Candidate calls for decompression handover must satisfy
both of the following conditions for the uplink or the downlink direction:
1.1 The sum of the carrier-to-interference ratio and the average power reduction in
uplink/downlink direction falls below a critical value (placeholder:
hoThres_Decompr_UL). (The average power reduction is related to the
maximum power at call setup applied by the power control algorithm.) For the
uplink direction:
C/IUL, averaged + power_redUL, averaged < hoThres_Decompr_UL
1.2 The receive level (RXLEV) in uplink/downlink direction falls below a threshold
(placeholder: hoThres_Decompr_Lev_UL) or the carrier-to-interference ratio in
uplink/downlink direction falls below the maximum C/I value. For the uplink
direction:
RXLEVUL, averaged < hoThres_Decompr_Lev_UL or C/IUL, averaged < C/Imax
This supplementary condition is applied to avoid unjustified decompression
handover in the transient phase.
g The decompression handover criteria described above are called
“advanced”. A simpler decompression handover criterion, called “standard”,
can be applied comparing only the measured C/I values with thresholds
without considering power reduction values. Decompression handover is
indicated if (for configuration of the “standard” criterion, see below):
C/IUL, averaged < hoThres_Decompr_UL or C/IDL, averaged <
hoThres_Decompr_DL
326 Id:0900d805805383c7 A50016-G5100-B556-04-7620

2. In addition, decompression handover can be triggered due to relaxing traffic load. If

the traffic loads in the cell and on Abis interface are below specific thresholds, a
decompression handover is indicated.
Best call selection for decompression handover:
Only the best suited connection from the previous step is selected for decompression
handover. In the basic variant, this is the one which value of the sum of the carrier-to-
interference ratio and the average power reduction is closest to the threshold value of
the previous step (placeholder: hoThres_Decompr_UL). Formula for the sum (denoted
as QI) for any call:
QI = C/IUL, averaged + power_redUL, averaged + C/IDL, averaged + power_redDL, averaged
In case of AMR calls an offset, specific for the kind of AMR call, can be added in order
to favour the compression handover of related AMR full rate calls.
Background on the purpose of the handover condition with RXLEV and C/Imax
In practice the process for the continuous determination of C/I values is limited to a
maximum hard-coded value C/Imax = 20 dB. This limitation arises from the determination
of C/I via measurements of BER (which is converted to RXQUAL) and mapping to cor-
responding C/I values. For high C/I values, the BER is very low and, for a reasonable
averaging window length, the accuracy of the resulting C/I is limited. In case that no bit
errors have been measured during the measurement period no precise prediction of the
real C/I is possible at all.
A C/I limited to a maximum C/Imax limits the effect of C/Iaveraged in the following equations
used for the compression/decompression handover decision (only the uplink direction is
considered here, the downlink direction is analogous):
For compression: C/IUL, averaged + power_redUL, averaged > hoThres_Compr_UL (I)
For decompression: C/IUL, averaged + power_redUL, averaged < hoThres_Decompr_UL (II)
In the transient phase (i.e. the start phase) of a call, when the power is still at the
maximum or close to it (i.e. neglegible power reduction) but is continuously changing
due to dynamic power reduction, the limitation of C/IUL, averaged may cause conse-
quences: Regarding compression handover, the limited C/IUL, averaged could delay satis-
fying condition (I) – especially with hoThres_Compr_UL ≥ 20 dB – until the power
reduction reaches a high value. Similarly, the decompression threshold in condition (II)
may be reached within the transient phase – especially with
hoThres_Decompr_UL ≥ 20 dB – causing an unjustified decompression handover.
Such delayed compression handovers and unjustified decompression handovers are
avoided by applying the additional handover conditions with RXLEV and C/Imax.
12.4.11.1 Attributes and configuration

There are different parameter sets for the different types of calls (not-AMR calls, only
narrowband AMR calls, wideband and narrowband AMR calls).
Table 57 gives an overview over the attributes used for compression and decompres-
sion handover.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 327

Not-AMR Narrowband AMR Additional wideband AMR

Enabling compression/decompression handover
EADVCMPDCMHO EADVCMPDCMHO EADVCMPDCMHO
EADVCMPHOSC EADVCMPHOAMR ECMPWBNB
EDRCMPWBNB
LCKRETWB
EADVCMPHOWBFS
Averaging
AMRACMRDL AMRWBACMRDNL
Traffic load thresholds
HRACTT1 HRACTAMRT1 HRACTAMRWBTH1
HRACTT2 HRACTAMRT2 HRACTAMWBRTH2
FRACTTH1 FRACTAMRTH1 FRACTAMRWBTH1
FRACTTH2 FRACTAMRTH2 FRACTAMRWBTH2
Quality thresholds
HOTHCDL HOTHCDL HOTHCDL
HOTHCUL HOTHCUL HOTHCUL
HOTHDDL HOTHDDL HOTHDDL
HOTHDUL HOTHDUL HOTHDUL
HOTHEFRCDL
HOTHEFRCUL
Level thresholds
HOTHCMPLVDL HOTHCMPLVDL HOTHCMPLVDL
HOTHCMPLVUL HOTHCMPLVUL HOTHCMPLVUL
HOTHDCMLVDL HOTHDCMLVDL HOTHDCMLVDL
HOTHDCMLVUL HOTHDCMLVUL HOTHDCMLVUL
Other attributes
HRDCMLIMTH ADVCMPHOOAMR ADVCMPHOOWBFS
ADVDCMPHOOWBFS
Table 57 Compression/decompression parameters overview
Configuration hints
A precondition for compression/decompression handovers is to enable intra-cell han-
dovers by setting the INTRACH attribute (related to the HAND object) to TRUE. Also the
“half rate speech” feature has to be enabled by setting HRSPEECH to TRUE
(HRSPEECH = FALSE disables compression/decompression handovers).
Compression and decompression handovers as described above (with “advanced”
decision criteria) are generally enabled by setting the attributes EADVCMPDCMHO,
EADVCMPHOAMR and EADVCMPHOSC to TRUE.
328 Id:0900d805805383c7 A50016-G5100-B556-04-7620

The setting EADVCMPDCMHO = FALSE does not stop compression/decompression

handovers, but restricts these handovers to a basic functionality: Only AMR calls are
considered (compression handover had been introduced for AMR calls at first), only the
“standard” handover decision criterion is applied for the AMR calls (no RXLEV consid-
erations, no traffic load criterion) and the best call selection algorithm is not available.
EADVCMPDCMHO = TRUE has the following effects (however for effective use it must
be combined with with EADVCMPHOAMR and EADVCMPHOSC, see below):
– It enables the load-dependent decompression handover decision.
– It enhances the compression/decompression handover decision algorithm by addi-
tional consideration of radio level criteria.
– It enables the best suitable call selection mechanism for compression and decom-
pression handover.
– It extends the decompression handover with the enhanced decision algorithm also
to non-AMR calls (FR, EFR, HR).
EADVCMPHOAMR = TRUE/FALSE is used to enable/disable the selection of AMR calls
as candidates for the most suitable call for a compression handover. If enabled, AMR
calls that fulfill all (advanced algorithm) compression conditions will be considered as
candidates for an intra-cell compression handover. If disabled, no AMR call will be
selected for compression handover. A change of the attribute becomes effective in the
next SACCH multiframe. This parameter is only checked during the AMR compression
handover decision in the BTS – it thus only controls AMR compression handover. AMR
decompression handover due to quality or due to load remains unaffected by this
parameter, i.e. even if EADVCMPHOAMR = FALSE, the BTS will still trigger decom-
pression handovers for AMR calls, if the corresponding conditions are met.
EADVCMPHOSC has the same effects on non-AMR calls as EADVCMPHOAMR on
AMR calls.
The traffic threshold attributes for half rate and full rate shall be set according to the fol-
lowing rules (i = 1, 2):
– FRACTTHi < HRACTTi
– FRACTAMRTHi < HRACTAMRTi
– FRACTAMRWBTHi < HRACTAMRWBTHi
An analogous configuration rule shall be respected for the corresponding parameters
related to Abis interface (ABISFRACTTHR < ABISHRACTTHR).
Parameters like HOTHCDL or HOTHCUL of the HAND object are typically set in the
fields of the service group dependent handover parameters in the relevant service
group, i.e. in SG15HOPAR and SG16HOPAR. Only if the corresponding SG15HOPAR
and SG16HOPAR parameters are set to <NULL>, the parameter values are determined
by the standard parameters as included in the HAND object.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 329

Attributes related to not-AMR compression/decompression handovers and

common attributes

Enabling (HAND object)
EADVCMPDC- enableAdvComprDe- This attribute is used to enable/dis- TRUE, TRUE
MHO comprHO able the advanced compres- FALSE
sion/decompression handover
algorithm.
EADVCM- enableAdvComprHoSC Selection of GSM HR capable TRUE, TRUE
PHOSC mobiles as candidates for compres- FALSE
sion handover.
Traffic load thresholds (BTSM object and BTS object)
ABISFRACT- abisFullRateActivation- The threshold indicating the percent- 0 ... 100 40
THR Threshold age of busy Abis subslots (fully busy
+ half busy + out of service subslots)
in the Abis pool that triggers the load-
based decompression handover
(from GSM-HR/AHR to GSM-
FR/EFR/AFR) in all the cells of the
site where the feature is enabled.
HRACTT1 hRActivationThreshold The threshold indicating the percent- 0 ... 10 000 6000
1 age of busy TCHs in case of
standard cell or complete area of a
concentric cell or far area of an
extended cell.
HRACTT2 hRActivationThreshold The threshold indicating the percent- 0 ... 10 000 6000
2 age of busy TCHs in case of inner
area of a concentric cell or near area
of an extended cell.
FRACTTH1 fullRateActivationThres Load dependent threshold for 0 ... 10 000 3000
hold1 decompression handover for
standard cells or the Complete Area
of a Concentric Cell, respectively Far
Area of an Extended Cell for
standard codecs.
FRACTTH2 fullRateActivationThres Load dependent threshold for 0 ... 10 000 3000
hold2 decompression handover for the
Inner Area of a Concentric Cell,
respectively Near Area of an
Extended Cell for standard codecs.
Quality thresholds (HAND object)
330 Id:0900d805805383c7 A50016-G5100-B556-04-7620


HOTHCDL hoThresComprDL This attribute determines the thresh- 0 ... 20 18
old in downlink direction regarding
the C/I evaluation for compression
handover indication.
HOTHCUL hoThresComprUL The threshold in uplink direction 0 ... 20 18
regarding the C/I evaluation for com-
pression handover indication.
HOTHDDL hoThresDecomprDL The threshold in downlink direction 0 ... 20 13
regarding the C/I evaluation for
decompression handover indication.
HOTHDUL hoThresDecomprUL The threshold in uplink direction 0 ... 20 13
regarding the C/I evaluation for
HOTHE- hoThresEFRComprDL The C/I threshold in downlink direc- 0 ... 20 18
FRCDL tion for compression handover from
EFR to GSM HR.
HOTHE- hoThresEFRComprUL The C/I threshold in uplink direction 0 ... 20 18
FRCUL for compression handover from EFR
to GSM HR.
Level thresholds (HAND object)
HOTHCM- hoThresComprLevDL The threshold in downlink direction 0 ... 63 40
PLVDL regarding the RXLEV evaluation for
compression handover indication.
HOTHCMPL- hoThresComprLevUL The threshold in uplink direction 0 ... 63 40
VUL regarding the RXLEV evaluation for
compression handover indication.
HOTHDCM- hoThresDecom- The threshold in downlink direction 0 ... 63 26
LVDL prLevDL regarding the RXLEV evaluation for
HOTHDCML- hoThresDecomprLe- The threshold in uplink direction 0 ... 63 26
VUL vUL regarding the RXLEV evaluation for
Other attributes (HAND object)
HRDCMLIMTH hRDecomprLimit- The threshold for limitation of load 0 ... 100 6
Threshold dependent decompression handover
Table 58 Common and not-AMR related compression/decompression parameters (Cont.)
A50016-G5100-B556-04-7620 Id:0900d805805383c7 331

Narrowband-AMR related attributes

EADVCM- enableAdvCom- This attribute is used to enable/dis- TRUE TRUE,
PHOAMR prHOAMR able the selection of AMR calls as FALSE
candidates for the most suitable call
for a compression handover.
Averaging (HAND object)
AMRACMRDL aMRAveragedCMRDL The size of the averaging window for 5 1 ... 31
Codec Mode Requests received
from the MS during an AMR call.
ABISFRACT- abisFullRateActivation- The threshold that indicates the per- 40 0 ... 100
THR Threshold centage of busy Abis subslots (fully
busy + half busy + out of service) in
the Abis pool that triggers the load-
based decompression handover
(from GSM-HR/AHR to GSM-
FR/EFR/AFR) in all the cells of the
site where the feature is enabled.
HRACTAMRT hRActivationThreshold Threshold indicating the percentage 6000 0 ... 10 000
1 1 of busy AMR TCHs of a standard cell
or complete area of a concentric cell
or far area of an extended cell.
HRACTAMRT hRActivationThreshold The threshold that indicates the per- 6000 0 ... 10 000
2 2 centage of busy AMR TCHs in case
of inner area of a concentric cell or
near area of an extended cell.
FRACTAMRT fullRateActivationAMR Load dependent threshold for 3000 0 ... 10 000
H1 Threshold1 decompression handover for
standard cells or the complete area
of a concentric cell (or far area of
extended cell) for standard codecs.
FRACTAMRT fullRateActivationAMR Load dependent threshold for 3000 0 ... 10 000
H2 Threshold2 decompression handover for the
Inner Area of a concentric cell,
respectively near area of an
extended cell for standard codecs.
ADVCM- advComprHoOff- Codec specific preference (offset of 36 0 ... 60
PHOOAMR setAMR AMR compared to standard codecs). (= 6 dB) (= –30 dB ...
+30 dB)
332 Id:0900d805805383c7 A50016-G5100-B556-04-7620

Additional attributes related to wideband AMR

ECMPWBNB enableComprWBToNB This attribute generally enables/dis- FALSE TRUE,
ables compression/decompression FALSE
handovers regarding wideband AMR
full rate speech calls.
EDRCMP- enableDynamicReas- This parameter allows to include cell FALSE TRUE,
WBNB signComprWBNB load dependent criteria for dynamic FALSE
reassignment related to compression
handover.
LCKRETWB lockReturnToWB This flag prohibits potential decom- FALSE TRUE,
pression handovers to wideband FALSE
AMR full rate channels.
EADVCM- enableAdvCom- This attribute enables/disables FALSE TRUE,
PHOWBFS prHoWBFS advanced compression/decompres- FALSE
sion handover criteria for wideband
AMR full rate speech calls (e.g.
makes the offset ADVCMPHOOAMR
effective or disables it).
Averaging (HAND object)
AMRWBAC- aMRWBAveragedC- This attribute defines the size of the 1 1 ... 31
MRDNL MRDownlink averaging window in downlink direc-
tion.
HRACTAMRW halfRateActivationAmr This attribute defines the load depen- 8000 0 … 10 000
BTH1 WBThreshold1 dent threshold for activation of
dynamic half rate allocation for AMR
wideband for standard cells or the
complete area of a concentric cell,
respectively far area of an extended
cell.
HRACTAMRW halfRateActivationAmr This attribute defines the load depen- 8000 0 … 10 000
BTH2 WBThreshold2 dent threshold for activation of
dynamic half rate allocation for AMR
wideband for the inner area of a con-
centric cell, respectively near area of
an extended cell.
Table 60 Compression/decompression parameters related to wideband AMR
A50016-G5100-B556-04-7620 Id:0900d805805383c7 333


FRACTAMRW fullRateActivationAMR This attribute defines the load depen- 0 0 … 10 000
BTH1 WBThreshold1 dent threshold for decompression
handover for AMR wideband capable
MSs for standard cells or the
complete area of a concentric cell,
respectively far area of an extended
cell.
FRACTAMRW fullRateActivationAMR This attribute defines the load depen- 0 0 … 10 000
BTH2 WBThreshold2 dent threshold for decompression
handover for AMR wideband capable
MSs for the inner area of a concentric
cell, respectively near area of an
extended cell.
ADVCM- advComprHoOff- This offset attribute is used to priori- 27 0 … 60
PHOOWBFS setWBFS tize compression handovers from (-3 dB) (-30 … 30 dB)
wideband AMR with respect to com-
pression handovers from narrow-
band AMR.
ADVDCM- advDecomprHoOff- This offset attribute is used to priori- 30 0 … 60
HOOWBFS setWBFS tize decompression handovers to (0 dB) (-30 … 30 dB)
wideband AMR with respect to
decompression handovers to nar-
rowband AMR.
ADVCM- advComprHoOff- This offset attribute is used to priori- 27 0 … 60
PHOOAMR setAMR tize compression handovers from (-3 dB) (30 … 30 dB)
narrowband AMR with respect to
compression handovers from
wideband AMR.
Table 60 Compression/decompression parameters related to wideband AMR (Cont.)
12.4.12 Handovers between AMR-wideband and AMR-narrowband

For comparable source bit rates (e.g. TCH/AFS6.70 and TCH/WFS6.60), AMR
wideband is as robust as AMR narrowband. However, AMR narrowband offers codec
modes with source bit rates lower than 6.70 kbit/s and these codec modes are more
robust than AMR wideband codecs. In order to keep the possibility to deploy the most
robust narrowband AMR codecs in scenarios where wideband AMR shall be used and
the radio conditions change strongly, a switch between wideband and narrowband
mode for ongoing connections is provided. However, such switches are considered as
exceptional cases.
Handovers between wideband AMR and narrowband AMR full rate codecs can be
enabled by the EROBHOMHO (“enableRobustHomingHo”) attribute.
334 Id:0900d805805383c7 A50016-G5100-B556-04-7620

Robustness handover
Robustness handover is the handover from wideband AMR on a full rate traffic channel
to narrowband AMR on a full rate traffic channel, for critical radio conditions.
If robustness handover has been enabled, both of the following conditions must be sat-
isfied for at least one direction (uplink/downlink) to trigger a robustness handover:
1. The sum of the carrier-to-interference ratio and the average power reduction in
uplink/downlink direction is below the “hoThresWBFrToNBFrUL”/”hoThresWBFr-
ToNBFrDL” value. (The average power reduction is related to the maximum power
at call setup applied by the power control algorithm.) For the uplink direction:
C/IUL, averaged + power_redUL, averaged < hoThresWBFrToNBFrUL
2. The receive level (RXLEV) in uplink/downlink direction is lower than the “hoThres-
RobustnessLevUL”/”hoThresRobustnessLevDL” threshold or the carrier-to-interfer-
ence ratio in uplink/downlink direction is below the maximum value. For the uplink
direction:
RXLEVUL, averaged < hoThresRobustnessLevUL or C/IUL, averaged < C/Imax
This is a supplementary condition.
The conditions indicated above have to be continuously maintained for at least one link
direction during the period defined by the HOTWBFRNBFR (“hoTimerWBFullrateNB-
Fullrate”) attribute.
Channel modification instead of intra-cell handover:
The switch of the channel type by the transition from wideband AMR on a full rate traffic
channel to narrowband AMR on a full rate traffic channel can not only be executed by a
intra-cell handover, but also by just a channel modification which has the following ben-
efits:
– The channel modification is faster than a handover.
– The call remains on the same channel, i.e. no downgrading of ongoing services is
required in case of resource bottlenecks.
– No power ramping is required after handover resulting in lower interference in the
network.
– The radio conditions on the channel are already known before switching to AMR
wideband. In case of poor radio conditions the call can remain in narrowband full
rate mode thus exploiting the robustness of the AMR narrowband codecs of low
source bit rate.
For enabling the switch from wideband AMR on a full rate traffic channel to narrowband
AMR on a full rate traffic channel, the CHMDMWBNB (“channelModeModifyWBNB“)
attribute is provided.
Homing handover
Homing handover is the handover from narrowband AMR on a full rate traffic channel to
wideband AMR on a full rate traffic channel. With a homing handover the speech quality
can be improved.
A frequent change between wideband and narrowband audio transmission might be
annoying for the subscribers. To prevent this, toggling can be prohibited via the attribute
“lockReturnToWB”. Actually “lockReturnToWB” = ENABLE prohibits homing handovers
to wideband AMR.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 335

Since homing handover is the opposite of robustness handover, corresponding condi-

tions are applied, the criteria are inverted and other threshold attributes are provided.
One of the following conditions must be satisfied for both directions (uplink and down-
link) to trigger a homing handover:
1. The sum of the carrier-to-interference ratio and the average power reduction in
uplink/downlink direction exceeds the “hoThNBToWBFullrateUL”/”hoThNBToWB-
FullrateDL” value.
C/IUL, averaged + power_redUL, averaged > hoThNBToWBFullrateUL
2. The receive level (RXLEV) in uplink/downlink direction exceeds the “hoThresHom-
ingLevUL”/”hoThresHomingLevDL” threshold and the carrier-to-interference ratio in
uplink/downlink direction is equal or higher than the maximum reported value.
RXLEVUL, averaged > hoThresHomingLevUL and C/IUL, averaged ≥ C/Imax
In order to avoid ping-pong handovers a penalty timer “TimerInhibitHomingHo” is imple-
mented. After a robustness handover, a back handover – i.e. a homing handover – is
forbidden until expiry of this timer.
The transition from narrowband AMR to wideband AMR within full rate TCHs can also
be executed by channel modification (analogously as for robustness handover).
Attributes

EROBHOMHO enableRobustHom- This parameter allows enabling/dis- FALSE TRUE,
ingHo abling of robustness and homing FALSE
handovers.
NBNOWB nBNoWB This attribute allows an automatic FALSE TRUE,
switch from a wideband channel to a FALSE
narrowband channel if it turns out
that the AMR wideband connection
cannot be established as end-to-end
service.
CHMDM- channelModeModify- This attributes determines if the FALSE TRUE,
WBNB WBNB switch between wideband and nar- FALSE
rowband AMR is performed via
Channel Mode Modify (TRUE) or
intra-cell handover (FALSE).
HOTHROBLV hoThresRobust- This attribute defines the downlink 26 0 … 63
DL nessLevDL RXLEV threshold for triggering (-84 dBm) (-110 ... -48
robustness handover. dBm)
HOTHROBLV hoThresRobustnessLe- This attribute defines the uplink 26 0 … 63
UL vUL RXLEV threshold for triggering (-84 dBm) (-110 ... -48
robustness handover. dBm)
HOTHHOM- hoThresHomingLevDL This attribute defines the downlink 40 0 … 63
LVDL RXLEV threshold for triggering (-70 dBm) (-110 ... -48
homing handover. dBm)
Table 61 Parameters related to handovers between wideband and narrowband AMR
336 Id:0900d805805383c7 A50016-G5100-B556-04-7620


HOTHHOML- hoThresHomingLevUL This attribute defines the uplink 40 0 … 63
VUL RXLEV threshold for triggering (-70 dBm) (-110 ... -48
homing handover. dBm)
HOTHWBNB- hoThWBToNBFullrat- Threshold for the robustness 5 (dB) 0 … 20 (dB)
FRDL eDL handover procedure in downlink
direction.
HOTHWBNB- hoThWBToNBFullra- Threshold for the robustness 5 (dB) 0 … 20 (dB)
FRUL teUL handover procedure in uplink direc-
tion.
HOTHNBWB- hoThNBToWBFullrat- Threshold for the homing handover 10 (dB) 0 … 20 (dB)
FRDL eDL procedure in downlink direction.
HOTHNBWB- hoThNBToWBFullra- Threshold for the homing handover 10 (dB) 0 … 20 (dB)
FRUL teUL procedure in uplink direction.
HOTWBFRN- hoTimerWBFullrateNB- This attribute, specified in number of 8 1 ... 127
BFR Fullrate SACCH periods, determines the (3.84 s)
interval in which the thresholds for
the robustness/homing handover
procedure must be analyzed.
TINHHOMHO timerInhibitHomingHO This attribute determines how long a 30 1 ... 254
homing handover is prohibited after a
robustness handover.
Table 61 Parameters related to handovers between wideband and narrowband AMR (Cont.)
12.5 Service dependent handover configuration

In order to have a greater flexibility in the handover algorithm definition, service based
handover thresholds have been introduced. Thereby an optimal usage of all available
radio channels according to the operator’s service policy and market strategy can be
achieved. Table 62 shows the service groups that have been defined (only circuit
switched services are concerned); each group is identified by a specific attribute that is
composed of a number of fields allowing to specify different thresholds according to the
service type.

SG-1 Signalling on hopping channel SG1HOPAR
SG-2 Signalling on non hopping channel SG2HOPAR
SG-3 CS speech FR/EFR/ASCI(VBS/VGCS) on hopping SG3HOPAR
channel
SG-4 CS speech FR/EFR/ASCI(VBS/VGCS) on non hopping SG4HOPAR
channel
SG-5 CS speech HR on hopping channel SG5HOPAR
Table 62 Service groups for handover purpose
A50016-G5100-B556-04-7620 Id:0900d805805383c7 337


SG-6 CS speech HR on non hopping channel SG6HOPAR
SG-7 CS data up to 9.6 kbit/s or HSCSD 9.6 kbit/s on hopping SG7HOPAR
channel
SG-8 CS data up to 9.6 kbit/s or HSCSD 9.6 kbit/s on non- SG8HOPAR
hopping channel
SG-9 CS data up to 14.4 kbit/s or HSCSD 14.4 kbit/s on SG9HOPAR
hopping channel
SG-10 CS data up to 14.4 kbit/s or HSCSD 14.4 kbit/s on non- SG10HOPAR
hopping channel
SG-11 CS speech AMR FR on hopping channels SG11HOPAR
SG-12 CS speech AMR FR on non hopping channels SG12HOPAR
SG-13 CS speech AMR HR on hopping channels SG13HOPAR
SG-14 CS speech AMR HR on non hopping channels SG14HOPAR
SG-15 CS speech AMR-WB FR GMSK on hopping channels SG15HOPAR
SG-16 CS speech AMR-WB FR GMSK on non-hopping SG16HOPAR
channels
Table 62 Service groups for handover purpose (Cont.)
For example the SG1HOPAR attribute contains the following thresholds (among
others):
– hoLowerThresholdLevDL: Lower RXLEV handover threshold for DL (range: 0...63)
– hoLowerThresholdLevUL: Lower RXLEV handover threshold for UL (range: 0...63)
– hoThresholdLevDLintra: DL RXLEV threshold for intra-cell handover due to bad
level (range: 0...63)
– hoThresholdLevULintra: UL RXLEV threshold for intra-cell handover due to bad
level (range: 0...63)
– hoLowerThresholdQualDL: Lower RXQUAL handover threshold for DL (range:
0...20)
– hoLowerThresholdQualUL: Lower RXQUAL handover threshold for UL (range:
0...20)
The user, when setting handover parameters, can choose to use specific settings for a
service group (filling one of the SGxxHOPAR attribute, xx = 1, 2, ...), or to use the service
independent thresholds (i.e. the general attributes that are valid for all the groups when
the user does not specify the SGxxHOPAR attributes).
The general configuration rule is the following:
a) When the user does not set any SGxxHOPAR parameter, service independent
parameters (i.e. the general parameters valid for all service groups) regard all the
circuit switched services;
b) When the user sets one SGxxHOPAR attribute related to a specific CS service, the
service dependent thresholds of this SGxxHOPAR attribute override the corre-
sponding service independent thresholds, but only these (so: if at least one of the
SGxxHOPAR attribute fields is set to a valid value, also all the other attribute fields
338 Id:0900d805805383c7 A50016-G5100-B556-04-7620

must be set to valid values). All the other service independent parameters remain
untouched.
If the user does not want to use the SGxxHOPAR thresholds, the user shall set the attri-
butes to NULL value; this value is considered as the DEFAULT value for the attributes.
The BTS is informed about the attribute settings in the following ways:
• The service independent thresholds and flags are transferred to the BTS via O&M
alignment;
• The thresholds belonging to SGxxHOPAR attributes are transferred to the BTS via
a specific optional Information Element (Service Group Handover Settings) added
in one of the following messages:
– CHANNEL ACTIVATION
– CHANNEL MODE MODIFY
– CHANNEL CONFIGURATION
The CHANNEL CONFIGURATION message is used to signal some changes
occurred in a set of parameters previously submitted with either the CHANNEL
ACTIVATION message or the CHANNEL MODE MODIFY message.
In case a SGxxHOPAR parameter is set to an invalid value, the BSC does not insert the
Information Element in the message concerned. In this case the BTS applies the thresh-
olds received via O&M alignment for the execution of the handover algorithm.
12.6 Generation of the target cell list

When the handover detection algorithms evaluate a handover condition, a target cell list
is generated, i.e. a list of the adjacent cells which are candidates for a handover. The
target cell list is based on the neighbor cell measurements of the MS. The condition for
taking a neighbour cell n into the target cell list is given by the following formula (equiv-
alent to the path loss criterion C1), a kind of minimum condition regarding the
RXLEVDL(n) values received by the MS:
RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max(n) – PWRMS, max)
with:
– RXLEVDL, averaged: The measured and averaged receive level of the BCCH signal of
the current or an adjacent cell (3GPP notation: RXLEV_NCELL).
– RXLEVDL, min: The minimum receive level at the MS.
– PWRUL, max(n): The maximum transmit power level the MS is permitted to use on a
traffic channel in the neighbour cell n.
– PWRMS, max: The maximum transmission power capability of the MS.
Attributes:
– RXLEVMIN (“rxLevMinCell“): This attribute is related to the ADJC object and speci-
fies RXLEVDL, min.
– MSTXPMAXGSM (“msTxPwrMaxGsm“): This attribute specifies PWRUL, max in case
the GSM 900, GSM850 or GSMR frequency band is used.
– MSTXPMAXPCS (“msTxPwrMaxPcs“): This attribute specifies PWRUL, max in case
the PCS 1900 frequency band is used.
– MSTXPMAXDCS (“msTxPwrMaxDcs“): This attribute specifies PWRUL, max in case
the DCS 1800 frequency band is used.
The second part on the right side of the equation, i.e. max(0,PWRUL, max – PWRMS, max),
has to be taken into account according to the following consideration: If the power capa-
A50016-G5100-B556-04-7620 Id:0900d805805383c7 339

bility of the MS is lower than the max. allowed UL transmission power (amount of the
difference: PWRUL, max – PWRMS, max), then the minimum receive level from a neighbour
cell has to be increased by just this lack of transmission power for compensation. The
lower the maximum transmit power of the MS, the higher the minimum receive level of
a candidate cell has to be.
g Assign a higher value to RXLEVMIN (“rxLevMinCell“) than to HOLTHLVDL
(“hoLowerThresholdLevDL“) / HOLTHLVUL (“hoLowerThresholdLevUL“) in order to
avoid ping-pong handovers. See Figure 124.
going handover
out
ming handov
co e
in
r
cell 1
power budget cell border
hoLowerThresholdLev
rxLevMinCell
cell 2 cell 3
rxLevMinCell > hoLowerThresholdLev
Figure 124 Thresholds defining cell borders

The RXLEVDL, averaged condition is applied in the given way to the following handover
types (the imperative handovers):
– Extended cell handover
– Concentric cell handover
– Quality handover
– RXLEV handover
– Distance handover
The cells for which the penalization time for the prevention of the handover failure rep-
etition (see chap. 12.8 Handover prevention procedures) has not expired are not
included in the target cell list.
Additional modifications/considerations for filling the target cell list for the other types of
handovers are described below.
Eventually the target cell list is sorted, see 12.6.1 Sorting the target cell list.
Modifications for forced handover

In case of a forced handover the RXLEVDL, averaged condition can be tightened by the
additional cell specific parameter FHORLMO (“fHORxLevMinOffset”), contained in the
ADJC object:
340 Id:0900d805805383c7 A50016-G5100-B556-04-7620

RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max(n) – PWRMS, max) +

FHORLMO
The FHORLMO parameter defines the forced handover receive level minimum offset
used to determine whether a neighbour cell should be regarded as suitable target cell
for forced handover or not.
Modifications for fast uplink handover

In case of a fast uplink handover the RXLEVDL, averaged condition can be tightened by the
additional cell specific parameter FULRXLVMOFF (“fastULRxLevMinOffset”):
RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max(n) – PWRMS, max) + FULRX-
LVMOFF
The FULRXLVMOFF parameter, contained in the ADJC object, defines the fast uplink
handover receive level minimum offset used to indicate the suitability of a neighbour cell
as target cell.
Two target cell sub-lists are built: The first sub-list (with higher priority) contains the cells
marked as predefined cells, the second sub-list (with lower priority) contains the cells
not marked as predefined cells. A cell can be predefined by setting the FULHOC (“fas-
tULHoCell“) attribute, subordinate to the ADJC object of this cell, to TRUE.
Additional conditions for power budget handover

In addition to the RXLEVDL, averaged criterion, the following two conditions must also be
fulfilled to take a neigbour cell n into the target cell list:
• The power budget condition is fulfilled:
PBGT(n) > HOM(n)
• In case of a hierarchical cell structure (HIERC = TRUE) the priority of the neigbour
cell n is equal or higher than the priority of the current cell s:
PNLC(n) ≤ PL(s)
(in case of speed sensitive power handover PNLC is replaced by PPNLC while
t < HOMDTIME)
These conditions have already been applied during the handover indication process.
For explanations and attributes please refer to 12.4.5 Power budget handover and
12.4.7 Speed sensitive power budget handover.
Additional conditions in case of DTM and hierarchical cell structure

In addition to the RXLEVDL, averaged criterion, the following two conditions must also be
fulfilled to take a neigbour cell into the target cell list (compare with the conditions for
power budget handover):
For t < DTMHOMT (t starts after e.g. a FORCED HANDOVER REQUEST):
– PBGT > DTMHOM (modified power budget condition)
– DTMPLneighbour cell < DTMPLserving cell in case of hierarchical cell structure
For t ≥ DTMHOMT the usual power budget conditions apply:
– PBGT > HOM
– PLNC < PL in case of hierarchical cell structure
These conditions have already been applied during the DTM power budget handover
indication process. For explanations and attributes please refer to 12.4.6 DTM power
budget handover.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 341

Modifications and additional considerations for traffic handover

For the selection of target cells for traffic handover the following attributes are provided:
– TRFHOT: (related to the HAND attribute) A timer determining the repetition rate of
the search for neighbour target cells.
– TRFKPRI: (related to the HAND attribute) This attribute is effective only when the
hierarchical cell structure is enabled, and it determines whether candidate cells have
to be of the same priority as the serving cell (TRFKPRI = TRUE) or may be of the
same or higher priority (TRFKPRI = FALSE)
– TRFMMA: (related to the HAND attribute) The maximum reduction for TRFHOM
– TRFMS: (related to the HAND attribute) The minimum reduction for TRFHOM
– TRFHOM: (related to the ADJC attribute) The offset in the power budget condition;
it defines the nominal cell border between cells
– BHOFOT: (related to the ADJC attribute) The time for which a back handover due
to traffic reason or power budget reason is suppressed
– TRFHORXLVMOFF: The offset added to the RXLEVDL, averaged condition of the
affected cell
The candidate cells are adjacent cells that belong to the same BSC of the serving cell.
When the BSC invokes the start of a traffic handover in the cell, a repetition timer is
started and a search for neighbour cells is executed. Every time this timer expires the
threshold TRFHOT, the offset in the power condition, which is applied for the neighbour
cell selection below, is changed (with the help of the m variable, see below) in order to
favour or unfavour subsequent handover attempts, and the timer starts again.
The following conditions are used for selecting the target cells:
• The RXLEVDL, averaged condition modified in the following way:
RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max(n) – PWRMS, max) + TRF-
HORXLVMOFF
The TRFHORXLVMOFF attribute is foreseen in order to make sure that a traffic
handover is only attempted towards those target cells which provide sufficient
service quality conditions.
• Moreover only the cells satisfying the following power condition can be included in
the target cell list:
PBGT(n) > TRFHOM(n) – K
where K is a dB value defined as follows:
K = m · TRFMS with m = 1, ..., TRFMMA / TRFMS (so
TRFMS ≤ K ≤ TRFMMA)
The m variable allows to change the power condition gradually, depending on the
previous actions. Every time the TRFHOT timer expires, m is changed as follows:
– When the traffic handover is activated by the BSC, m is set to 1.
– If the handover due to traffic is still enabled, m is incremented by one, thus
favouring the neighbour cell in the next target cell search.
– If the handover due to traffic has been disabled meanwhile by the BSC, m is dec-
remented by one, thus obstructing the neighbour cell in the next target cell
search.
When m reaches the 0 value, the BTS skips the traffic handover procedure.
• In case of a hierarchical cell structure the target cell list is additionally restricted to
the cells satisfying the following priority condition, depending on the TRFKPRI value:
– PLNC(n) = PL for TRFKPRI = TRUE
342 Id:0900d805805383c7 A50016-G5100-B556-04-7620

– PLNC(n) ≥ PL for TRFKPRI = FALSE

(in case of speed sensitive power handover PNLC is replaced by PPNLC while
t < HOMDTIME)
Modifications for quality handover

In specific network configurations the minimum level criteria for the target cell in a quality
handover can not always guarantee that the received downlink power level is high
enough to maintain the connection. For this reason an additional power offset has been
defined to take only these cells into the target cell list for a quality handover which
exceed the usual minimum received downlink power level of the serving cell by this
offset. This minimizes the drop rate of the calls due to unsuccessful handovers.There-
fore the following attributes have been implemented:
• ENAQUALEVHOM (“enableQualityLeveHOMargin“): This attribute is related to the
HAND Object and enables or disables that the additional power offset is included in
the RXLEVDL, averaged formula.
• QUALLEVHOM (“qualLevelHoMargin“): This attribute is related to the ADJC Object
and determines the power offset. Values: 0, 1, 2, 3, ..., 125, 126. “0” corresponds to
“–63 dB”, “1” corresponds to “–62 dB”, ..., ”126” corresponds to “+63 dB”. The
default value is: “69” which corresponds to “+6 dB”.
With ENAQUALEVHOM = TRUE, the RXLEVDL, averaged(n) condition is modified as
follows:
RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max(n) – PWRMS, max) + QUAL-
LEVHOM
Modifications for level handover: level handover margin

A cell can offer a good outdoor coverage while including a poor coverage area (for
example within a building or around a corner). When a MS accesses the poor coverage
area, it can occur, that the downlink receive level falls under the level threshold indicat-
ing a level handover, but no target cells can be found due to the usual RXLEVDL, aver-
aged(n) condition:
RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max(n) – PWRMS, max) (I)
So it would be desirable to decrease the RXLEVDL, min(n) threshold, resulting in more
target cells found. Unfortunately the reduction of RXLEVDL, min(n) – without any compen-
sation – would have a negative effect on the selection of neigbour cells for quality han-
dovers (too many inappropriate neigbour cells), which is done with the same formula.
Therefore the following additional criterion has been introduced, which can be
enabled/disabled by the ELEVHOM attribute:
RXLEVDL, averaged(n) > RXLEVDL, averaged(s) + LEVHOM (II) (s: serving cell)
LEVHOM is the level handover margin attribute, an offset allowing to configure the con-
dition (II).
With ELEVHOM = TRUE, both RXLEVDL, averaged(n) conditions (I) and (II) are applied
simultaneously. In this case the RXLEVDL, min(n) value in the usual RXLEVDL, averaged(n)
condition (I) can be decreased (thus increasing the potential number of target cells)
without negative impact: The second condition is only fulfilled, if the downlink receive
level breaks strongly down; so the increase of additional target cells is restricted to areas
with poor coverage.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 343

12.6.1 Sorting the target cell list

The target list is sorted in different ways depending on the cell structure (normal and
hierarchical cell structure) and in case of hierarchical cell structure depending on the
ranking method selected. In all cases the power budget equation (see 12.4.5 Power
budget handover) is used which is is evaluated for all cells of the target cell list:
PBGT(n) =
(min(PWRUL, max(s), PWRMS, max) – RXLEVDL, averaged(s) – power_redDL,averaged(s))
– (min(PWRUL, max(n), PWRMS, max) – RXLEVDL, averaged(n))
Handover margins are taken into account by calculating (PBGT(n) – HOM(n)). HOM is
associated with a timer (see 12.8 Handover prevention procedures).
The sorting of the target list is executed in the BTS.
Sorting in case of normal cell structure

The target cell list is sorted in decreasing order of (PBGT(n) – HOM(n)), i.e. the cells with
the highest (PBGT(n) – HOM(n)) values are ranked first, the cells with the lowest values
are ranked last.
Sorting in case of hierarchical cellular structure

Two ranking methods are available:
• Ranking method 0: The following ranking steps are performed:
– First, the target cells are distributed in two target cell sub-lists: The sub-list with
higher priority contains the cells with PBGT(n) – HOM(n) > 0, the sub-list with
lower priority contains the cells with PBGT(n) – HOM(n) < 0.
– Second, the cells within a sublist are grouped according to their cell priorities
defined by PLNC (see 12.4.5 Power budget handover); a cell with lower PLNC
value has a higher priority (within the sublist) than a cell with higher PLNC value.
In case of speed sensitive power handover PNLC is replaced by PPNLC while
t < HOMDTIME.
– Third, the cells of the same PLNC priority within a sublist are ordered according
to their (PBGT(n) – HOM(n)) values.
• Ranking method 1: The following ranking steps are performed:
– First, the target cells are distributed in two target cell sub-lists: The sub-list with
higher priority contains the cells which fulfill a tightened RXLEVDL, averaged(n) con-
dition: RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max(n) – PWRMS,
max) + LEVONC
The second sub-list contains the target cells which do not respect the above
condition, but only the minimum condition already used for the initial target cell
list generation.
LEVONC defines a level offset in order to exclude neigbour cells with low
RXLEVDL, averaged values from the first target cell sub-list.
– Second, the cells within a sublist are grouped according to their cell priorities
defined by PLNC; a cell with lower PLNC value has higher priority than a cell with
higher PLNC value.
– Third, the cells of the same PLNC priority within a sublist are ordered according
to their (PBGT(n) – HOM(n)) values.
The second and third ranking steps of both ranking methods are equal.
344 Id:0900d805805383c7 A50016-G5100-B556-04-7620

The candidate target cells of the first sub-list have the highest priority; within a sublist,
the cells with the lowest PLNC value have the highest priority, at last (among the cells
with equal priority) the (PBGT(n) – HOM(n)) values determine the lowest order priorities.
Regarding a power budget handover which is only indicated if PBGT(n) – HOM(n) > 0,
the target cell list contains only cells for the first sub-list with ranking method 0. In other
words, the first sorting step of ranking method 0 is automatically done (with empty
second sub-list). Therefore ranking method 0 is automatically assumed (ranking method
1 is not appropriate) and only one sorted list results.
Attributes:
The HIERF (“hierarchicalCellRankFlag“) attribute determines the ranking method. The
Rank0 value defines that ranking method 0 is to be applied, the Rank1 value selects
ranking method 1.
LEVONC (“levelOffsetNCell“): This attribute defines the level offset that is added to the
minimum receive level of an adjacent cell to become a target cell in case the ranking
method 1 is specified.
12.7 Handover execution

When the BTS has detected a handover condition, it sends the HANDOVER CONDI-
TION INDICATION message to the BSC including the target cell list (the NCELL attri-
bute can limit the number of cells to be included in this message). Since the handover
execution procedures depend on the handover category (intra-cell, inter-cell/intra-BSC,
inter-cell/inter-BSC), the BSC first checks this category. The next steps of the handover
execution are described in the following topics.
The LOTERCH attribute enables/disables a BSS-internal inter-cell handover request,
e.g. if LOTERCH = FALSE, the handover request is handled as inter-BSS handover and
the MSC is involved.
The LOTRACH attribute enables/disables a BSS-internal intra-cell handover request,
e.g. if LOTRACH = FALSE, the handover request is handled as inter-BSS handover and
the MSC is involved.
The BSC channel allocation strategy (both in the assignment case and in the handover
case) takes care of the RF resource indication messages received by the BTS, reporting
the interference level of the idle channels (on a cell basis) classified in up to 5 interfer-
ence bands, in order to specify the lowest interference level for any new call.
Intra-cell handover
An intra-cell handover is enabled with LOTRACH = TRUE and is executed by the BSC
(the MSC is not required, but is informed after the successful execution of the handover);
in case of a concentric or extended cell, the LOTRACH attribute is discarded.
After the reception of the HANDOVER CONDITION INDICATION message from the
BTS and in case an intra-cell handover is indicated, the BSC proceeds as follows (see
also Figure 125):
A50016-G5100-B556-04-7620 Id:0900d805805383c7 345

-3 "43 "3# -3#
-EASUREMENT2EPORT
3
)NTRACELL(ANDOVER#OND)ND
#HANNEL!CTIVATION
!SSIGNMENT#OMMAND
&
3ET!SYNCHR"AL-ODE
& %STABLISH)NDICATION
5NNUMBERED!CKNOWL
&
!SSIGNMENT#OMPLETE
&
(ANDOVER0ERFORMED
2ELEASE2EQUEST
-EASUREMENT2EPORT
3 2ELEASE#ONFIRM
2&#HANNEL2ELEASE
3 3!##(
2&#HANNEL2ELEASE!CK
& &!##(
Figure 125 Intra-cell handover messaging
1. Search for free radio channel:

The BSC looks for a free channel within the cell.
If no appropriate radio resource is found, the handover execution process within the
BSC is terminated and the BSC waits for the next HANDOVER CONDITION INDI-
CATION message from the BTS which will be sent after the relevant BTS repetition
timer expires. In case of a quality handover request, a ping-pong between the intra-
cell and inter-cell requests is foreseen within the BTS algorithm with the help of the
skip_flag (see 12.4.3.1 Quality handover), so that, if an intra-cell handover fails, the
request can be changed to an inter-cell handover.
Else, if an appropriate free radio channel is found, the procedure goes on with the
next step.
2. New channel activation:
The BSC requests the new radio channel (TCH) at the BTS for the subsequent
assignment procedure and informs the BTS by the CHANNEL ACTIVATION
346 Id:0900d805805383c7 A50016-G5100-B556-04-7620

message which the BTS confirms with the CHANNEL ACTIVATION ACKNOWL-
EDGE message.
3. New channel assignment procedure:
The BSC sends the ASSIGNMENT COMMAND message to the mobile station. The
mobile station switches to the new channel and tries to establish this connection.
This includes the setup of a layer-2 connection and reporting with the SET ASY-
CHRONOUS BALANCED MODE layer-2 message from MS to BTS and with the
UNNUMBERED ACKNOWLEDGEMENT layer-2 message back from BTS to MS.
Having accomplished this step, the MS responds to the BSC with the ASSIGNMENT
COMPLETE message. The BSC shall receive this message, before the timer T10
expires.
4. Notification to the MSC:
The BSC informs the MSC with the HANDOVER PERFORMED message, that a
handover within the BSC (intra-cell in this case) has been successfully executed.
5. Release of the old channel:
The BSC requests the release of the old channel by sending the RELEASE
REQUEST message to the BTS which the BTS confirms by the RELEASE
CONFIRM message. Then the BSC releases the old radio link and reports this
action by sending the RF CHANNEL RELEASE message to the BTS, eventually the
BTS sends back the corresponding acknowledgement message.
g Regarding the Ater/A interface part of the connection the BSC, having received the
CHANNEL ACTIVATION ACKNOWLEDGE message, adds the downlink branch of
the new channel to the existing full duplex connection. This allows the mobile to
receive speech immediately when it connects to the target channel and thus reduces
the muting gap during the handover procedure. The temporary DL connection is
replaced by the new full duplex connection after the BSC´s receipt of the ESTAB-
LISH INDICATION message.
The parallel addition of the new DL channel can be disabled by setting bit 4 and/or
bit 5 of the MNTBMASK (“maintenanceBitMask“) attribute, for more information see
end of next topic Inter-cell/intra-BSC handover.
Inter-cell/intra-BSC handover
An inter-cell handover is enabled with LOTERCH = TRUE and is executed by the BSC
(the MSC is not required, but is informed after the successful execution of the handover).
After the reception of the HANDOVER CONDITION INDICATION message from the
BTS and in case an inter-cell handover is indicated, the BSC scans the target cell list
included in this message in the given order beginning with the first target cell (with the
highest priority). The following decisions are possible:
• If the current target cell belongs to the BSC area and a free and appropriate radio
channel is found, the handover is executed, which is described below.
In case of a traffic handover only the neigbour cells with a traffic level lower than the
TRFLTH value are appropriate. The TRFLTH attribute is related to the HAND attri-
bute and determines the low traffic level threshold.
g When the user sets the TRFHITH (high level traffic threshold, see
12.4.10 Traffic handover) and TRFLTH (low level traffic threshold) values, the
following condition must be satisfied: TRFHITH – TRFLTH ≥ 15
• If the current target cell belongs to the BSC area, is appropriate and no free radio
channel is found, the BSC proceeds to the next target cell. A cell can be inappropri-
ate for various reasons, e.g.:
A50016-G5100-B556-04-7620 Id:0900d805805383c7 347

– the cell is not accessible by the BSC because of database misalignment;

– a frequency redefinition in the cell is in progress;
– serving cell and target cell have different bands but the classmark info from the
MS does not permit GSM to DCS handover.
– in case of traffic handover, the traffic level in the neighbour cell is too high
(exceeds the TRFLTH threshold)
• If the current target cell does not belong to the BSC area, an inter-cell/inter-BSS
handover is triggered: The BSC send the HANDOVER REQUIRED message to the
MSC, which tries to execute the handover as described in the next topic. The
HANDOVER REQUIRED message contains all remaining target cells of the target
cell list (in case the first target cell does not belong to the BSC area, the complete
target cell list is sent to the MSC).
• The end of the target cell has been reached without success. No handover is exe-
cuted.
If the BSC has found a free channel in an appropriate target cell, the following procedure
is executed:
The BSC requests the new radio channel for the subsequent assignment procedure
and informs the BTS via the CHANNEL ACTIVATION message. The target BTS
activates the new radio channel (TCH in the target cell) and responds to the BSC
with the CHANNEL ACTIVATION ACKNOWLEDGE message.
2.1 Regarding the Ater/A interface part of the connection the BSC adds the downlink
branch of the new channel to the existing full duplex connection (this allows the
mobile to receive speech immediately when it connects to the target channel).
2.2 The BSC sends the HANDOVER COMMAND message to the mobile station
(usually with the “Activation Type” IE: “related to asynchronous handover”
because the radio resources of different sites (BTSM areas) are usually not syn-
chronized). The HANDOVER COMMAND message contains e.g. characteris-
tics of the new channel and of the new cell (e.g. a frequency list in case of
frequency hopping) and a power level for the initial power on the new channel.
2.3 The MS switches to the new activated radio channel, attempts to seize it and
requests further information from the target BTS by sending the HANDOVER
ACCESS message via new FACCH to the BTS. The MS can immediately
receive speech on the new channel (DL direction).
2.4 The target BTS sends the HANDOVER DETECTION message to the BSC in
order to notify this BSC that the MS is seizing the new channel.
2.5 The BSC switches the matrix connection (affecting the Ater/A interface part of
the connection) and MS speech is now transmitted via the new connection also
in UL direction.
2.6 The target BTS answers the HANDOVER ACCESS message of the MS with the
PHYSICAL INFORMATION message, which contains various physical layer-
related information (e.g. the actual timing advance which the BTS derives from
the time delay of the HANDOVER ACCESS burst), allowing the correct trans-
mission by the MS.
2.7 The MS synchronizes to the new radio channel and tries to set up the layer-2
connection in the target cell by sending the SABM (Set Asynchronous Balanced
Mode) layer-2 message via the new FACCH.
348 Id:0900d805805383c7 A50016-G5100-B556-04-7620

2.8 When the layer-2 connection could be established, the target BTS confirms with
the UNNUMBERED ACKNOWLEDGEMENT layer-2 message. The target BTS
also reports to the BSC with the ESTABLISH INDICATION message on the new
channel.
2.9 The MS accomplishes the assignment procedure by sending the HANDOVER
COMPLETE message to the BSC on the new channel. The BSC shall receive
this message before the timer T8 expires.
3. Notification to the MSC:
The BSC informs the MSC with the HANDOVER PERFORMED message, that a
handover within the BSC (inter-cell in this case) has been successfully executed.
4. Release of the old channel:
The BSC requests the release of the old channel by sending the RELEASE
REQUEST message to the old BTS. The old BTS confirms with the RELEASE
CONFIRM message. Then the BTS releases the old radio link and sends the RF
CHANNEL RELEASE message to the old BTS, eventually the acknowledgement
message is sent back from the old BTS to the BSC.
An ongoing call on the MS during the handover procedure is disturbed mainly between
step 2.3 and step 2.5, and possibly until step 2.7.
g In case the source and target cells are finely synchronized, which is usual for cells
belonging to the same site (BTSM area) and is indicated by the HOSYNC attribute,
the handover procedure is simplified resulting in a faster handover: The
HANDOVER COMMAND message sent by the BSC then contains the “Activation
Type” IE: “related to synchronous handover”. When the MS accesses the target cell
after receipt of the HANDOVER COMMAND message, it transmits 4 consecutive
HANDOVER ACCESS messages and immediately establishes the layer-2 connec-
tion on the new FACCH by sending the SABM after that. No PHYSICAL INFORMA-
TION message is sent to the MS.
g Step 2.1 is useful in any case as it reduces the muting gap during handover.
However, for the (rather unrealistic) theoretical case that some settings for AMR
speech are unfavourable (e.g. inhomogeneous Initial Codec Modes or/and Active
Codec Sets in the BSC's cells, the operator may decide to disable the addition of the
DL target channel (parallel to the current DL channel) for AMR calls, as (possible)
codec mismatches on the target cell may lead to some noise effects that are
regarded as worse than the handover speech gap itself. While setting bit 4 of the
MNTBMASK attribute disables step 2.1 for standard codecs (EFR, FR, HR), setting
of bit 5 disables step 2.1 for AMR codecs.
Inter-cell/inter-BSC handover
This type of handover is performed in the following cases:
– The BSC, scanning the target cell list contained in the HANDOVER CONDITION
INDICATION message from the BTS, has found that the appropriate target cell
belongs to a different BSC area.
– Intra-BSC handling is disabled (by LOTRACH = FALSE and LOTERCH = FALSE)
The following procedure is performed (see Figure 126):
A50016-G5100-B556-04-7620 Id:0900d805805383c7 349

-3 "43 "3# -3# 4ARGET"3# 4ARGET

"43
-EASUREMENT
3 2EPORT (ANDOVER#OND
)NDICATION (ANDOVER
2EQUIRED (ANDOVER
2EQUEST #HANNEL
-EASUREMENT !CTIVATION
3 2EPORT
#HANNEL
(ANDOVER !CTIVATION!CK -3
(ANDOVER 2EQUEST!CK
(ANDOVER #OMMAND
& #OMMAND
3WITCHTONEW
(ANDOVER
2ADIO#HANNEL
(ANDOVER !CCESS &
(ANDOVER $ETECTION
0HYSICAL
$ETECT
& )NFORMATION
3 3!##( 3ET!SYNCHR
%STABLISH "AL-ODE &
& &!##( )NDICATION 5NNUMBERED
& !CKNOWL
(ANDOVER
(ANDOVER #OMPLETE &
#LEAR #OMPLETE
2ELEASE #OMMAND
2EQUEST
-EASUREMENT
2ELEASE 2EPORT 3
#ONFIRM #LEAR
#OMPLETE
2ELEASED
-EASUREMENT
2&#HANNEL
2EPORT 3
2ELEASE
2&#HANNEL
2ELEASE!CK 2ELEASE
#OMPLETE -EASUREMENT
2EPORT 3
Figure 126 Inter-cell, inter-BSC handover messaging
1. Putting the MSC in charge:

The BSC sends the list of target cells within the HANDOVER REQUIRED message
to the MSC which governs the handover procedure (in case the BSC has already
scanned a part of the target cell list, only the remaining target cells, beginning with
the first cell not belonging to the BSC area are contained).
2. Searching for the target BSC:
The MSC searches the target cell list and identifies the target (new) BSC which the
current target cell belongs to.
350 Id:0900d805805383c7 A50016-G5100-B556-04-7620


3.1 The MSC sends a HANDOVER REQUEST message containing the target cell
to the target BSC.
3.2 The target BSC, having received the HANDOVER REQUEST message,
searches for radio resources in the target BTS. In case an appropriate free radio
channel (TCH) is found, this channel is requested for the subsequent channel
assignment and the BSC informs the BTS by sending the CHANNEL ACTIVA-
TION message.
3.3 The target BTS responds to the target BSC with the CHANNEL ACTIVATION
ACKNOWLEDGE message. Consequently the target BSC responds to the MSC
with the HANDOVER REQUEST ACKNOWLEDGE message including the
reserved radio channel of the target BTS.
The MSC sends a HANDOVER COMMAND message to the serving (old) BSC,
which initiates the handover execution by sending a HANDOVER COMMAND
message to the MS (with the “Activation Type” IE: “related to asynchronous han-
dover” because the radio resources related to different BSCs are usually not syn-
chronized). The following procedure is very similar to the intra-BSC channel
assignment:
4.1 The MS switches to the new activated radio channel, attempts to seize it and
requests further information from the target BTS by sending the HANDOVER
ACCESS message via new FACCH to the BTS.
4.2 The target BTS sends the HANDOVER DETECTION message to the target
BSC in order to notify this BSC that the MS is seizing the new channel.
4.3 The target BSC forwards the HANDOVER DETECTION message by sending
the HANDOVER DETECT message to the MSC.
4.4 The target BTS answers the HANDOVER ACCESS message of the MS with the
PHYSICAL INFORMATION message, which contains various physical layer-
related information (e.g. the actual timing advance which the BTS derives from
the time delay of the HANDOVER ACCESS burst), allowing the correct trans-
mission by the MS.
4.5 The MS synchronizes to the new radio channel and tries to set up the layer-2
connection in the target cell by sending the SABM (Set Asynchronous Balanced
Mode) layer-2 message via the new FACCH.
4.6 When the layer-2 connection could be established, the target BTS confirms with
the UNNUMBERED ACKNOWLEDGEMENT layer-2 message. The target BTS
also reports to the target BSC with the ESTABLISH INDICATION message on
the new channel.
4.7 The MS accomplishes the assignment procedure by sending the HANDOVER
COMPLETE message to the target BSC on the new channel. The BSC shall
receive this message before the timer T8 expires.
4.8 The target BSC acknowledges the reception of the HANDOVER COMPLETE
message by sending a HANDOVER COMPLETE message to the MSC.
5. Release of the old channel and of the old terrestrial connection:
5.1 When the MSC receives the HANDOVER COMPLETE message, it orders the
old BSC to release its dedicated radio resources by means of the CLEAR
COMMAND message.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 351

5.2 The old BSC releases the radio channel in the same way as for an BSC-internal
inter-cell handover and responds to the MSC with the CLEAR COMPLETE
message.
5.3 The SCCP connection is released with the two SCCP messages RELEASED
and RELEASE COMPLETE.
If a handover attempt with one target cell is not successful, the MSC is in charge to
initiate another handover attempt with the next target cell and so on.
Details on ciphering information:

The HANDOVER REQUEST message from the MSC optionally includes the “Chosen
Encryption Algorithm” IE informing the target BSC which encryption code (especially
which A5/3 algorithm) has been used for the call so far. The target BSC transfers this
information into the “Cipher Mode Setting” IE of the HANDOVER COMMAND to be sent
to the MS, thereby informing the MS which encryption code is to be used.
Repetition of the PHYSICAL INFORMATION message:
After receipt of HANDOVER ACCESS bursts with a correct handover reference the BSS
sends a PHYSICAL INFORMATION message to the MS and starts the timer T3105. If
the timer expires before the BSS receives any correctly decoded layer 2 frame from the
MS, it repeats the PHYSICAL INFORMATION and restarts T3105 (more general T3105
is used for LAPDm UI-frames (layer 2 frames in unacknowledged mode)). Receipt of a
correctly decoded layer 2 leads to the reset of T3105. The maximum number of repeti-
tions is determined by the parameter NY1. If this number is reached and T3105 expires
again, the BTS sends a CONNECTION FAILURE INDICATION message with cause
“handover access failure” to the BSC which releases the new allocated channels and
stops the context related to the handover.
Remarks:
• The MS can only receive the PHYSICAL INFORMATION within a time frame deter-
mined by the MS timer T3124 (time to receive the PHYSICAL INFORMATION)
which is fixed to 320 ms. T3124 is started when the MS transmits the first
HANDOVER ACCESS message, and is stopped when the PHYSICAL INFORMA-
TION was received. If no PHYSICAL INFORMATION is received before expiry of
T3124, the MS returns to the old channel in the originating BTS and sends a
HANDOVER FAILURE message to the BSC.
• The MS can also return to the old channel after having successfully received the
PHYSICAL INFORMATION message: When the MS having sent the SABM
message via the new FACCH does not receive the acknowledgement (UA
message) by the BTS, it retransmits the SABM message. The time between two re-
transmissions is determined by the value of the T200 timer for this channel type
which is hardcoded in the MS but which is not unambiguously defined by the stan-
dard. A usual solution for a FACCH FR repetition time is 32 TDMA frames (T200)
and the number of re-transmissions (N200) restricted to 5. This means that for the
resulting time of approx. 800 ms the MS tries to set up the layer 2 connection on the
target channel. If all these attempts fail, the MS tries to return to the old channel.
• Any CONNECTION FAILURE INDICATION is a trigger event for the TCH drop
counter NRFLTCH and the SDCCH drop counter NRFLSDCC. For this reason the
time determined by NY1 · T3105 must be longer than the sum of the maximum time
the MS might need to return to the old channel and the time necessary for the
release of the new channel (RF CHANNEL RELEASE). If this rule is not considered,
352 Id:0900d805805383c7 A50016-G5100-B556-04-7620

call drops would be counted even if there is no real call drop but just a reversion to
the old channel during handover. As described above, in case of unsuccessful
access to the target channel it may (in the worst case) take more than 1 s (T3124
(= 320 ms) + 800 ms) before the MS returns to the old channel. The signalling of the
handover failure and the subsequent release of the target channel takes additional
time (especially in case of MSC controlled handover). Field experiences have shown
that he following setting is suitable to avoid the aforementioned drawbacks:
NY1 · T3105 ≥ 2 s.
Regarding that T3105 is restricted to a maximum time of 120 ms and the BTS sets
T3105 to the fixed value 50 ms after the first PHYSICAL INFORMATION re-trans-
mission, it is recommended to set the values to T3105 = MS10-10 (tunit-tvalue) and
NY1 = 50 avoiding a “bombardment” of the MS with unnecessary FACCH messages
(that steal the frames of the normal speech channel) within the handover speech
gap.
Delayed handover for emergency calls

The “Delayed handover for emergency calls” feature restricts handovers for an MS,
which starts an emergency call, in order to prevent interference with the execution of a
location procedure. Thus major delays of location procedures can be avoided.
After the BSC has received the CHANNEL ACTIVATION message during the setup of
an emergency call, the BSC starts an internal timer. Until this timer has not expired, no
forced handovers and non-imperative handovers (power budget handover, traffic han-
dover, compression/decompression handover) are processed for the emergency call.
The delay time (the time period after which the timer expires) is specified by the value
of the ULPWRD (“uplinkPowerDelay“) attribute. This timer value is also used for the
“Delayed power control for emergency calls” feature, see chap. Power Control. Conse-
quently the delayed power control feature has to be enabled to allow delayed handover.
This is done by the ULPWRDSUP (“uplinkPowerDelaySupport”) attribute.
The delayed handover also restricts the reorganization of radio resources done by
forced handovers. This could lead to non-optimal PS resource assignments.
12.8 Handover prevention procedures

The handover procedures shall be inhibited for the following purposes:
• to avoid back handover to the old cell in case of power budget triggered handover
• to avoid further handover repetitions after a specific number of consecutive
handover failures
• to avoid further handover repetitions after a specific number of consecutive success-
ful intra-cell handovers
The procedures provided for these situations are described in the following topics.
Back handover prevention

The following attributes have been defined for back handover prevention:
– TIMERFHO (“timerFHO“): The time period for suppression of back handover in case
of a forced handover
– TINHBAKHO (“timerInhibitBackHo“): The time period for suppression of back
handover in case of any other handover
A50016-G5100-B556-04-7620 Id:0900d805805383c7 353

– HOM (“hoMargin“): An offset influencing the power budget condition which allows to
suppress that a cell is included in the target cell list, and which also suppresses
power budget handover indications.
Figure 127 shows the interplay between BTS and BSC in order to prevent a back
handover from cell B to cell A in case a handover has been previously executed from
Cell A to Cell B.
BTS A BSC BTS B
Intercell Handover Condition Indication
(Target Cell List: B, C, D; HO Cause: ...)

Channel Activation
(Originating Cell: A; HO Cause: ...)
Successful Handover
(Target Cell List: B, C, D; HO Cause: PBGT)

(Cell A excluded)
Figure 127 Prevention of back handover

1. Preconditions:
1.1 Cell A has requested a handover by sending a HANDOVER CONDITION INDI-
CATION message to the BSC, the target cell candidates B, C and D are included
in this message.
1.2 The BSC has selected cell B as target cell and orders the handover to cell B by
sending the CHANNEL ACTIVATION message to the BTS responsible for
cell B. This message informs the BTS about the original cell (cell A) and the
handover cause.
1.3 The handover from cell A to cell B is executed.
2. Settings in the BTS:
The BTS for cell B starts the relevant timer; the TIMERFHO or TINHBAKHO value
defines how long a back handover to cell A shall be suppressed.
3. Target cell list evaluation during the runtime of the timer:
The BTS adds the value of the HOM attribute to the power budget condition for cell
A (leading to the PBGT(cell A) > HOM(cell A) condition, see 12.4.5 Power budget
handover), thus suppressing that the power budget handover condition indicates
cell A as appropriate neigbour cell.
4. After expiry of the timer the selection of target cell A is no longer suppressed in cell
B (the HOM value no longer influences the power budget condition).
In case a sequence of handovers is performed – e.g. from cell A to cell B to cell C –, a
handover from cell C to cell A is not inhibited (this is not a direct back handover); cell B
does not inform cell C about the previous handover from cell A to cell B.
354 Id:0900d805805383c7 A50016-G5100-B556-04-7620

Prevention of handover failure repetition

The following attributes have been defined for the definition of the penalization time and
the number of permitted handover failures:
• NOFREPHO: allows to enable/disable the prevention of handover failure repetition
• MAXFAILHO: The maximum number of handover failures that can occur on the
same connection towards the same cell
• TINHFAIHO: The time period for which the BTS excludes an adjacent cell from the
target cell list when the MAXFAILHO threshold has been reached
Figure 128 shows the interplay between BTS and BSC in order to prevent unlimited rep-
etitions of handovers between cell A and cell B in case handover attempts from cell A to
Cell B have been failed for a specific maximum number of times.
BTS A BSC BTS B
(Target Cell List: B, C, D; HO Cause: ...)

Channel Activation
(Originating Cell: A; HO Cause: ...)
Handover not successful
MAXFAILHO consecutive
Handover Failure Indication (B) HO failures on cell B
(Target Cell List: C, D; HO Cause: ...)

(Cell B excluded)
Figure 128 Prevention of handover failure repetition

The following steps are executed in case the NOFREPHO is set to TRUE:
1. Preconditions:
1.1 Cell A has requested a handover by sending a HANDOVER CONDITION INDI-
CATION message to the BSC, the target cell candidates B, C and D are included
in this message.
1.2 The BSC has selected cell B as target cell, but the handover to cell B has failed
MAXFAILHO times.
2. The BSC informs the BTS responsible for cell A about the handover failure by
sending the HANDOVER FAILURE INDICATION message. This message informs
the BTS about the inappropriate target cell (cell B).
3. The BTS for cell A starts the relevant timer; the TINHFAIHO value defines how long
a handover to cell B shall be inhibited.
4. Target cell list evaluation during the runtime of the timer:
The BTS excludes cell B from any target list for all types of handovers.
5. After expiry of the timer the selection of target cell B is no longer suppressed.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 355

Limitation of intra-cell handover repetition

The following attributes have been introduced for the definition of the penalization time
and the number of permitted intra-cell quality handovers:
• MAIRACHO (“maxIntraCellHandover“): The maximum number of consecutive, suc-
cessful quality intra-cell handovers (managed by BSC) that are permitted in the
same BTS
• TINOIERCHO (“timerNoIntraCellHo“): The time period determining how long a
quality intra-cell handover is inhibited for a specific connection in the cell, if the
MAIRACHO threshold has been reached
Figure 129 shows the interplay between BTS and BSC in order to prevent unlimited rep-
etitions of intra-cell handovers within cell A in case a specific number of intra-cell han-
dovers have been previously performed.
BTS A BSC
Channel x
Intracell Handover Condition Indication
(HO Cause: Quality)
Channel Activation
(Channel y; HO Cause: Quality)
MAIRACHO consecutive
Successful Handover
successful intra-cell HOs
Channel y
Intracell Handover Condition Indication
(HO Cause: Quality)
Channel Activation
Timer T started
(Channel z; HO Cause: Quality)
(Indication of last quality intra-cell handover)
Successful Handover
Channel z
no more Intracell Handover

Condition Indication (quality)
until T > TINOIERCHO
Figure 129 Limitation of intra-cell handover repetition

1. On the BSC side the number of consecutive successful intra-cell handovers is
counted.
2. When the number of consecutive successful intra-cell quality handovers reaches the
MAIRACHO limit, the BSC sends a CHANNEL ACTIVATION message to the BTS
356 Id:0900d805805383c7 A50016-G5100-B556-04-7620

which informs the BTS about the original cell (cell A) and the handover cause and
indicates that further repetitions shall be inhibited.
3. The BTS starts the relevant timer; the TINOIERCHO value defines how long further
intra-cell quality handovers shall be inhibited.
4. Target cell list evaluation
During runtime of the timer the BTS inhibits intra-cell quality handovers within the
cell. Other handover types are not affected.
5. After expiry of the timer the inhibition of intra-cell quality handovers is stopped.
12.9 Call release due to excessive distance

When the distance of a Mobile Station, having established a call, has exceeded a pre-
defined threshold value and no handover could have been successfully performed, the
BTS triggers the release of the call. This is useful in two situations:
• The Mobile Station is moving towards a region where no service is supported. In this
case, call release avoids jamming the adjacent radio timeslot;
• The Mobile Station crosses the border line to another PLMN no agreement exists
with. In this case, even if the distance from the BTS still allows communication, it is
better to release the call to avoid co-channel interference with the other network.
The BTS indicates the call release by the CONNECTION FAILURE message including
the following cause: “distance limit exceeded” (the same message, but without the “dis-
tance limit exceeded” cause, is used to release a call in case of abnormal conditions).
Optimization and parameters

In order not to release a call too early, the power level of each cell on a PLMN border
line shall be set in a way, that the power handover condition is satisfied and a handover
is tried, before the timing advance has reached the threshold value for the excessive
distance (see Figure 130).
Cell A Cell B
Cell C
Cell D Cell E
PLMN Boarder Excessive Distance
Figure 130 Example for excessive distance
A50016-G5100-B556-04-7620 Id:0900d805805383c7 357

EEXCDIST (“enableExcessiveDistance“): This parameter determines whether the

feature call release due to excessive distance is enabled or not.
EXCDIST (“excessiveDistance“): This parameter specifies the distance limit between
MS and BTS to be used for a call release due to excessive distance. If the MS-BTS
distance is bigger than the value entered for EXCDIST, no call setup is possible. On the
other hand, if during an ongoing call the MS-BTS distance exceeds the EXCDIST
threshold, the BTS sends the CONNECTION FAILURE message to the BSC and the
call is released. The value entered for EXCDIST must be greater than the value entered
for the distance handover threshold.
12.10 GSM-UMTS intersystem handovers

When a user, having established a circuit switched call (voice or data) in a UMTS
network, moves out of the UMTS coverage area into a GSM area, a handover from
UMTS to GSM must be handled to avoid a call drop. Vice versa it can happen that a
UMTS capable MS/UE, having established a connection within the GSM system, moves
into an UMTS covered area where a UMTS connection would be more appropriate, e.g.
for better radio transmission conditions or higher capacity. Therefore intersystem han-
dovers are provided from UMTS to GSM and from GSM to UMTS as well.
Figure 131 shows the network elements involved in the intersystem handover and the
interfaces. The combined 2G/3G-MSC is the crucial network element connecting the
GSM and the UMTS system; it supports the Iu interface towards the RNC on the UMTS
side and the A interface towards the BSC on the GSM side.
5M -3 5U
"43 .ODE"
!BIS '3- 5-43 )UB
''-3#
"3# 2.#
! )U
Figure 131 UMTS/GSM network architecture

A 2G-MSC is not sufficient, because it only supports the A interface to the BSCs of the
GSM network (a “pure” 3G-MSC supporting only the Iu interface towards the RNC for
UMTS is also not sufficient), but it can be interfaced with 3G-MSCs that support the Iu
interface.
The suggested configurations for the execution of a handover from GSM to UMTS in a
combined 2G/3G-MSC configuration are the following:
• 2G-MSC ciphering on / 3G-MSC ciphering on;
• 3G-MSC ciphering off / 3G-MSC ciphering off.
358 Id:0900d805805383c7 A50016-G5100-B556-04-7620

Classmark information
The UE/MS is expected to send the UTRAN CLASSMARK CHANGE message to the
network in order to provide the network with UTRAN related information for intersystem
handover. The BSC stores the information and evaluates whether the UE/MS is capable
to perform the intersystem handover. The BSC forwards this information to the BTS and
to the MSC. The transmission of the UTRAN CLASSMARK CHANGE message requires
either that handovers from GSM to UMTS have generally been enabled by setting the
EUHO (“enableHoFromGsmToUmts”) attribute to TRUE or that early classmark sending
is enabled by setting the EARCLMS3G (“earlyClassmarkSending3G“) parameter to
TRUE. In the latter case the “3G Early Classmark Sending Restrictor “ is always set to
the value “H” (Handover) within the SYSTEM INFORMATION and PACKET SYSTEM
INFORMATION messages independently from the value of the EUHO attribute; thus
UTRAN CLASSMARK CHANGE messages are provided immediately after a relevant
request message.
A special use case for EARCLMS3G = TRUE is that the UE starts a call in a GSM cell
where handovers to UMTS are disabled (EUHO = FALSE) and then it performs an
intra-GSM handover towards a cell with handover to UMTS enabled (EUHO = TRUE),
then in the target cell the UE can trigger the collection of UTRAN measurements, but the
handover towards UMTS cannot be executed (if EARCLMS3G is not set to TRUE).
g If in a cell ENHANCED MEASUREMENT REPORTs (see Messages for RRM man-
agement) are used for release 4 MSs with 3G capabilities (the REPTYP attribute is
set to ENHANCED_ONLY_FOR_R43G_MS) and the EUHO parameter is set to
FALSE, then the EARCLMS3G parameter of the BTS object must be set to TRUE
in order to guarantee a proper classification of MSs/UEs and, as a consequence, to
guarantee the correct enabling of EMRs ENHANCED MEASUREMENT REPORTs.
Measurement information from BTS to MS

MEASUREMENT INFORMATION messages (see Messages for RRM management)
can be sent from the BTS to the MS in dedicated mode on SACCH informing the MS/UE
e.g. about the 3G neighbours to be monitored during an ongoing call (MEASUREMENT
INFORMATION messages can be seen as the 3G-equivalent to SYSTEM INFORMA-
TION TYPE 5, 5bis and 5ter messages). Therefore it is required that handovers from
GSM to UMTS are generally enabled (EUHO = TRUE). In other words, the UE can only
report 3G neighbour cells if EUHO was set to TRUE in the cell and the UE was thus
informed via the MEASUREMENT INFORMATION messages about the 3G neighbours
to be monitored during an ongoing call.
Reporting quantity
MultiRAT mobiles (RAT = Radio Access Technology) can report the radio conditions of
UMTS FDD neighbour cells either by RSCP values (level oriented) or by Ec/No values
(quality oriented), but not both at the same time:
• RSCP (Received Signal Code Power): This value indicates the DL receive level in
the UMTS FDD neighbour cell and is thus comparable to the RXLEV value in GSM.
• Ec/No (Energy chip to Noise over all): This value indicates the DL quality in the
UMTS FDD neighbour cell and is thus comparable to the RXQUAL resp. C/I values
in GSM.
Additional background information:
In a UMTS FDD network, the different calls are transmitted via the same radio fre-
quency, the distinction of the channels is done on the basis of code division multiplex,
A50016-G5100-B556-04-7620 Id:0900d805805383c7 359

i.e. each channel is characterized by its own code. The overall downlink signal which is
broadcast in a particular UMTS neighbour cell is expressed as RSSI (Received Signal
Strength Indicator). This RSSI value, however, must be distinguished from the RSCP
value, which is valid for a particular code only. The relation of RSSI, RSCP and Ec/No
is defined as: RSSI – RSCP = Ec/No
12.10.1 Handover from GSM to UMTS

From the BSC and the BTS point of view, the GSM-to-UMTS handover is mainly per-
formed as a normal MSC controlled handover in the GSM system; only BSC/BTS func-
tions are required. The BTS initiates the handover in the same way as for GSM-internal
handovers: When the BTS has detected that the handover condition is satisfied and a
handover is necessary, it generates a target cell list (TCL). The target cell list contains
those neighbor cells, which are the best target cell candidates. The target cell list is
sorted according to the cell priorities and according to the Service Handover information
sent from the BSC to the BTS.
In case a UMTS cell is on the top of the target cell list, the handover procedure from
GSM to UMTS is executed according to the following main steps (see Figure 132):
1. The BSC sends the HANDOVER REQUIRED message to the 2G/3G-MSC; the
request contains a single target UMTS cell to which the UE/MS shall be re-directed.
2. The 2G/3G-MSC sends the RELOCATION REQUEST message to the selected
target RNC.
3. The RNC and affected Node B then execute the necessary actions to allow the
MS/UE to access its resources; once the resource allocation has been completed,
the RNC returns a RELOCATION REQUEST ACK message to the 2G/3G-MSC.
4. The 2G/3G-MSC sends a HANDOVER COMMAND message to the BSC.
5. On receipt of the HANDOVER COMMAND message, the BSC sends the INTER-
SYSTEM to UTRAN HANDOVER COMMAND message to the BTS which forwards
it to the UE/MS. The UE/MS then accesses the radio resource.
6. On detection of the UE/MS by Node B (having received the HANDOVER ACCESS
message from the UE/MS) and RNC (having received the HANDOVER DETEC-
TION message from the Node B), the RNC sends a RELOCATION DETECT
message to the 2G/3G-MSC.
7. When the UE is successfully communicating with the Node B, the UE sends the
HANDOVER COMPLETE message to the Node B which forwards the message to
the RNC.
8. The RNC informs the 2G/3G MSC about the successfull handover by sending the
RELOCATION COMPLETE message to 2G/3G-MSC.
9. The release of the GSM radio resources is started by the CLEAR COMMAND sent
from the 2G/3G MSC to the BSC.
10. The release of the resources is performed in the same way as for a normal MSC-
controlled GSM intra-system handover.
360 Id:0900d805805383c7 A50016-G5100-B556-04-7620

MS/UE BTS BSC 2G/3G MSC Target RNC Target

Node B
Measurement
Report Intercell Handover
Cond. Indication Handover
Required Relocation
Request Radio Link
Measurement Setup Request Activate new 3G
Report
Radio Link Radio Channel
Intersystem to Relocation Setup Response
Intersystem to UTRAN Handover Request Ack.
UTRAN Handover Command MS/UE
Command
Switch to new
Handover
Radio Channel
Handover Access
Relocation Detection
Detect
Handover
Relocation Complete
Clear Complete
Release Command
Request
Release
Confirm Clear
Complete
Released
RF Channel
Release
RF Channel
Release Ack. Release
Complete
Figure 132 Handover from GSM to UMTS

Besides, the “Classmark Enquiry Mask” Information Element (IE) has been imple-
mented in the BSS system according to 3GPP. It is sent to the MS within the CLASS-
MARK ENQUIRY message by the BSC in case the BSC initiates a 2G/3G handover and
it instructs the MS to provide its 3G radio capability data to the network. The “Classmark
Enquiry Mask” IE is maintained only if needed, it is not required for a normal Location
Update procedure.
In case it is the MSC which sends the CLASSMARK REQUEST message to the BSC
thereby triggering the BSC to send the CLASSMARK ENQUIRY message to the MS,
the “Classmark Enquiry Mask” IE is not included.
Restrictions
An intersystem handover of a CS call into a neigbour 3G cell marked by IHSPA = TRUE
is not performed. Such a 3G cell is optimized for high speed packet services and
A50016-G5100-B556-04-7620 Id:0900d805805383c7 361

supports HSDPA and HSUPA; the cell is intended to concentrate PS traffic. For this
reason, such cells are not included in the MEASUREMENT INFORMATION and the
SYSTEM INFORMATION TYPE 2quater messages.
12.10.1.1 Attributes and configurations

The first thing the user has to do is to generally enable handovers from GSM to UMTS
on a cell basis. After that the user can enable different handover types according to his
needs. In order to allow comparison of the handover criteria of GSM with conditions in
the UMTS target cells, various attributes are foreseen for the different handover types.
Enabling GSM to UMTS handovers

To enable handovers from GSM cells towards the UMTS network in general, the EUHO
(“enableHoFromGsmToUmts”) attribute related to the HAND object has to be set to
TRUE.
Reporting quantity
The FDDREPQTY (related to the BTS object) indicates the reporting quantity for
UTRAN FDD cells; valid values are RSCP and EC_NO. The setting of the FDDREPQTY
has an influence on the 2G-3G handover processing in the BTS:
• 2G-3G handovers from GSM to UMTS due to 'better cell' (power budget handover)
are only possible if FDDREPQTY is set to RSCP, as only in this case a comparison
of the RXLEV value of the serving GSM cell to the RSCP value in the UMTS FDD
neighbour cell is possible via the handover margin.
• Imperative 2G-3G handovers from GSM to UMTS are possible with both settings of
FDDREQTY, but the processing of the measured values is different:
– If FDDREPQTY is set to RSCP, the handover minimum condition, which is
checked in order to determine whether a particular UMTS FDD neighbour cell is
a suitable target cell for imperative handovers from GSM to UMTS, is defined by
the RSCP-oriented parameter RXLEVMINC.
– If FDDREPQTY is set to EC_NO, the handover minimum condition, which is
a suitable target cell for imperative handovers from GSM to UMTS, is defined by
the Ec/No-oriented parameter UMECNO.
• 2G-3G handovers from GSM to UMTS due to 'sufficient coverage' are possible with
both settings of FDDREPQTY, but the processing of the measured values is differ-
ent:
– If FDDREPQTY is set to RSCP, the sufficient coverage condition, which is
a suitable target cell for 'sufficient coverage' handovers from GSM to UMTS, is
defined by the RSCP-oriented parameter USRSCP
– If FDDREPQTY is set to ECNO, the sufficient coverage condition, which is
a suitable target cell for such handovers from GSM to UMTS, is defined by the
Ec/No-oriented parameter USECNO.
Imperative handovers
Imperative handovers (level handovers, quality handovers and distance handovers) can
be enabled by setting the EUIMPHO attribute to TRUE.
The following attributes are provided for generating the target cell list:
362 Id:0900d805805383c7 A50016-G5100-B556-04-7620

• RXLEVMINC (related to the ADJC3 object): the minimum level which is required to
include an UMTS cell into the handover target cell list in case of an imperative han-
dover; it is valid in case FDDREPQTY = RSCP.
• UMECNO (related to the ADJC3 object): the minimum level which is required to
include an UMTS cell into the handover target cell list in case of an imperative han-
dover; it is valid only for FDD cells in case FDDREPQTY = EC_NO.
• MSTXPMAXUMTS (related to the TGTFDD object or the TGTTDD object): indicates
the maximum transmission power level a UE is allowed to use in the UMTS cell.
The condition for including the neigbour cell n in the target cell list is analogous as for
GSM (see 12.6 Generation of the target cell list):
RXLEVDL, averaged(n) > RXLEVDL, min(n) + max(0,PWRUL, max on UMTS – PWRMS, max)
Here, RXLEVDL, min(n) is specified by the following attributes:
– RXLEVMINC in case of FDDREPQTY = RSCP (the neighbour cell measurement
quantity is RSCP):
– UMECNO in case of FDDREPQTY = EC_NO (the neighbour cell measurement
quantity is Ec/No):
In all cases PWRUL, max on UMTS is specified by the MSTXPMAXUMTS attribute.
Power budget handover

Once the user has enabled handovers from GSM to UMTS using the EUHO attribute,
the user can enable the power budget handover to UMTS by setting the EUBCHO attri-
bute (“enableBetterCellHoToUmts”) to TRUE.
The handover conditions for the GSM to UMTS handover are the same as for an intra-
GSM handover (see 12.4.5 Power budget handover), but have some new attributes
regarding the UMTS adjacent cells:
Power budget condition:
PBGT(n) =
(min(PWRUL, max , PWRMS, max) – RXLEVDL, averaged – power_redDL,averaged) –
(min(PWRUL, max on UMTS(n) , PWRMS, max on UMTS(n)) – RXLEVDL, averaged(n))
and:
PBGT(n) > HOM(n) + UADJ(n)
• PWRUL, max: The maximum GSM transmission power that a Mobile Station is permit-
ted to use on a control channel in the serving GSM cell: This value is specified by:
– MSTXPMAXDCS in case the DCS 1800 frequency band is used
– MSTXPMAXGSM in case the GSM 900, GSM850 or GSMR frequency band is
used
– MSTXPMAXPCS in case the PCS 1900 frequency band is used
• PWRMS, max: The maximum transmission power capability of the Mobile Station in
the GSM cell.
• RXLEVDL, averaged: The averaged downlink RXLEV value of the current GSM cell
• power_redDL,averaged: Dynamic power reduction, i.e. the averaged difference
between the maximum downlink RF power supported in the cell and the current
downlink power due to power control
• PWRUL, max on UMTS(n) : The maximum UMTS transmission power that a Mobile
Station is permitted to use on a traffic channel in the adjacent cell n
A50016-G5100-B556-04-7620 Id:0900d805805383c7 363

• PWRMS, max on UMTS(n): The maximum transmission power capability of the Mobile
Station in the UMTS cell.
• RXLEVDL, averaged(n): The averaged RXLEV value of the neighbor UMTS cell
g Here, for power budget handover, the RSCP measurement quantity has to be
used and the FDDREPQTY attribute must be set to RSCP. The UMTS FDD
measurement quantity Ec/No can not be used, because Ec/No is a quality
measure and not a received level measure.
If the FDDREPQTY attribute is set to EC_NO by the user, then power budget
handovers from GSM to UMTS are automatically disabled by the BTS.
• HOM: An offset allowing to tighten the power budget condition in order to prevent
frequent back handovers or repetitive handovers
• UADJ (“umtsAdjust”): An offset allowing to adjust the carrier level of the UMTS
adjacent cell to the carrier level of the serving GSM cell
The condition for appropriate target cells:
The same condition is applied as for Imperative handovers.
The cell priority condition in case of a hierarchical cell structure:
PLNC(n) ≤ PL(s)
with:
– PL (“priorityLayer“): The hierarchical priority of the serving GSM cell s
– PLNC (priorityLayerNCell): The hierarchical priority of the UMTS neighbour cell n
(the same attribute as for a GSM neighbour cell), related to the ADJC3G object.
Sufficient UMTS coverage handover

Once the user has enabled handovers from GSM to UMTS using the EUHO attribute,
he can enable the Sufficient UMTS coverage handover to UMTS by the EUSCHO
parameter (“enableSufficientUmtsCoverageHoToUmts”).
The main objective of the GSM to UMTS sufficient UMTS coverage handover is to
perform a handover to the UMTS system as soon as possible, i.e. as soon as the UMTS
measurement quantity (RSCP or EC_NO for FDD cells, RSCP for TDD cells) exceeds
a certain "sufficient" threshold. So, this handover type is used to direct as much traffic
as possible to areas which offer "sufficient" UMTS coverage.
Therefore, the execution of the sufficient UMTS coverage handover has a higher priority
than the power budget handover; i.e. if the conditions of both handover types are fulfilled
simultaneously, the sufficient UMTS coverage handover is executed.
For a sufficient UMTS coverage handover from GSM to UMTS, the BTS compares the
RXLEVDL, averaged(n) of the UMTS neighbour cell n with a "sufficient" threshold, then the
BTS includes an UMTS neighbour cell into target cell list, if the following condition is met:
• In case of FDDREPQTY = RSCP (the neighbour cell measurement quantity is
RSCP):
RXLEVDL, averaged(n) > USRSCP(n) + max(0, PWRUL, max on UMTS – PWRMS, max)
• In case of FDDREPQTY = EC_NO (the neighbour cell measurement quantity is
Ec/No):
RXLEVDL, averaged(n) > USECNO(n) + max(0, PWRUL, max on UMTS – PWRMS, max)
with:
– USRSCP (“umtsSuffRscp”): The threshold above which the BTS initiates a sufficient
UMTS coverage handover from GSM to UMTS in case of FDDREPQTY = RSCP
364 Id:0900d805805383c7 A50016-G5100-B556-04-7620

– USECNO (“umtsSuffEcNo”): The threshold above which the BTS initiates a suffi-
cient UMTS coverage handover from GSM to UMTS in case of
FDDREPQTY = EC_NO
Speed sensitive handover

Speed Sensitive GSM to UMTS handover is a special kind of power budget handover or
Sufficient UMTS coverage handover. It suppresses handovers to UMTS microcells in
case of fast moving mobiles in order to avoid multiple handovers within a small time
period.
To enable speed sensitive handover from a GSM cell towards a UMTS cell, the user
must set the MICROCELL attribute in the ADJC3G object instance to TRUE. The
MICROCELL attribute determines whether the adjacent cell is regarded as a microcell.
For the speed sensitive GSM to UMTS power budget handover the same attributes and
algorithms are used as for the corresponding intra-GSM handovers (please refer to
12.4.7 Speed sensitive power budget handover), but now several parameters are
related to the ADJC3G object:
– HOMDTIME
– HOMSOFF
– HOMDOFF
– PPLNC
For the speed sensitive GSM to UMTS sufficient UMTS coverage handover only the
attributes HOMDTIME and PPLNC are used, which is done in the same way as for intra-
GSM power budget handovers, and the evaluation of the RXLEVDL, averaged(n) condition
is done as described in the relevant topic above (Sufficient UMTS coverage handover).
Forced handover (Directed Retry)

Forced handover is related to the Directed Retry feature and can be executed for GSM
to UMTS cases in the same way as for intra-GSM cases (see 12.4.9 Forced handover).
Once the user has generally enabled handovers from GSM to UMTS using the EUHO
attribute, he can enable Forced handover from GSM to UMTS setting the EUSDCHO
attribute (“enableUmtsSdcchHo”) of the BSC object to TRUE.
In order to support the GSM to UMTS Directed Retry, the BTS includes UMTS cells in
the Target Cell List (TCL) and sorts the TCL as for an imperative handover.
In addition to radio conditions or congestion, the BSC can initiate the Directed Retry from
GSM to UMTS if the "Service Handover" IE in the ASSIGNMENT REQUEST message
is set to "Handover to either UTRAN or cdma2000 should be performed". This service
based Directed Retry is required in order to achieve that the MS/UE is handed over to
UMTS already during the call assignment phase; i.e. during the early phase in which the
MS/UE is assigned to a GSM SDCCH, so that it can be avoided that a GSM TCH is
assigned to a MS/UE which should be handed over to UMTS as soon as possible.
Service handover
The "Service Handover" IE is supported by the BSC/BTS and it is sent by the MSC to
the BSC in the HANDOVER REQUEST message and in the ASSIGNMENT REQUEST
message. This IE specifies whether a handover to UMTS "should", "should not" or "shall
not" be performed. The following list describes the possible settings in the "Service Han-
dover" IE, done in the MSC, and the related consequences:
A50016-G5100-B556-04-7620 Id:0900d805805383c7 365

• Case 1: The "Service Handover" IE is set to:

"Handover to neither UTRAN nor cdma2000 shall not be performed”:
The BSC/BTS shall not select an UMTS cell; i.e. the MS/UE is never handed over
from GSM to UMTS, instead the MS/UE is kept within the GSM system.
The BSC adds this IE to the CHANNEL ACTIVATION message and sends it to the
BTS. The BTS generates a target cell list without UMTS target cells. Consequently
the Sufficient UMTS Coverage handover is disabled by the BTS for this MS/UE.
• Case 2: The "Service Handover" IE is set to:
"Handover to neither UTRAN nor cdma2000 should not be performed":
The MS/UE should be kept in the GSM system as long as possible.The BSC adds
this IE to the CHANNEL ACTIVATION message and sends it to the BTS.
In order to achieve that a MS/UE is kept in the GSM as long as possible, the BTS
only includes UMTS cells in the target cell list (TCL) in case of an imperative han-
dover. Consequently the Sufficient UMTS Coverage handover is disabled by the
BTS for this MS/UE.
Additionally the sorting of the target cell list is modified in the following way in order
to prefer GSM target cells: The GSM target cells and the UMTS target cells are
sorted separately; at first all GSM target cells according to the hierarchical cell pri-
orities and the (PBGT(n) – HOM(n)) values and then the UMTS target cells accord-
ing to the same criteria. At last the GSM target cells are put on the top of the target
cell list.
• Case 3: the "Service Handover" IE is set to:
"Handover to either UTRAN or cdma2000 should be performed":
The BSC/BTS should handover the MS/UE from GSM to UMTS as soon as possible.
The BSC adds this IE to the CHANNEL ACTIVATION message and sends it to the
BTS. Consequently the Sufficient UMTS Coverage handover is enabled by the BTS
for this MS/UE even if the sufficient UMTS Coverage handover is generally disabled
by EUSCHO = FALSE.
Additionally the sorting of the target cell list is modified in the following way in order
to prefer UMTS target cells: The GSM target cells and the UMTS target cells are
sorted separately; at first all UMTS target cells according to the hierarchical cell pri-
orities and the (PBGT(n) – HOM(n)) values and then the GSM target cells according
to the same criteria. At last the UMTS target cells are put on the top of the target cell
list.
Further considerations regarding the configuration of GSM to UMTS handovers

• Prevention of back handover (GSM to UMTS) cannot be supported.
• ASCI is a GSM feature and it is not supported by the UMTS system. Therefore, if the
MS/UE is an ASCI talker, no handover from GSM to UMTS is performed, i.e. the
ASCI talker is kept within the GSM system. As consequence, the BTS generates the
target cell list without including an UMTS target cells.
• The BSCT3121 (“bscTimer3121”) attribute, belonging to BSC object, defines the
timer that is started by the sending an INTERSYSTEM TO UTRAN HANDOVER
message and is normally stopped when the HANDOVER COMPLETE message is
received.
The following parameters inform the MS/UE about 3G neigbour cells to be monitored
and measurement parameters; their values appear e.g. in SYSTEM INFORMATION
messages and the MEASUREMENT INFORMATION message (the fields in these
messages have different names (3GPP naming conventions)):
366 Id:0900d805805383c7 A50016-G5100-B556-04-7620

• The MS/UE searches for UMTS cells, if the signal level (from the serving GSM cell)
is below or above a certain threshold. The user can set this value by the QSRHC
(““qSearchC”“) attribute of the BTS object; instead the QSRHCINI (“qSearchCini-
tial”) value has to be used by the MS/UE before QSRHC is received from the
network (i.e. before the MS enters the dedicated mode arriving from the idle mode);
• The FDDMURREP (“fddMultiratReporting”) attribute and the TDDMURREP (“tdd-
MultiratReporting”) attribute define the number of best valid UMTS neighbour cells
(FDD and TDD) which are reported by the MS/UE. The remaining positions in the
measurement report are used for reporting of GSM cells. If there are still remaining
positions, these are used to report the next best valid UMTS cells;
• UMTSSRHPRI (“umtsSearchPriority”): indicates if a mobile may search 3G cells
when BSIC decoding is required, i.e. if the searching time can be longer than the
normal value (13 s instead of 10 s). The equivalent 3GPP parameter
3G_SEARCH_PRIO is considered during BSIC decoding of surrounding neighbour
cells of different radio access technologies. The MS uses at least 4 spare frames per
SACCH block period for the decoding the BSICs (e.g. in the case of TCH/F, four idle
frames per SACCH block period). These frames are termed 'search' frames. The MS
attempts to demodulate the SCH on the BCCH carrier of as many surrounding cells
as possible, and to decode the BSIC as often as possible, and, as a minimum, at
least once every 10 s. A multi-RAT MS is allowed to extend this period to 13 s, if the
neighbour cell list contains cells from other RATs and if indicated by the parameter
3G_SEARCH_PRIO. The MS gives priority for synchronisation attempts in signal
strength order and considering the parameter MULTIBAND_REPORTING (param-
eter NMULBAC).
• NMULBAC (“nMultibandcell”): This parameter corresponds to the 3GPP parameter
MULTIBAND_REPORTING, is relevant for dualband configurations and specifies in
which way the MS shall report the neighbour cells of the frequency bands used in
the serving and neighbouring cells. Possible values:
– 0: Normal reporting of the six strongest cells, with known and allowed NCC part
of BSIC, irrespective of the band used.
– 1: The MS shall report the strongest cell, with known and allowed NCC part of
BSIC, in each of the frequency bands in the BA list, excluding the frequency
band of the serving cell.
– 2: The MS shall report the two strongest cells, with known and allowed NCC part
of BSIC, in each of the frequency bands in the BA list, excluding the frequency
band of the serving cell.
– 3: The MS shall report the three strongest cells, with known and allowed NCC
part of BSIC, in each of the frequency bands in the BA list, excluding the fre-
quency band of the serving cell.
Regarding the values “1”, “2” and “3”, the remaining positions in the measurement
report shall be used for reporting of cells in the band of the serving cell. If there are
still remaining positions, these shall be used to report the next strongest identified
cells in the other bands irrespective of the band used.
• FDDDIV (“fddDiversity“): indicates if diversity is used in the UMTS FDD target cell
or not. It corresponds to the 'Diversity' bit which is sent to the MS/UE, together with
the primary scrambling code (see parameter FDDSCRMC).
• FDDSCRMC (“fddScramblingCode“): defines the primary scrambling code used by
the target FDD cell. It corresponds to the 'Scrambling Code' which is sent to the
MS/UE within the FDD_CELL_INFORMATION field.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 367

• REPTYP (“reportType“): This parameter indicates to the mobile to use the

ENHANCED MEASUREMENT REPORT or MEASUREMENT REPORT messages
for measurements reporting. The setting of this parameter is reflected in the IE
REPORT_TYPE which is sent to the MS/UE in connected mode within the MEA-
SUREMENT INFORMATION message via SACCH.
• FDDREPO (“fddReportOffset“): This parameter is relevant for 'Enhanced Measure-
ment Reporting' and defines a fixed offset to be applied to all reported 3G neighbour
cells. The offset is applied as follows: if there is not enough space in the report for
all valid cells, those cells are reported that have the highest sum of the reported
value and the parameter FDD_REPORTING_OFFSET. This offset parameter,
however, does not affect the actual reported value. If a cell can not be reported due
to lack of space in the report message (MEASUREMENT REPORT or ENHANCED
MEASUREMENT REPORT), then no cell with a lower value shall be reported, even
if one of these cells with a lower value would fit into the report.
FDDREPO corresponds to the 3GPP parameter FDD_REPORTING_OFFSET.
• FDDREPTH (“fddReportThreshold“): This parameter defines a threshold which
UTRAN cell has to exceed in order to be reported in the ENHANCED MEASURE-
MENT REPORT. FDDREPTH corresponds to the 3GPP parameter
FDD_REPORTING_THRESHOLD.
• FDDREPTH2 (“fddReportThreshold2“): This parameter defines the threshold which
each reported UTRAN FDD adjacent cell has to exceed with its not-reported value
in order to be included in the ENHANCED MEASUREMENT REPORT. FDDREPTH
corresponds to the 3GPP parameter FDD_REPORTING_THRESHOLD_2.
12.10.2 Handover from UMTS to GSM

From the BSC and the BTS point of view, the UMTS to GSM handover is mainly per-
formed as a normal MSC controlled handover of the GSM system; only BSC/BTS func-
tions are required.
This type of handover is very important in the UMTS introduction phase, when the UMTS
system covers relatively small areas only (so called UMTS islands).
The following main steps are executed during the handover procedure:
1. When the UMTS network, currently supporting the MS/UE, determines that the
MS/UE must be handed over to the GSM network, it sends a HANDOVER
REQUEST message to the 2G/3G-MSC; the request contains a single target GSM
cell to which the MS/UE shall be re-directed.
2. When the 2G/3G-MSC receives the handover request, it begins the process of
handing over the UE/MS to the BSS; the 2G/3G-MSC sends the HANDOVER
REQUEST message to the BSC.
3. The BSC then executes the necessary actions to allow the MS/UE to access the
BSS resources; in particular the BSC must check, if the BTS equipment supports the
64 bit GSM ciphering key, which is used in the GSM system after a handover from
the UMTS network (see below).
4. When the BSS has allocated resources for the MS/UE, it returns the HANDOVER
REQUEST ACK message to the MSC.
5. The HANDOVER COMMAND message is sent to the MS/UE.
6. The MS/UE accesses the GSM network analogous to an inter-BSC handover.
7. The resources on the UMTS network are released.
368 Id:0900d805805383c7 A50016-G5100-B556-04-7620

Ciphering
The intersystem handover from UMTS to GSM implies a change of the ciphering algo-
rithm from the UMTS UEA algorithm to the appropriate GSM A5/3 algorithm. Then, the
2G/3G-MSC, when receiving the handover request from the UMTS network, converts
the 128 bit UMTS cipher key into the 64 bit GSM cipher key.
The 2G/3G-MSC informs the BSC about the 64 bit GSM cipher key, which is the result
of the UMTS to GSM cipher key conversion, by sending the HANDOVER REQUEST
message. This message includes the “Chosen Encryption Algorithm” IE informing the
target BSC about the GSM encryption code (especially the A5/3 algorithm) to be used.
The target BSC transfers this information into the “Cipher Mode Setting” IE of the
HANDOVER COMMAND to be sent to the MS, thereby informing the MS which encryp-
tion code is to be used.
Restrictions regarding ciphering and checks in case of BTS1s

Legacy BTS1s exclusively equipped with BBSIG44 boards do support 64 bit cipher
keys, but not BTS1s equipped with older BBSIG boards; these boards only support
cipher keys with up to 54 bit and therefore do not support ciphering after UMTS to GSM
handover.
The PUREBBSIG44CONF attribute related to the BTS object allows the BSC to distin-
guish between a BTS1 which contains only BBSIG44 boards, and a BTS1 which
contains a mixture of BBSIG and BBSIG44 boards.
When the BSC receives the HANDOVER REQUEST message (containing the 64 bit
GSM cipher key to be used) from the 2G/3G-MSC and a BTS1 is involved, the BSC
checks the length of the cipher key:
• If the cipher key length check results in "length = 8 bytes", then the BSC checks the
value of the PUREBBSIG44CONF attribute and acts as follows:
– PUREBBSIG44CONF = TRUE indicates that the BTS contains BBSIG44 boards
only and therefore supports the 64 bit ciphering. Consequently the handover can
be performed and the BSC sends the HANDOVER REQUEST ACK message to
the 2G/3G-MSC.
– PUREBBSIG44CONF = FALSE indicates that the BTS contains a mixture of
BBSIG and BBSIG44 and therefore does not support the 64 bit ciphering. Con-
sequently the BSC rejects the handover by sending the HANDOVER FAILURE
message with cause "ciphering algorithm not supported" to the 2G/3G-MSC.
• If the cipher key length check results in "length = 7 bytes or smaller" (i.e. in case of
traditional GSM calls), then the BSC checks the GSM service and data rate:
– Only for 14.4 kbit/s data calls the PUREBBSIG44CONF attribute is checked
(because such calls are not supported by BBSIG boards; the high 14.4 kbit/s
bitrate allows to conclude that the BTS is equipped with at least one BBSIG44
board). The further decisions and actions are executed as in the case above
(“length = 8 bytes”).
– For all other services and data rates different from 14.4 kbit/s data calls, the BSC
rejects the handover by sending the HANDOVER FAILURE message with
cause "ciphering algorithm not supported" to the 2G/3G-MSC.
To summarize, if the user wants to enable the BTS1 equipment to support handovers
from UMTS to GSM, first the user must equip them with BBSIG44 boards only; then the
user sets the PUREBBSIG44CONF attribute to TRUE value.
A50016-G5100-B556-04-7620 Id:0900d805805383c7 369

Cell changing and cell reselection Radio network management
13 Cell changing and cell reselection

An MS in idle mode has to camp on an appropriate cell in order to allow communication
with the mobile network, e.g. for receiving paging messages. The process for choosing
the cell to camp on is called cell selection. When the MS in idle mode moves around, a
change of the cell could be required, the related process is called cell reselection. An
analogous cell change within the GSM network in case of a packet switched connection
is also called cell reselection and replaces handovers applied for circuit switched calls.
The criteria for cell selection and reselection are introduced in chap. 13.1 Criteria for cell
selection and cell reselection.
The GPRS procedures for cell change and cell reselection are explained in:
– 13.2 Network assisted cell change (NACC)
– 13.3 External network assisted cell change (ENACC)
– 13.4 Network controlled cell reselection (NCCR)
Intersystem cell reselection is described in:
– 13.5 GSM-UMTS cell reselection
– 13.6 Network controlled reselection from GSM/GPRS to UMTS due to sufficient
UMTS coverage
13.1 Criteria for cell selection and cell reselection
13.1.1 C1 criterion
The C1 criterion or path loss criterion uses the following equation:
C1 = RXLEVDL, averaged – RXLEVDL, min – max(0,PWRMS, max on CCCH – PWRMS, max)
with:
– RXLEVDL, averaged: The measured and averaged receive level of the BCCH signal of
the current or an adjacent cell.
– RXLEVDL, min: The minimum receive level at the MS.
– PWRMS, max on CCCH: The maximum transmit power level the MS can use when
getting access to the system on a CCCH of the cell.
– PWRMS, max: The maximum transmission power capability of the MS.
The C1 criterion is applied for:
– Cell selection/reselection for a GSM MS in idle mode
– Cell selection/reselection for a GPRS MS in idle mode in case the BCCH is used as
broadcast channel (PBCCH not available)
– Cell reselection of GPRS MSs in packet transfer mode in case the BCCH is used as
broadcast channel (PBCCH not available)
– Abnormal cell reselection: A PBCCH exists but all access attempts of the MS via
PRACH in the current cell have failed, and access on another cell is allowed.
The C1 criterion can be replaced by the C2 criterion (see below) if the relevant param-
eters are provided via the BCCH.
Explanations:
The MS dynamically calculates the C1 value for the serving cell and the six strongest
non-serving cells at least every 5 s. The path loss criterion is satisfied – i.e. the receive
370 Id:0900d8058052e3be A50016-G5100-B556-04-7620

Radio network management Cell changing and cell reselection
level is considered as sufficient – , if C1 > 0 (if C1 has been below 0 for a period of 5 s,
the path to the cell is regarded as lost). If the C1 value of one non-serving cell is higher
than C1 of the serving cell for a period of 5 s, then the MS performs a cell reselection to
that neighbour cell. If several neighbour cells have constantly higher C1 values than the
serving cell, then the reselection is performed to the neighbour cell with the highest C1
value.
The term max(0,PWRMS, max on CCCH – PWRMS, max) is applied to ensure a sufficient uplink
RXLEV even for MSs with low transmission power capability. The lower the maximum
transmission power capability of the MS, the lower is the C1 value and thus the higher
the minimum RXLEV for access must be.
Modifications:
If the current cell and the new cell belong to different location areas, the new cell is only
selected if the path loss criterion C1 on the new cell exceeds C1 on the old serving cell
by at least a configurable offset value (hysteresis value) for a period of 5 s. This mech-
anism is used to avoid unnecessary location update procedures, as these procedures
always cause considerable signalling load in the BSS and the core network (MSC etc.).
The hysteresis value is sent on the BCCH (SYSTEM INFORMATION TYPE 3 and TYPE
4) in the “Cell Selection Parameters” IE and in the SET SYSTEM INFORMATION 10 in
the “Differential Cell Parameters” IE.
Attributes
The following attributes are provided for the C1 criterion in case of idle GSM MSs:
• RXLEVAMI (“rxLevAccessMin“): The minimum receive level at the MS required for
the access to the system. The RXLEVAMI value determines RXLEVDL, min in the C1
formula.
• MSTXPMAXCH (“msTxPwrMaxCcch“): The maximum transmit power level a MS
can use when getting access to the system on a CCCH of the cell. The MSTXP-
MAXCH value determines PWRMS, max on CCCH in the C1 formula.
• CELLRESH (“cellReselectHysteresis“): This attribute determines the hysteresis
value regarding C1 for a cell reselection into a cell of another location area.
The following additional attributes are provided in case of GPRS MSs in packet
idle/transfer mode (PBCCH available):
• GRXLAMI (“gprsRxLevelAccessMin”): The minimum received level at the MS
required for the access to the system. The GRXLAMI value determines RXLEVDL,
min in the C1 formula.
• GMSTXPMAC (“gprsRxLevelAccessMin“): The maximum power that the Mobile
Station can use to access the cell in case a PBCCH is present. The GMSTXPMAC
attribute is related to the PTPPKF object and its values for the serving and neighbour
cells are broadcast on the PBCCH of the serving cell. In case the PBCCH does not
exist, the Mobile Station uses the MSTXPMAXCH attribute instead The GMSTXP-
MAC value determines PWRMS, max on CCCH in the C1 formula.
In case of DCS 1800 cells PWROFS (“powerOffset”) defines an offset added to the
MSTXPMAXCH value to be used by DCS1800 Class 3 Mobile Stations for the cal-
culation of C1 (and C2).
• RAARET (“randomAccessRetry”): This parameter corresponds to the 3GPP param-
eter RANDOM_ACCESS_RETRY and determines whether random access retry on
another cell is allowed or not.
A50016-G5100-B556-04-7620 Id:0900d8058052e3be 371

13.1.2 C2 criterion
The C2 criterion is an optional feature that can be enabled on a cell basis. It is an
enhancement of the cell selection criterion C1. C2 is useful for micro-cell configurations
since it prevents fast moving MSs from performing unnecessary cell reselections.
The following formulas are applied:
• Serving cell (s):
C2(s) = C1(s)
• Neighbour cell (n):
– During the penalization time period:
C2(n) = C1(n) + OFFSETperm (n) – OFFSETtemp (n)
– After expiry of the penalization time period:
C2(n) = C1(n) + OFFSETperm (n)
with:
– OFFSETperm (n): permanent offset
– OFFSETtemp (n): temporary offset
Explanations:
If the MS places a non-serving cell on the list of the six strongest carriers, it starts a
penalty timer the value of which has been broadcast on the BCCH.
As long as the timer runs, C2 is increased by a permanent offset and decreased by a
temporary offset. By this temporary offset the C2 value of the non-serving cell is artifi-
cially made worse and the cell reselection is suppressed.
On expiry of the timer the temporary offset is disregarded and thus – if the C2 value of
a non-serving cell still exceeds the one of the serving cell for a period of 5 s – the MS
performs a cell reselection.
See also Figure 133 which shows the C2 graph dependent on the C2 parameters.
C2
C1 + CRESOFF
CRESOFF
TEMPOFF
C1
C1 + CRESOFF + TEMPOFF
Time
PENTIME
start of timer expiry of timer
Figure 133 C2 graph

Modifications:
If the current cell and the new cell belong to different location areas, the new cell is only
selected if the path loss criterion C2 on the new cell exceeds C2 on the old serving cell
by at least a configurable offset value (hysteresis value) for a period of 5 s. This mech-
372 Id:0900d8058052e3be A50016-G5100-B556-04-7620

anism is used to avoid unnecessary location update procedures, as these procedures

always cause considerable signalling load in the BSS and the core network (MSC etc.).
The hysteresis value and attribute is the same as for the C1 criterion.
If the penalty time is set to the maximum value (31, i.e. 260 s), the permanent offset is
not added but subtracted, resulting in a permanent decrease of priority. Thereby it is
possible to exclude particular cells from the cell reselection permanently, i.e. without any
time limitation.
Attributes
• CRESPARI (“cellReselectionParamInd“): This attribute is used to enable/disable the
C2 criterion. If enabled (CRESPARI = 1), the C2 cell reselection parameters are
broadcast on the BCCH in the “SI 4 Rest Octets” IE (SYSTEM INFORMATION
TYPE 4) and the “SI 3 Rest Octets” IE (SYSTEM INFORMATION TYPE 3). If
CRESPARI is set to 0, the parameters CRESOFF, TEMPOFF, PENTIME (and also
CBQ (“cellBarQualify“)) are skipped.
• CRESOFF (““cellReselectionOffset): The “permanent” offset applied in the C2 crite-
rion
• TEMPOFF (“temporaryOffset“): The “temporary” (time dependent) offset applied in
the C2 criterion
• PENTIME (“penaltyTime“): This attribute gives the duration for which the temporary
offset is applied.
13.1.3 C31 criterion

Every GPRS MS in packet idle mode and in packet transfer mode performs cell reselec-
tion autonomously on the basis of the cell selection criteria C31/C32 in case a PBCCH
is available in the cell (C1 is used in case only the BCCH is available and no PBCCH
exists (or access on PRACH in the current cell fails)).
The C31 signal level threshold criterion for hierarchical cell structures is used to deter-
mine whether prioritized hierarchical GPRS/EGPRS cell reselection is to be executed.
It is defined by the following equations:
C31(s) = RXLEVDL, averaged(s) – RXLEVDL, GPRS, HCS, min(s)
C31(n) = RXLEVDL, averaged(n) – RXLEVDL, GPRS, HCS, min(n) – OFFSETGPRS, temp (n)
C31(n) = RXLEVDL, averaged(n) – RXLEVDL, GPRS, HCS, min(n)
with:
– RXLEVDL, GPRS, HCS, min: the signal threshold for applying GPRS/EGPRS hierarchical
cell structures criteria in the C31 equation.
– OFFSETGPRS, temp (n): temporary offset
The C31 criterion is fulfilled, if C31 > 0 and the neigbour cell has the same priority as the
serving cell [GHCSPC(n) = GHCSPC(s)]:
Attributes
The parameters for the C31 criterion are subordinate to the ADJC object (GHCSTH also
subordinate to PTPPKF).
A50016-G5100-B556-04-7620 Id:0900d8058052e3be 373

• GHCSTH (“gprsHierarchicalCellStructureThreshold“): The signal threshold for

applying GPRS/EGPRS hierarchical cell structures criteria in the cell reselection.
The user defines the threshold both for the serving cell (via PTPPKF object) and for
its adjacent cells (via ADJC object). It defines the value RXLEVDL, GPRS, HCS, min(n).
• GPENTIME (“gprsPenaltyTime“): This attribute gives the duration for which the tem-
porary offset is applied in the C31 criterion (same attribute for the C32 criterion).
• GTEMPOFF (“gprsTemporaryOffset“): This attribute defines the temporary offset
applied in the C31 criterion (same attribute for the C32 criterion).
• GHCSPC (“gprsHierarchicalCellStructPriorityClass“): This attribute represents the
Hierarchical Cell Structure priority for cell reselection (same attribute for the C32 cri-
terion).
• C31H (“c31Hysteresis”): This parameter corresponds to the 3GPP parameter
C31_HYSTERESIS and indicates if the GPRS reselect hysteresis (GCELLRESH,
see below) shall be applied to the C31 criterion.
• GCELLRESH (“gprsCellReselectHysteresis”): GPRS cell reselect hysteresis, this
parameter corresponds to the 3GPP parameter
GPRS_CELL_RESELECT_HYSTERESIS and indicates the hysteresis to be sub-
tracted from the C31 value of the neighbour cells if the MS is in ready state and the
neighbour cell belongs to the same routing area. If C31H = TRUE, GCELLRESH is
additionally subtracted from the C31 values of the neighbour cells.
13.1.4 C32 criterion

The C32 criterion is similar to the C2 criterion used for GSM, but it makes use of
GPRS/EGPRS parameters. C32 contains, in addition to C1, for the neighbour cells a
permanent offset (to make a neighbour cell better or worse regarding reselections) and
a temporary offset, which is used to make a neigbour cell worse during a short time
period (the Mobile Station "sees" that cell, but does not select it for that time period; this
can be used to prevent some cells from being reselected by a fast driving Mobile Sta-
tion).
C32(s) = C1(s)
C32(n) = C1(n) + OFFSETGPRS, perm (n) – OFFSETGPRS, temp (n)
C32(n) = C1(n) + OFFSETGPRS, perm (n)
with:
– OFFSETGPRS, perm (n): permanent offset (positive or negative)
– OFFSETGPRS, temp (n): temporary offset
The C32 criterion is fulfilled, if C32 > 0 and the neigbour cell has the same priority as the
serving cell [GHCSPC(n) = GHCSPC(s)]:
Attributes
The parameters for the C32 criterion are subordinate to the ADJC object.
• GRESOFF (“gprsReselectOffset“): This attribute specifies the positive or negative
permanent offset/hysteresis in the C32 formula.
374 Id:0900d8058052e3be A50016-G5100-B556-04-7620

• GPENTIME (“gprsPenaltyTime“): This attribute gives the duration for which the tem-
porary offset is applied in the C32 criterion.
• GTEMPOFF (“gprsTemporaryOffset“): This attribute defines the temporary offset
applied in the C32 criterion.
• GHCSPC (“gprsHierarchicalCellStructPriorityClass“): This attribute represents the
Hierarchical Cell Structure priority for cell reselection.
• C32QUAL (“c32Qualifier”): this parameter corresponds to the 3GPP parameter
C32_QUALIFIER. If C32QUAL = TRUE, positive GPRS_RESELECT_OFFSET
values (set by GRESOFF) are only applied to the neighbour cell with the highest
averaged receive level value of those cells for which C32 is compared.
13.2 Network assisted cell change (NACC)

Network Assisted Cell Change (NACC) provides the Mobile Station with system infor-
mation of the target cell before a cell change is performed (i.e. as long as the MS is still
in the old cell and during ongoing packet data transfer). This feature significantly
reduces the service interruption time in case of cell change, because the MS needs not
to collect system information in the target cell by listening to the BCCH/PBCCH, before
it can start with any data transfer.
The NACC procedure is supported by 3GPP release 4 MSs and later. In particular, real
time services like streaming and push-and-talk benefit from this feature because of the
reduction of the service interruption from 5 s down to 500 – 700 ms. This enables the
PLMN operator to offer the mobile subscribers enhanced packet switched services.
The NACC procedure is applied on all cells controlled by a BSC (internal cells). For a
cell reselection between cells of different BSCs (external cells), NACC is not applicable;
instead ENACC (see chap. 13.3 External network assisted cell change (ENACC)) is
used. Besides, NACC between GSM and UMTS cells is also not possible (according to
the 3GPP Rel.5 standards).
Functional details
Network Assisted Cell Change is executed in the so-called Cell Change Notification
(CCN) mode. If NACC is enabled/supported in a BSC’s area, this information is broad-
cast in all cells controlled by the BSC via the BCCH (SYSTEM INFORMATION TYPE
13) or PBCCH (PACKET SYSTEM INFORMATION TYPE 1/13/14). Therefore the
CCN_ACTIVE parameter value is provided in the “GPRS Cell Options” Information
Element. The receipt of the CCN_ACTIVE value puts the MS into CCN mode (if possi-
ble). In CCN mode the MS contacts the BSC when cell reselection conditions are met
and delays cell reselection (with packet data transfer ongoing) to let the network answer
with neighbour cell system information.
Some details of the NACC procedure depend on the Network Control Order (NCO) con-
figurable by the user. The following procedure is applied in case of NCO = NC1 (see
Figure 134); deviations for NCO = NC0 are described subsequently.
A50016-G5100-B556-04-7620 Id:0900d8058052e3be 375

MS BTS A BSC
CNN
mode RLC Data Blocks
PDTCH
Packet Cell Change Notification

PACCH
Target
RLC Data Blocks cell
PDTCH evalu-
ation
Packet Neighbour Cell Data
PACCH
RLC Data Blocks

PDTCH
Packet Cell Change Continue or

PACCH
Packet Cell Change Order
Packet Control Ack (Cell Change)

PACCH
BTS B
Cell Change
Packet PSI/SI Status

PACCH
Packet Serving Cell Data

PACCH
RLC Data Blocks

Data flow in blue
PDTCH Signalling in black
Figure 134 Message flow for network assisted cell change
1. The MS sends the PACKET CELL CHANGE NOTIFICATION message to the BSC.
This message carries the BSIC and the ARFCN as identitiy for the proposed target
cell as well as the measurement reports for the proposed target cell and for other
neighbour cells if available. Packet data transfer in the current cell is ongoing.
2. The BSC evaluates the path loss criterion for the proposed target cell and – if nec-
essary and available – for the other neigbour cells.
3. After the evaluation, the BSC sends system information of the appropriate target cell
selected via the PACKET NEIGHBOR CELL DATA message.
4. If the target cell proposed by the MS is acceptable regarding the path loss criterion,
the BSC confirms this target cell by sending the PACKET CELL CHANGE
CONTINUE message. Otherwise the BSC sends the PACKET CELL CHANGE
376 Id:0900d8058052e3be A50016-G5100-B556-04-7620

ORDER message ordering the MS to execute a reselection different from the MS’s
original proposal.
5. The MS answers with the PACKET CONTROL ACK message and executes the cell
reselection. In case the MS has received a PACKET CELL CHANGE ORDER
message in the previous step, it leaves the CNN mode and behaves as for Network
Controlled Cell Reselection (NCCR; the NCO is set to NC2 and the MS no longer
controls the cell reselection).
6. After the switch to the new cell, the MS requests missing PACKET SYSTEM INFOR-
MATION or SYSTEM INFORMATION by sending the PACKET PSI/SI STATUS
message to the BTS of the new cell.
7. The MS is provided with the missing information via the PACKET SERVING CELL
DATA message on PACCH.
In case of NCO = NC0 the MS does not send measurement reports for NACC evalua-
tion. So the cell reselection is completely controlled by the MS, the BSC cannot change
the proposed target cell.
g Network Controlled Cell Reselection (NCCR) takes precedence over Network
Assisted Cell Selection (NACC). If NCCR is enabled, the Network Control Order
(NCO) is set to NC2 and the CNN mode is not applicable.
Additional information about Network Control Order:
The NCO value is periodically broadcast from the network to the MS as a two bit value
within the optional field “NC Measurement Attributes” of either the PACKET SYSTEM
INFORMATION TYPE 5 message (if PBCCH is present in the cell) or SYSTEM INFOR-
MATION TYPE 2quater (if PBCCH is not present in the cell, via BCCH); alternatively,
the network can use the PACKET MEASUREMENT ORDER message or the PACKET
CELL CHANGE ORDER message sent on the PACCH to address a particular MS. The
following attribute values of NCO are provided:
– NC0 (bit value: 00): Either MS controlled cell reselection (NACC), no measurement
reports regarding reselection from MS to network, or MSs in packet idle mode.
– NC1 (bit value: 01): MS controlled cell reselection (NACC); the MS sends measure-
ment reports for cell reselection, but it still performs the reselection autonomously.
– NC2 (bit value: 10): Network controlled cell reselection (NCCR); the MS sends mea-
surement report regarding reselection and it does not perform the cell reselection
autonomously.
The bit value 11 is reserved for future use and is currently interpreted as the NC0 value.
Attributes
The following attributes are provided to configure the Network Assisted Cell Change
feature:
• CCHANTFACT (“cellChangeNotificationActive“): This attribute related to the BSC
object determines whether or not Network Assisted Cell Change / the Channel
Change Notification procedure (CCN) is supported in the whole BSC area: Default
value: FALSE (disabled).
• NACCNTWCOR (“nACCNetworkControlOrder”): This parameter defines the usage
of Network Control Order during NACC when the MS is in packet transfer mode.
When NACC is enabled, the value of this parameter is put in the parameter Network
Control Order inside the PACKET MEASUREMENT ORDER message.
A50016-G5100-B556-04-7620 Id:0900d8058052e3be 377

• SYSPACKSYSSUP (“sysInfoPacketSysInfoSupport“): This attribute related to the

BSC object indicates if the PACKET PSI STATUS and PACKET SI STATUS
messages are supported or not in the BSC.
13.3 External network assisted cell change (ENACC)

The External Network Assisted Cell Change feature provides a GPRS MS in packet
transfer mode with target cell system information when the MS is moving between GSM
cells and a cell reselection towards a cell of another BSC (external cell) is indicated.
This feature extends the Network Assisted Cell Change feature (limited to BSC-internal
cell reselection) to support also cell reselection towards cells belonging to different
BSCs. ENACC reduces the service outage time during the execution of the cell reselec-
tion procedure towards external adjacent cells. The support is given to the Mobile
Stations as system information about the target cell before the Mobile Station performs
the cell reselection procedure (while packet data transfer is ongoing).
Functional details
The External Network Assisted Cell Change feature interacts with the Network Assisted
Cell Change (NACC) feature. Each Mobile Station in Cell Change Notification mode
informs the BSC system about the proposed cell for the execution of the reselection pro-
cedure. If the proposed target cell belongs to another BSC, this external BSC is included
in providing system information related to the selected cell to the Mobile Station. ENACC
uses RAN Information Management (RIM; RAN: Radio Access Network) for the
exchange of target cell system information between RAN nodes (e.g. BSCs and SGSN).
RIM is related to the Core Network and is specified by 3GPP.
Attributes
• ENACCE (“externalNACCEnable“): This attribute permits to enable/disable the
External Network Assisted Cell Change functionality in relation with its related
license status. Validity Range: TRUE, FALSE.
• CCHNOACT3GPP (“cellChangeNotificationActiveThreeG“): This attribute of the
BSC object is intended to indicate whether the CCN mode in the serving cell for cell
reselection towards 3G cells is enabled in the BSC or not. Only the FALSE value is
allowed, meaning that ENACC towards 3G is not supported.
To enable the feature the following conditions have to be satisfied:
– The Network Assisted Cell Change feature has been enabled.
– The External Network Assisted Cell Change feature license has been installed.
13.4 Network controlled cell reselection (NCCR)

With Network Controlled Cell Reselection the network requests measurement reports
from the GPRS MSs and controls their cell reselection based on these measurements
and on configurable parameters. The network may command a GPRS MS to a neigh-
bour cell that provides better radio conditions or allows to optimize the traffic distribution.
If network-controlled cell reselection is enabled, the network instructs the GPRS mobile
to transmit the RXLEV_DL values of both serving and adjacent cells in PACKET MEA-
SUREMENT REPORT messages. Two network controlled reselection mechanisms are
provided:
378 Id:0900d8058052e3be A50016-G5100-B556-04-7620

• Radio Link Network Controlled Cell Reselection: The network commands a GPRS
MS to a neighbour cell that provides better radio conditions.
• Traffic Control Network Controlled Cell Reselection: The network redistributes MSs
among cells to satisfy the maximum number of service requests. The Traffic Control
network controlled cell reselection guarantees the optimum usage of resources, i.e.
a better GPRS/EGPRS traffic distribution among the available channels in all of the
available cells
Network Controlled Cell Reselection is related to the Network Control Order value NC2
and takes precedence over Network Assisted Cell Change related to Network Control
Order values NC0 and NC1.
NCCR evaluation regarding the radio link control strategy

The cell reselection algorithm is based on the GPRS reselection and on the C1 and C32
values (for more details on GPRS reselection see the GPRS global description manual).
In the following the latter case is described:
• A reselection procedure is indicated, if the C1 path loss criterion falls under the
NCC1TH threshold for the current cell:
C1 < NCC1TH
• In this case the most appropriate adjacent cell is determined as follows:
First, the C1 value of a target cell candidate must exceed the NCC1THADJC(n)
threshold: C1(n) > NCC1THADJC(n)
Second, the target cell candidates are ranked according to the C32 criterion.
The adjacent cell with the highest C32 value is taken as target cell. The ranking can
be modified by the attributes NCGRESOFF, NCGTEMPOFF, NCGPENTIME.
Moreover the adjacent cells of the same routing area can be prioritized by setting
the NCSARA attribute to TRUE, in this case the NCRARESH attribute has the
default value 0 dB (DB00) which must be kept; if NCSARA = FALSE, the value of
the NCRARESH attribute is subtracted from the C32 value of the neighbour cells.
If hierarchical cells are present, then the C31 criterion is applied and under the
adjacent cells for which C31 ≥ 0, the cells are regarded which have the highest pri-
ority, and among those the cell with the highest C32 value is selected (if no cell fulfils
the C31 criterion, all cells are assumed as equally appropriate).
NCCR evaluations regarding the traffic control strategy

The traffic control algorithm is applied to cells in vertical allocation state belonging to the
same PCU. The evaluation is based on:
– The number of configured channels for GPRS/EGPRS
– The number of used channels for GPRS/EGPRS
– The type of strategy set by the user: permanently reserved for GPRS/EGPRS or
common pool
– The type of allocation (horizontal or vertical allocation)
Every time a new GPRS/EGPRS packet switched data call is established it is checked
if the radio resource occupation has reached or exceeded the CRESELTRHSOUT
threshold. In positive case, the algorithm looks for Mobile Stations candidates to be
forced to a cell reselection. The candidate target cells are the results of the Network
Controlled Cell Reselection algorithm and have a traffic load below the threshold deter-
mined by the CRESELTRSHINP attribute. The number of Mobile Stations to be forced
in reselection is determined taking as many Mobile Stations as the radio resources that
A50016-G5100-B556-04-7620 Id:0900d8058052e3be 379

have to be released in order to put the traffic load under the threshold defined by the
NCTRFPSCTH attribute.
Procedure for network controlled cell reselection

Figure 135 shows the main parts of message flow during the network controlled cell
reselection procedure. The following steps occur:
1. A Mobile Station in packet idle mode operates with Network Control Order NC0.
2. When a packet data flow (uplink or downlink) has been established, the BSC
modifies the Network Control Order value from NC0 to NC2 and orders NC2 for the
MS by sending a PACKET MEASUREMENT ORDER message; NC2 is usually acti-
vated for every Mobile Station in packet transfer mode.
3. The MS periodically transmits PACKET MEASUREMENT REPORTs to the BSC.
These reports are used to feed the algorithm for Network Controlled Cell Reselec-
tion.
4. Having received the measurement report, the system applies the NCCR algorithms.
5. In case the NCCR calculations indicate a reselection situation (including the candi-
date target cell), the BSC sends a PACKET CELL CHANGE ORDER message,
inducing a cell change. The message contains the characteristics of the candidate
target cell: the BTS Identity Code (BSIC) and the BCCH frequency including the new
network control measurement parameters valid for the Mobile Station in the target
cell.
The network also specifies whether a Mobile Station has to immediately abort any
Temporary Block Flow (TBF) in progress in the old cell or not by the
IMMEDIATE_REL attribute.
6. The Mobile Station performs the indicated cell change.
If the procedure fails on the new cell, then the Mobile Station returns to the old cell
and, if necessary, establishes a new packet data flow in the old cell.
7. A cell update procedure towards the SGSN is activated:
The BSC signals a RADIO STATUS message (cause: “cell reselection ordered”) to
the SGSN. This message contains a reference to the MS, i.e. the Temporary Logical
Link Identifier (TLLI).
8. The SGSN indicates towards the BSC that the new cell has been assumed from the
SGSN, too.
9. The BSC uses this indication to re-route any queued RLC (Radio Link Control)
blocks to the affected Mobile Station. The BSC indicates to the SGSN, if the queued
RLC blocks are discarded. It is the responsibility of the higher layer protocols (in the
SGSN) to cope with eventually discarded LLC (Logical Link Control) frames as a
consequence of the discarded RLC blocks.
10. The MS can send RLC data blocks in the new cell and proceeds with packet mea-
surements.
11. In case the MS finishes the packet data transfer and the last RLC block has been
sent to the BSC, then the BSC (before finishing the Temporary Block Flow) changes
the network control mode again to the NC0 according to the fact that the Mobile
Station enters the packet idle mode and does not transfer PACKET MEASURE-
MENT REPORTs any more.
380 Id:0900d8058052e3be A50016-G5100-B556-04-7620

MS BTS A BSC SGSN
TBF established
Packet Measurement Order

PACCH
(NCO = NC2)
RLC Data Blocks UL/DL Unitdata PDUs

PDTCH
Packet Measurement Report

PACCH
(Measurements for NCCR)

PDTCH
Packet Cell Change Order

PACCH
Radio Status
(Cause: Cell Reselection Ordered)
Cell Change, Cell Update Procedure
BTS B Flush LL
(indicating the new cell entered)
Flush LL Ack
(indicating re-routing or discarding of

queued RLC blocks)
PDTCH
Packet Measurement Report

PACCH Data flow in blue
(Measurements for NCCR) Signalling in black
Figure 135 Message flow for network controlled cell reselection

To avoid frequent cell reselections of the same adjacent cells due to anomalous Mobile
Station behaviour during NCCR, the TRFPSCTRL timer attribute is used: The BSC does
not order the Mobile Station to move again into the same adjacent cell until a timer
expires the TRFPSCTRL value and the following condition is satisfied:
STGTTLLIINF > TRFPSCTRL
The STGTTLLIINF attribute (“storageTimeTLLIInfo”) indicates the time (in seconds) for
which the BSC stores the information about TLLI (last used coding scheme and BLER)
after the end of each TBF for that TLLI. If this attribute is set to NULL, no TBF temporary
data is stored and “ping-pong” cell reselections can not be avoided.
A50016-G5100-B556-04-7620 Id:0900d8058052e3be 381

Attributes
The following attributes of the PTPPKF object are provided for NCCR:
• NCRESELFLAG (“ncReselectionFlag”): This attribute enables/disables the Radio
Link Network Controlled Cell Reselection.
• TRFPS (“trafficPs”): This attribute enables/disables the Traffic Control part of the
NCCR feature
• DNC2MSGPREL99 (“disableNC2MessagesToPreRel99”): Most of release 97/98
MSs do not correctly handle the Network Control Order NCO2 and NCCR. Setting
DNC2MSGPREL99 = TRUE allows to perform NCCR for pre-99 release MSs
(sending of 2 messages of network control order is disabled).
• Bit 44 of the MNTBMASK attribute: enables fault tolerant handling of those MSs that
do not behave in the proper way for NCCR, especially pre-99 release MSs. Setting
bit 44 to 1 starts an additional algorithm: If or example after a PACKET MEASURE-
MENT ORDER message from the BSC the MS does not send any Packet Measure-
ment Report or no valid measurement report arrives at the BSC within the
observation time (NTWCREPPTR), the BSC sends a PACKET MEASUREMENT
ORDER message with NC0 to force this faulty MS back to mobile controlled cell
reselection mode.
The following attributes of the PTPPKF object are provided for NCCR:
• NTWCREPPTR (“networkControlReportPeriodTransfer”) and NTWCREPPIDL
(“networkControlReportPeriodIdle”): The time period for transmission of Packet
Measurement Reports when the Mobile Station is in packet transfer mode and
packet idle mode, respectively.
• NTWCNDRXP (“networkControlNonDRXPeriod”): The minimum time the Mobile
Station stays in non-DRX mode after a Packet Measurement Report has been sent.
• NCC1TH (“ncC1Threshold”): The threshold for the path loss value C1 triggering the
reselection procedure
• NCSARA (“ncSameRoutingArea”): When this attribute is set to TRUE, then the
adjacent cells of the same routing area have priority compared to the adjacent cells
of other routing areas
• NCRARESH (“ncRaReselectHysteresis”): The hysteresis value subtracted from the
C32 value for the neighbour cells. Range: DB00 (which means 0 dB) ... DB30
(30 dB)
• NCTRFPSCTH (“ncTrafficPSControlThreshold”): The threshold under which no
other GPRS mobiles are ordered to change the cell.
• CRESELTRHSOUT (“cellReselectionThresholdOutput”): Threshold indicating a cell
reselection due to too high traffic load
• CRESELTRSHINP (“cellReselectionThresholdInput”): Threshold indicating that an
adjacent cell is an appropriate target cell due to traffic load
• TRFPSCTRLT (“trafficPSControlTimer”): Minimum time between two consecutive
cell reselection procedures ordered or assisted by network (through Packet Cell
Change Order or Packet Cell Change Continue messages) on the same MS towards
the same adjacent cell. This timer threshold is used to avoid too frequent cell rese-
lections of the same adjacent cell.
The following attributes of the ADJC object are provided for NCCR:
• NCC1THADJC (“NCC1ThresholdAdjacent”) The threshold of the C1 path loss value
for adjacent cells used to select candidate target cells for reselection
382 Id:0900d8058052e3be A50016-G5100-B556-04-7620

• NCGRESOFF (“ncGprsReselectOffset”), NCGTEMPOFF (“ncGprsTemporaryOff-

set”), NCGPENTIME (“ncGprsPenaltyTime”): These attributes allow to create a
further ranking among adjacent cells.
13.5 GSM-UMTS cell reselection

General
With the introduction of the UMTS network, it becomes very important to allow a dual
mode Mobile Station to reselect a UMTS cell starting from a GSM cell. The main benefit
of this feature is that a Packet Switched (PS) connection which has been activated in
the GSM/GPRS system can be delivered also to the UMTS system. The feature is
relative to the inter-system cell reselection from the GSM/GPRS to UMTS: the proce-
dures and the criteria by which the UE/MS decides to trigger the inter-system change
are described in the next chapter. Besides, the cell reselection procedure is important
to guarantee a better quality connection when the MS/UE detects a stronger signal from
a neighbour cell, even if it belongs to a different Radio Access Technology (RAT).
Here it is considered a mobile network in which the UMTS and the GPRS technologies
are installed and configured together; this kind of network is considered a mixed
UMTS/GPRS network or also a multi-Radio Access Technology (RAT) network, where
multi-RAT means more than one Radio Access Technology (different Radio Access
Technologies are for examples UMTS FDD, UMTS TDD, GSM/GPRS). Besides, both
the UMTS and the GSM systems support the GPRS (General Packet Radio System)
technology.
Functionality
When a mobile station changes from the GSM/GPRS to the UMTS radio access tech-
nology, it executes an inter-system change. A prerequisite for an intersystem change
from the GSM/GPRS to the UMTS is that the UE/MS shall be camped on a GSM cell. A
UE/MS shall indeed perform a GPRS attach procedure to the SGSN in order to access
to the GPRS services. The GPRS Attach Procedure is described in the TS 23.060 Rec-
ommendation; only the UE/MS and the SGSN are involved in this procedure: the BSS
support is not necessary.
Depending on the Mobility Management (MM) state before the inter-system change and
whether the Location Area (LA) is changed or not, the UE/MS shall follow different pro-
cedures.
In STANDBY state the Routing Area Update (RAU) procedure is started only if the
Routing Area is changed. If the UE/MS in STANDBY state performs the cell reselection
to an UMTS cell inside its Routing Area, it does not start a RAU, but a "Selective RAU"
(see the TS 23.060 Recommendation, chapter 6.13.1.3 "Selective RAU"), for example
it starts a RAU procedure only in case that it sends the uplink Protocol Data Units (PDUs
are buffered in the UE/MS until the RAU is performed) or also in case it is paged by the
SGSN. If the UE/MS in STANDBY state performs the cell reselection to an UMTS cell
outside its Routing Area, it starts an UMTS Routing Area Update (RAU) procedure.
When a UE/MS in READY state changes to UTRAN, independent of whether the RA has
changed or not, the UE/MS shall execute the UMTS Routing Area Update procedure
and afterwards performs the RABs (Radio Access Bearer) Assignment. The RA update
procedure is either combined RA / LA update or only RA update, according to the
content of the UPDATE TYPE message sent by the UE/MS to the SGSN.
A50016-G5100-B556-04-7620 Id:0900d8058052e3be 383

For this last case the intra-SGSN inter-system cell reselection procedure when a
combined Routing Area/Location Area Update is requested is represented in next
Figure 136. In case it is required only the Routing Area Update, the steps: 4, 5, 6, 9 are
not performed. The RAB Assignment procedure is described in the steps: 10 and 11.
Figure 136 Cell reselection from GSM to UMTS

An intra-SGSN cell reselection takes place when the UE/MS selects a better neighbour
cell belonging to the UMTS system, and this cell is under the control of the same mixed
SGSN (2G/3G-SGSN) which it is managed also by the serving GSM/GPRS cell. The
2G/3G-SGSN detects that it is an intra-SGSN cell reselection by noticing that it handles
the old Routing Area. In this case, the 2G/3G-SGSN has the necessary information
about the UE/MS and there is no need to inform the GGSN or the Home Location
Register (HLR) about the UE/MS location.
384 Id:0900d8058052e3be A50016-G5100-B556-04-7620

The UMTS adjacent cell information is sent on the broadcast carrier of the GSM network
in order to inform the UE/MS which frequencies have to be monitored for reselection pur-
poses.
Intersystem change decision

The Mobile Station measures the reselection specific parameters (e.g. receive power
level and receive quality) and evaluates them. If the following conditions are fulfilled, the
Mobile Station initiates a cell reselection to an adjacent UMTS cell:
• RSCP(UMTS target cell) ≥ RLA_P(GSM serving cell) + XXX_Qoffset
• For all of the suitable GSM neighboring cells
RSCP(UMTS target cell) ≥ RLA_P(GSM neigbour cell) + XXX_Qoffset
• Only for FDD cells:
Ec/No (UTRAN FDD target cell) ≥ FDDQMI
where:
• RSCP (Received Signal Code Power): The DL receive level in the UMTS FDDneigh-
bour cell and is thus comparable to the RXLEV value in GSM.
• Ec/No (Energy chip to Noise over all); this value indicates the DL quality in the UMTS
FDD neighbour cell and is thus comparable to the RXQUAL resp. C/I values in GSM.
• RLA_P: The received power level from the GSM cell concerned.
• XXX_Qoffset: Offset for cell reselection for UMTS cells. Different offset attributes are
provided for FDD and TDD cells, they also depend on the type of service (circuit
switched or packet switched) the Mobile Station supports in the GSM cell; the attri-
butes for the CS service type are related to the BTS object, the attributes for the PS
service type are related to the PTPPKF object:
– FDDQO (“fddQOffset”) for FDD UMTS cells and CS services of the MS
– TDDQO (“tddQOffset”) for TDD UMTS cells and CS services of the MS
– FDDGQO (“fddGPRSQOffset”) for FDD UMTS cells and PS services of the MS
– TDDGQO (“tddGPRSQOffset”) for TDD UMTS cells and PS services of the MS
• FDDQMI (“fddQMin”): The minimum threshold for Ec/No for UMTS FDD cell rese-
lection; the attribute is related to the BTS object.
Moreover, the mobile network indicates whether the measurements for the cell reselec-
tion of the UMTS cells should be performed or not by using a specific threshold; the
threshold indicates, if the signal level of the serving cell should be below or above it, in
order to perform UMTS cells measurements; the user sets this value by the QSRHI
(“qSearchI”) attribute of the BTS object in case of CS services, and by the QSRHPRI
(“qSearchPriority”) attribute of the PTPPKF object in case of PS services.
Besides, the user must also define the UMTS neighboring cells as candidates for rese-
lection. Therefore the user creates an instance of the ADJC3G object, subordinate to
the BTS object.
Forced reselection
A 3G cell can be optimized for high speed PS services by providing HSDPA and
HSUPA. If this property of the 3G cell is indicated by IHSPA = TRUE, then a HSDPA-
capable mobile station in an adjacent 2G cell, just having finished its CS activities, is
forced to perform a reselection to the high speed 3G cell – if possible. Therefore the high
speed 3G cell is included in the “Cell selection indicator after release of all TCH and
SDCCH” information element inside the CHANNEL RELEASE message.
A50016-G5100-B556-04-7620 Id:0900d8058052e3be 385

13.6 Network controlled reselection from GSM/GPRS to UMTS

due to sufficient UMTS coverage
The main objective of the Network Controlled Cell Reselection from GSM/GPRS to
UMTS due to sufficient UMTS coverage is to perform a cell reselection to the UMTS
system as soon as possible, i.e. as soon as the UMTS measurement quantity exceeds
a certain sufficient threshold in order to direct as much packed switched traffic as
possible to UMTS in areas which offer sufficient UMTS coverage.
Without activating this feature, GSM/GPRS to UMTS cell reselection can only be initi-
ated by the Mobile Station itself and not by the network. The Network Controlled Cell
Reselection is only performed within the GSM Radio Access Technology (RAT) and not
between different RATs.
The thresholds for sufficient UMTS coverage for packed switched and for circuit
switched services can be set independently.
BSC function required

To support the network controlled cell reselection from GSM/GPRS to UMTS due to suf-
ficient UMTS coverage, the BSC must evaluate the 3G measurements of 3G neighbour
cells (UMTS cells) which the Mobile Station sends to the BSC in the PACKET MEA-
SUREMENT REPORT message. Based on this evaluation, the BSC can initiate the
migration from GSM/GPRS network to UMTS.
Attributes related to the BSC object

EUSCNCRESEL (“enableUmtsSuffCovNcResel“): This attribute is used to enable
Network Controlled Cell Reselection from GSM/GPRS to UMTS due to sufficient UMTS
coverage. This attribute is adjustable per BSC area. Range: TRUE, FALSE (default:
FALSE)
g Network Controlled Cell Reselection is the basis for this cell reselection from
GSM/GPRS to UMTS due to sufficient UMTS coverage and must have been
enabled (NCRESELFLAG = ENABLE).
Attributes related to the ADJC3G object

The following attributes are provided and have to be set for each adjacent 3G cell:
• USRSCPNCRESEL (“umtsSuffRscpNcResel“)
This attribute defines the RSCP (Received Signal Code Power) threshold in UMTS
above which the BSC initiates the cell reselection from GSM/GPRS to UMTS.
Range: 0...63 (recommended values: 8 for FDD, 18 for TDD cells)
• USECNONCRESEL (“umtsSuffEcNoNcResel“)
This attribute affects FDD neighbour cells and defines the Ec/No threshold above
which the BSC initiates the cell reselection from GSM/GPRS to UMTS.
• USRSCP (“umtsSuffRscp“)
This attribute defines the RSCP (Received Signal Code Power) threshold in UMTS
above which the BSC initiates a handover from GSM/GPRS to UMTS due to suffi-
cient UMTS coverage in case of TDD adjacent cells or in case of FDD when the
FDDREPQTY attribute is set to the RSCP value.
• USECNO (“umtsSuffEcNo)
This attribute defines the threshold above which BTS initiates a a handover from
GSM/GPRS to UMTS due to sufficient UMTS coverage in case of FDD when the
FDDREPQTY attribute is set to the EC_NO value.
386 Id:0900d8058052e3be A50016-G5100-B556-04-7620

• TUESP (“timerUeSpeed“)
This timer inhibits cell reselection from GSM/GPRS to UMTS in case of fast moving
mobiles. An UMTS microcell is only included in the UMTS target cell list, if the
threshold condition for "sufficient UMTS coverage" is met during the whole timer
period. Range: 0...100 s (default: 5 s)
Attributes related to the PTPPKF object

• GFDDREPQTY = RSCP / EC_NO
This attribute (“gprsFddReportingQuantity“) determines whether RSCP or Ec/No is
used as the reporting quantity for FDD cells in the packet measurement report.
• GFDDMURREP = 0 / 1 / 2 / 3
This attribute (“gprsFddMultiratReporting”) defines the number of best valid FDD
cells which the MS shall include in the packet measurement report.
• GTDDMURRWP = 0 / 1 / 2 / 3
This attribute defines the number of best valid TDD cells which the MS shall include
in the packet measurement report.
• QSRHPRI (“qSearchPriority“)
This attribute determines when the MS shall search for UMTS neighbour cells:
ALWAYS or NEVER or when the signal level of the GSM serving cell is below/above
the threshold in case of a UMDB<nn>/OMDB<nn> value.
• GUMTSSRHPRI = TRUE / FALSE
This attribute (“gprsUmtsSearchPriority“) indicates if an MS can search 3G cells
when BSIC decoding is required.
• TFAILNCU (“timerFailNcUmtsCell“)
This attribute defines the timer started from BSC when it has received a PACKET
CELL CHANGE FAILURE message containing an UMTS cell description from a
MS/UE. Until expiry of this timer, this UMTS neighbour cell is excluded from the
UMTS target cell list.
• MAFAILNCU (“maxFailNcUmtsCell“)
This parameter is the maximum number of packet cell change order messages
transmitted for the same UMTS Neighbour cell for a MS/UE, in case the ordered cell
change fails.
• TBNCU (“timerBackNcUmts“)
This timer is started when a MS has switched back to a GSM/GPRS cell after a
previous reselection from the GSM/GPRS cell to the UMTS cell. Until expiry of this
timer, network controlled GSM/GPRS to UMTS cell reselection is inhibited, thus fast
"ping pong" reselections are avoided.
• EUMSSNCRESEL (“enableUmtsMssNcResel“) = TRUE / FALSE
This attribute is used to enable the Mobile Speed Sensitivity (MSS) part of the
network controlled GSM/GPRS to UMTS cell reselection algorithm.
A50016-G5100-B556-04-7620 Id:0900d8058052e3be 387

Special radio network features Radio network management
14 Special radio network features

This chapter describes features which do not fit well into previous chapters.
14.1 Multi-Operator BSS – 2G network sharing

This feature allows different network operators to share a 2G radio access network: The
radio access network is conducted by one operator (who may own this network or may
share the ownership with other operators) related to a certain core network. Other oper-
ators maintaining their own core networks (MSCs etc.) can connect to this “external”
radio access network and can participate in the utilization of the radio access network
elements (BSCs, BTSs).
The main benefit of the “Multi-Operator BSS – 2G network sharing” feature is that the
deployment costs for a radio access network can be minimized. In particular the number
of network elements to be set up and operated in a shared radio area are reduced. The
costs can be shared among the different network operators.
Principle
Figure 137 shows the principle of radio access network sharing for two operators A and
B. Each operator has its own core network (MSC, HLR, SGSN, GGSN etc.). Operator A
owns the radio access network of region A, operator B provides the radio access
network of region B. With 2G radio access network sharing, operator B connects to an
external BSC of region A and uses operator A’s resources.
The basic idea for the implementation of the feature is that an operator B can have own
radio cells within a physical site and RAN equipment of operator A, and operator A’s
BSC controls these radio cells of operator B. These radio cells of operator B can cover
the same area as operator A’s radio cells, but use independent carriers and are con-
nected to operator B’s core network (while operator A’s cells are connected to operator
A’s core network). So the resources used by the different operators are well distin-
guished and there is a determined connection between a cell and its operator’s core
network for access to services and routing. The radio resource management procedures
(related to BTS and BSC) do not care for which operator the resources are handled; only
when a connection to an MSC/SGSN is required, the MSC/SGSN related to the affected
cell is selected (e.g. an MS camping in operator B’s cell, which is controlled by operator
A’s BSC, and accessing the network is always routed to operator B’s core network –
even if the MS owner is a subscriber of operator A).
Only one operator – the host operator – manages a shared radio access network,
namely the owner of the related network elements.
The “2G radio access network sharing” feature is applied to the circuit switched (CS) and
to the packet switched (PS) domain of the radio access network.
388 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

Radio network management Special radio network features
Independent carriers
and PLMN-IDs
Network Operator A
Abis
Site 1 A
A / Gb Abis (shared)
Site 2 A
MSC A / BSC A (shared)
SGSN A (shared)
A / Gb
Network Operator B
Abis
Site 1 B
A / Gb Abis
Site 2 B
MSC B / BSC B
SGSN B
Core Network Radio Access Network
Figure 137 Principle of radio access network sharing
Radio access network sharing in the CS domain

Information to relate cells to the right network operator in a shared radio access network
environment are stored in the BTS objects (representing the cells) and for the MSCs
(representing the network operators) in the BSC object. The BSC is connected to the
desired MSCs via SS7 links on A interface. Thus data between BTSs and MSC can be
routed correctly in the uplink and downlink direction.
Each cell is related to the network operator where to link to via the CELLGLID (cell global
identity) parameter of the BTS managed object which includes the fields MCC (mobile
country code) and MNC (mobile network code). Especially MNC determines the network
operator in charge.
On the other side, the BSC stores information about the MSC where to link to in the new
PLMNIDL (“plmnIdentifierList“) attribute subordinate to the MSC object. Each BTS is
related to a certain PLMN identity number, which contains the MCC and MNC of the BTS
(corresponding to CELLGLID data). And all PLMN identities for a certain MSC are
gathered in the PLMNIDL attribute.
Figure 138 shows an example for the relations between BTSs and MSCs. The links
between BSC and MSCs via A interface are established mainly via the OPC and TPC
managed objects of the BSC and the LINKSET managed object. OPC (originating point
code) is the local CCS7 signalling point of the BSC for one MSC and represents the
source SPC (signalling point code) in LINKSET. The source SPCs for links to additional
MSCs are determined by the TPC (transport point code) managed object. The link des-
tination, i.e. the desired MSC, is represented by the DPC (destination point code)
managed object. For more information about the topics concerning Abis and A interface,
please refer to the Transmission and transport network management manual.
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 389

BTS:0
BSC A (shared)
CELLGLID =
100-01-30-1
MSC A DPC:0
(Network operator A) (MSC A) MSC:0 Abis
A LINKSET:0 PLMNIDL:
100-01
SPC OPC:0 100-02
(BSC A) (BSC A) BTS:1
Abis
CELLGLID =
100-02-20-1
MSC B DPC:1
(Network operator B) (MSC B) MSC:1
A LINKSET:1 PLMNIDL: BTS:2

100-03
SPC TPC:0
(BSC A) (BSC A) CELLGLID =
Abis 100-03-300-1
SPC: Signalling point code DPC: Destination point code

OPC: Originating point code TPC: Transport point code
Figure 138 Example of radio access network sharing in the CS domain
Radio access network sharing in the PS domain

The radio access network sharing in the PS domain is based on the feature “Multiple
PCU Pooling”: The PCUs are grouped in pools, each PCU pool is linked to one PS node,
i.e. to one SGSN (since the flexible Gb feature has to be disabled).
Several PCUs are gathered in the CPCU object (see the GPRS Global Description func-
tional area description). On the one hand, the SGSN of a network operator is related to
a CPCU object in the BSC via Gb interface, on the other hand the radio cells for this
network operator are related to the operator’s CPCU object via the CPCUN attributes of
the PTPPKF objects. Thus data between BTSs and SGSN can be routed correctly in the
g Taking into account that the “Flexible Gb interface” feature cannot be enabled and
CPCU is assigned to only one SGSN, each operator is assigned to only one CPCU.
Figure 139 shows an example of radio access network sharing between two network
operators in the PS domain.
The number of available PDTs (equivalent to the number of Abis timeslots) per BSC is
limited and controlled by licence. In order to avoid an unbalanced usage of PDTs
between different sharing operators, the attribute MAXNPDT (“maxNumberPDT”) is
introduced to limit the number of used PDTs for each CPCU: every time a new PDT is
requested, the BSC checks if the max, number of usable PDTs is reached for that
CPCU.
390 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

BTS:0
BSC A (shared)
PTPPKF
CPCUN = 1
SGSN A RNSEVLIP
(Network operator A) (SGSN A) CPCU:1 Abis
Gb NSE:0 PCU:1
RNSEVLIP:0 PCU:2
(BSC A) NSEVLIP:0
(BSC A) BTS:1
Abis
PTPPKF
CPCUN = 1
SGSN B RNSEVLIP
(Network operator B) (SGSN B)
CPCU:2
Gb NSE:1 BTS:2
PCU:3
RNSEVLIP:0 NSEVLIP:0
(BSC A) (BSC A) PTPPKF
Abis CPCUN = 2
(R)NSEVLIP: (Remote) NSE virtual link IP

NSE: Network service identity
Figure 139 Example of radio access network sharing in the PS domain
System impacts
“2G radio access network sharing” for packet switched (PS) services is based on the
“Multiple PCU pooling” feature: The PCUs are grouped in pools, each PCU pool is linked
to one PS node, i.e. to one SGSN when the flexible Gb feature is not enabled. Without
“Multiple PCU Pooling” all PCUs configured in a BSC would be associated to only one
pool and a distribution to several PS nodes / SGSNs is inhibited.
“2G radio access network sharing” also uses the “Support of multiple MNC in BSS”
feature, which has to be enabled, otherwise “2G radio access network sharing” does not
work. “2G radio access network sharing” does not work together with the following
features which thus have to be disabled:
– “Flexible A interface”
– “Flexible Gb interface”
– “Central service network layer”
User interface
Each network operator can be provided with just the relevant performance data for its
particular cells and calls, which is done via FTP. Operator specific dedicated cell data is
also available for each operator. Data common for the BSS is not accessible by external
operators connected to the BSS. The same applies to other data which is not operator
specific – e.g. configuration parameters and alarms, counters not related to perfor-
mance management.
2G radio access network sharing with another network operator can be configured by
the operator owning and controlling the radio access network. The configuration is done
via BSC-LMT or Radio Commander.
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 391

Data for configuration, monitoring and measuring are stored in different files:
– Files for operator specific cell data (per cell and operator), concerning e.g. the fol-
lowing managed objects: BTS, TGTBTS, PTPPKF, TRX, CHAN
– Files for operator specific performance data (per cell and operator)
– Files for all performance data (common, not operator specific)
– Files for BSS common data, concerning e.g. the following managed objects: BSC,
BTSM, SS7L, ATMVP, ATMVC
At the LMT all data received and decoded for configuration, monitoring and measuring
are visible. There is no split between common and operator specific data.
The Radio Commander supports user accounts for a main operator, which usually owns
the affected radio access network, and sharing operators, which use the “external” radio
access network. The two types of operators have the following tasks and rights:
Main operator:
– Configuration of the operators
– Radio Commander system administration
– Authorization profiles
– Configuration of the radio access network sharing
– Configuration of performance management scanners
– Radio Commander file storage and conversion settings
– Evaluation of own performance management data
– Access to BSS common data
– Access to own dedicated cell data
– Access to all performance management data
Sharing operator:
– Evaluation of own performance management data
– Access to own dedicated cell data
The access rights of a sharing operator can be extended.
Parameters
Short Name Long Name Description Default Range

Parameters of the MSC managed object
PLMNIDL plmnIdentifierList This attribute contains the list of PLMN (network) NULL (Max. list
identifiers related to the cells. Each PLMN ID size: 10)
contains the mobile country code (MCC) and the
mobile network code (MNC) in the same way as in
the CELLGLID attribute of a BTS.
Parameters of the BSC managed object
ERANSHR enableRANShar- This attribute enables/disables the “2G radio False TRUE /
ing access network sharing” feature. FALSE
Parameters of the CPCU managed object
MAXNPDT maxNumberPDT This parameter defines the maximum number of NULL 0 ... 8500
PDTs that can be used for the related CPCU.
Table 63 Parameters for 2G radio access network sharing
392 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

14.2 IMSI based handover

With “IMSI based handover”, applied in a shared network, a host GSM operator is able
to configure the radio access network (RAN) in such a way that handovers are only
allowed to cells permitted for the subscriber. The subscriber’s IMSI indicates which cells
are permitted as handover targets. The feature includes that the mobile station only
measures received signal strengths of the adjacent cells permitted as handover targets.
The host operator is the owner of the network elements and related equipment (BSC,
BTS). A client operator generally buys GSM coverage from the host operator in the fol-
lowing ways:
– Rent a part of the host RAN.
– Agree the access of the own subscribers to the host RAN as visitors.
Benefits
The owner of a shared network (the host operator) can
– prevent unnecessary handover attempts from his own subscribers to the client oper-
ators network.
– prevent unnecessary handover attempts from subscribers of a client operator to his
own network.
– support the transfer of own subscribers to his own network.
Vice versa, the client operator gets the corresponding benefits.
Data structures
Three data structures are necessary in order to allow the specification of permitted
target cells for handovers:
– Subscriber group (new): A selection of subscribers of one network operator identi-
fied by a part of IMSI digits (MCC, MNC and part of MSIN).
– Authorized networks list (new): A listing of PLMNs in terms of MCC + MNC allowed
for handover.
– Cell global identifier (CGI): The cell identity including MCC and MNC, thus indicating
the PLMN of the cell’s operator. The operator is either the host operator or the client
operator which has rented the cell. In the latter case the rented cells have to be set
up with the client’s PLMN ID (MCC + MNC) which requires that the host operator
supports multiple MNCs. Of course, a cell operated by the host operator and with
agreed access for the client operator keeps the host operators PLMN ID.
Usually there are several subscriber groups and authorized networks lists, and each
subscriber group is linked with one authorized networks list. The following mechanism
is applied:
Basic mechanism
If the IMSI of the subscriber, whose MS is in dedicated mode, is known and if a sub-
scriber group (derived from this IMSI) can be found for this subscriber, then the system
looks up the linked authorized networks list. All neighbour cells related to a PLMN (via
CGI) included in this authorized networks list are permitted as handover targets, other
neighbour cells are excluded.
If the feature is enabled, but no IMSI is available or no subscriber group is found for an
IMSI or there is no link of the subscriber group to an authorized networks list, then there
is no IMSI-specific exclusion of neigbour cells as handover targets; instead all neigbour
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 393

cells which belong to the PLMNs (as visible in the CGIs) of a default authorized networks
list (the most common list) are permitted; usually these default PLMNs are that of the
host operator and the PLMNs of the roaming partners.
14.2.1 Adressing subscribers and PLMNs

Subscriber identity
Both GSM and 3G networks recognize a subscriber (a mobile user) according to his
International Mobile Subscriber Identity (IMSI) which is a worldwide unique number
sequence. The IMSI consists of three parts:
– Mobile Country Code (MCC)
– Mobile Network Code (MNC)
– Mobile Subscriber Identification Number (MSIN).
The subscriber's IMSI is stored in the SIM/USIM card, which is a user-specific identifi-
cation and storage device. The BSC receives the IMSI by the MSC via the COMMON
ID message (as soon as possible) or via the HANDOVER REQUEST message in case
of an inter-BSC or inter-system (RNC-BSC) handover (In general, sending of the IMSI
via air-interface is avoided). The BSC stores the subscriber specific IMSI.
Details for subscriber groups

A subscriber group (managed object SG) comprises all subscribers of a network
operator with the same values of certain digits of their IMSIs. The determined digits and
their values represent the home PLMN of the subscriber group.
The HPLMNID (“homePlmnIdentifier”) attribute subordinate to the SG object indicates
which of 15 (at most) IMSI digits are taken into account and which values they must
have, e.g.:
HPLMNID = 1 2 3 4 5 6 x 8
means that all subscribers with the first 6 digits set to 1, 2, 3, 4, 5, 6 and the 8th digit set
to 8 belong to the service group independent of the value of the 7th digit and all digits
starting from the 9th.
A subscriber who does not belong to a configured subscriber group is defined as default
subscriber.
The subscriber group also indicates if WCDMA roaming (i.e. handovers to 3G cells) is
allowed (attribute: “3Gallowed”).
Details for CGIs and PLMNs

All cells configured in a BSC are identified with a Cell Global Identifier (CGI) that consists
of four parts:
– Mobile Country Code (MCC)
– Mobile Network Code (MNC)
– Location Area Code (LAC)
– Cell Identifier (CI).
This is valid for both 2G and 3G cells.
The identifier of a PLMN area consists of the MCC and the MNC and is globally unique.
All cells of a GSM network, which are located only in one country, belong to the same
PLMN area. In general, several operators in the same country cannot use the same
MNC value. If an operator has GSM networks in several countries, then the operator
394 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

must own and use a unique country-specific PLMN code for the cells of each GSM
network.
The same PLMN code can be used for both GSM and 3G radio access network of a
single operator in a country if a national telecommunication regulator of the country
allows this for the operator.
14.2.2 Management of subscriber groups and authorized networks lists

An authorized networks list determines the networks in terms of PLMN IDs whose cells
are allowed for handover, see Table 64 where each row defines such an authorized
networks list. For example the second authorized networks list allows to use the cells of
the host operator’s PLMN and PLMN 2 as handover targets; all cells belonging to the
same authorized networks list have equal handover target priority regarding PLMN con-
siderations. The first authorized networks list in the table comprises the greatest number
of PLMNs (and handover targets), and would typically be used as default list if no other
authorized networks list could be selected. Separate default lists are foreseen for han-
dovers to 2G cells only and to 2G and 3G cells.
The concept of several authorized networks lists allows a host operator to establish
multiple agreements with different client operators.
Authorized
Authorized networks
networks list
1 host PLMN PLMN 2 PLMN 3 PLMN 4 PLMN 5 –
2 host PLMN PLMN 2 – – – –
3 host PLMN PLMN 3 – – – –
... ... ... ... ... ... ...
10 host PLMN PLMN 2 PLMN 3 PLMN 4 PLMN 5 –
Table 64 Authorized networks lists
Table 65 shows a list of subscriber groups. A subscriber group is determined by the

value of its HPLMNID attribute (a part of an IMSI) and is linked to an authorized networks
list (here subscriber group 2 is linked to authorized networks list 2).
Subscriber group IMSI part defining 3G handovers Link to authorized

number the subscribers allowed networks list
1 IMSI fraction 1 yes 2
2 IMSI fraction 2 no 2
3 IMSI fraction 3 yes 3
... ... ... ...
127 IMSI fraction 127 yes no link target
128 IMSI fraction 128 ... ...
Table 65 Subscriber groups list
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 395

A subscriber is allowed to use services of one authorized networks list only, i.e. there
can be only one link from a subscriber group to one authorized networks list.
A basic idea of the feature implementation is to exclude adjacent cells as handover
targets only if explicitly requested and if the required information is available. Assuming
that IMSI based handover is enabled, the following cases of missing information are of
importance:
• If a subscriber’s IMSI does not belong to any configured subscriber group or if, for
any reason, the BSC does not get the IMSI from the MSC, then the subscriber is
considered as default subscriber and is automatically linked to the default authorized
networks list (a default authorized networks list can comprise a subset of all avail-
able PLMNs). Thereby existing roaming agreements with other operators not using
IMSI based handover are kept. Moreover the operator has to define subscriber
groups and authorized networks lists only for exceptional subscriber groups which
shall have restricted handover access. According to this idea, no subscriber group
has to be defined for the host operator’s PLMN (and possibly his roaming partners).
• If a subscriber group has no link to an authorized networks list, then there is no
restriction of handover targets for the subscribers of this group (this is the same
behaviour as with IMSI based handover disabled).
Example
Figure 140 shows an example of a shared network.
PLMN A
(countrywide coverage)
PLMN A
PLMN C PLMN C
PLMN B
PLMN B
Authorized networks lists (ANLs):
Subscriber group A: M C C M N C (A) ... ... ANL A: PLMN (A)
Subscriber group B: M C C M N C (B) ... ... ANL B: PLMN (A) PLMN (B)
Subscriber group C: M C C M N C (C) ... ... ANL C: PLMN (A) PLMN (C)
ANL default: PLMN (A) PLMN (B) PLMN (C)
Figure 140 IMSI based handover in a shared network (example)
396 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

Operator A is the host operator offering countrywide GSM coverage. Operators B and
C are client operators having rent GSM coverage in special areas. There are authorized
networks agreements between operator A and B and between operator A and C, but not
between B and C. Thus handovers from operator B’s cells to operator C’s cells and vice
versa shall be prohibited as much as reasonable. Additionally, subscribers of operator
A shall be kept in cells of operator A (which offer complete GSM coverage).
The following configuration provides the desired behaviour, see Table 66:
Three subscriber groups are set up – one for each operator – and one related authorized
networks list for each of them. Another authorized networks list is created as default list.
IMSI based subscriber group Authorized allowed PLMNs

networks list
SG_A: All subscribers of operator A ANL_A PLMN_A
SG_B: All subscribers of operator B ANL_B PLMN_A, PLMN_B
SG_C: All subscribers of operator C ANL_C PLMN_A, PLMN_C
– ANL_default PLMN_A, PLMN_B,
PLMN_C
Table 66 Service groups and related authorized networks lists in a shared network
(example)
The default authorized networks list in the table avoids restrictions of handover targets
but allows handovers from PLMN_B to PLMN_C and vice versa.
Alternatively, the default authorized networks list can be configured to contain only
PLMN_A. In this case the subscribers of operators B and C are directed in operator A’s
cells in case of a handover and if IMSI information is not available. Here it is not neces-
sary to set up SG_A and ANL_A when ANL_A and ANL_default would contain identical
allowed PLMNs (here only PLMN_A).
14.2.3 Information flow between network elements and MS

The “IMSI based handover” feature applies the usual messages and message flows
between MS, BTS, BSC and MSC. One new message for Abis interface and one new
information element (IE) are introduced (see below), another existing message is mod-
ified.
Information relevant for neigbour cell evaluation and IMSI based handover is contained
in the following messages transmitted when a dedicated channel has been established
between MS and BSS:
SI5, SI5bis, SI5ter, SI6 and MI
(SI5: SYSTEM INFORMATION TYPE 5, MI: MEASUREMENT INFORMATION)
• SI5 informs the MS about the BCCH frequencies of the neighbour cells to be moni-
tored. SI5bis and SI5ter are used as an (optional) extension to SI5 and essentially
contain the BCCH frequencies of DCS1800, PCS1900 and GSM900 with extended
band to be monitored.
Of course SI5ter is not provided for MSs without dual band capability.
• SI6 gives various information about the current cell (e.g. cell identity and cell
options). Here the “NCC permitted” IE is of interest. It provides a definition of the
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 397

allowed NCCs: Only those neighbour cells whose NCC is indicated as “permitted” in
the IE are included in the MEASUREMENT REPORTs from the MS in dedicated
mode (“NCC permitted” corresponds with the PLMNP attribute). With IMSI based
handover enabled, the “NCC permitted” IE is set according to the relevant autho-
rized networks list.
If the “Repeated SACCH” feature is enabled, the transmission of SI5 messages is
accompanied with the transmission of SI6 messages.
• MI informs the MS about the 3G neigbour cells to be monitored and about various
parameters, e.g. for measurements. MI also includes information about 2G neigh-
bour cells (“BSIC description” information element).
Neigbour cell information is provided in form of BCCH allocation lists (BA lists) and
BSICs.
In the following, SI5x stands for SI5, SI5bis and and SI5ter.
The basic message flow applied for IMSI based handover proceeds as follows (see
Figure 141 and Figure 142):
1. The BSC gets the IMSI of the MS from the MSC within the HANDOVER REQUEST
message or the COMMON ID message. The BSC derives the neighbour cells of
interest by relating the IMSI to a subscriber group – if possible – and evaluating the
correct authorized networks list.
2. The BTS gets SI5x, SI6 and MI messages, including the neighbour cells of interest
(possibly a subset of all neighbour cells due to the authorized networks list if IMSI
based handover is enabled) from the BSC via the CHANNEL ACTIVATION
message and/or the SACCH INFO MODIFY message. The BTS keeps a list of the
possible target cells for a handover in which the MS’s neighbour cell measurements
will be stored.
The complete SI5x and SI6 information is included in one CHANNEL ACTIVATION
or SACCH INFO MODIFY message. The MI messages are sent via another SACCH
INFO MODIFY message; the number of MI messages depend on how many 3G
neigbours have to be reported, e.g. 32 neigbours require 11 MI messages.
3. The MS, in dedicated mode with a TCH established, gets SI5x, SI6 and MI
messages from the BTS via SACCH on TCH.
4. The MS monitors the BCCHs of the neighbour cells which were included in the BTS
messages and reports its measurement results to the BTS by MEASUREMENT
REPORTs via SACCH on TCH.
5. If the BTS, evaluating the MS’s MEASUREMENT REPORTs, detects a handover
condition, it generates a target cell list according to the allowed handover target cells
(corresponding to the neighbour cells which the MS monitors).
398 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

-3 "43 "3# -3#
(ANDOVER2EQUEST)-3)
#HANNEL!CTIVATION3)X3)
3!##()NFO-ODIFYNX-)
3EIZUREOFNEW4#(
3)X3)-)

4#(3!##(
-EASUREMENT2EPORT .EIGHBOURCELLS
4#(3!##(
(ANDOVER#ONDITION
#REATIONOFTHE
4ARGET#ELL,IST
.EIGHBOURCELLS
(ANDOVER#ONDITION)NDICATION )NFORMATIONRELATEDTO
.EIGHBOURCELLS )-3)BASEDHANDOVERINBLUE
Figure 141 Message flow related to “IMSI based handover” during a handover
Table 67 shows which neighbour cells are provided by SI5x, SI6 and MI messages
depending on the configurations for IMSI based handover.
3G HO allowed 2G IMSI HO 3G IMSI HO Neighbour cell infos in SI5x, 3G neighbour cell infos in MI
for SG enabled enabled SI6 messages messages (*)
no no no All 2G ADJCs All 3G ADJCs

no no yes All 2G ADJCs No 3G ADJCs
no yes no Authorized ADJCs All 3G ADJCs
no yes yes Authorized ADJCs No 3G ADJCs
yes no no All 2G ADJCs All 3G ADJCs
yes no yes All 2G ADJCs Authorized 3G ADJCs
yes yes no Authorized 2G ADJCs All 3G ADJCs
yes yes yes Authorized 2G ADJCs Authorized 3G ADJCs
SG: Subscriber group, HO: Handover
Authorized ADJCs: Adjacent cells built according to authorized networks list for the SG
(*) MI also contains 2G ADJC information (BSIC description).
Table 67 Neigbour cells information in SI and MI messages for IMSI based handover
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 399

Integrated view
For a complete view, the neighbour cell information which is provided before a TCH has
been established, must be considered (see Figure 142).
• Before a dedicated channel is allocated, the neigbour cell information is broadcast
to the MS via SI2 and SI2ter.
• In a short time period after the SDCCH has been established, the IMSI related
neigbour cell information is not yet available. During this time period, if IMSI based
handover is enabled and the system awaits IMSI based information, only SI6 is
transmitted to the MS. Thus the MS knows about the neigbour cell information of
SI2x only (which could cause an SDCCH handover not conform with IMSI based
handover).
If no IMSI-specific information is awaited, the next step is immediately applied.
• After the IMSI-related information is available, the neigbour cells of interest are put
into SI5x and MI messages, and then the SI5x, SI6 and MI messages are transmit-
ted to the MS according to an appropriate scheduling scheme (e.g. “vital sequence”
in case of “Repeated SACCH”, see FD10558).
-3 "43 "3# -3#
3)X
"##(
#HANNEL2EQUEST
2!#( #HANNEL2EQUIRED
#HANNEL!CTIVATION
3$##(VOID3!##()NFO)%
3$##(ESTABLISHMENT
#OMMON)$)-3)
3)
3$##(3!##(
#ALLSETUP
#HANNEL!CTIVATION4#(3)X3)
3!##()NFO-ODIFYNX-)
4#(ESTABLISHMENT
3)X3)-)

4#(3!##(
-ESSAGESRELEVANTFOR)-3)BASEDHANDOVERINBLUE
Figure 142 Message flow related to “IMSI based handover” during call establishment
400 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

The neigbour cells in SI2x and SI5x might be different; for this case the BA_USED and
3G_BA_USED flags sent in the MEASUREMENT REPORTs from the MS indicate
which set of system information is used by the MS. Vice versa, the BSS takes care for
the handling of the BA_IND/3G_BA_IND flags included in SI2x, SI5x and MI:
BA_IND/3G_BA_IND values in SI2x are always different from the values in SI5x and MI.
Update of neighbour cell information:
Updating of IMSI-specific SI and MI messages is not provided for ongoing calls. If e.g.
IMSI based handover is enabled and neigbour cell information changes due to O&M
operations, then only new “common” (not IMSI-specific) SI and MI information, updated
by the BSC on the basis of the default authorized networks list, are sent to the BTS (this
avoids overload situations on the Abis interface since updated IMSI-specific messages
would have to be sent separately for all MSs involved). The BSC also toggles the
BA_IND/3G_BA_IND values within the SI/MI messages. Consequently an MS with a call
ongoing, recognizing the change of the BA_IND/3G_BA_IND value, uses the updated
common SI and MI information.
New calls are not impacted by previous updates of neigbour cell information; just the
new IMSI-specific SI and MI messages are provided.
Modified/new information elements and messages

“SACCH information” IE
This new information element can include a complete set of SI5x and SI6 messages or
MI messages, i.e. the SACCH filling information to be used on a specific channel
(replacing any SACCH filling information as given by the SACCH FILLING message(s))
as long as the channel is active.
The “SACCH information” IE can be included in the SACCH INFO MODIFY message or
in the CHANNEL ACTIVATION message.
The BSC uses a void “SACCH information” IE in the CHANNEL ACTIVATION message
to inform the BTS that IMSI-specific SI5x and MI information will follow. Consequently
the BTS transmits to the affected MS the SI6 message only, before the BTS gets the
next “SACCH information” IEs (including IMSI-specific SI and MI) within the next
CHANNEL ACTIVATION message and/or SACCH INFO MODIFY message. Then, after
a TCH is established, the BTS adds the IMSI-specific SI5x and MI to the scheduling
scheme.
SACCH INFO MODIFY message
This new message is introduced to send channel specific (here IMSI-specific) system
information from the BSC to the BTS on Abis interface. It includes the "SACCH informa-
tion” IE, which carries the channel specific system information.
If IMSI based handover has been enabled, the SACCH INFO MODIFY message is sent
to the BTS after the reception of the CHANNEL ACTIVATION ACK message for the
TCH activated. In case of Direct Assignment, when the same TCH is maintained for
traffic, it is sent to the BTS after reception of the MODE MODIFY ACK message.
CHANNEL ACTIVATION message
The CHANNEL ACTIVATION message is modified: Now it can include the “SACCH
Information IE” by which the BTS gets the IMSI-specific SI5x, SI6 messages just for the
TCH activated. Without the added IE, the CHANNEL ACTIVATION message uses about
a half of the max. load, so there is enough space for an entire SI5x, SI6 message set.
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 401

14.2.4 Managed objects and parameters

Managed objects
The following new managed objects are implemented:
• SG (“SubscriberGroup”):
This object defines a group of subscribers belonging to the same 2G and/or 3G
operator identified by a part of IMSI digits (MCC, MNC and part of MSIN) stored in
the subscriber SIM. It is possible to define up to 128 subscriber groups.
Command tree: “MANAGED-ELEMENT h BSS-FUNCTIONAL”
• ANL (“AuthorizedNetworkList”):
This object defines a list of up to 6 authorized networks each identified by its PLMN
identifier (MCC, MNC). It is possible to define up to 10 authorized networks lists.
Command tree: “MANAGED-ELEMENT h BSS-FUNCTIONAL”
Parameters
The following table shows the parameters implemented for IMSI based handover.

Parameters of the BSC managed object
DEF2GAUTH default2GAuthorizedNu This attribute indicates which authorized NULL 0 ... 9
NID mberIdentifier networks list for IMSI based handover to
a 2G target cell shall be used for sub-
scribers whose PLMN is not included in
the subscriber group list or whose IMSI
is not available in the BSC. The value
<NULL> indicates that all GSM neigh-
bouring cells are acceptable as
handover targets.
DEF3GAUTH default3GAuthorizedNu This attribute indicates which authorized NULL 0 ... 9
NID mberIdentifier networks list for IMSI based handover to
a 3G target cell shall be used for sub-
scribers whose PLMN is not included in
the subscriber group list or whose IMSI
is not available in the BSC. The value
<NULL> indicates that all GSM neigh-
bouring cells are acceptable as
handover targets.
Parameters of the HAND managed object
IBHOTO2GC iMSIBasedHoTo2GCell This attribute indicates whether IMSI FALSE TRUE/FALSE
based handover to GSM cells is
enabled/disabled.
IBHOTO3GC iMSIBasedHoTo3GCell This attribute indicates whether IMSI FALSE TRUE/FALSE
based handover to 3G cells is
enabled/disabled.
Parameters of the ANL managed object
Table 68 Parameters for IMSI based handover
402 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620


ANLNAME authorizedNetworkList- This attribute indicates the name of the – character
Name authorized networks list. string with
1 – 15 digits
APLMNIDx authorizedPlmnIdentifi- The authorized PLMN x which consists NULL -
(x = 0 ... 5) erx of a sequence of 3 fields:
(x = 0 ... 5) – MCC (string of 3 digits),
– MNC (string of 2/3 digits)
– Technology (enumerative:
technology_2G, technology_3G,
technology_2G_3G).
Parameters of the SG managed object
SGNAME subscriberGroupName This attribute indicates the name of the – character
operator who owns the subscriber string with
group. 1 – 15 digits
HPLMNID homePlmnIdentifier A string (1 – 15 characers) that identifies – character
which digits shall be taken into account string with
to classify the subscriber as belonging to 1 – 15 digits
this subscriber group and which values
these digits shall have.
ALL3G allowed3G This attribute indicates if the subscriber TRUE TRUE/FALSE
can use 3G networks.
ANLNUM authorizedNetworkList- This attribute indicates which authorized NULL 0 ... 9
Number networks list is used for a subscriber to
filter out neighbour cells of non equiva-
lent PLMNs. The value <NULL> means
that all defined neighbours regardless of
their home PLMN are told to an MS.
Table 68 Parameters for IMSI based handover (Cont.)
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 403

14.3 TRX reconfiguration

TRX reconfiguration is the re-assignment of TRX hardware to TRX functional managed
objects in case of TRX hardware failure. Three types of applications apply to the TRX
reconfiguration:
• TRX reconfiguration in case a redundant TRX is available
• BCCH recovery in case no redundant TRX is available
• TRX reconfiguration in concentric cells (no redundant TRX)
14.3.1 TRX reconfiguration in case a redundant TRX is available

The feature “Standby TRX” (optional) allows to keep redundant TRX hardware (i.e.
carrier units) in a cell which is automatically related to a TRX functional managed object
in case the TRX hardware previously related to this TRX object fails. The traffic is inter-
rupted during the reconfiguration, but the capacity of the cell can be kept (which is par-
ticularly useful in cells with one or very few TRXs).
Usually the BTSE software expects for each cell that the number of TRXs which are
created in the BSC database exactly matches with the number of created and equipped
Carrier Units (CUs) in the BTSE. Although it is possible to create more CUs for a cell
than requested by the BSC, extra CUs are ignored after assigning the best matching
hardware to the TRXs. The extra CUs are also not considered for TRX reconfigurations
in case of CU outages. With the feature “Standby TRX” TRX reconfigurations are no
longer restricted to the CUs which are assigned to a TRX. Additional CUs which are
related to a cell (wired to a combiner) are also considered for TRX reconfiguration.

For preparing the “Standby TRX” feature an additional carrier unit (standby carrier unit)
has to be created and equipped in the BTSE (command: CREATE CU and setting the
“standbyStatus” parameter to the ColdStandby value). Then the feature can be enabled
by setting the ESTDBYTRX (“enableStandbyTRX”) attribute to TRUE.
g If “TX diversity time shift” is enabled, a pair of standby CUs has to be created.
14.3.2 BCCH recovery in case no redundant TRX is available

If the carrier unit (CU) which serves as BCCH carrier fails or is locked by the user, the
BTS autonomously starts a reconfiguration in order to have another CU operate as
BCCH carrier. This reconfiguration is done by changing relations between the CUs and
the related TRX FMOs (Functional Managed Objects).
More in detail, if the CU related to the BCCH TRX (i.e. TRX:0) fails or is disabled (e.g.
locked), another CU for the same cell and in 'enabled' state which was previously
assigned to a non-BCCH TRX (e.g. TRX:1) is re-assigned to the BCCH TRX; vice-versa
the CU which has just failed or is disabled is re-assigned to the non-BCCH TRX. As a
result of the swap, the BCCH TRX is served by a working CU and the non-BCCH TRX
is out of service due to its assignment to the failed/disabled CU as shown in Figure 143.
404 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

Hardware Objects Functional Objects

Carrier Unit A TRX:0

(BCCH-TRX)
a) Initial BTSE internal
Assignment Assignment
Carrier Unit B TRX:1

(non-BCCH-TRX)
BTSE internal
Assignment
Carrier Unit A TRX:0
(BCCH-TRX)
b) Assignment Failure
after BCCH
Recovery
(non-BCCH-TRX)
Figure 143 BCCH recovery

Remarks:
• At least one SDCCH and – if applied – the SMS cell broadcast channel (CBCH) is
necessary for the BCCH TRX. Thus, a reconfiguration of the BCCH TRX implies a
reconfiguration of at least one SDCCH and the CBCH. In this way it is assured that
all necessary control channel functions are available after any BCCH recovery.
• The reconfiguration procedure does not evaluate the CHAN configuration of the
TRX for selection of the target TRX. For example it does not check whether the non-
BCCH-TRX is a pure TCH TRX or whether it also contains SDCCHs.
• BCCH reconfiguration is started as soon as the failure is detected. It can last up to
five seconds, until the new CU for the BCCH-TRX is in service. If the conditions for
TRX reconfiguration are not satisfied within this time frame, the TRX reconfiguration
is not executed.
• If synthesizer frequency hopping is configured for the non-BCCH-related TRXs and
the TRX hardware for the BCCH, which is not hopping, fails, the reconfiguration can
relate the BCCH without frequency hopping to a TRX which has previously operated
with frequency hopping. When the failed TRX-HW for the BCCH is put back in
service after fault clearance, another reconfiguration re-establishes the original
assignment.
• If synthesizer frequency hopping is configured, hopping is not disabled if the
failed/locked TRX-HW is involved in the hopping sequence. This system behavior is
independent of the BCCH recovery.
• The current assignment of the CUs to the TRX HMOs can be administered from the
Radio Commander/LMT user interfaces by getting the 'basic' attributes of the CUs.
The TRX hardware is contained in the Carrier Units, i.e. GCU (GSM Carrier Unit, sup-
porting GMSK modulation) or ECU (EDGE Carrier Unit, supporting 8PSK and GMSK
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 405

modulation) or FlexCU (Two Carrier Unit based on the ECU) boards. Some details of
the reconfiguration procedure depend on the Carrier Unit configuration for a cell as
described in the following topics.
Only GCU boards or only ECU boards are used for a cell
If the failed/locked CU is put back to service, no second reconfiguration to the initial state
before the failure/locking event is performed, the assignment of the TRX Managed
Objects to the CU is not changed.
GCU and ECU boards are used for a cell

In case a cell is operated with a GCU and an ECU in GMSK modulation mode (TRXMD
= GSM), the ECU has to carry the BCCH because its output power is higher than that of
the GCU. If this ECU fails or is locked by the user, an automatic reconfiguration is initi-
ated at first as described above, relating the GCU to the BCCH TRX object. If the ECU
has recovered or is unlocked, a second reconfiguration takes place relating the ECU to
the BCCH TRX object again (this second reconfiguration does not happen, if there is no
mixture of GCUs and ECUs in one cell).
Analogous mechanisms apply to other inhomogeneous Carrier Unit configurations for
one cell (e.g. GCU and FlexCU).
FlexCUs are used for a cell

When a cell is operated with FlexCU boards, the BCCH recovery procedure is different,
because a FlexCU provides two carrier units and the one with the odd number shall not
carry the BCCH because of thermal reasons. The Hardware related Managed Objects
of the two carrier units of a FlexCU are denoted as FCUTR:2k and FCUTR:2k+1 where
k denotes the number of the FlexCU board. An automatic recovery procedure applies
the following rules:
The BCCH-TRX shall not be related to:
1. a FLEXCU ’side’ with odd number, i.e. FCUTR:2k+1 instances (k = 0, 1, …)
2. a FlexCU which is split across two cells
3. a FlexCU with a FCUTR instance in ’disabled’/’failed’ state
The numbering indicates the priority order. In case the user has assigned the BCCH
TRX Hardware related Managed Object to a FCUTR that does not fulfil the rules above,
a recovery is accomplished when an appropriate FCUTR is available.
Example:
One FlexCU board provides the Managed Objects FCUTR:0 and FCUTR:1, another
FLEXCU board provides FCUTR:2 and FCUTR:3. FCUTR:0, FCUTR:1 and FCUTR:2
serve one cell, the FCUTR:3 is assigned to another cell. The BCCH has been assigned
to the FCUTR:0 (even instance, its related FlexCU is not split across two cells).
When a fault occurs on the BCCH FCUTR, a reconfiguration procedure is executed
assigning the BCCH to the FCUTR:2 (the other even instance in the cell). In case the
FCUTR:0 comes back in service, a new reconfiguration is executed relating the BCCH
to FCUTR:0 again in order to fulfill the rule 2.
14.3.3 TRX reconfiguration in concentric cells (no redundant TRX)

In case of a Concentric Cell, the failure or a manual locking of a CU serving a 'complete
area' TRX activates a TRX reconfiguration. In this case, the TRX reconfiguration
changes the BTSE internal assignment to assign the failed/disabled CU to an 'inner
406 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

area' TRX, and to assign another CU previously active for the ’inner area’ to the ’com-
plete area’ TRX. In this way the 'complete area' TRX is available again The reconfigura-
tion mechanism is analogous as for the BCCH recovery as represented in Figure 144.
Hardware Objects Functional Objects


(complete area)
a) Initial BTSE internal
Assignment Assignment
Carrier Unit C TRX:2

(inner area)
BTSE internal
Assignment
(complete area)
b) Assignment Failure
after TRX Re-
configuration
Carrier Unit C TRX:2
(inner area)
Figure 144 TRX reconfiguration in concentric cells

Remarks:
• The assignment of the TRX objects to the CUs does not change if the failed/locked
CU is put back to service.
• The current assignment of the CU to the TRX objects is managed from Radio Com-
mander or LMT Evolution by getting/setting the values of the CU 'basic' attributes.
• TRX reconfiguration is not started immediately after the occurred event (failure or
manual locking of CU). Due to the fact that the BTSE needs some time to shut down
call processing functions in the affected TRX, TRX reconfiguration is started approx-
imately 5 s after the trigger event. If the conditions for TRX reconfiguration are not
satisfied within this time interval, the TRX reconfiguration is not executed.
14.4 BSS overload control

The aim of the Overload Control Mechanism is to preserve the traffic-handling capabil-
ities of the Base Station System under adverse conditions.
Overload is a condition that occurs when the traffic loads exceeds the traffic processing
capacity of the BSS.
Overload control mechanism implemented in the BSC consists of traffic detection mech-
anism and defensive actions.
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 407

Traffic detection mechanism consists of specific overload messages sent either from the
various parts of the network (BTS and/or MSC) or from the BSC itself (overload detec-
tion).
Defensive actions have the purpose to reduce both mobile originating and/or mobile ter-
minating calls.
MSC overload handling

The MSC overload handling is started only if the attribute MSCOVLH (“mscOvlHand”) is
set to TRUE.
MSC overload is detected in the following situations/conditions:
– The BSC receives the BSSMAP message OVERLOAD from the MSC.
When MSC overload condition is detected, the BSC performs the following actions:
– It generates an alarm message towards the Radio Commander, LMT Evolution and
event logfile.
– It starts an algorithm for the reduction of terminating traffic which systematically
discards PAGING messages received from the MSC.
– It starts an algorithm for the reduction of originating traffic which systematically
discards CHANNEL REQUIRED messages received from the BTSs.
BTS overload handling

The BTS overload handling is started only if the attribute BTSOVLH (“btsOvlHand”) is
set to TRUE.
1. BTS overload is detected when occuring the following situations/conditions:
PCH overload in BTS
– The BSC has received the Abis RSL message OVERLOAD from the BTS.
2. AGCH overload in BTS
– The BSC has received the Abis RSL message DELETE INDICATION from the
BTS.
3. RACH overload
– The BTS has detected an overload on the RACH. No special overload defence
actions are applied by BTS or BSC.
When the above listed BTS overload conditions are detected, the BSC starts or contin-
ues suitable overload regulation measures.
g If the BTS overload condition:”Abis LAPD signalling overload” is detected for a par-
ticular BTSM, the BSC regards this situation as an overload situation for all BTSs
that belong to the same BTSM.
For load control information regarding the BTS the following attributes are provided:
• TCCCHLDI (“thresholdCcchLoadIndication”): This attribute defines a threshold used
by the BTS to inform the BSC about the load of CCCH. It is used in PCH and RACH
load measurements. For the PCH it determines the percentage of possible paging
requests stored in the BTS before CCCH load indication is sent to BSC.
• PCCCHLDI (“periodCcchLoadIndication“): This parameter specifies the time
distance between two CCCH LOAD INDICATION messages sent to the BSC (the
CCCH LOAD INDICATION is only sent to the BSC if the CCCH load threshold
TCCCHLDI is reached). The value PCCCHLDI = 0 indicates that the CCCH LOAD
INDICATION is not repeated but sent only once.
408 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

• RACHLAS (“rachLoadAveragingSlots”): This parameter defines the averaging

window for the RACH load measurements. The BTS reports these measurements
to the BSC according to the setting of the parameter PCCCHLDI.
The CCCH LOAD INDICATION reporting period should always be greater than the
averaging window size: RACHLAS < PCCCHLDI
BSC overload
The BSC overload handling is started only if the parameter BSCOVLH (“bscOvlHand”)
is set to TRUE. BSC overload is detected in the following conditions:
1. SS7 link congestion
– The Tx buffers of the CCS7 links are congested.
2. Internal message congestion
– The percentage of busy level 3 radio registers to handle incoming call requests
has exceeded a hardcoded threshold of 90%.
– The real time processor load of the AP processor has exceeded a threshold set
by the OVLSTTHR attribute. The BSC considers the exceeding of this threshold
as an overload condition and starts the associated overload handling measures.
The BSC regards the overload condition as no longer present, if the telephonic
processor real time load has dropped below the threshold set by the
OVLENTHR attribute.
– For the eBSC, a lack of AP memory resources is detected. If the memory occu-
pation of the AP exceeds an hardcoded threshold of 70%, the eBSC starts
overload handling to avoid memory corruptions.The BSC regards the overload
condition as no longer present, if the AP memory usage has dropped below the
same harcoded threshold.
– For the BSC1, a lack of TDPC memory resources is detected. If the memory
occupation of the TDPC exceeds a hardcoded threshold of 70%, the BSC1
starts overload handling to avoid memory corruptions. The BSC1 regards the
overload condition as no longer present, if the TDPC memory usage has
dropped below the same harcoded threshold; the oscillations are avoided using
the timer T18.
3. BSC1 PPXL overload
– The real time processor load of the PPXX has exceeded 70%. If the PPXX pro-
cessor load exceeds a hardcoded threshold of 70%, the BSC1 considers the
exceeding of this threshold as an overload condition and starts the associated
overload handling measures. The BSC1 regards the overload condition as no
longer present, if the PPXX processor real time has dropped below the same
harcoded threshold.
– A lack of PPXX memory resources is detected. If the memory occupation of the
PPXX exceeds a hardcoded threshold of 70%, the BSC1 starts overload
handling to avoid memory corruptions. The BSC1 regards the overload condition
as no longer present, if the PPXX memory usage has dropped below the same
harcoded threshold; the oscillations are avoided using the timer T18.
4. BSC paging queue overflow
– An overflow occurs in the BSC paging queue. A BSC paging queue overflow is
detected when the BSC cannot place a received PAGING in the queue and
discards the received PAGING message. Note: How quickly the buffered
PAGING messages are removed from the BSC paging queue, depends on the
paging delivery rate (BSC –> BTS) and the Location Area Code (LAC). The
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 409

maximum number of LACs per BSC is 20 and maximum different paging rate
towards BTSs of the same LAC is 9.
The BSC overload regulation measures depend on the type of overload condition which
was detected.
When the above listed BSC overload conditions different from “BSC Paging Queue” are
detected, the BSC performs the following actions:
– It generates an alarm message towards the Radio Commander, LMT Evolution,
event logfile.
– It sends the BSSMAP OVERLOAD message to the MSC.
– It starts an algorithm for the reduction of terminating traffic which systematically
discards PAGING messages received from the MSC.
– It starts an algorithm for the reduction of originating traffic which systematically
discards CHANNEL REQUIRED messages received from the BTSs.
When the “BSC Paging Queue” overload condition is detected, the BSC performs the
following actions:
– It generates an alarm message towards the Radio Commander, LMT Evolution,
event logfile.
– It sends the BSSMAP OVERLOAD message to the MSC.
In this case, no reduction of originating or terminating traffic is performed at all. Instead,
terminating traffic is reduced indirectly due to the fact that the MSC reduces the PAGING
messages when it receives an OVERLOAD message from the BSC which indicates
BSC overload.
14.5 Antenna hopping

Antenna hopping offers a hopping mechanism in addition to frequency hopping: the DL
bursts of a channel are transmitted on GSM frame basis (or every 2nd or 4th frame) over
alternating antennas within a cell. Antenna hopping allows to obtain a performance
improvement (diversity gain) of several dBs in DL direction.
The hopping mechanism is the main difference between antenna hopping and the fre-
quency hopping schemes, baseband and synthesizer hopping: TX antenna hopping is
performed on CU basis, not on timeslot basis, in other words: complete CUs, including
all timeslots on them, perform antenna hopping. It is not possible to generate antenna
hopping sequences for each timeslot individually. A combination of synthesizer fre-
quency hopping and antenna hopping is possible, whereas a combination with
baseband frequency hopping is not allowed because the TX diversity / antenna hopping
feature itself is based on some baseband hopping mechanism.
The feature is a complete SW feature, requiring no modifications in any HW.
Antenna hopping is supported only by the mainline BTSs, BS240XS and e-Micro BTS
(not BTS1s). All types of BTS combiners are supported except for FICOMs. FICOMs are
tuned via motor to a specific TRX frequency so that only baseband frequency hopping
is possible, which is forbidden parallel to antenna hopping. CUs connected to a FICOM
are excluded automatically from antenna hopping.
Antenna hopping has to deal with various types of CUs (e.g. GSMCU, EDGE-CU and
SB-EDGE-CU for switched beams) and frequency bands (e.g. GSM900, DCS1800 and
PCS1900). For this a CU-POOL concept has been developed, restricting the antenna
hopping between CUs of the same POOL only and thus also between the antennas to
which the corresponding CUs of the POOL are connected. It is not possible to perform
410 Id:0900d8058056fbc1 A50016-G5100-B556-04-7620

antenna hopping between CUs of different types and frequency bands. All CUs of the
same frequency band and of the same HW type are always assigned to the same CU-
POOL. For each pool a hopping sequence is calculated. The pool grouping and the cal-
culation of pool sequences are done in the BTS core (COBA) by a dedicated algorithm.
Antenna hopping is enabled for either all CUs including the BCCHTRX CU or for all CUs
except for the BCCH-TRX CU. If antenna hopping for the BCCH-TRX is excluded, the
corresponding CU is not assigned to any CU-POOL.
Attributes
• EANTHOP (“enableAntennaHopping”): This parameter enables or disables
(TRUE/FALSE) antenna hopping.
• ANTHOPMOD (“antennaHoppingMode”): This attribute defines whether antenna
hopping is applied for the BCCH TRX or not.Antenna Hopping is enabled either:
– for all CUs including the BCCH-TRX CU (value ALLTRX) or
– for all CUs except for the BCCH-TRX CU (value NOBCCHTRX).
• ANTHOPP (“antennaHoppingPeriod”): This attribute defines the antenna hopping
period, i.e. how many frames are transmitted over each antenna before the next
antenna is used to send the frames. Antenna hopping is performed every one, two
or four frames. Additionally there is the mode 4-4-5, which means that each 3rd
hopping step the period is extended from 4 to 5 frames (suitable especially for
GPRS/EGPRS). The number of antenna changes depends on the number of used
antennas and the service (4-4-5 used for EDGE).
A50016-G5100-B556-04-7620 Id:0900d8058056fbc1 411

Appendix Radio network management
15 Appendix
15.1 Handover parameters overview

)NTERCELL4#(HANDOVER )NTERCELL3$##( 3$##(HANDOVER
(!.$).4%2#(425%INTRA ANDINTER "3# NOTFORFORCEDANDTRAFFICHANDOVER
(!.$)%2#(/3$##(425%INTERCELLINTRA "3#
"3#%)3$##((/%.!",%INTER "3#
"3#-3#CONTROLOFINTER CELL4#( 4#( HANDOVER
(!.$,/4%2#(425% (/IS"3#CONTROLLED
,/4%2#(&!,3% (/IS-3#CONTROLLED
0ARAMETERSRELEVANTFORALLTYPESOFINTERCELLHANDOVER
(!.$.#%,,4(/2134./&2%0(/
-!8&!),(/
4'4"43-3480-!8'3- $#3 0#3

ADJC28,%6-).4).(&!)(/
1UALITY(/ ,EVEL(/ $ISTANCE(/ &ORCED(/
4RAFFIC(/
(!.$ (!.$ (!.$ "3# "3#
2815!,(/425% 28,%6(/425% $)34(/425% %.&/2#(/ 42&#4
(/!615!, (/!6,%6 (/!6$)34 %.!",% (!.$
(/,4(15$, (/,4(,6$, (/4-32- %)3$##((/ 42&(/%425%
(/,4(155, (/,4(,65, %.!",% 42&()4(
INTER "3#$2 42&,4(
ADJC 42&-3
(/-ARGIN (/-ARGIN %XTENDED#ELL &(/2,-/ 42&--!
(!.$ (!.$ (!.$ ADJC
%.!15!,%6(/- %,%6(/-425% (/4-32-% 42&(/-
ADJC ADJC 42&(/28,6
,%6(/- -/&&
15!,,%6(/-
0REVENTIONOFBACK(/
0REVENTION 0REVENTION
(!.$./"!+(425% OFBACK(/
OFBACK(/
ADJC:4).("!+(/ ADJC: ADJC:

4)-%2&(/ "(/&/4
(IERARCHICAL#ELL3TRUCTURE(#3 (#3
(!.$()%2#425% (!.$
()%2#425%
0,
(!.$ (!.$ 42&+02)
()%2&2!.+ ()%2&2!.+ ADJC:
ADJC: ADJC: 0,.#
0,.# 0,.#
,%6/.#
#ONCENTRIC#ELLSSECTORIZED
"43#/.#%,,425%
(!.$).).(/##%,,

4HESEPARAMETERSARENOTRELEVANTFOR&ORCED(/&AST5PLINK(/AND4RAFFIC(/

&ORCED(/'Directed Retry'ANDg&ORCED(/DUETO0REEMPTIONg INDEPENDENTOFTHE).4%2#(FLAG

0ARAMETERSARESETFROMPOINTOFVIEWOFTHEHANDOVERTARGETCELLS

.OTRELEVANTFOR&ORCED(/AND4RAFFIC(/
Figure 145 Intercell handover parameters, part 1
412 Id:0900d8058053233b A50016-G5100-B556-04-7620

Radio network management Appendix
)NTERCELL4#(HANDOVER )NTERCELL3$##( 3$##(HANDOVER

(!.$).4%2#(425%INTRA ANDINTER "3# (!.$)%2#(/3$##(425%INTERCELLINTRA "3#
"3#%)3$##((/%.!",%INTER "3#
"3#-3#CONTROLOFINTERCELL4#( 4#( HANDOVER
(!.$,/4%2#(425% (/IS"3#CONTROLLED
,/4%2#(&!,3% (/IS-3#CONTROLLED
0ARAMETERSRELEVANTFORALLTYPESOFINTERCELLHANDOVER
(!.$.#%,,4(/2134./&2%0(/
-!8&!),(/
4'4"43-3480-!8'3- $#3 0#3

ADJC:28,%6-).4).(&!)(/
0OWER"UDGET(/ &AST5PLINK(/
5SUAL#ASE 3PEED3ENSITIVE(/ $UAL4RANSFER-ODE

(!.$ (!.$ (!.$ (!.$
(/!6072" (/!6072" (/!6072" %&5,(/425%
0"'4(/425% 0"'4(/425% $4-0"'4(/ 4(,%6&5,(/
$0"'4(/425% 425% !,%6&5,(/
ADJC: ADJC: ADJC: ADJC:

(/- (/- $4-(/- &5,(/#
(/-3/&& &5,28,6-/&&
(/-$4)-%
(/-$/&&
-)#2/#%,,
(#3 (#3 (#3

(!.$ (!.$ (!.$
()%2#425% ()%2#425% ()%2#425%
0, 0, $4-0,
!$*# !$*# !$*#
0,.# 0,.# $4-0,.#
00,.#
#ONCENTRIC#ELLSSECTORIZED
"43#/.#%,,425%
(!.$).).(/##%,,

4HESEPARAMETERSARENOTRELEVANTFORFASTUPLINKHANDOVER
Figure 146 Intercell handover parameters, part 2
A50016-G5100-B556-04-7620 Id:0900d8058053233b 413

)NTRA CELL(/DUETOQUALITY )NTRA CELL(/DUETO !DVANCED #OMPRESSION

%NHANCED0AIRING $ECOMPRESSION(/
%XTENDED#ELL #ONCENTRIC#ELL "3# "3#

NEARTOFAR COMPLETETOINNER %0!425% 42&#4
FARTONEAR INNERTOCOMPLETE
(!.$ "43 (!.$
%84#(/425% #/.#%,,425% ).42!#(
#(!. 428 %!$6#-0#-$(/
%8-/$%425% 428!2%! %!$6#-0(/!-2
gDOUBLEg43FAR 0722%$ %!$6#-0(/3#
%8-/$%&!,3% (!.$ !$6#-0(//!-2
gSINGLEg43NEAR (/28,6$,)
(!.$ (/28,6$,/
(/-34!- #OMPRESSION(/ $ECOMPRESSION(/
(/-2'4! (/4(%&2 #$, (/4(%&2 $$,
(/!6$)34 (/DECISION (/4(%&2 #5, (/4(%&2 $5,
ALSOON (/4(#-0,6$, (/4($#-,6$,
DISTANCECRITERIA (/4(#-0,65, (/4($#-,65,
(!.$
##$)34425% A 2ADIO4#(LOAD A 2ADIO4#(LOAD A 2ADIO4#(LOAD
(/##$)34 REASON REASON REASON
"43 "43 "43
%0!4 (2!#4!-24 &2!#4!-24(
%0!4 (2!#4!-24 &2!#4!-24(
(2!#44 &2!#44(
(2!#44 &2!#44(
4#( 4#( (/ 3$##( 3$##( (/
(2$#-,)-4(
(!.$ (!.$
).42!#(425%
)2!#(/3$##(425% B !BIS4#(LOAD B !BIS4#(LOAD B !BIS4#(LOAD
REASON REASON REASON
"3#-3##ONTROL "43- "43- "43-
(!.$ !")3(2!#4(2 !")3(2!#4(2 !")3&2!#4(2
,/42!#(425% "3#CONTROLLED
,/42!#(&!,3% -3#CONTROLLED
(!.$
(/!615!,(/!6,%6
(/,4(15$,(/,4(155,
(/4$,).4(/45,).44(/2134
(/REPETITIONLIMITATION
(!.$
%,)-)4#(425%
-!)2!#(/4)./)%2#(/

&OR(3#3$CALLSNOINTRA CELL(/DUETOQUALITYISPERFORMEDINDEPENDENTOFTHE).42!#(FLAG

4HESETTINGOF,/42!#(HASNOEFFECTFORCONCENTRICANDEXTENDEDCELLS

#ONCENTRIC#ELL(/AND%XTENDED#ELL(/IS./4EVALUATEDDURINGTHE3$##(PHASE
THUSTHESEINTRA CELL(/CAUSESARENOTRELEVANTFOR3$##(INTRA CELL(/
Figure 147 Intracell handover parameters
414 Id:0900d8058053233b A50016-G5100-B556-04-7620

15.2 Power control parameters overview
Parameters relevant for both MS and BS Power Control
PWRC:
PWRINCSS
PWREDSS
PAVRLEV
PAVRQUAL
PCONINT
PWRCONF
-30OWER#ONTROL "30OWER#ONTROL Power Control Indication

due to
072# 072# link failure warning
EMSPWRC EBSPWRC
LOWTLEVU LOWTLEVD PWRC:
LOWTQUAU LOWTQUAD EPWCRLFW
UPTLEVU UPTLEVD PCRLFTH
UPTQUAU UPTQUAD RDLNKTBS
EBSPWCR
PCMBSTXPRL
Derived HO Power Derived HO Power

Uplink Downlink
ADJC: ADJC:
EDLDERHOPWR EULDERHOPWR
PWRC: PWRC:
ADDPATHLDBC ADDPATHLDBC
DERHOPWRSM DERHOPWRSM
MULPWRRED MDLPWRRED
ESTDLINT
Delayed PWRC for

Emergency Calls
PWRC:
ULPWRDSUP
ULPWRD
Figure 148 Power control parameters
A50016-G5100-B556-04-7620 Id:0900d8058053233b 415

15.3 Functional object tree for radio network configuration
BSC ADJC
BTSM BTS ADJC3G
CPCU CBTS CFHSY FHSY

BSS FUNCTIONAL
PCU HAND
TGTBTS TGTPTPPKF PWRC
TGTFDD PTPPKF
TGTTDD TRX CHAN
Figure 149 Functional object tree for radio network configuration
15.4 Signalling for call processing on radio area and Abis area
Every TRX has an associated LPDLR channel, which is used for the radio signalling (i.e.
signalling for call processing) of this particular TRX. In other words, any cell access, sig-
nalling transaction or call which involves any radio channel (CHAN object) subordinate
to this TRX, is signaled via this LPDLR, no matter whether it is
– a BCCH procedure (e.g. random access via the RACH, paging via the PCH or an
immediate assignment procedure via the AGCH,
– a SDCCH transaction (e.g. location update, SMS in idle mode, IMSI detach etc.) or
– a transaction signaled via an SACCH or FACCH (TCH assignment, handover, SMS
in busy mode etc.)
Physically the LPDLR signalling messages are sent within the same Abis timeslot(s)
which is (are) assigned to an existing LPDLM object(s) for the responsible BTSM (BTS
Site Manager controlling one or more cells within one BTS network element). The dis-
tinction between the LPDLM messages (O&M messages between BSC and BTSM) and
the LPDLR messages (TRX-specific radio signalling communication between BSC and
BTS/TRX) is made on the basis of the LAPD addressing identities SAPI (Service Access
Point Identifier) and TEI (Terminal Endpoint Identifier) in the layer-2 header of the LAPD
messages: While LPDLM messages are always signalled with SAPI = 62 and the TEI of
the BTSM, the radio signalling messages related to a particular TRX are always signaled
with SAPI = 0 and the TEI number which is automatically assigned to the TRX during
the BTS equipment alignment.
The parameter LPDLMN identifies the LPDLM link (and thus the physical Abis timeslot)
via which the LPDLR signalling of the TRX shall be performed. If only one LPDLM is
created for a particular BTSM, of course, only this LPDLM number can be selected for
LPDLMN. If, however, more than one LPDLM is created for a particular BTSM, LPDLMN
determines the LPDLM, via which the LPDLR signalling of a particular TRX shall be per-
formed by default. Thus the LPDLMN definition defines the standard load sharing distri-
bution for radio signalling communication among the available physical Abis timeslots
416 Id:0900d8058053233b A50016-G5100-B556-04-7620

that were configured as LPDLMs. If an LPDLM fails (e.g. due to failure of the superordi-
nate PCMB link), the radio signalling messages of the affected TRX are automatically
transmitted via one of the remaining LPDLMs in order to guarantee the availability of all
TRXs of the BTSM, even if one of the PCMB connections has failed.
Figure 150 gives an overview over the parameters related to radio signalling. For more
information about the BTS Site Manager and Abis configuration, please refer to Trans-
mission and transport network management.
"43
!BIS
"43- "3#
#/"!
0#-,INE
"43CELL 0#-#/.
,)#$
0#-"?
428 PORT?
3IGNALLINGFOR"43-
,0$,-. ,0$,- 428AND428 0#-"
428 !")3#( 0#-,

PCMB NO TIMESLOT NO LICD NO PORT NO
,0$,-.
#/3!

0#-,INE
,)#$
"43CELL 0#-#/.
0#-"?
428 PORT?
,0$,-. ,0$,- 3IGNALLINGFOR"43-AUXILIARY 0#-"

428
!")3#( 0#-,
Figure 150 LAPD signalling
A50016-G5100-B556-04-7620 Id:0900d8058053233b 417

15.5 Example for SACCH messaging

Figure 151 shows a “Measurement Report” message from an MS sent to the BTS via
SACCH. Regarding the Data Link Layer, UI (Unnumbered Information) frames are used
which correspond with unacknowledged frame transmission (other frame types regard-
ing the data link layer are I frames used for information transfer between layer 3 entitities
in acknowledged mode, and the S frame). “No. of N-cells” stands for “number of neigh-
bour cells”, “BA” for “BCCH allocation”, “DTX” for “discontinuous transmission”.
RXLEV/RXQUAL values comprising a subset of TDMA frames are necessary and used
in case of discontinuous transmission.
Bit Number
8 7 6 5 4 3 2 1
Physical Layer
SACCH Fast Power

Spare Actual MS Power Level Octet 1
Rep. Req. Control
Actual Timing Advance (TA) Octet 2
Link Protocol Service Access Point Command/ Extension

Spare Octet 3
Data Link Layer
Discriminator (LPD) Identifier (SAPI) Response Bit (EA)
Receive Sequence Number Send Sequence Number I or S/U

Poll Bit Octet 4
(here: 0 0 0 (UI frame)) (here: 0 0 1 (UI frame)) Format
Length Indicator Octet 5
Protocol Discriminator (here: RRM) Skip Indicator (here: no skip) Octet 6
Message Type (here: Measurement Report) Octet 7
„Measurement Results“ Information Element Identity Octet 8

Layer 3: Radio Resource Control
BA used DTX used RXLEV Serving Cell (Full Set of TDMA Frames) Octet 9
3G BA Measure-
RXLEV Serving Cell (Subset of TDMA Frames) Octet 10
used ment valid
No. of
Spare RXQUAL Serving Cell (Full Set) RXQUAL Serving Cell (Subset) Octet 11
N-Cells (1)
No. of
RXLEV Neighbour Cell 1 Octet 12
N-Cells (2)
BCCH Frequency Neighbour Cell 1 BSIC Neighbour Cell 1 (1) Octet 13
BSIC Neighbour
RXLEV Neighbour Cell 2 (1) Octet 14
Cell 1 (2)
................................
BCCH Freq.
N-Cell 6 (2) BSIC Neighbour Cell 6 Octet 23
Figure 151 Example for uplink SACCH messaging
418 Id:0900d8058053233b A50016-G5100-B556-04-7620

15.6 Protocol view on the GSM radio network

Figure 152 shows an extract of the GSM protocol architecture for signalling within the
radio access network. The parts concerning the radio interface (Um interface) are Radio
Resource Management (RR) on the network layer (layer 3), Link Access Protocol
(LAPDm, “m” stands for “mobile”) on the data link layer (layer 2) and TDMA/FDMA on
the physical layer (layer 1). In some cases also Mobility Management (MM) and Con-
nection Management (CM) – not shown in Figure 152 – (also components of layer 3) are
affected.
MS BTS BSC
Exchange of RR messages RR
Network layer
RR
(layer 3)
RR' BTSM BTSM
Data link layer

LAPDm LAPDm LAPDm LAPDm
(layer 2)
G.703 G.703
Physical layer TDMA TDMA
G.705 G.705
(layer 1) FDMA FDMA
G.732 G.732
Um Abis
(Radio network management parts emphasized)
Figure 152 GSM protocol structure for the radio access network
LAPDm provides functions for the control of the data link connection. These include
means for sequence control (to maintain the sequential order of frames across a data
link connection), detection of format and operational errors on a data link and flow
control.
Radio Resource Management (RR) provides functions for establishing, maintaining
and releasing radio connections that allow a point-to-point dialogue between the
network and a MS. RR basically comprises frequency and channel allocation/adminis-
tration; additionally handover procedures and cell selection/re-selection is included. In
case no RR connection is established, Radio Resource Management is also responsible
for the reception of the uni-directional BCCH and CCCH.
Radio Resource Management is one sublayer of layer 3. The other sublayers following
in upward direction are Mobility Management and Connection Management.
Mobility Management (MM) supports the mobility of user terminals, e.g. by informing
the network of its present location and providing user identity confidentiality. All MM pro-
cedures require that a RR connection and a LAPDm link have already been established.
Connection Management (CM) provides functions and procedures for Call Control
(CC), Supplementary Services (SS) and Short Message Services (SMS).
A50016-G5100-B556-04-7620 Id:0900d8058053233b 419

15.6.1 Messages for radio resource management

Table 69 lists the messages for radio resource management.
Message Channel Direction

Channel establishment
ADDITIONAL ASSIGNMENT DCCH BSS –> MS
IMMEDIATE ASSIGNMENT CCCH BSS –> MS
IMMEDIATE ASSIGNMENT EXTENDED CCCH BSS –> MS
IMMEDIATE ASSIGNMENT REJECT CCCH BSS –> MS
DTM ASSIGMENT FAILURE DCCH MS –> BSS
DTM REJECT DCCH BSS –> MS
DTM REQUEST DCCH MS –> BSS
PACKET ASSIGNMENT DCCH BSS –> MS
Ciphering
CIPHERING MODE COMMAND DCCH BSS –> MS
CIPHERING MODE COMPLETE DCCH MS –> BSS
Handover
ASSIGNMENT COMMAND DCCH BSS –> MS
ASSIGNMENT COMPLETE DCCH MS –> BSS
ASSIGNMENT FAILURE DCCH MS –> BSS
DTM ASSIGMENT COMMAND DCCH BSS –> MS
INTER SYSTEM TO UTRAN HANDOVER DCCH BSS –> MS
COMMAND
HANDOVER ACCESS DCCH MS –> BSS
HANDOVER COMMAND DCCH BSS –> MS
HANDOVER COMPLETE DCCH MS –> BSS
HANDOVER FAILURE DCCH MS –> BSS
PHYSICAL INFORMATION DCCH BSS –> MS
INTER SYSTEM TO CDMA2000 HANDOVER DCCH BSS –> MS
COMMAND
Channel release
CHANNEL RELEASE DCCH BSS –> MS
PARTIAL RELEASE DCCH BSS –> MS
PARTIAL RELEASE COMPLETE DCCH MS –> BSS
Paging
PACKET NOTIFICATION DCCH BSS –> MS
Table 69 Messages for radio resource management
420 Id:0900d8058053233b A50016-G5100-B556-04-7620


PAGING REQUEST TYPE 1 / 2 / 3 PCH BSS –> MS
PAGING RESPONSE DCCH MS –> BSS
System information
SYSTEM INFORMATION TYPE 1 BCCH BSS –> MS
SYSTEM INFORMATION TYPE 2 / 2bis / 2ter / BCCH BSS –> MS
2quater / 2n
SYSTEM INFORMATION TYPE 3 / 4 BCCH BSS –> MS
SYSTEM INFORMATION TYPE 5 / 5bis / 5ter SACCH BSS –> MS
SYSTEM INFORMATION TYPE 6 SACCH BSS –> MS
SYSTEM INFORMATION TYPE 7 / 8 / 9 BCCH BSS –> MS
SYSTEM INFORMATION TYPE 10 / 10bis / 10ter SACCH BSS –> MS
SYSTEM INFORMATION TYPE 13 / 13alt BCCH BSS –> MS
SYSTEM INFORMATION TYPE 14 SACCH BSS –> MS
SYSTEM INFORMATION TYPE 15 ... 20 BCCH BSS –> MS
DTM INFORMATION DCCH BSS –> MS
VBS/VGCS
NOTIFICATION/FACCH DCCH BSS –> MS
NOTIFICATION/NCH NCH BSS –> MS
NOTIFICATION RESPONSE DCCH MS –> BSS
VBS/VGCS RECONFIGURE DCCH BSS –> MS
VBS/VGCS RECONFIGURE2 DCCH BSS –> MS
TALKER INDICATION DCCH MS –> BSS
UPLINK ACCESS VGCH-CH MS –> BSS
UPLINK BUSY VGCH-CH MS –> BSS
UPLINK FREE DCCH BSS –> MS
UPLINK RELEASE VGCH-CH MS –> BSS
VGCS UPLINK GRANT DCCH BSS –> MS
PRIORITY UPLINK REQUEST SDCCH MS –> BSS
VGCS NEIGHBOUR CELL INFORMATION DCCH BSS –> MS
DATA INDICATION DCCH MS –> BSS –> MS
DATA INDICATION 2 DCCH MS –> BSS –> MS
NOTIFY APPLICATION DATA DCCH BSS –> MS
Measurement
EXTENDED MEASUREMENT ORDER SACCH BSS –> MS
Table 69 Messages for radio resource management (Cont.)
A50016-G5100-B556-04-7620 Id:0900d8058053233b 421


EXTENDED MEASUREMENT REPORT SACCH MS –> BSS
MEASUREMENT REPORT SACCH MS –> BSS
MEASUREMENT INFORMATION SACCH BSS –> MS
ENHANCED MEASUREMENT REPORT SACCH MS –> BSS
Miscellaneous
CHANNEL MODE MODIFY DCCH BSS –> MS
CHANNEL MODE MODIFY ACKNOWLEDGE DCCH MS –> BSS
CHANNEL REQUEST RACH MS –> BSS
CLASSMARK CHANGE DCCH MS –> BSS
CLASSMARK ENQUIRY DCCH BSS –> MS
UTRAN CLASSMARK CHANGE DCCH MS –> BSS
CDMA2000 CLASSMARK CHANGE DCCH MS –> BSS
GERAN IU MODE CLASSMARK CHANGE DCCH MS –> BSS
FREQUENCY REDEFINITION DCCH BSS –> MS
SYNCHRONIZATION CHANNEL INFORMATION SCH BSS –> MS
RR STATUS DCCH MS –> BSS
GPRS SUSPENSION REQUEST DCCH MS –> BSS
Configuration Change
CONFIGURATION CHANGE COMMAND DCCH BSS –> MS
CONFIGURATION CHANGE ACKNOWLEDGE DCCH MS –> BSS
CONFIGURATION CHANGE REJECT DCCH MS –> BSS
Application
APPLICATION INFORMATION DCCH BSS <–> MS
Table 69 Messages for radio resource management (Cont.)
15.6.1.1 System information messages

In idle mode the network broadcasts the following SYSTEM INFORMATION TYPE x
(SIx) messages via BCCH to provide general information to the MS camping on that cell:
SI2, SI3 and SI4; optionally SI1, SI2bis, SI2ter, SI7, SI8, SI13, SI16 and SI17 and further
types. Based on this information the MS is able to decide whether and how it may gain
access to the system via the current cell.
In active/dedicated mode, i.e. after the MS has got a dedicated channel (SDCCH or
TCH) the network conveys the connection specific system information in the SI5, SI6
messages, optionally also in SI5bis and SI5ter, via the DL SACCH. Based on this infor-
mation the MS is able to perform measurements on the BCCH carriers of the neighbour
cells for handover purposes.
The following topics give some details about system information messages.
422 Id:0900d8058053233b A50016-G5100-B556-04-7620

System information type 1

SI1 mainly provides the MSs in idle mode with the reference frequency list to be used
by the MS in order to decode the “Mobile Allocation” information element (which speci-
fies the frequencies used in the frequency hopping sequence). This information is
packed in the “Cell Channel Description” information element within SI1, which gives a
bitmap representation of the frequencies for GSM900: For every frequency an own bit
position is provided. If the bit value is “1”, then the frequency represented by this bit
position is included in the “Cell Allocation”. For other frequency bands special formats
representing the frequencies are defined (see 3GPP TS 44.018). The frequencies in the
the “Cell Channel Description” are set up by the CALLF<nn> attributes and form (after
sorting in increasing ARFCN order) the Cell Allocation frequency list.
SI1 also provides the “RACH Control Parameters” information element which parame-
ters are necessary to control the RACH utilization.

SI2 mainly informs about the BCCH carriers to be monitored by the mobile stations in
idle mode in the cell. This information is provided by the “Neigbour Cell Description”
information element which is coded as the “Cell Channel Description” information
element (in SI1).
SI2 also provides the “RACH Control Parameters” information element (as in SI1) and
the “NCC Permitted” information element which defines the allowed NCCs (Network
Color Codes, part of BSIC) on the BCCH carriers to be reported in the MEASUREMENT
REPORT message by the mobile stations in the cell.
The optional SI2quater gives e.g. information about 3G neighbour cells to be monitored
by the MS.

SI3 gives information about control on the RACH, the location area identification, the cell
identity and various other details about the current cell. This information is located in the
following information elements:
– “Cell Identity”
– “Location Area Identification”
– “Control Channel Description”
– “Cell Options” (includes information about e.g. discontinous transmission (DTX))
– “Cell Selection Parameters” (includes e.g. the minimum RXLEV at the MS for which
it is permitted to access the system, the maximum MS transmit power on a control
channel and the cell-reselect hysteresis value)
– “RACH Control Parameters”

SI4 gives information about control on the RACH, the location area identification and
various other details about the current cell. SI4 is applied if SMSCB (Short Message
Service Broadcast) is active. The information is located in the following information ele-
ments:
– “Location Area Identification” (as in SI3)
– “Cell Selection Parameters” (as in SI3)
– “RACH Control Parameters” (as in SI3)
A50016-G5100-B556-04-7620 Id:0900d8058053233b 423

– “CBC Channel Description” (indicates where the CBCH can be found and can
indicate frequency hopping)
– “CBC Mobile Allocation” (corresponding with the “Mobile Allocation” information
element)

SI5 informs the MS in connected mode via SACCH on TCH about the BCCH frequen-
cies of the neigbour cells, which is especially important after a handover since the SI2
on the new cell cannot be received by the MS.
SI5bis and SI5ter are used as an extension to SI5 and essentially contain the BCCH fre-
quencies of DCS1800, PCS1900 and GSM900 with extended band. The SI5bis
message is sent if and only if the EXT IND bit in the “neigbour cell description” IE in both
the SI5 and SI5bis messages indicates that each information element only carries a part
of the BCCH allocation list (BA list).

SI6 is similar to SI3 and gives various information about the current cell. It contains the
following information elements:
– “Cell Identity” (as in SI3)
– “Location Area Identification” (as in SI3)
– “Cell Options” (as in SI3)
– “NCC Permitted” (as in SI2)
15.6.1.2 Other selected messages

Paging request type 1 message
This message is sent on the CCCH by the network and may identify up to two MSs in
idle mode in order to trigger channel access (it may also be sent to a MS in packet idle
mode to transfer mobility management information (i.e. to trigger the cell update proce-
dure). The following list shows a selection of information elements which can be
included in this message (for complete listing of possible information elements see
3GPP TS 44.018).
• “Page Mode”
This mandatory IE determines if e.g. normal or extended paging is used.
• “Channels Needed”:
This mandatory IE indicates which type of channel (e.g. SDCCH or TCH full rate) is
needed (for each mobile station).
• “Mobile Identity”:
This mandatory IE identifies the mobile stations via TMSI/P-TMSI or IMSI.
Immediate assignment message

This message is sent from the network to the MS in idle mode on the CCCH and
provides the MS with channel configuration data in order to enable the MS to seize an
SDCCH in the current cell (thus changing to dedicated mode).
In case the MS is in packet idle mode, this message is sent via PACCH encapsulated in
the PACKET CS COMMAND message in order to enable a change to an uplink or
downlink packet data channel configuration.
424 Id:0900d8058053233b A50016-G5100-B556-04-7620

The following list shows a selection of information elements which can be included in
this message (for complete listing of possible information elements see 3GPP TS
44.018).
• “Page Mode”:
This mandatory IE determines if e.g. normal or extended paging is used.
• “Dedicated Mode or TBF”:
This mandatory IE indicates whether a SDCCH for CS services shall be allocated
(dedicated mode) or a Temporary Block Flow (PS services) shall be established.
• “Channel Description”, see Figure 153:
This mandatory IE in case of CS services determines:
– The channel type (e.g bidirectional or unidirectional channel) and TDMA offset
– The timeslot of the channel within a TDMA frame
– The TSC (Training Sequence Code)
– The ARFCN of the TCH to be seized by the MS (if no frequency hopping is
applied, which is indicated by H = 0)
– If frequency hopping is applied (H = 1): several frequency hopping parameters
(MAIO, HSN)
• “Packet Channel Description”:
This mandatory IE in case of PS services determines channel parameters corre-
sponding to those for CS services (e.g. ARFCN, timeslot, TSC, frequency hopping
parameters) and additional PS specific parameters):
• “Request Reference”:
This mandatory IE provide the random access information used in the channel
request and the frame number, FN modulo 42432, in which the channel request was
received.
• “Timing Advance”
• “Mobile Allocation”:
This IE gives a bitmap representation of the frequencies used in the frequency
hopping sequence. For decoding of the mobile allocation bitmap, it is mapped with
the cell allocation frequency list (containing all non-BCCH frequencies allocated in
the cell) where the ARFCNs are sorted in increasing ARFCN order: The position N
in the mobile allocation bitmap is related to the N-th ARFCN in the cell allocation fre-
quency list. If bit N of the mobile allocation has the value 1, then and only then the
N-th ARFCN is used for frequency hopping.
Here, the cell allocation list has to be derived from the “Cell Channel Description” IE
within the SYSTEM INFORMATION TYPE 1 message.
Bit Number
8 7 6 5 4 3 2 1
Channel Description IE Identifier Octet 1
Channel type and TDMA offset Timeslot number (TN) Octet 2
H=1 MAIO (high part)

Training sequence (TSC) Octet 3
H=0 Spare ARFCN (high part)
MAIO (low part) Hopping sequence number (HSN)
Octet 4
ARFCN (low part)
Figure 153 Channel description information element
A50016-G5100-B556-04-7620 Id:0900d8058053233b 425

Assignment command message

The ASSIGNMENT COMMAND message is sent during call establishment from the
network to the MS, which has already seized the SDCCH, in order to provide the MS
with information about channel configuration for changing from SDCCH to TCH. The fol-
lowing list shows a selection of information elements which can be included in this
message (for complete listing of possible information elements see 3 GPP TS 44.018).
• “Channel Description 2”:
This mandatory IE determines:
– The channel type (e.g bidirectional or unidirectional TCH/FS) and TDMA offset
– The timeslot of the TCH within a TDMA frame
– The TSC (Training Sequence Code)
– The ARFCN of the TCH to be seized by the MS (if no frequency hopping is
applied)
– If frequency hopping is applied: several frequency hopping parameters (MAIO,
HSN)
• “Power Command”:
This mandatory IE provides information about the power control mode (enhanced
power control or not, fast power control or not) and the power level the MS shall
apply when sending on the TCH.
• “Cell Channel Description”:
This IE gives a representation of the frequencies allocated in the cell.
• “Multislot Allocation”:
This IE provides a description of which channels are used in downlink and uplink
respectively in a multislot configuration. It also groups the channels into channel
sets.
• “Channel Mode”:
This IE determines the type of data transmitted via the channel (e.g. speech, data,
half rate, full rate) as well as the coding/decoding mode (e.g. AMR or not AMR) and
transcoding mode.
In case of a multislot configuration, for each channel (timeslot) or channel set an own
IE of this type is provided. In case of AMR the “MultiRate Configuration” provides the
necessary information about the codecs to be used.
• “Mobile Allocation”:
This IE gives a bitmap representation of the frequencies used in the frequency
hopping sequence. For decoding of the mobile allocation bitmap, it is mapped with
the cell allocation frequency list (containing all non-BCCH frequencies allocated in
the cell) where the ARFCNs are sorted in increasing ARFCN order: The position N
in the mobile allocation bitmap is related to the N-th ARFCN in the cell allocation fre-
quency list. If bit N of the mobile allocation has the value 1, then and only then the
N-th ARFCN is used for frequency hopping.
• “MultiRate Configuration”:
This IE gives all parameters related to multirate speech codecs. It includes the set
of AMR codec modes, AMR thresholds and hysteresis values.
Handover command message

This message is sent during the handover execution process from the network to the
MS on FACCH in order to provide the MS with configuration parameters of the new cell
and TCH to be seized. The following list shows a selection of information elements
426 Id:0900d8058053233b A50016-G5100-B556-04-7620

which can be included in this message (for complete listing of possible information
elements see 3 GPP TS 44.018).
• “Cell Description”
This IE provides a minimum of data of the target cell. It contains the target cell’s
BCCH ARFCN, NCC and BCC.
• “Channel Description 2” (as in the Assignment command message)
• “Handover Reference”:
This IE provides a reference value used for access identification.
• “Power Command and Access Type”:
This mandatory IE provides information about the power control mode (enhanced
power control or not, fast power control or not), the power level the MS shall apply
when sending on the TCH and a flag indicating the access type (HANDOVER
ACCESS message from the MS is mandatory (bit value: 0) or optional (bit value: 1)).
• “Cell Channel Description” (as in the Assignment command message)
• “Multislot Allocation” (as in the Assignment command message)
• “Channel Mode” (as in the Assignment command message)
• “Mobile Allocation” (as in the Assignment command message)
• “Timing Advance”
• “MultiRate Configuration” (as in the Assignment command message)
Measurement report
This message contains the “Measurement Results” IE which is illustrated in
15.5 Example for SACCH messaging.
Enhanced measurement report

ENHANCED MEASUREMENT REPORT messages are sent by the MS in dedicated
mode on SACCH – if requested – with a defined periodicity which depends on the used
channel type and the mode the MS/UE is currently in (see 3GPP 45.008 for further
details).
An ENHANCED MEASUREMENT REPORT message contains (among others) the fol-
lowing main data:
• “BA_USED”:
This flag indicates which of the two 2G BCCH Allocations (BCCH list of 2G neigh-
bour frequencies) the MS has used for the neigbour cell measurements. The one for
idle mode (for cell reselection) or the one for connected mode (for handover).
• “3G_BA_USED”:
This flag is the 3G equivalent of the BA_USED flag.
• “REPORTING_QUANTITY”:
The type of reported value (according to parameter FDDREPQTY)
• Serving cell measurement data:
– “DTX used”:
Flag indicating if DTX was used in uplink direction in the measurement period
– “RXLEV_VAL”:
The downlink RXLEV value of the serving cell
– “RXQUAL_FULL”:
The downlink RXQUAL value of the serving cell
A50016-G5100-B556-04-7620 Id:0900d8058053233b 427

– “MEAN_BEP” and “CV_BEP”:

The mean and 'coefficient of variation' of the Bit Error Probability (BEP)
measures (averaged over the reporting period)
– “NBR_RCVD_BLOCKS”:
The number of correctly decoded downlink blocks in the measurement period
(this value is used by the BTS to calculate the downlink FER)
• Neighbour cell measurement data:
– “BCCH frequency number”:
The relative frequency number within the BA list
– “BSIC”
– “RXLEV_NCELL”:
The downlink RXLEV value of the neighbour cell
Within the message part that contains the neighbour cell measurement data the neigh-
bour cell measurements are listed in a defined priority order:
1. The number of strongest valid GSM cells with a reported value equal or greater than
the reporting threshold for its band (parameter FDDREPTH) in the frequency band
of the serving cell.
2. The number of strongest valid GSM cells with a reported value equal or greater than
the reporting threshold for its band (parameter FDDREPTH) in each of the frequency
bands in the BA list excluding that of the serving cell.
3. The number of best valid cells and with a reported value equal or greater than
XXX_REPORTING_THRESHOLD (parameter FDDREPTH), in each supported
other radio access technology/mode in the 3G neighbour cell list, according to the
value of the parameters XXX_MULTIRAT_REPORTING (parameter FDDMUR-
REP).
When the radio access technology is UTRAN FDD, then additionally the non-
reported value (from CPICH EC/N0 and CPICH RSCP) must be equal or greater
than FDD_REPORTING_THRESHOLD_2 (parameter FDDREPTH2).
4. Remaining cells of lower priorities, validity or access technologies (see 3GPP spec-
ification 44.018).
For each of the priority levels above, the following rules apply:
– If the number of valid cells is less than indicated the unused positions in the report
are left for the lower priorized cells.
– If there is not enough space in the report for all valid cells, the cells are reported that
have the highest sum of the reported value (e.g. RXLEV) and the parameter
XXX_REPORTING_OFFSET for respective radio access technology (parameter
FDDREPO). This offset parameter, however, does not affect the actual reported
value. If a cell cannot be reported due to lack of space in the report, then no cell with
a lower value is reported, even if one of these cells with a lower value would fit into
the report.
Measurement information message

This message is sent from the BTS to the MS in dedicated mode on SACCH (only if han-
dovers from GSM to UMTS are enabled) informing the MS/UE e.g. about the 3G neigh-
bours to be monitored during an ongoing call (from this point of view MEASUREMENT
INFORMATION messages can be seen as the 3G-equivalent to SYSTEM INFORMA-
TION TYPE 5, 5bis and 5ter messages); information about 2G cells is also included
(BSICs). The following list shows a selection of information elements which can be
428 Id:0900d8058053233b A50016-G5100-B556-04-7620

included in this message (for complete listing of possible information elements see 3
GPP TS 44.018).
• “BA_IND”: This parameter allows the network to distinguish the BA list for cell rese-
lection (MS in idle mode, SI2 neighbour cell information) from the BA list for
handover (MS in connected mode, SI5 neighbour cell information). The BA_IND
values of the two BA lists are always different. BA_IND sent from the network to the
MS corresponds with BA_USED sent from the MS to the network in the MEASURE-
MENT REPORT message.
• “3G_BA_IND”: This parameter is the equivalent of the BA_IND parameter for 3G
neighbour cells.
• “POWER CONTROL INDICATOR”: indicates if PWRC is set or not.
• “FDD_CELL_INFORMATION” field: It includes e.g.:
– “FDD Diversity”: indicating if diversity is used in the UMTS FDD target cell or not
(parameter: FDDDIV).
– “FDD Scrambling Code”: defines the primary scrambling code used by the target
FDD cell (parameter: FDDSCRMC).
• “REPORT_TYPE”: This parameter indicates to the mobile if the ENHANCED MEA-
SUREMENT REPORT or MEASUREMENT REPORT message shall be used for
measurements reporting (parameter: REPTYP).
• “BSIC”: This field, together with the BA list (not included in this message), allows to
derive the Neighbour Cell List
• “MEASUREMENT PARAMETERS”: This field contains e.g. the
MULTIBAND_REPORTING/“Number of multi band cells” flag parameter: This
parameter is relevant for dualband configurations and specifies in which way the MS
shall report the neighbour cells of the frequency bands used in the serving and
neighbouring cells (parameter: NMULBAC).
• “3G MEASUREMENT PARAMETERS”: It includes e.g.:
– “Qsearch Connected”: A threshold condition for the serving 2G cell: If the spec-
ified threshold condition is fulfilled, then 3G cells shall be considered for
handover neighbour cell monitoring (parameter: QSRHC).
– “3G_SEARCH_PRIO”: indicates if a mobile may search 3G cells when BSIC
decoding is required, i.e. if the searching time can be longer than the normal
value (13 s instead of 10 s) (parameter: UMTSSRHPRI).
– “FDD Reporting Quantity”: determines if the MS shall report in terms of RSCP or
EC/N0 (parameter: FDDREPQTY).
– “FDD MultiRat Reporting”: indicating the number of FDD UTRAN cells the UE
shall include in the MEASUREMENT REPORTs (parameter: FDDMURREP).
– “FDD Reporting Offset”: If 'Enhanced Measurement Reporting' is enabled and
there is not enough space in the report for all valid cells, those 3G cells are
reported that have the highest sum of the reported value and the offset (param-
eter: FDDREPO).
– “FDD Reporting Threshold”: defines a threshold which an UTRAN cell has to
exceed in order to be reported in the ENHANCED MEASUREMENT REPORT
(parameter: FDDREPTH).
Classmark change message

This message is sent from the MS to the network as response to a classmark enquiry
from the network or in order to indicate e.g. special MS capabilities. It contains a “Mobile
A50016-G5100-B556-04-7620 Id:0900d8058053233b 429

Station Classmark 2” or a “Mobile Station Classmark 3” information element providing

the following main information (for more details see 3GPP TS 24.008):
Mobile Station Classmark 2:
– “RF power capability” field: indicating the RF power capability of the MS (class 1 –5).
– “PS capability” field: indicating the capability of the MS for packet switched services.
– “A5/1”, “A5/2”, “A5/3” fields: indicating if the specified ciphering algorithms are avail-
able.
– “VBS”, “VGCS” fields: indicating if the MS is capable of the specified ASCI services.
– “FC” field: indicating a special frequency capability of the MS.
– “LCS VA capability” field: indicating if the MS has LCS (location services) value
added location request notification capability.
Mobile Station Classmark 3:
– “Multiband Support” field: indicating which additional frequency bands the MS
supports (P-GSM, E-GSM or R-GSM, GSM 1800).
– “A5/4”, “A5/5”, “A5/6”, “A5/7” fields: indicating if the specified ciphering algorithms
are available.
– “HSCSD Multi Slot Class”
– “Extended Measurement Capability” field: indicating if the MS supports 'Extended
Measurements' or not.
– “MS Positioning Method” field: indicating the positioning method supported by the
MS for the provision of location services (LCS).
– “ECSD Multi Slot class” field
– “Modulation Capability”: indicating the MS’s 8-PSK capability.
– “UMTS FDD Radio Access Technology Capability”
– “DTM GPRS Multi Slot Class”
– “High Multislot Capability” field: indicating the support of multislot classes 30 to 45.
– “DTM Enhancements Capability”
– “Repeated ACCH Capability” field: indicating whether the MS supports Repeated
SACCH and Repeated Downlink FACCH.
15.6.2 LAPDm messages

LAPDm messages which do not need to carry layer 3 messages are e.g.:
– SABM (Set Asynchronous Balanced Mode):
This message initiates the acknowledged transmission of the subsequent messages
on the control channel. All messages within this acknowledged mode are checked
by the LAPDm flow control mechanism based on sequence numbers that are
assigned to each transmitted LAPDm message (such messages allowing flow
control are I frames). The SABM message requires acknowledgement itself.
– DISCONNECT:
This message is used to stop the transmission of control frames in acknowledged
mode. The DISCONNECT message requires acknowledgement itself.
– UA (Unnumbered Acknowledge): This message is used to acknowledge the receipt
of a SABM or DISCONNECT message.
15.6.3 Messages for mobility management

Table 70 lists the messages for radio mobility management.
430 Id:0900d8058053233b A50016-G5100-B556-04-7620

Message Direction
Registration
IMSI DETACH INDICATION MS –> BSS
LOCATION UPDATING ACCEPT BSS –> MS
LOCATION UPDATING REJECT BSS –> MS
LOCATION UPDATING REQUEST MS –> BSS
Security
AUTHENTICATION REJECT BSS –> MS
AUTHENTICATION REQUEST BSS –> MS
AUTHENTICATION RESPONSE MS –> BSS
AUTHENTICATION FAILURE MS –> BSS
IDENTITY REQUEST BSS –> MS
IDENTITY RESPONSE MS –> BSS
TMSI REALLOCATION COMMAND BSS –> MS
TMSI REALLOCATION COMPLETE MS –> BSS
Connection management
CM SERVICE ACCEPT MS <–> BSS
CM SERVICE PROMPT BSS –> MS
CM SERVICE REJECT BSS –> MS
CM SERVICE ABORT MS –> BSS
CM SERVICE REQUEST MS –> BSS
CM RE-ESTABLISHMENT REQUEST MS –> BSS
ABORT BSS –> MS
Miscellaneous
MM INFORMATION MS <–> BSS
MM STATUS MS <–> BSS
MM NULL MS –> BSS
Table 70 Messages for mobility management
CM service request message

The CM SERVICE REQUEST message is sent by the mobile station to the network to
request a service such as CS connection establishment, supplementary services acti-
vation, short message transfer, location services. It includes the following information
elements:
• “CM service type”
This IE specifies which service is requested from the network, e.g. mobile originating
call establishment, SMS, voice group call establishment.
A50016-G5100-B556-04-7620 Id:0900d8058053233b 431

• “Ciphering Key Sequence Number”

This IE allows the network to identify the ciphering key Kc which is stored in the
mobile station without invoking the authentication procedure.
• “Mobile Station Classmark 2”
This IE provides information about special MS capabilities
• “Mobile Identity”
This IE provides either the IMSI, TMSI/P-TMSI/M-TMSI, IME, IMEISV (IMEI +
software version number), or the temporary mobile group identity (TMGI), associ-
ated with the optional MBMS session identity.
• “Priority Level”
432 Id:0900d8058053233b A50016-G5100-B556-04-7620

15.7 Protocol view on GPRS and packet data/message flow

Figure 154 shows the protocol structure for GPRS with focus on data link layer functions.
Radio Resource management (RR, not shown) is performed in the BSS between LLC
and RLC/MAC. LLC is located between RR and MM (Mobility Management).
MS BTS BSC SGSN
Network Layer
SNDCP SNDCP
(Layer 3)
Data Link Layer A

LLC LLC
(Layer 2 A)
RLC RLC BSSGP BSSGP

(not Layer 2) (not Layer 2)
Data Link Layer B
(Layer 2 B)
Frame Frame
MAC MAC
Relay Relay
G.703
TDMA
FDMA
G.703
Physical Layer TDMA

:::
G.705 L1 bis L1 bis

(Layer 1) FDMA
G.732
Um Abis Gb
MAC: Medium Access Control LLC: Logical Link Control

RLC: Radio Link Control SNDCP: Subnetwork Dependent Convergence Protocol
Figure 154 GPRS protocol structure

The data link layer is divided in two parts, Logical Link Control (LLC) between MS and
SGSN, Radio Link Control and Medium Access Control (RLC and MAC) between MS
and BSC.
• LLC: This protocol provides a reliable logical link between MS and SGSN. Its func-
tionality is based on LAPDm and includes e.g. order control of PDUs (Packet Data
Units), flow control, error detection, Automatic Repeat Request (ARQ). Within the
LLC layer a logical link is addressed by the TLLI (Temporary Logical Link Identifier).
• RLC: This protocol provides segmentation and reassembly of LLC PDUs into
RLC/MAC blocks and, in RLC acknowledged mode of operation, Backward Error
Correction enabling selective retransmission of unsuccessfully delivered RLC/MAC
blocks with ARQ. In RLC acknowledged mode also the order of higher layer PDUs
is controlled.
• MAC: This protocol provides functions for the management of shared transmission
resources (e.g. scheduling, multiplexing). More in detail MAC supports TBFs that
allow e.g. a mobile station to use several physical channels (timeslots) in parallel.
A50016-G5100-B556-04-7620 Id:0900d8058053233b 433

BSSGP (BSS GPRS Protocol) corresponds with BSSMAP for circuit switched GSM. It
is used to transfer LLC frames together with related information between the SGSN and
the BSC.
The SNDCP (Sub Network Dependent Convergence Protocol) is the protocol specified
for the logical layer 3 interface between the MS and the SGSN. It performs the following
tasks: Encryption, compression, segmentation, reassembling, multiplexing/demultiplex-
ing of signaling information and data packets.
For more information on GPRS protocols and interfaces, see GPRS global description.
Figure 155 shows the container units used for carrying GPRS signalling and user data.
On Gb interface, i.e. between SGSN and BSC, packet data units are transported via so
called LLC frames. The BSC converts such LLC frames in RLC/MAC frames and packs
them in PCU frames for transportation to the BTS via Abis interface. Eventually the BTS
puts the content of a PCU frame in four consecutive bursts forming one radio block and
sends them to the MS via air interface (Um).
SGSN BSC BTS MS

Core Net
Gb Abis Um
IP data LLC packet RLC/MAC

packet data unit block
PCU frame
Radio block
RLC/MAC
block
PCU frame
Radio block
Figure 155 GPRS data container units
15.8 RLC/MAC data blocks

Downlink RLC/MAC data block
Figure 156 provides an example of a downlink RLC/MAC data block. Additionally the
packing of LLC PDUs (Packet Data Units) and the use of the Length Indicator in con-
junction with the M and E bits is shown. In the example, LLC PDU 1 continues from a
previous RLC data block and ends in the RLC data block shown. LLC PDU 2 follows LLC
PDU 1 and is completely contained within the RLC data block. LLC PDU 3 follows LLC
PDU 2, beginning in the RLC data block shown, and continues into the next RLC data
block.
434 Id:0900d8058053233b A50016-G5100-B556-04-7620

Bit Number
8 7 6 5 4 3 2 1
MAC Layer
Payload Type RRBP S/P USF Octet 1
PR TFI FBI Octet 2
BSN E=0 Octet 3

RLC Layer
Length Indicator = 11 M=1 E=0 Octet 4
Length Indicator = 26 M=1 E=1 Octet 5
Octet 6
...
LLC Packet Data Unit 1 (cont.) LLC PDU 1
Octet 16
Octet 17
Data Layer
...
LLC Packet Data Unit 2 LLC PDU 2
Octet 42
Octet 43
...
LLC Packet Data Unit 3 LLC PDU 3
Octet N
Figure 156 Downlink RCL/MAC data block (example)

Explanations of header fields:
• USF: Uplink state flag. This field indicates the owner or use of the next uplink radio
block on the same timeslot.
• S/P: Supplementary/Polling. This field indicates whether the RRBP field is valid or
not.
• RRBP: Relative Reserved Block Period. This field specifies a single uplink block in
which the MS shall transmit either a PACKET CONTROL ACKNOWLEDGEMENT
message or a PACCH block to the network.
• Payload Type: This field distinguishes certain types of data, e.g. RLC data block or
a RLC data block that contains an RLC/MAC control block.
• FBI: Final Block Indicator. This field indicates that the downlink RLC data block is
the last one of the downlink TBF.
• TFI: Temporary Flow Identity. This field identifies the Temporary Block Flow (TBF)
to which the RLC data block belongs.
• PR: Power Reduction. This field indicates the power level reduction of the current
RLC block.
A50016-G5100-B556-04-7620 Id:0900d8058053233b 435

• E: Extension. This field indicates the presence of an optional octet in the header.
• BSN: Block Sequence Number. This field carries the absolute Block Sequence
Number (modulo Sequence Number Space) of each RLC data block within the TBF.
• M: More. This field, along with the E field and the Length Indicator, is used to delimit
LLC PDUs within a TBF.
• Length Indicator: This field indicates the number of octets of the RLC data field
belonging to the related LLC PDU.
Uplink RLC/MAC data block

Figure 157 shows an example of an uplink RLC/MAC data block.
Bit Number
8 7 6 5 4 3 2 1
Payload Type Countdown Value SI R Octet 1
Spare PI TFI TI Octet 2
BSN E Octet 3
Length Indicator M E Octet 4
................. ...
Length Indicator M E Octet M
TLLI ...
Octet
PFI E
M+5
RLC Data ...
Octet N
Figure 157 Uplink RCL/MAC data block (example)

Explanations:
• R: Retry. This field indicates whether the mobile station transmitted the CHANNEL
REQUEST, PACKET CHANNEL REQUEST, EGPRS PACKET CHANNEL
REQUEST or MPRACH PACKET CHANNEL REQUEST message one time or more
than one time during its most recent channel access.
• SI: Stall Indicator. This field indicates whether the mobile's RLC transmit window can
advance (i.e. is not stalled) or can not advance (i.e. is stalled).
436 Id:0900d8058053233b A50016-G5100-B556-04-7620

• Countdown Value: This field allows the network to calculate the number of RLC data
blocks remaining for the current uplink RLC entity.
• TI: TLLI Indicator. This field indicates the presence of an optional TLLI field within
the RLC data block.
• PI: PFI Indicator. This field indicates the presence of the optional PFI field.
• PFI: Packet Flow Identifier.
A50016-G5100-B556-04-7620 Id:0900d8058053233b 437

15.9 Mobile station power classes and power control levels
Power class Nominal maximum output power

GSM900/GSM850 DCS1800 PCS1900
1 – 1 W (30 dBm) 1 W (30 dBm)
2 8 W (39 dBm) 0.25 W (24 dBm) 0.25 W (24 dBm)
3 5 W (37 dBm) 4 W (36 dBm) 2 W (33 dBm)
4 2 W (33 dBm) – –
5 0.8 W (29 dBm) – –
Table 71 Mobile station power classes
GSM900/GSM850 DCS1800 PCS1900

Power Nominal output Power Nominal output Power Nominal output
control level power (dBm) control level power (dBm) control level power (dBm)
0–2 39 29 36 22 – 29 Reserved
3 37 30 34 30 33
4 35 31 32 31 32
5 33 0 30 0 30
6 31 1 28 1 28
7 29 2 26 2 26
8 27 3 24 3 24
9 25 4 22 4 22
10 23 5 20 5 20
11 21 6 18 6 18
12 19 7 16 7 16
13 17 8 14 8 14
14 15 9 12 9 12
15 13 10 10 10 10
16 11 11 8 11 8
17 9 12 6 12 6
18 7 13 4 13 4
19 – 31 5 14 2 14 2
15 – 28 0 15 0
16 – 21 Reserved
Table 72 Power control levels
438 Id:0900d8058053233b A50016-G5100-B556-04-7620

15.10 Frequency/channel conversion table
Frequency-Band ARFCN Quantity Uplink (MHz) Downlink(MHz)

E-GSM 900 0...124 125 890.0 - 914.8 935.0 - 959.8
975...1023 49 880.2 - 889.8 925.2 - 934.8
P-GSM 900 1...124 124 890.2 - 914.8 935.2 - 959.8
R-GSM 900 0...124 125 890.0 - 914.8 935.0 - 959.8
955...1023 69 876.2 - 889.8 921.2 - 934.8
GSM-850 128...251 124 824.2 - 848.8 869.2 - 893.8
GSM-RE 1...55 55 890.2 - 901.0 935.2 - 946.0
955...1023 69 876.2 - 889.8 921.2 - 934.8
GSM 1800 512...885 374 1710.2 -1784.8 1805.2 -1879.8
GSM 1900 512...810 299 1850.2 -1909.8 1930.2 -1989.8
Table 73 Frequency/channel conversion table
15.10.1 GSM 850-900 table
ARFCN Frequency (MHz) ARFCN Frequency (MHz) ARFCN Frequency (MHz)

Uplink Downlink Uplink Downlink Uplink Downlink
0 890.0 935.0 1 890.2 935.2 2 890.4 935.4
3 890.6 935.6 4 890.8 935.8 5 891.0 936.0
6 891.2 936.2 7 891.4 936.4 8 891.6 936.6
9 891.8 936.8 10 892.0 937.0 11 892.2 937.2
12 892.4 937.4 13 892.6 937.6 14 892.8 937.8
15 893.0 938.0 16 893.2 938.2 17 893.4 938.4
18 893.6 938.6 19 893.8 938.8 20 894.0 939.0
21 894.2 939.2 22 894.4 939.4 23 894.6 939.6
24 894.8 939.8 25 895.0 940.0 26 895.2 940.2
27 895.4 940.4 28 895.6 940.6 29 895.8 940.8
30 896.0 941.0 31 896.2 941.2 32 896.4 941.4
33 896.6 941.6 34 896.8 941.8 35 897.0 942.0
36 897.2 942.2 37 897.4 942.4 38 897.6 942.6
39 897.8 942.8 40 898.0 943.0 41 898.2 943.2
42 898.4 943.4 43 898.6 943.6 44 898.8 943.8
45 899.0 944.0 46 899.2 944.2 47 899.4 944.4
48 899.6 944.6 49 899.8 944.8 50 900.0 945.0
Table 74 GSM table
A50016-G5100-B556-04-7620 Id:0900d8058053233b 439


51 900.2 945.2 52 900.4 945.4 53 900.6 945.6
54 900.8 945.8 55 901.0 946.0 56 901.2 946.2
57 901.4 946.4 58 901.6 946.6 59 901.8 946.8
60 902.0 947.0 61 902.2 947.2 62 902.4 947.4
63 902.6 947.6 64 902.8 947.8 65 903.0 948.0
66 903.2 948.2 67 903.4 948.4 68 903.6 948.6
69 903.8 948.8 70 904.0 949.0 71 904.2 949.2
72 904.4 949.4 73 904.6 949.6 74 904.8 949.8
75 905.0 950.0 76 905.2 950.2 77 905.4 950.4
78 905.6 950.6 79 905.8 950.8 80 906.0 951.0
81 906.2 951.2 82 906.4 951.4 83 906.6 951.6
84 906.8 951.8 85 907.0 952.0 86 907.2 952.2
87 907.4 952.4 88 907.6 952.6 89 907.8 952.8
90 908.0 953.0 91 908.2 953.2 92 908.4 953.4
93 908.6 953.6 94 908.8 953.8 95 909.0 954.0
96 909.2 954.2 97 909.4 954.4 98 909.6 954.6
99 909.8 954.8 100 910.0 955.0 101 910.2 955.2
102 910.4 955.4 103 910.6 955.6 104 910.8 955.8
105 911.0 956.0 106 911.2 956.2 107 911.4 956.4
108 911.6 956.6 109 911.8 956.8 110 912.0 957.0
111 912.2 957.2 112 912.4 957.4 113 912.6 957.6
114 912.8 957.8 115 913.0 958.0 116 913.2 958.2
117 913.4 958.4 118 913.6 958.6 119 913.8 958.8
120 914.0 959.0 121 914.2 959.2 122 914.4 959.4
123 914.6 959.6 124 914.8 959.8
128 824.2 869.2 129 824.4 869.4 130 824.6 869.6
131 824.8 869.8 132 825.0 870.0 133 825.2 870.2
134 825.4 870.4 135 825.6 870.6 136 825.8 870.8
137 826.0 871.0 138 826.2 871.2 139 826.4 871.4
140 826.6 871.6 141 826.8 871.8 142 827.0 872.0
143 827.2 872.2 144 827.4 872.4 145 827.6 872.6
146 827.8 872.8 147 828.0 873.0 148 828.2 873.2
149 828.4 873.4 150 828.6 873.6 151 828.8 873.8
Table 74 GSM table (Cont.)
440 Id:0900d8058053233b A50016-G5100-B556-04-7620


152 829.0 874.0 153 829.2 874.2 154 829.4 874.4
155 829.6 874.6 156 829.8 874.8 157 830.0 875.0
158 830.2 875.2 159 830.4 875.4 160 830.6 875.6
161 830.8 875.8 162 831.0 876.0 163 831.2 876.2
164 831.4 876.4 165 831.6 876.6 166 831.8 876.8
167 832.0 877.0 168 832.2 877.2 169 832.4 877.4
170 832.6 877.6 171 832.8 877.8 172 833.0 878.0
173 833.2 878.2 174 833.4 878.4 175 833.6 878.6
176 833.8 878.8 177 834.0 879.0 178 834.2 879.2
179 834.4 879.4 180 834.6 879.6 181 834.8 879.8
182 835.0 880.0 183 835.2 880.2 184 835.4 880.4
185 835.6 880.6 186 835.8 880.8 187 836.0 881.0
188 836.2 881.2 189 836.4 881.4 190 836.6 881.6
191 836.8 881.8 192 837.0 882.0 193 837.2 882.2
194 837.4 882.4 195 837.6 882.6 196 837.8 882.8
197 838.0 883.0 198 838.2 883.2 199 838.4 883.4
200 838.6 883.6 201 838.8 883.8 202 839.0 884.0
203 839.2 884.2 204 839.4 884.4 205 839.6 884.6
206 839.8 884.8 207 840.0 885.0 208 840.2 885.2
209 840.4 885.4 210 840.6 885.6 211 840.8 885.8
212 841.0 886.0 213 841.2 886.2 214 841.4 886.4
215 841.6 886.6 216 841.8 886.8 217 842.0 887.0
218 842.2 887.2 219 842.4 887.4 220 842.6 887.6
221 842.8 887.8 222 843.0 888.0 223 843.2 888.2
224 843.4 888.4 225 843.6 888.6 226 843.8 888.8
227 844.0 889.0 228 844.2 889.2 229 844.4 889.4
230 844.6 889.6 231 844.8 889.8 232 845.0 890.0
233 845.2 890.2 234 845.4 890.4 235 845.6 890.6
236 845.8 890.8 237 846.0 891.0 238 846.2 891.2
239 846.4 891.4 240 846.6 891.6 241 846.8 891.8
242 847.0 892.0 243 847.2 892.2 244 847.4 892.4
245 847.6 892.6 246 847.8 892.8 247 848.0 893.0
248 848.2 893.2 249 848.4 893.4 250 848.6 893.6
A50016-G5100-B556-04-7620 Id:0900d8058053233b 441


251 848.8 893.8
955 876.2 921.2 956 876.4 921.4 957 876.6 921.6
958 876.8 921.8 959 877.0 922.0 960 877.2 922.2
961 877.4 922.4 962 877.6 922.6 963 877.8 922.8
964 878.0 923.0 965 878.2 923.2 966 878.4 923.4
967 878.6 923.6 968 878.8 923.8 969 879.0 924.0
970 879.2 924.2 971 879.4 924.4 972 879.6 924.6
973 879.8 924.8 974 880.0 925.0 975 880.2 925.2
976 880.4 925.4 977 880.6 925.6 978 880.8 925.8
979 881.0 926.0 980 881.2 926.2 981 881.4 926.4
982 881.6 926.6 983 881.8 926.8 984 882.0 927.0
985 882.2 927.2 986 882.4 927.4 987 882.6 927.6
988 882.8 927.8 989 883.0 928.0 990 883.2 928.2
991 883.4 928.4 992 883.6 928.6 993 883.8 928.8
994 884.0 929.0 995 884.2 929.2 996 884.4 929.4
997 884.6 929.6 998 884.8 929.8 999 885.0 930.0
1000 885.2 930.2 1001 885.4 930.4 1002 885.6 930.6
1003 885.8 930.8 1004 886.0 931.0 1005 886.2 931.2
1006 886.4 931.4 1007 886.6 931.6 1008 886.8 931.8
1009 887.0 932.0 1010 887.2 932.2 1011 887.4 932.4
1012 887.6 932.6 1013 887.8 932.8 1014 888.0 933.0
1015 888.2 933.2 1016 888.4 933.4 1017 888.6 933.6
1018 888.8 933.8 1019 889.0 934.0 1020 889.2 934.2
1021 889.4 934.4 1022 889.6 934.6 1023 889.8 934.8
442 Id:0900d8058053233b A50016-G5100-B556-04-7620

15.10.2 GSM 1800 table

512 1710.2 1805.2 513 1710.4 1805.4 514 1710.6 1805.6
515 1710.8 1805.8 516 1711.0 1806 517 1711.2 1806.2
518 1711.4 1806.4 519 1711.6 1806.6 520 1711.8 1806.8
521 1712.0 1807.0 522 1712.2 1807.2 523 1712.4 1807.4
524 1712.6 1807.6 525 1712.8 1807.8 526 1713.0 1808.0
527 1713.2 1808.2 528 1713.4 1808.4 529 1713.6 1808.6
530 1713.8 1808.8 531 1714.0 1809 532 1714.2 1809.2
533 1714.4 1809.4 534 1714.6 1809.6 535 1714.8 1809.8
536 1715.0 1810.0 537 1715.2 1810.2 538 1715.4 1810.4
539 1715.6 1810.6 540 1715.8 1810.8 541 1716.0 1811.0
542 1716.2 1811.2 543 1716.4 1811.4 544 1716.6 1811.6
545 1716.8 1811.8 546 1717.0 1812 547 1717.2 1812.2
548 1717.4 1812.4 549 1717.6 1812.6 550 1717.8 1812.8
551 1718.0 1813.0 552 1718.2 1813.2 553 1718.4 1813.4
554 1718.6 1813.6 555 1718.8 1813.8 556 1719.0 1814.0
557 1719.2 1814.2 558 1719.4 1814.4 559 1719.6 1814.6
560 1719.8 1814.8 561 1720.0 1815 562 1720.2 1815.2
563 1720.4 1815.4 564 1720.6 1815.6 565 1720.8 1815.8
566 1721.0 1816.0 567 1721.2 1816.2 568 1721.4 1816.4
569 1721.6 1816.6 570 1721.8 1816.8 571 1722.0 1817.0
572 1722.2 1817.2 573 1722.4 1817.4 574 1722.6 1817.6
575 1722.8 1817.8 576 1723.0 1818 577 1723.2 1818.2
578 1723.4 1818.4 579 1723.6 1818.6 580 1723.8 1818.8
581 1724.0 1819.0 582 1724.2 1819.2 583 1724.4 1819.4
584 1724.6 1819.6 585 1724.8 1819.8 586 1725.0 1820.0
587 1725.2 1820.2 588 1725.4 1820.4 589 1725.6 1820.6
590 1725.8 1820.8 591 1726.0 1821.0 592 1726.2 1821.2
593 1726.4 1821.4 594 1726.6 1821.6 595 1726.8 1821.8
596 1727.0 1822.0 597 1727.2 1822.2 598 1727.4 1822.4
599 1727.6 1822.6 600 1727.8 1822.8 601 1728.0 1823.0
602 1728.2 1823.2 603 1728.4 1823.4 604 1728.6 1823.6
605 1728.8 1823.8 606 1729.0 1824.0 607 1729.2 1824.2
Table 75 DCS table
A50016-G5100-B556-04-7620 Id:0900d8058053233b 443


608 1729.4 1824.4 609 1729.6 1824.6 610 1729.8 1824.8
611 1730.0 1825.0 612 1730.2 1825.2 613 1730.4 1825.4
614 1730.6 1825.6 615 1730.8 1825.8 616 1731.0 1826.0
617 1731.2 1826.2 618 1731.4 1826.4 619 1731.6 1826.6
620 1731.8 1826.8 621 1732.0 1827.0 622 1732.2 1827.2
623 1732.4 1827.4 624 1732.6 1827.6 625 1732.8 1827.8
626 1733.0 1828.0 627 1733.2 1828.2 628 1733.4 1828.4
629 1733.6 1828.6 630 1733.8 1828.8 631 1734.0 1829.0
632 1734.2 1829.2 633 1734.4 1829.4 634 1734.6 1829.6
635 1734.8 1829.8 636 1735.0 1830.0 637 1735.2 1830.2
638 1735.4 1830.4 639 1735.6 1830.6 640 1735.8 1830.8
641 1736.0 1831.0 642 1736.2 1831.2 643 1736.4 1831.4
644 1736.6 1831.6 645 1736.8 1731.8 646 1737.0 1832.0
647 1737.2 1832.2 648 1737.4 1832.4 649 1737.6 1832.6
650 1737.8 1832.8 651 1738.0 1833.0 652 1738.2 1833.2
653 1738.4 1833.4 654 1738.6 1833.6 655 1738.8 1833.8
656 1739.0 1834.0 657 1739.2 1834.2 658 1739.4 1834.4
659 1739.6 1834.6 660 1739.8 1834.8 661 1740.0 1835.0
662 1740.2 1835.2 663 1740.4 1835.4 664 1740.6 1835.6
665 1740.8 1835.8 666 1741.0 1836.0 667 1741.2 1836.2
668 1741.4 1836.4 669 1741.6 1836.6 670 1741.8 1836.8
671 1742.0 1837.0 672 1742.2 1837.2 673 1742.4 1837.4
674 1742.6 1837.6 675 1742.8 1837.8 676 1743.0 1838.0
677 1743.2 1838.2 678 1743.4 1838.4 679 1743.6 1838.6
680 1743.8 1838.8 681 1744.0 1839.0 682 1744.2 1839.2
683 1744.4 1839.4 684 1744.6 1839.6 685 1744.8 1839.8
686 1745.0 1840.0 687 1745.2 1840.2 688 1745.4 1840.4
689 1745.6 1840.6 690 1745.8 1840.8 691 1746.0 1841.0
692 1746.2 1841.2 693 1746.4 1841.4 694 1746.6 1841.6
695 1746.8 1841.8 696 1747.0 1842.0 697 1747.2 1842.2
698 1747.4 1842.4 699 1747.6 1842.6 700 1747.8 1842.8
701 1748.0 1843.0 702 1748.2 1843.2 703 1748.4 1843.4
704 1748.6 1843.6 705 1748.8 1843.8 706 1749.0 1844.0
Table 75 DCS table (Cont.)
444 Id:0900d8058053233b A50016-G5100-B556-04-7620


707 1749.2 1844.2 708 1749.4 1844.4 709 1749.6 1844.6
710 1749.8 1844.8 711 1750.0 1845.0 712 1750.2 1845.2
713 1750.4 1845.4 714 1750.6 1845.6 715 1750.8 1845.8
716 1751.0 1846.0 717 1751.2 1846.2 718 1751.4 1846.4
719 1751.6 1846.6 720 1751.8 1846.8 721 1752.0 1847.0
722 1752.2 1847.2 723 1752.4 1847.4 724 1752.6 1847.6
725 1752.8 1847.8 726 1753.0 1848.0 727 1753.2 1848.2
728 1753.4 1848.4 729 1753.6 1848.6 730 1753.8 1848.8
731 1754.0 1849.0 732 1754.2 1849.2 733 1754.4 1849.4
734 1754.6 1849.6 735 1754.8 1849.8 736 1755.0 1850.0
737 1755.2 1850.2 738 1755.4 1850.4 739 1755.6 1850.6
740 1755.8 1850.8 741 1756.0 1851.0 742 1756.2 1851.2
743 1756.4 1851.4 744 1756.6 1851.6 745 1756.8 1851.8
746 1757.0 1852.0 747 1757.2 1852.2 748 1757.4 1852.4
749 1757.6 1852.6 750 1757.8 1852.8 751 1758.0 1853.0
752 1758.2 1853.2 753 1758.4 1853.4 754 1758.6 1853.6
755 1758.8 1853.8 756 1759.0 1854.0 757 1759.2 1854.2
758 1759.4 1854.4 759 1759.6 1854.6 760 1759.8 1854.8
761 1760.0 1855.0 762 1760.2 1855.2 763 1760.4 1855.4
764 1760.6 1855.6 765 1760.8 1855.8 766 1761.0 1856.0
767 1761.2 1856.2 768 1761.4 1856.4 769 1761.6 1856.6
770 1761.8 1856.8 771 1762.0 1857.0 772 1762.2 1857.2
773 1762.4 1857.4 774 1762.6 1857.6 775 1762.8 1857.8
776 1763.0 1858.0 777 1763.2 1858.2 778 1763.4 1858.4
779 1763.6 1858.6 780 1763.8 1858.8 781 1764.0 1859.0
782 1764.2 1859.2 783 1764.4 1859.4 784 1764.6 1859.6
785 1764.8 1859.8 786 1765.0 1860.0 787 1765.2 1860.2
788 1765.4 1860.4 789 1765.6 1860.6 790 1765.8 1860.8
791 1766.0 1861.0 792 1766.2 1861.2 793 1766.4 1861.4
794 1766.6 1861.6 795 1766.8 1861.8 796 1767.0 1862.0
797 1767.2 1862.2 798 1767.4 1862.4 799 1767.6 1862.6
800 1767.8 1862.8 801 1768.0 1863.0 802 1768.2 1863.2
803 1768.4 1863.4 804 1768.6 1863.6 805 1768.8 1863.8
A50016-G5100-B556-04-7620 Id:0900d8058053233b 445


806 1769.0 1864.0 807 1769.2 1864.2 808 1769.4 1864.4
809 1769.6 1864.6 810 1769.8 1864.8 811 1770.0 1865.0
812 1770.2 1865.2 813 1770.4 1865.4 814 1770.6 1865.6
815 1770.8 1865.8 816 1771.0 1866.0 817 1771.2 1866.2
818 1771.4 1866.4 819 1771.6 1866.6 820 1771.8 1866.8
821 1772.0 1867.0 822 1772.2 1867.2 823 1772.4 1867.4
824 1772.6 1867.6 825 1772.8 1867.8 826 1773.0 1868.0
827 1773.2 1868.2 828 1773.4 1868.4 829 1773.6 1868.6
830 1773.8 1868.8 831 1774.0 1869.0 832 1774.2 1869.2
833 1774.4 1869.4 834 1774.6 1869.6 835 1774.8 1869.8
836 1775.0 1870.0 837 1775.2 1870.2 838 1775.4 1870.4
839 1775.6 1870.6 840 1775.8 1870.8 841 1776.0 1871.0
842 1776.2 1871.2 843 1776.4 1871.4 844 1776.6 1871.6
845 1776.8 1871.8 846 1777.0 1872.0 847 1777.2 1872.2
848 1777.4 1872.4 849 1777.6 1872.6 850 1777.8 1872.8
851 1778.0 1873.0 852 1778.2 1873.2 853 1778.4 1873.4
854 1778.6 1873.6 855 1778.8 1873.8 856 1779.0 1874.0
857 1779.2 1874.2 858 1779.4 1874.4 859 1779.6 1874.6
860 1779.8 1874.8 861 1780.0 1875.0 862 1780.2 1875.2
863 1780.4 1875.4 864 1780.6 1875.6 865 1780.8 1875.8
866 1781.0 1876.0 867 1781.2 1876.2 868 1781.4 1876.4
869 1781.6 1876.6 870 1781.8 1876.8 871 1782.0 1877.0
872 1782.2 1877.2 873 1782.4 1877.4 874 1782.6 1877.6
875 1782.8 1877.8 876 1783.0 1878.0 877 1783.2 1878.2
878 1783.4 1878.4 879 1783.6 1878.6 880 1783.8 1878.8
881 1784.0 1879.0 882 1784.2 1879.2 883 1784.4 1879.4
884 1784.6 1879.6 885 1784.8 1879.8
446 Id:0900d8058053233b A50016-G5100-B556-04-7620

15.10.3 GSM 1900 table

512 1850.2 1930.2 513 1850.4 1930.4 514 1850.6 1930.6
515 1850.8 1930.8 516 1851.0 1931.0 517 1851.2 1931.2
518 1851.4 1931.4 519 1851.6 1931.6 520 1851.8 1931.8
521 1852.0 1932.0 522 1852.2 1932.2 523 1852.4 1932.4
524 1852.6 1932.6 525 1852.8 1932.8 526 1853.0 1933.0
527 1853.2 1933.2 528 1853.4 1933.4 529 1853.6 1933.6
530 1853.8 1933.8 531 1854.0 1934.0 532 1854.2 1934.2
533 1854.4 1934.4 534 1854.6 1934.6 535 1854.8 1934.8
536 1855.0 1935.0 537 1855.2 1935.2 538 1855.4 1935.4
539 1855.6 1935.6 540 1855.8 1935.8 541 1856.0 1936.0
542 1856.2 1936.2 543 1856.4 1936.4 544 1856.6 1936.6
545 1856.8 1936.8 546 1857.0 1937.0 547 1857.2 1937.2
548 1857.4 1937.4 549 1857.6 1937.6 550 1857.8 1937.8
551 1858.0 1938.0 552 1858.2 1938.2 553 1858.4 1938.4
554 1858.6 1938.6 555 1858.8 1938.8 556 1859.0 1939.0
557 1859.2 1939.2 558 1859.4 1939.4 559 1859.6 1939.6
560 1859.8 1939.8 561 1860.0 1940.0 562 1860.2 1940.2
563 1860.4 1940.4 564 1860.6 1940.6 565 1860.8 1940.8
566 1861.0 1941.0 567 1861.2 1941.2 568 1861.4 1941.4
569 1861.6 1941.6 570 1861.8 1941.8 571 1862.0 1942.0
572 1862.2 1942.2 573 1862.4 1942.4 574 1862.6 1942.6
575 1862.8 1942.8 576 1863.0 1943.0 577 1863.2 1943.2
578 1863.4 1943.4 579 1863.6 1943.6 580 1863.8 1943.8
581 1864.0 1944.0 582 1864.2 1944.2 583 1864.4 1944.4
584 1864.6 1944.6 585 1864.8 1944.8 586 1865.0 1945.0
587 1865.2 1945.2 588 1865.4 1945.4 589 1865.6 1945.6
590 1865.8 1945.8 591 1866.0 1946.0 592 1866.2 1946.2
593 1866.4 1946.4 594 1866.6 1946.6 595 1866.8 1946.8
596 1867.0 1947.0 597 1867.2 1947.2 598 1867.4 1947.4
599 1867.6 1947.6 600 1867.8 1947.8 601 1868.0 1948.0
602 1868.2 1948.2 603 1868.4 1948.4 604 1868.6 1948.6
605 1868.8 1948.8 606 1869.0 1949.0 607 1869.2 1949.2
Table 76 PCS table
A50016-G5100-B556-04-7620 Id:0900d8058053233b 447


608 1869.4 1949.4 609 1869.6 1949.6 610 1869.8 1949.8
611 1870.0 1950.0 612 1870.2 1950.2 613 1870.4 1950.4
614 1870.6 1950.6 615 1870.8 1950.8 616 1871.0 1951.0
617 1871.2 1951.2 618 1871.4 1951.4 619 1871.6 1951.6
620 1871.8 1951.8 621 1872.0 1952.0 622 1872.2 1952.2
623 1872.4 1952.4 624 1872.6 1952.6 625 1872.8 1952.8
626 1873.0 1953.0 627 1873.2 1953.2 628 1873.4 1953.4
629 1873.6 1953.6 630 1873.8 1953.8 631 1874.0 1954.0
632 1874.2 1954.2 633 1874.4 1954.4 634 1874.6 1954.6
635 1874.8 1954.8 636 1875.0 1955.0 637 1875.2 1955.2
638 1875.4 1955.4 639 1875.6 1955.6 640 1875.8 1955.8
641 1876.0 1956.0 642 1876.2 1956.2 643 1876.4 1956.4
644 1876.6 1956.6 645 1876.8 1956.8 646 1877.0 1957.0
647 1877.2 1957.2 648 1877.4 1957.4 649 1877.6 1957.6
650 1877.8 1957.8 651 1878.0 1958.0 652 1878.2 1958.2
653 1878.4 1958.4 654 1878.6 1958.6 655 1878.8 1958.8
656 1879.0 1959.0 657 1879.2 1959.2 658 1879.4 1959.4
659 1879.6 1959.6 660 1879.8 1959.8 661 1880.0 1960.0
662 1880.2 1960.2 663 1880.4 1960.4 664 1880.6 1960.6
665 1880.8 1960.8 666 1881.0 1961.0 667 1881.2 1961.2
668 1881.4 1961.4 669 1881.6 1961.6 670 1881.8 1961.8
671 1882.0 1962.0 672 1882.2 1962.2 673 1882.4 1962.4
674 1882.6 1962.6 675 1882.8 1962.8 676 1883.0 1963.0
677 1883.2 1963.2 678 1883.4 1963.4 679 1883.6 1963.6
680 1883.8 1963.8 681 1884.0 1964.0 682 1884.2 1964.2
683 1884.4 1964.4 684 1884.6 1964.6 685 1884.8 1964.8
686 1885.0 1965.0 687 1885.2 1965.2 688 1885.4 1965.4
689 1885.6 1965.6 690 1885.8 1965.8 691 1886.0 1966.0
692 1886.2 1966.2 693 1886.4 1966.4 694 1886.6 1966.6
695 1886.8 1966.8 696 1887.0 1967.0 697 1887.2 1967.2
698 1887.4 1967.4 699 1887.6 1967.6 700 1887.8 1967.8
701 1888.0 1968.0 702 1888.2 1968.2 703 1888.4 1968.4
704 1888.6 1968.6 705 1888.8 1968.8 706 1889.0 1969.0
Table 76 PCS table (Cont.)
448 Id:0900d8058053233b A50016-G5100-B556-04-7620


707 1889.2 1969.2 708 1889.4 1969.4 709 1889.6 1969.6
710 1889.8 1969.8 711 1890.0 1970.0 712 1890.2 1970.2
713 1890.4 1970.4 714 1890.6 1970.6 715 1890.8 1970.8
716 1891.0 1971.0 717 1891.2 1971.2 718 1891.4 1971.4
719 1891.6 1971.6 720 1891.8 1971.8 721 1892.0 1972.0
722 1892.2 1972.2 723 1892.4 1972.4 724 1892.6 1972.6
725 1892.8 1972.8 726 1893.0 1973.0 727 1893.2 1973.2
728 1893.4 1973.4 729 1893.6 1973.6 730 1893.8 1973.8
731 1894.0 1974.0 732 1894.2 1974.2 733 1894.4 1974.4
734 1894.6 1974.6 735 1894.8 1974.8 736 1895.0 1975.0
737 1895.2 1975.2 738 1895.4 1975.4 739 1895.6 1975.6
740 1895.8 1975.8 741 1896.0 1976.0 742 1896.2 1976.2
743 1896.4 1976.4 744 1896.6 1976.6 745 1896.8 1976.8
746 1897.0 1977.0 747 1897.2 1977.2 748 1897.4 1977.4
749 1897.6 1977.6 750 1897.8 1977.8 751 1898.0 1978.0
752 1898.2 1978.2 753 1898.4 1978.4 754 1898.6 1978.6
755 1898.8 1978.8 756 1899.0 1979.0 757 1899.2 1979.2
758 1899.4 1979.4 759 1899.6 1979.6 760 1899.8 1979.8
761 1900.0 1980.0 762 1900.2 1980.2 763 1900.4 1980.4
764 1900.6 1980.6 765 1900.8 1980.8 766 1901.0 1981.0
767 1901.2 1981.2 768 1901.4 1981.4 769 1901.6 1981.6
770 1901.8 1981.8 771 1902.0 1982.0 772 1902.2 1982.2
773 1902.4 1982.4 774 1902.6 1982.6 775 1902.8 1982.8
776 1903.0 1983.0 777 1903.2 1983.2 778 1903.4 1983.4
779 1903.6 1983.6 780 1903.8 1983.8 781 1904.0 1984.0
782 1904.2 1984.2 783 1904.4 1984.4 784 1904.6 1984.6
785 1904.8 1984.8 786 1905.0 1985.0 787 1905.2 1985.2
788 1905.4 1985.4 789 1905.6 1985.6 790 1905.8 1985.8
791 1906.0 1986.0 792 1906.2 1986.2 793 1906.4 1986.4
794 1906.6 1986.6 795 1906.8 1986.8 796 1907.0 1987.0
797 1907.2 1987.2 798 1907.4 1987.4 799 1907.6 1987.6
800 1907.8 1987.8 801 1908.0 1988.0 802 1908.2 1988.2
803 1908.4 1988.4 804 1908.6 1988.6 805 1908.8 1988.8
A50016-G5100-B556-04-7620 Id:0900d8058053233b 449


806 1909.0 1989.0 807 1909.2 1989.2 808 1909.4 1989.4
809 1909.6 1989.6 810 1909.8 1989.8
450 Id:0900d8058053233b A50016-G5100-B556-04-7620

Index
Numerics call release
2G network sharing 388 excessive distance 357
2G/3G-MSC 358 GPRS 206
8-PSK modulation 97 GSM 192
capacity on demand 250
CBC 154
A CBCH 154
A3 213 cell
A5/3 90 concentric 28
A8 90 dual band 26
active codec set 82 extended 27
adaptive multi-rate (AMR) 75 mixed 27
adaptive power control 276 sleeping 51
adjacent cells 45 standard 26
admission control 252 cell allocation 118
advanced speech call items (ASCI) 129 cell barring 50
allocation retention priority (ARP) 228 cell broadcast center (CBC) 154
AMR 75 cell identifier (CI) 25
antenna hopping 410 cell layers 31
ASCI 129 cell priority 31
authentication center (AuC) 90, 213 cell reselection 370
authentication key Ki 90, 213 from GSM to UMTS 383
authorized networks 395 channel allocation algorithm (CAA) 253
averaging channel coding 69
for handover 304 EGPRS 96
for power control 281 GPRS 94
GSM 72
B channel combinations 57
BA list 48 channel mode adaptation 75
back handover prevention 353 ciphering
bad quality probability 240 A5/1 90
barred access class 50 A5/3 90
barring a cell 50 ciphering key 89
base station color code (BCC) 25 class A / class B mobile station 113
base station identity code (BSIC) 25 classic power control 275
baseband frequency hopping 116 classmark information 215
BCCH allocation list 48 for intersystem handover 359
BCCH recovery 404 client operator 393
block ciphering 90 codec mode adaptation 75
broadcast channels 56 coding schemes (CS1, CS2, CS3 and CS4) 94
BTS power control 274 combined channel (TCH/SD) 59
burst 53 comfort noise insertion (CNI) 92
burst shift 303 common control channels 56
BVCI 26 complementary area 157
compression/decompression handover 325
concatenated PCU frame 96
C concentric cell 28
C1 criterion 370 concentric cell handover 309
C2 criterion 372 connection management 419
C31 criterion 373 contention resolution 197
C32 criterion 374 CS radio channel allocation 234
call re-establishment 194 CS1, CS2, CS3 and CS4 94
A50016-G5100-B556-04-7620 Id:0900d80580539dd9 451

D frequency redefinition 119

data rates frequency reuse 120
EGPRS traffic channels 96 full rate (FR) speech 71
GPRS traffic channels 94 functional object tree 416
GSM (AMR) traffic channels 77
GSM (HR/FR/EFR) traffic channels 72 G
DCS 1800 34 GPRS protocol architecture 433
dedicated control channels 57 GPS positioning 146
dedicated mode 111 group call area (GCA) 129
delayed handover for emergency calls 353 GSM 1800 34
delayed PDCH release 208 GSM 850 35
delayed power control 288 GSM 900 33
derived handover power 290 GSM cell 24
direct TCH assignment 220 GSM protocol architecture 419
directed retry 224
discontinuous transmission (DTX) 92
H
distance (MS-BTS)
calculation 307 half rate (HR) speech 71
distance handover 315 handover
DMA admission control 239 categories 296
downgrading 227 compression/decompression 325
DTM power budget handover 320 concentric cell 309
dual band operation 28 distance 315
dual band standard cell 26 extended cell 308
dual transfer mode (DTM) 112, 210 fast uplink 322
dynamic MAIO allocation 122 forced 323
GSM to UMTS 358, 360
imperative 298
E inter-cell 297
early classmark sending 215 intra-cell 297
Ec/No 359 level 315
effective fractional load 240 measurements 301
emergency call power budget 316
delayed handover 353 priorities 299
ENACC 378 quality 313
energy chip to noise over all 359 SDCCH 298
enhanced full rate (EFR) speech 72 speed sensitive 321
enhanced measurement report 427 traffic 324
enhanced pairing 230 UMTS to GSM 368
enhanced timing advance positioning (E-TA) 147 handover execution 345
excessive distance 357 handover margin
extended band 34 application on the power budget condition 318
extended cell 27 for DTM related handover 341
extended cell handover 308 for level handover 343
extended uplink temporary block flow 208 for quality handover 343
external network assisted cell change (ENACC) 378 for speed sensitive handover 321
for traffic handover 342
F prevention of back handover 354
FACCH handover prevention 353
signal-noise discrimination 307 hierarchical cell structure 31
FACCH message DL retransmission 180 hierarchical paging 169
far area 27 high speed circuit switched data (HSCSD) 74
fast uplink handover 322 hopping sequence number (HSN) 118
frequency band 33 horizontal allocation 244
frequency hopping 116 host operator 393
452 Id:0900d80580539dd9 A50016-G5100-B556-04-7620

HSCSD 74 mobile allocation (MA) 118

hyperframe 55 mobile allocation index offset (MAIO) 118
mobile country code (MCC) 25
I mobile network code (MNC) 25
mobility management 419
idle mode 111
modulation and coding schemes (MCSs) 96
IMSI 394
MS maximum power levels 286
IMSI based handover 393
MS multislot class mask 254
individual subscriber authentication key Ki 90
MS overheating management 261
intelligent selective paging 170
MS power control 274
inter-cell handover 297
mTBF 109
inter-BSC, procedure 349
multiframe 54
intra-BSC, procedure 347
multi-operator BSS 388
interference class 216
multiple temporary block flow (mTBF) 109
interference measurements 216
multiplexing 106
interleaving blocks 70
multiRAT 359
intersystem handover 358
intersystem network architecture 358
intra-cell handover 297 N
procedure 345 NACC 375
narrowband AMR 76
K NCCR 378
near area 27
KASUMI 90
neigbour cell 45
Kc 89, 90
network assisted cell change (NACC) 375
Ki 90, 213
network color code (NCC) 25
network controlled cell reselection (NCCR) 378
L network mode of operation 179
LAPD link 39 network sharing 388
LAPDm 165, 419 normal burst 70
layer 158
LCS 146 O
level handover 315
object tree 416
link access protocol 419
omnicell 24
link adaptation
one phase access (GPRS) 195
(E)GPRS 99
overheating management 261
GSM (AMR) 79
overload control 407
LLC 433
LLC queue 109
location area (LA) 25 P
location area code (LAC) 25 packet broadcast control channel 63
location area identity (LAI) 25 packet common control channels 63
location services (LCSs) 146 packet control unit (PCU) 258
logical channel packet data terminal (PDT) 208
GPRS 62 packet data traffic channel 62
GSM 56 packet dedicated control channels 63
logical link control (LLC) 433 packet flow context (PFC) 228
packet flow indicator 229
M packet flow management 109
packet idle mode 112
MCS jumping 104
packet transfer mode 112
MCS1, MCS2, ..., MCS9 96
paging 167
measurement report 418
paging block 175
measurement result 418
paging coordination 179
micro cell 31
paging delivery rates 172
mixed cell 27
A50016-G5100-B556-04-7620 Id:0900d80580539dd9 453

paging group 175 reselection

paging groups 176 cell 370
path loss criterion 370 RLC acknowledged mode 112
PBCCH/PCCCH multiframe configuration 67 RLC unacknowledged mode 112
PCM encoding 70 RLC/MAC layer 433
PCS 1900 35 round trip delay time 304
PCU 258 routing area code (RACODE) 26
PCU frame routing area colour (RACOL) 26
concatenated 96 routing area identity 25
standard 95 RSCP 359
PDCH reservation 66
PFC scheduler 109 S
physical channel 53
SACCH
power budget handover 316
message repetition 183
power control
messages scheduling 183
adaptive 276
SACCH message 418
at the BTS 274
sampling rate 76
at the MS 274
SAPI 165
basics 270
sector cell 24
classic 275
service groups
power control loop 270
for handover 337
power reduction, TRX 286
for power control 285
preemption 222
service layer list (SLL) 156
primary area 157
SID frames 92
priority level (PL) 222
signal-noise discrimination
protocol architecture
FACCH 307
GPRS 433
RACH 162
GSM 419
signature response 213
public queue 152
silence description (SID) frames 92
site 24
Q sleeping cell 51
quality handover 313 SMS cell broadcast (SMS-CB) 154
quality of service 250 soft blocking 239
queuing 225 speech coding 69
speech frame 69
R speed sensitive handover 321
SRES 213
RACH
standard cell 26
signal-noise discrimination 162
static MAIO allocation 120
RACH message retransmission 165
stealing flag 70
radio block 53, 69
stream ciphering 89
radio burst 53
subscriber 394
radio channel 53
subscriber authentication key Ki 90
radio channels
subscriber group 394
creation and configuration 63
superframe 55
radio link failure 192
synchronization
radio link failure warning 284
inter-site 29
radio resource management
intra-site 29
GPRS 433
synthesizer frequency hopping 117
GSM 419
system information 422
railway GSM 35
RAND 90, 213
reallocation 237 T
received signal code power 359 tail bits 70
re-establishment of a call 194 tandem free operation (TFO) 86
454 Id:0900d80580539dd9 A50016-G5100-B556-04-7620

target cell 45
target cell list
generation 339
sorting 344
TBF 106
TBF establishment 195
TBF scheduler 260
TBF weight 256
TDMA frame 53
TDPC 258
temporary block flow (TBF) 106
temporary flow identity (TFI) 107
temporary overpower 289
TFI 107
timing advance (TA) 304, 307
timing advance positioning 146
timing offset (TO) 304, 307
TLLI 197
traffic handover 324
training sequence (TSC) 70
transcoding 87
transfer delay 252
TRAU frame 69
TRX power reduction 286
TRX reconfiguration 404
two phases access (GPRS) 195
U
umbrella cell 31
uplink incremental redundancy 110
uplink reply 135
uplink state flag (USF) 107
uplink time difference of arrival positioning (U-
TDOA) 147
USF 107
USF granularity 108
V
vertical allocation 244
VGCS 129
VLR 213
voice activity detection (VAD) 92
voice broadcast service (VBS) 134
voice group call service (VGCS) 129
vulnerability 222
W
waiting list management 238
weight 256
wideband AMR 76
wireless priority service (WPS) 151
WPS 151
WPS queue 152
A50016-G5100-B556-04-7620 Id:0900d80580539dd9 455

456 Id:0900d80580539dd9 A50016-G5100-B556-04-7620

Radio Network Management

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Radio Network Management

Uploaded by

Copyright:

Available Formats

GSM/EDGE RAN - BR line

Functional area description

Radio network management

f Important Notice on Product Safety

The same text in German:

Reason for update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1 Introduction to functional area descriptions . . . . . . . . . . . . . . . . . . . . . . 17

2 Overview: Radio network management . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 Cells, frequency bands and transceivers . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Coding and transmission modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.7 Discontinuous transmission and comfort noise insertion . . . . . . . . . . . . 92

6 Frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

8 Signalling and call establishment/release . . . . . . . . . . . . . . . . . . . . . . . 160

8.5.1 Radio link timeout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192

9 Radio channel allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216

10 GPRS radio channel management . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

10.3.7 Attributes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263

11 GSM power control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270

12.10.1 Handover from GSM to UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360

13 Cell changing and cell reselection . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370

14 Special radio network features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388

15.10.3 GSM 1900 table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447

Figure 46 RLC/MAC block coding for CS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

Figure 136 Cell reselection from GSM to UMTS. . . . . . . . . . . . . . . . . . . . . . . . . . . 384

Table 45 Power control threshold attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Reason for update

Issue Date Summary

1 Introduction to functional area descriptions

1.1 Functional area descriptions and related operating

1.2 Scope and content of the functional area descriptions

"Master procedures" describes:

1.3 Symbols used

ESD (Electrostatic Sensitive Device) precautions to be taken

Reference to another procedure/procedure step

Reference to another procedure; return after having finished

Note; important information

Use the LMT to enter commands

Figure 1 Symbols used

2 Overview: Radio network management

Network elements of the radio access network

Figure 2 GSM/EDGE RAN architecture

BSS TRAU MSC/VLR GSM core network

Structure of the manual

– Chap. 12 Handover describes the strategies applied when an active MS with an

Evolution from GSM to GPRS to EDGE

On-site and remote radio network management

Figure 4 Configuration with LMT, RC and OTS

3 Cells, frequency bands and transceivers

3.1 Cells and their addressing

Cells with different shapes and sites

Omnicell Shaped omnicell Sector cell

Figure 5 Omnicells and sector cells

Hexagonal cells Rhomboidal cells

Figure 6 3-cell sites

Adressing cells and BTSs

3.2 Cell types

Dual band standard cell

GSM900/DCS1800 and GSM850/DCS1800 Mhz are supported. Dual band standard

near area far area

Figure 7 Extended cell areas

Figure 8 Concentric cell areas

Parameters and configuration

– The synchronization information carried on SCH is not sent simultaneously.

&2!./&&3 FRAMEX FRAMEX FRAMEX

&2!./&&3 FRAMEX FRAMEX FRAMEX

&2!./&&3 FRAMEX FRAMEX FRAMEX