BPUG Extv12

Wireless Service Provider Solutions
BSS Parameters User Guide

PE/DCL/DD/0036 12.01/EN Standard January 2000
<36> : BSS Parameters User Guide
Wireless Service Provider Solutions

BSS Parameters User Guide
Document number: PE/DCL/DD/0036
Document status: Standard
Document issue: 12.01/EN
Product release: GSM/BSS V12
Date: January 2000
Copyright 19962000 Nortel Matra Cellular and Nortel Networks, All Rights Reserved
Printed in France
NORTEL NETWORKS AND NORTEL MATRA CELLULAR CONFIDENTIAL:
The information contained in this document is the property of Nortel Networks and/or Nortel Matra Cellular. Except as
specifically authorized in writing by Nortel Networks and Nortel Matra Cellular, the holder of this document shall keep
the information contained herein confidential and shall protect same in whole or in part from disclosure and
dissemination to third parties and use for evaluation, operation and maintenance purposes only.
You may not reproduce, represent, or download through any means, the information contained herein in any way or in
any form without prior written consent of Nortel Networks and Nortel Matra Cellular.
The following are trademarks of Nortel Networks Corporation: NORTEL, NORTEL NETWORKS, the NORTEL
NETWORKS corporate logo, the NORTEL Globemark, HOW THE WORLD SHARES IDEAS.
All other brand and product names are trademarks or registred trademarks of their respective holders.
Publication History
PUBLICATION HISTORY
SYSTEM RELEASE : GSM/BSS V12
January 2000
Issue 12.01/EN
Modifications after Review
September 1999
Issue 11.03/EN
April 1999
Issue 11.02/EN
March 1999
Issue 11.01/EN
June 1998
Issue 10.01/EN
March 1998
Issue 09.03/EN
Confidential information may not be copied or disclosed without permission
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page iii

Publication History
January 1998
Issue 09.02/EN
January 1998
Issue 09.01/EN
Page iv PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
Table of contents
ABOUT THIS DOCUMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
PRESENTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
APPLICABILITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
AUDIENCE FOR THIS MANUAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
RELATED DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
Applicable documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
DOCUMENT STRUCTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII
1 CLASSIFICATION OF BSS PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.1 GROUPS OF BSS PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 PROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 PARAMETERS INFORMATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.4 PARAMETERS VERSUS BSS FEATURES AND PROCEDURES . . . . . . . . . . . . . . . . 19
2 ALGORITHMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2 CONVENTIONS & UNITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.1 Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.2 Phase 2 BTS and MS maximum transmitting output powers . . . . . . . . . . . . . . . . . . . . . . 22
2.2.3 GSM Products sensitivity and power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.4 Conversion rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.5 Accuracy related to measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.6 Frequency band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.3 SELECTION, RESELECTION ALGORITHMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
2.3.1 Selection or reselection between cells of current Location Area (Sel_1) . . . . . . . . . . . . 210
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page v

Table of contents
2.3.2 Criteria for reselection towards a cell of a different Location Area (Sel_2) . . . . . . . . . . . 211
2.3.3 C2 additional reselection criterion (for phase 2) (Sel_3) . . . . . . . . . . . . . . . . . . . . . . . . . . 211
2.4 MEASUREMENT PROCESSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
2.4.1 Mp_1: Measurement processing (run by the BTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
2.4.2 Mp_2: Measurement processing in dedicated mode (run by the MS) . . . . . . . . . . . . . . . 218
2.4.3 Missing Downlink Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
2.5 DIRECT TCH ALLOCATION & HANDOVER ALGORITHMS . . . . . . . . . . . . . . . . . . . . . 226
2.5.1 General formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
2.5.2 Direct TCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227
2.5.3 Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
2.5.4 HandOver decision priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
2.5.5 Directed Retry Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
2.5.6 Concentric/Dualcoupling/Dualband cell Handover (Ho_3) . . . . . . . . . . . . . . . . . . . . . . . . 232
2.5.7 Rescue Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
2.5.8 Power Budget Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
2.5.9 Handover for traffic reasons (from V12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
2.5.10 Handover decision according to adjacent cell priorities and load (from V12) . . . . . . . . 240
2.5.11 Automatic cell tiering (from V12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
2.5.12 Microcellular Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
2.5.13 Forced Handover (Ho_10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
2.5.14 Early HandOver Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
2.5.15 Maximum RxLev for Power Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
2.5.16 Presynchronized HO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
2.5.17 Radio channel allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
2.5.18 Define eligible neighbor cells for intercell handover (except directed retry) (Ho_11) . . 253
Page vi PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
Table of contents
2.5.19 Handover to 2nd best candidate when return to old channel (Ho_12) . . . . . . . . . . . . . . 254
2.5.20 Protection against RunHO=1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
2.5.21 General protection against HO pingpong (from V12) . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
2.6 HANDOVER ALGORITHMS ON THE MOBILE SIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
2.7 POWER CONTROL ALGORITHMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
2.7.1 Power control performed by the BTS (Step by step) (Pc_1) . . . . . . . . . . . . . . . . . . . . . . . 259
2.7.2 One shot power control (Pc_2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260
2.7.3 Fast power control at TCH assignment (Pc_3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
2.7.4 Power control on mobile side (Pc_4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262
2.8 TCH ALLOCATION MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
2.8.1 TCH Allocation and Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
2.8.2 Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
2.8.3 Barring of access class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
2.8.4 Radio link failure process (run by the MS) (Rlfms) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
2.8.5 Radio link failure process (run by the BTS) (Rlfbs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
2.8.6 Call reestablishment procedure (Cr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
2.8.7 Call Clearing Process (run by BTS) (Cc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
2.8.8 Interference Management (BTS and BSC) (If) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
2.8.9 DTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
2.9 PCH AND RACH CHANNEL CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
2.9.1 Paging command Process (Pag) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
2.9.2 Paging command repetition process (run by BTS) (Pag_rep) . . . . . . . . . . . . . . . . . . . . . 293
2.9.3 Request access command process (RA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
2.9.4 Request access command repetition process (RA_rep) . . . . . . . . . . . . . . . . . . . . . . . . . . 294
2.10 FREQUENCY HOPPING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
2.10.1 Frequency hopping principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page vii

Table of contents
2.10.2 Main benefits of frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
2.10.3 Synthesised frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
2.10.4 Baseband Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 299
2.11 BSC OVERLOAD MANAGEMENT MECHANISMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2102
2.11.1 Mechanism up to V.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2102
2.11.2 Mechanism defined from V12 on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2109
2.12 CABINET OUTPUT POWER SETTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2115
2.12.1 Cabinet power description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2115
2.12.2 Pr computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2116
2.12.3 Ps computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2118
2.13 DUAL BAND HANDLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2121
2.13.1 Multiband mobile station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2121
2.13.2 Impact on existing procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2121
2.14 CPU/BIFP LOAD SHARING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125
2.14.1 Feature principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125
2.14.2 Customer/service provider benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2125
2.15 EXTENDED CCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2126
2.15.1 Customer/service provider benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2126
2.15.2 Feature functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2126
2.15.3 Counters used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2127
2.16 PCM ERROR CORRECTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2128
2.16.1 Feature principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2128
2.16.2 Feature benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2129
2.16.3 Parameters and counters associated with this feature . . . . . . . . . . . . . . . . . . . . . . . . . . . 2129
2.17 UPLINK MAPPING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2130
2.17.1 Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2130
2.17.2 Main benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2133
Page viii PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
Table of contents
3 ALGORITHM PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 CELL SELECTION AND RESELECTION PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . 33
3.3 RADIO LINK FAILURE PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 SIGNAL QUALITY AVERAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
3.5 SIGNAL STRENGTH AVERAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
3.6 NEIGHBOR CELL AVERAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320
3.7 DISTANCE AVERAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
3.8 HANDOVER (GLOBAL) PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324
3.9 INTRACELL HANDOVER PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
3.10 INTERCELL HANDOVER THRESHOLDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
3.11 HANDOVER FOR MICROCELLULAR NETWORK PARAMETERS . . . . . . . . . . . . . . . 354
3.12 DISTANCE MANAGEMENT PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
3.13 POWER CONTROL PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
3.14 TCH ALLOCATION MANAGEMENT PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
3.15 DIRECTED RETRY HANDOVER PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
3.16 CONCENTRIC CELLS PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
3.17 INTERFERENCE LEVEL PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
3.18 RADIO RESOURCES CONTROL AT CELL LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3102
3.19 BSS TIMERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3104
3.20 PAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3113
3.21 FREQUENCY HOPPING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3118
3.22 BSC LOAD MANAGEMENT PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3124
3.23 DUAL BAND PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3126
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page ix

Table of contents
3.24 DTX PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3129
3.25 MISCELLANEOUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3130
3.26 PCM ERROR CORRECTION PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3133
3.27 UPLINK MAPPING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3134
3.28 CELL TIERING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3136
4 ENGINEERING ISSUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 HOW TO OPTIMIZE POWER CONTROL USE? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 ONESHOT POWER CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 MINIMUM TIME BETWEEN HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.4 DIRECTED RETRY HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.1 Directed Retry benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.5 CONCENTRIC CELLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
4.6 IMPACT OF DTX ON AVERAGING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
4.7 BEST NEIGHBOR CELLS STABILITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424
4.8 TCH ALLOCATION GENERAL RULES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425
4.9 GENERAL RF RULES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
4.10 DIFFERENCE BETWEEN UPLINK AND DOWNLINK LEVELS . . . . . . . . . . . . . . . . . . . 427
4.11 EFFECTS OF NOOFMULTIFRAMESBETWEENPAGING ON MOBILE BATTERIES AND

RESELECTION REACTIVITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
4.12 EFFECTS OF SMSCB USE ON NOOFBLOCKSFOR ACCESSGRANT . . . . . . . . . 431
4.13 IMPACT OF THE AVERAGING ON THE HANDOVERS . . . . . . . . . . . . . . . . . . . . . . . . . 434
4.13.1 Global statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434
4.13.2 Study of reactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
4.13.3 Ping pong vs Reactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438
4.14 IMPACT OF CALL REESTABLISMENT ON THE NETWORK . . . . . . . . . . . . . . . . . . . 439
4.14.1 Impact on capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
Page x PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
Table of contents
4.14.2 Impact on call drops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 439
4.15 FREQUENCY SPACING BETWEEN TWO TRXS OF THE SAME AREA . . . . . . . . . . 441
4.15.1 No frequency hopping case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 441
4.15.2 Frequency hopping case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
4.15.3 Summary for the frequency spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
4.16 LINK BUDGET (LB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 443
4.17 MINIMUM COUPLING LOSS (MCL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
4.18 GENERAL RULES FOR SYNTHESISED FREQUENCY HOPPING . . . . . . . . . . . . . . . 449
4.18.1 Nortel choice between Baseband and Synthesised Frequency hopping . . . . . . . . . . . . 449
4.18.2 Fractional frequency load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452
4.18.3 Maximum TRX configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 453
4.18.4 SFH parameter setting for 1:1 pattern: strategy 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
4.18.5 SFH parameter setting for 1:3 pattern: Strategy 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
4.19 BSC BOARDS MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
4.19.1 SICD boards management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 466
4.19.2 BSCB boards management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 469
4.20 DUAL BAND NETWORKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
4.20.1 How to favour a frequency band? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 470
4.20.2 How not to favour a frequency band? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473
4.21 MICROCELL BENEFITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
4.21.1 Microcell benefits according to cell radius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
4.21.2 Microcell benefits in terms of Quality Of Service (QOS) : . . . . . . . . . . . . . . . . . . . . . . . . . 475
4.22 SETUP PRINCIPLES OF A NEIGHBORING LIST AND A BCC PLAN . . . . . . . . . . . . 476
4.22.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
4.22.2 4/12 reuses pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page xi

Table of contents
4.22.3 1:3 and 1:1 Fractional reuse pattern specific case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 480
4.22.4 HandOver list versus Reselection list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
4.22.5 Setup principles of a BSIC plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 482
4.23 STREET CORNER ENIRONMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
4.23.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 484
4.23.2 Case A: Mobile moving straight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485
4.23.3 Case B: Mobile turning at the cross road . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 486
4.24 BTS SENSITIVITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
4.24.1 Definition of Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 488
4.24.2 Static and Dynamic Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
4.24.3 Typical / Guaranteed Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 489
4.24.4 Space diversity gains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
4.24.5 Crosspolarization antenna use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
4.25 SDCCH DIMENSIONING AND TDMA MODELS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
4.25.1 SDCCH Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 494
4.25.2 SDCCH distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496
4.25.3 TDMA Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497
4.25.4 PCM Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
4.26 ENGINEERING GUIDELINES FOR EXCEPTIONAL EVENTS . . . . . . . . . . . . . . . . . . . 499
4.26.1 BSS: Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 499
4.26.2 BSS: Suggestions for parameters to be modified for the special event . . . . . . . . . . . . . 4101
4.26.3 NSS level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4102
4.27 ENGINEERING LIMITS WITH BSC OVERLOAD CONTROL MECHANISM . . . . . . . . 4106
4.27.1 What does the CPU Engineering limit mean ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4107
4.27.2 What does the CPU Call Processing limit mean ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4107
Page xii PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
Table of contents
4.28 POWER CONTROL COMPENSATION IN INTERZONE HANDOVER . . . . . . . . . . . . . 4110
4.28.1 Dualband cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4110
4.28.2 Concentric cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4114
4.28.3 Dualcoupling cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4114
4.29 CELL TIERING GAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4116
4.29.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4116
4.29.2 Simulations results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4116
4.29.3 Gain estimation based on terrain data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4118
4.29.4 Capacity gain estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4119
4.29.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4121
5 APPENDIX A: MAIN EXCHANGE PROCEDURES AT BSC LEVEL . . . . 51
5.1 PROC_1: ESTABLISHMENT PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.2 PROC_2: CHANNEL MODE PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.3 PROC_3: DEDICATED CHANNEL ASSIGNMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.4 PROC_4: INTRACELL HANDOVER PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.5 PROC_5: INTRABSS HANDOVER PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.6 PROC_6: INTERBSS HANDOVER PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.7 PROC_7: RESOURCE RELEASE PROCEDURE (EXAMPLE) . . . . . . . . . . . . . . . . . . . 57
5.8 PROC_8: SACCH DEACTIVATION PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.9 CASE OF MOBILE TERMINATING CALLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.10 CASE OF MOBILEINITIATING CALLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 510
6 ERLANG TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1
7 ABBREVIATIONS & DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.1 ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
7.2 DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page xiii

List of figures
FIGURE 21 MICROCELLULAR TYPE A HO ALGORITHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
FIGURE 22 CASE OF PHASE 1 MOBILES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
FIGURE 23 CASE OF PHASE 2 MOBILES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295
FIGURE 24 BASE BAND FREQUENCY HOPPING MECHANISM . . . . . . . . . . . . . . . . . . . . . . 2100
FIGURE 25 POWER IN CABINET DESCRIPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2115
FIGURE 41 MICROMICRO HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
FIGURE 42 EXAMPLE OF A CROSSROAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
FIGURE 43 PROBLEM OF FIELD VARIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
FIGURE 44 MICROMACRO HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
FIGURE 45 MACROMACRO HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
FIGURE 46 OMNIDIRECTIONAL SITES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414
FIGURE 47 TRISECTORIAL DIRECTIONAL SITES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
FIGURE 48 COLLISION BETWEEN PAGING AND SMSCB IF

NOOFBLOCKSFORACCESSGRANT = 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
FIGURE 49 EXAMPLE OF AGCH AND CBCH COLLISION WITH

NOOFBLOCKSFORACCESSGRANT = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
FIGURE 410 REPARTITION OF THE HO FOR EACH SET OF PARAMETERS . . . . . . . . . . . . 435
FIGURE 411 SIMULATION FOR A MS WITH A 1 KM/H SPEED CDF: CUMULATIVE

DISTRIBUTION FUNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451
FIGURE 412 MEAN CPU OCCUPANCY BEHAVIOUR FOR ANY GIVEN BOARD OF THE
BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4106
Page xiv PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
List of tables
TABLE 21 TIMER RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 296
TABLE 22 PR VS BSTXPWRMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2116
TABLE 23 BSTXPWRMAX VS BTS TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2118
TABLE 24 S8000 OUTDOOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2120
TABLE 25 S8000 INDOOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2120
TABLE 41 CPU ENGINEERING LIMIT VALUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4107
TABLE 42 CPU CALL PROCESSING LIMIT VALUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4108
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page xv

List of tables
PAGE INTENTIONALLY LEFT BLANK
Page xvi PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
About this document
ABOUT THIS DOCUMENT
PRESENTATION
This document describes BSS GSM and Nortel algorithms and parameters from an
engineering point of view.
This document is written by Nortel BSS experts and contains extensive Nortel BSS
parameters setting knowhow. Informations coming from experiments, studies,
simulations are also related in the document.
APPLICABILITY
This version is compliant with the V12 BSS GSM release.
AUDIENCE FOR THIS MANUAL

All persons who have to deal with BSS GSM and Nortel algorithms and parameters
at an engineering point of view.
RELATED DOCUMENTS
Applicable documents
[A1] GSM Recommendations
Reference documents
Approved External NMC documents:
[E1] PE/SYS/DD/0065 Configuration parameters for BSS

[E2] PE/DCL/DD/07 BSS Operating Principles Vol 7 Section #4
[E3] PE/DCL/DD/00 BSS Product Documentation Overview
DOCUMENT STRUCTURE
In Chapter 1, BSS algorithm parameters are presented in alphabetic order according
to their group. Process and related objects are also provided.
Chapter 2 describes the GSM Nortel BSS algorithms and recommends ways to use
them efficiently.
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page xvii

About this document
All BSS parameters used in the algorithms are described in Chapter 3. For each
parameter, a recommended value and a default value are given. Engineering rules
explain how to select the parameter value.
In Chapter 4, engineering issues resulting from studies on parameter setting and on
products, simulations and experiments are developped.
Chapter 5 gives the main exchange procedures at BSC level.
In Chapter 6, an index of BSS parameters helps users to locate rapidly the
parameters description in Chapter 3.
In Chapter 7, the signification of all the abbrevations used in this document and
some keydefinitions are explained.
Page xviii PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
Classification of BSS parameters
1 CLASSIFICATION OF BSS PARAMETERS

1.1 GROUPS OF BSS PARAMETERS
BSS parameters in this document are classified in groups. A group corresponds to
a feature. For instance the handover microcellular algorithm is governed by a set
of parameters that form the micro_HO group. The following groups are defined:
BSC_load_mgt: parameters related to BSC load management
BSS_timers: parameters related to BSS timers
Concent_HO: parameters related to HO in Concentric cells
Dist_ave: parameters related to distance averaging
Dist_mgt: parameters related to distance management
DRetry_HO: parameters related to directed Retry HandOver
Dual_band: parameters related to dual band
Freq_Hop: parameters related to frequency hopping
Global_HO: parameters related to HandOver (Global)
inter_HO: parameters related to inter cell HandOver
Interf_lev.: parameters related to Interference level
intra_HO: parameters related to intra cell HandOver
Lev_ave: parameters related to signal strength averaging
micro_HO: parameters related to HandOver for microcellular network
Nei_ave: parameters related to neighbor cell averaging
Pwr_Ctrl: parameters related to Power control
Paging: parameters related to paging channels
Qual_ave: parameters related to signal quality averaging
RR_Ctrl: parameters related to radio resources control at cell level
Res_alloc: parameters related to resource allocation
Rlink_fail: parameters related to Radio link failure
Selection: parameters related to cell selection or reselection
Cell_Tiering: parameters related to Automated Cell Tiering
Traffic_HO: parameters related to handover for traffic reasons
Data_Trsf: parameters related to data transfer
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page 11

1.2 PROCESS
Several groups can belong to a same process. The various process or subprocesses
for all parameters are listed below:
Sel: Selection process
Pc: Power control process
Pag: Paging process
Ho: HO decision process
Cc: Call clearing process
Mp: Measurement process
If: Interference level management process
Rlf: Radio link failure process
All: Ressources allocation process
Furthermore, one process can be distributed among the different subsystems of the
GSM system.
Page 12 PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
1.3 PARAMETERS INFORMATIONS

The following table gives the relation ship between the objects of the OMCR as
they are described in [E1] and the former classification with Groups and algorithms.
Parameters From Object Group Process

name version MS BSS MSC
accesClassCongestion V9 bts Res_alloc Sel
adjacentCellUmbrellaRef V9 bts DRetry_HO Ho
allocPriorityTable V7 bts Res_alloc All
allocPriorityThreshold V7 bts Res_alloc All
allocPriorityTimers V7 bts Res_alloc All
allocWaitThreshold V7 bts Res_alloc All
allOtherCasesPriority V7 bts Res_alloc All
answerPagingPriority V7 bts Res_alloc All
assignRequestPriority V7 bts Res_alloc All
Attenuation V9 btsSiteManager Pwr_Hop
averagingPeriod V7 handOverControl Interf_lev If
baseColorCode V7 bts
biZonePowerOffset V12 adjacentCellHandover,
handOverControl
bscHopReconfUse V8 bsc Frq_Hop
bscMSAccessClassBarringFunction V9 bsc Res_alloc All
bscQueueingOption V7 signallingPoint Res_alloc All
bsMsmtProcessingMode V7 bts Pwr_Ctrl
bsPowerControl V7 powerControl Pwr_Ctrl Pc
bssSccpConEst V7 signaling Point
bssMapT1 V7 bsc BSS_timers
bssMapTchoke V7 bsc Global_HO
bsTxPwrMax V7 powerControl Pwr_Ctrl Pc
bts time between HO configuration V9 + V12 bts Global_HO Ho
btsHopReconfRestart V8 bts Freq_Hop
btslsHopping V7 bts Freq_Hop
btsMSAccessClassBarringFunction V9 bts Res_alloc All
btsTresholdHopReconf V8 bts Freq_Hop


callClearing V7 bts Selection Cc
callReestablishment V7 bts Rlink_fail Rlf Rlf Rlf
callReestablishmentPriority V7 bts Res_alloc All
cellAllocation V7 bts Freq_Hop
cellBarQualify V8 bts Res_alloc
cellBarred V7 bts Res_alloc
cellDeletionCount V7 bts Nei_ave Ho
cellDtxDownLink V7 bts
cellReselInd V8 bts Selection Sel
cellReselectHysteresis V7 bts Selection Sel
cellReselectOffset V8 bts Selection Sel
cellType V7 bts micro_HO Ho
cellType V7 adjacentCellHandOver micro _HO Ho
channelType V7 channel Res_alloc
concentAlgoIntMsRange V9 handOverControl Concent_HO Ho
concentAlgoExtMsRange V9 handOverControl Concent_HO Ho
concentAlgoIntRxLev V9 handOverControl Concent_HO Ho
concentAlgoExtRxLev V9 handOverControl Concent_HO Ho
Concentric cell V9 + V12 bts Concent_HO
configRef V8 btsSiteManager
CpueNumber V12 btsSiteManager BSC_load_mgt
data mode 14.4 kbit/s V11 transcoder board Data_trf
data non transparent mode V11 signaling Point, bts Data_trf
data transparent mode V11 signaling Point, bts Data_trf
delayBetweenRetrans V8 bts Paging Pag
directedRetryAlgo V9 adjacentCellHandOver DRetry_HO Ho
directedRetryModeUsed V9 bts DRetry_HO Ho
directedRetryPrio V12 bts DRetry_HO Ho
distHreqt V7 handOverControl Dist_ave Mp
distWtsList V7 handOverControl Dist_ave Mp
dtxMode V7 bts
early classmark sending V10 bts
emergencyCallPriority V7 bts Res_alloc All
extendedCell V9 bts Dist_mgt
forced handover algo V9 adjacentCellHandOver Global_HO Ho
fhsRef V7 channel Freq_Hop
HandOver from signalling channel V7 handOverControl Global_HO Ho
HOSecondBestCellConfiguration V9 bsc Global_HO Ho
hoMargin V7 adjacentCellHandOver Global_HO Ho
hoMarginBeg V11 bts Global_HO Ho

4119001036

hoMarginTrafficOffset V12 adjacentCellHandover Traffic_HO Ho
hoMarginDist V8 adjacentCellHandOver Global_HO Ho
hoMarginRxLev V8 adjacentCellHandOver Global_HO Ho
hoMarginRxQual V8 adjacentCellHandOver Global_HO Ho
hoMarginTiering V12 handOverControl Cell_Tiering
hoPingpongCombination V12 adjacentCellHandover Global_HO Ho
hoPingpongTimeRejection V12 adjacentCellHandover Global_HO Ho
hoTraffic V12 bts, bsc Traffic_HO Ho
HoppingSequenceNumber V7 frequencyHoppingSystem Freq_Hop
incomingHandOver V7 handOverControl
interBscDirectedRetry V9 bsc DRetry_HO Ho
interBscDirectedRetryFromCell V9 bts DRetry_HO Ho
interCellHOExtPriority V7 bts Res_alloc All
interCellHOIntPriority V7 bts Res_alloc All
intraCellQueueing V8 bts intra_HO Ho
interferer cancel algo usage V10 bts
intraBscDirectedRetry V9 bsc DRetry_HO Ho
interferenceType V12 adjacentCellHandover Cell_Tiering
intraBscDirectedRetryFromCell V9 bts DRetry_HO Ho
intraCell V7 + V12 handOverControl intra_HO Ho
intraCellHOIntPriority V7 bts Res_alloc All
intraCellSDCCH V8 handOverControl intra_HO Ho
lRxLevDLH V7 handOverControl inter_HO Ho
lRxLevDLP V7 powerControl Pwr_Ctrl Pc
lRxLevULH V7 handOverControl inter_HO Ho
lRxLevULP V7 powerControl Pwr_Ctrl Pc
lRxQualDLH V7 handOverControl Global_HO Ho
lRxQualDLP V7 powerControl Pwr_Ctrl Pc
lRxQualULH V7 handOverControl Global_HO Ho
lRxQualULP V7 powerControl Pwr_Ctrl Pc
LapdTerminalNumber V7 lapdLink BSC_load_mgt
maio V7 channel Freq_Hop
maxNumberRetransmission V8 bts Paging Pag
measurementProcAlgo V12 bts
microCellCaptureTimer V8 adjacentCellHandOver micro_HO Ho
microCellStability V8 adjacentCellHandOver micro_HO Ho
microCellStability V8 bts micro_HO Ho
minNbOfTDMA V7 bts Res_alloc
missDistWt V7 handOverControl Dist_ave Cc,Mp
missRxLevWt V7 handOverControl Lev_ave Ho,Mp


missRxQualWt V7 handOverControl Qual_ave Ho,Mp
mobileAllocation V7 frequencyHoppingSystem Freq_Hop
modeModifyMandatory V9 bsc DRetry_HO Ho
msBtsDistanceInterCell V7 handOverControl Global_HO Ho
msRangeMax V7 handOverControl Dist_mgt Ho
msTxPwrMax V7 bts Global_HO Ho
msTxPwrMaxCCH V7 bts Selection Sel
msTxPwrMax2ndBand V12 bts Pwr_ctrl Pc
msTxPwrMaxCell V7 adjacentCellHandOver Global_HO Ho
multi band reporting V10 bts Dual_band
nbOfRepeat V8 bts Paging Pag
new power control algorithm V9 + V12 powerControl Pwr_Ctrl Pc
noOfBlocksForAccessGrant V7 bts Paging Pag
noOfMultiframesBetweenPaging V7 bts Paging Pag
notAllowedAccessClasses V7 bts Res_alloc Sel
numberOfSlotsSpreadTrans V7 bts Paging Pag
numberOfTCHFreeBeforeCongestion V9 bts Res_alloc Sel
numberOfTCHFreeToEndCongestion V9 bts Res_alloc Sel
numberOfTCHQueuedBeforeCongestion V9 bts Res_alloc Sel
numberOfTCHQueuedToEndCongestion V9 bts Res_alloc Sel
numberofPwciSamples V12 handOverControl Cell_Tiering
offsetLoad V12 adjacentCellHandover
offsetPriority V12 adjacentCellHandover
otherServicesPriority V7 bts Res_alloc All
pagingOnCell V9 bts Paging Pag
penaltyTime V8 bts Selection Sel
pcmErrorCorrection V12 bts
powerBudgetInterCell V7 handOverControl Global_HO Ho
powerControl V7 powerControl Pwr_Ctrl Pc
powerIControlIndicator V7 bts
powerIncrStepSize V7 powerControl Pwr_Ctrl Pc
powerRedStepSize V7 powerControl Pwr_Ctrl Pc
preSynchroTimingAdvance V10 adjacentCellHandOver Dist_mgt
priority V7 transceiver Res_alloc
processorLoadSupConf V8 + V12 bsc BSC_load_ngt
pwciHreqave V12 handOverControl Cell_Tiering
radChanSellIntThreshold V8 handOverControl Interf If
radioLinkTimeOut V7 bts Rlink_fail Rlf
radResSupBusyTimer V8 bsc RR_ctrl
radResSupervision V8 bts RR_ctrl

4119001036

radResSupFreeTimer V8 bsc RR_ctrl
retransDuration V8 bts Paging Pag
rlf1 V8 bts Rlink_fail Rlf
rndAccTimAdvThreshold V8 bts Dist_ngt
runCallClear V7 bts Dist_mgt Cc, Mp
runHandOver V7 bts Global_HO Ho, Mp
runPwrControl V7 bts Pwr_Ctrl Pc, Mp
rxLevAccessMin V7 bts Selection Sel
rxLevDLIH V7 handOverControl intra_HO Ho
rxLevDLPBGT V11 adjacentCellHandOver Global_HO Ho
rxLevHreqave V7 handOverControl Lev_ave Mp
rxLevHreqaveBeg V11 handOverControl Nei_ave Mp
rxLevHreqt V7 handOverControl Lev_ave Mp
rxLevMinCell V7 adjacentCellHandOver Global_HO Ho
rxLevNCellHreqaveBeg V11 handOverControl Global_HO
rxLevULIH V7 handOverControl intra_HO Ho
rxLevWtsList V7 handOverControl Lev_ave Mp
rxNCellHreqave V7 handOverControl Nei_ave Mp
rxQualHreqAve V7 handOverControl Qual_ave Mp
rxQualHreqt V7 handOverControl Qual_ave Mp
rxQualWtsList V7 handOverControl Qual_ave Mp
rxQualDLIH V12 handOverControl Intra_HO Ho
rxQualULIH V12 handOverControl Intra_HO Ho
SiteGsmFctList V7 btsSiteManager
standardIndicator AdjC V10 + V12 adjacentCellHandOver Dual_band
standardIndicator AdjC V10 + V12 adjacentCellReselection Dual_band
synchronized V7 adjacentCellHandhOver Global_HO
SpeechMode V8 bts
selfTuningObs V12 handOverControl Cell_Tiering
smallToLargeZoneHOPriority V9 handOverControl Res_alloc Ho
smsCB V7 bts
t3101 V9 bts Timer
t3103 V9 bts Timer
t3107 V9 bts Timer
t3109 V9 bts Timer
t3111 V9 bts Timer
t3122 V9 bts Timer
temporaryOffset V8 bts Selection Sel


thresholdInterference V7 handOverControl Interf_lev If
timerPeriodicUpdateMS V7 bts Timer
timeBetweenHOConfiguration V9 + V12 bsc Global_HO Ho
uplinkMappingProcessingMode V12 bsc Um Um
uplinkMappingChannelNumber V12 bts Um Um
uplinkMappingFreq V12 bts Um Um
uplinkMappingMeasurement- V12 bts Um Um
Mode
uplinkPowerControl V8 powerControl Pwr_Ctrl Pc
uRxLevDLP V7 powerControl Pwr_Ctrl Pc
uRxLevULP V7 powerControl Pwr_Ctrl Pc
uRxQualDLP V7 powerControl Pwr_Ctrl Pc
uRxQualULP V7 powerControl Pwr_Ctrl Pc
zoneTxPwrMaxReduction V9 transceiverZone Concent_HO Ho
zone frequency hopping V9 transceiverZone
zone frequency threshold V9 transceiverZone

4119001036
1.4 PARAMETERS VERSUS BSS FEATURES AND

PROCEDURES
B.1.1 Level averaging
Attribute Object
rxLevHreqave handOverControl
rxLevHreqt handOverControl
rxLevWtsList handOverControl
missRxLevWt handOverControl
rxLevHreqaveBeg handOverControl
B.1.2 Quality averaging
Attribute Object
rxQualHreqave handOverControl
rxQualHreqt handOverControl
rxQualWtsList handOverControl
missRxQualWt handOverControl
B.1.3 Distance averaging
Attribute Object
distHreqt handOverControl
distWtsList handOverControl
missDistWt handOverControl
B.1.4 Cell Eligibility
Attribute Object
rxLevMinCell adjacentCellHandOver
rxNCellHreqave handOverControl
cellDeletionCount bts
rxLevHreqave handOverControl
missRxLevWt handOverControl
msTxPwrMaxCell adjacentCellHandOver
msTxPwrMax bts
HOSecondBestCellConfiguration bsc
rxNCellHreqaveBeg handOverControl

B.1.5 Radio Link Failure
Attribute Object
radioLinkTimeOut bts
rlf1 bts
rlf2 bts
rlf3 bts
t3111 bts
t3109 bts
B.1.6 Interference management
Attribute Object
averagingPeriod handoverControl
thresholdInterference handoverControl
radChanSelIntThreshold handoverControl
B.1.7 PCH and RACH control parameters
Attribute Object
delayBetweenRetrans bts
maxNumberRetransmission bts
nbOfRepeat bts
noOfBlocksForAccessGrant bts
noOfMultiframesBetweenPaging bts
numberOfSlotsSpreadTrans bts
pagingOnCell bts
retransDuration bts
t3122 bts
B.2.1 Enhanced Full Rate encoding
Attribute Object
speechMode signallingPoint
speechMode bts
multipleVocoder bsc
version transcoder
algorithmUsed transcoderBoard
B.2.2 Concentric cell
Attribute Object
concentric cell bts

4119001036
concent AlgoExtMsRange handOverControl

concent AlgoExtRxLev handOverControl
concent AlgoIntMsRange handOverControl
concent AlgoIntRxLev handOverControl
zone Tx power max reduction transceiverZone
transceiverEquipmentClass transceiverEquipment
zone frequency hopping transceiverZone
zone frequency threshold transceiverZone
small to large zone HO Priority handOverControl
transceiver zone ref transceiver
runHandover bts
RELATED FEATURES:
B.1.1. : Level averaging parameters
B.1.3. : Distance averaging parameters
B.1.6. : Interference management.
B.2.3 Extended cell
Attribute Object
extended cell bts
rndAccTimAdvThreshold bts
msRangeMax handOverControl
callClearing bts
channelType channel
B.2.4 Queueing and priority management
Attribute Object
allocPriorityTable bts
allocPriorityTimers bts
allocPriorityThreshold bts
allocWaitThreshold bts
allOtherCasesPriority bts
answerPagingPriority bts
assignRequestPriority bts
bscQueueingOption signallingPoint
callReestablishmentPriority bts
emergencyCallPriority bts

Attribute Object
interCellHOExtPriority bts
interCellHOIntPriority bts
intraCellHOIntPriority bts
otherServicesPriority bts
small to large zone HO Priority handOverControl
directedRetryPriority bts
intraCellQueuing bts
B.2.5 SMSCB
Attribute Object
smsCB bts
noOfBlocksForAccessGrant bts
channelType channel
B.2.6 Frequency Hopping
Attribute Object
btsIsHopping bts
hoppingSequenceNumber frequencyHoppingSystem
maio channel
siteGsmFctList btsSiteManager
cellAllocation bts
mobileAllocation frequencyHoppingSystem
fhsRef channel
configRef btsSiteManager
bscHopReconfUse bsc
btsHopReconfRestart bts
btsThresholdHopReconf bts
zone frequency hopping transceiverZone
zone frequency threshold transceiverZone

4119001036
B.2.7 Selection / Reselection (idle mode)
Attribute Object
cellBarQualify bts
cellBarred bts
rxLevAccessMin bts
msTxPwrMaxCCH adjacentCellHandOver
cellReselInd bts
cellReselectHysteresis bts
cellReselectOffset bts
temporaryOffset bts
penaltyTime bts
rndAccTimAdvThreshold bts
B.2.8 Dynamic barring of access class
Attribute Object
bscMsAccessClassBarringFunction bsc
btsMsAccessClassBarringFunction bts
accessClassCongestion bts
numberOfTCHFreeBeforeCongestion bts
numberOfTCHFreeToEndCongestion bts
numberOfTCHQueuedBeforeCongestion bts
numberOfTCHQueuedToEndCongestion bts
notAllowedAccessClasses bts
emergencyRestricted bts
B.2.9 DTX
Attribute Object Remark

dtxMode bts Uplink
cellDtxDowlink bts Downlink

B.2.10 Uplink Power control

uplinkPowerControl powerControl flag
new power control algorithm bts
powerIncrStepSize powerControl step by step algorithm
only
powerRedStepSize powerControl step by step algorithm
only
runPowerControl bts
lRxQualULP powerControl
uRxQualULP powerControl step by step algorithm
only
lRxLevULP powerControl
uRxLevULP powerControl step by step algorithm
only
msTxPwrMax bts
msTxPwrMax2ndBand bts
RELATED FEATURES:
B.1.2. : Quality averaging parameters
B.2.11 Downlink Power control

bsPowerControl powerControl flag
new power control algorithm bts
powerIncrStepSize powerControl step by step algorithm
only
powerRedStepSize powerControl step by step algorithm
only
runPwrControl bts
lRxQualDLP powerControl
uRxQualDLP powerControl step by step algorithm
only
lRxLevDLP powerControl
uRxLevDLP powerControl step by step algorithm
only

4119001036
RELATED FEATURES:
B.2.12 Directed retry handover

interBscDirectedRetry bsc
intraBscDirectedRetry bsc
interBscDirectedRetryFromCell bts
intraBscDirectedRetryFromCell bts
modeModifyMandatory bsc
directedRetryModeUsed bts
msTxPwrMaxCell adjacentCellHandOver bts mode
msTxPwrMax bts bts mode
directedRetryAlgo adjacentCellHandOver bts mode
adjacent cell umbrella ref bts bsc mode
directedRetryPrio bts
RELATED FEATURES:
B.2.4. : Queueing parameters
B.1.6.: Interference management
B.2.13 Uplink intracell handover
Attribute Object
intraCell handOverControl
intraCellSDCCH handOverControl
runHandOver bts
rxLevULIH handOverControl
lrxQualULH (before V12) handOverControl
rxQualULIH (V12) handOverControl

RELATED FEATURES:
B.2.14 Downlink intracell handover
Attribute Object
intraCell handOverControl
intraCellSDCCH handOverControl
runHandOver bts
rxLevDLIH handOverControl
lrxQualDLH (before V12) handOverControl
rxQualDLIH (V12) handOverControl
RELATED FEATURES:
B.2.15 Intercell handover on bad uplink quality criterion

HandOver from signalling channel handOverControl
runHandOver bts
lrxQualULH handOverControl Threshold
hoMarginRxQual adjacentCellHandOver Eligibility
RELATED FEATURES:
B.1.4. : cell eligibility parameters
B.1.6. : Interference management parameters
B.2.16 Intercell handover on bad downlink quality criterion

runHandOver bts
lrxQualDLH handOverControl Threshold
hoMarginRxQual adjacentCellHandOver Eligibility

4119001036
RELATED FEATURES:
B.2.17 Intercell handover on bad uplink level criterion

runHandOver bts
lrxLevDLH handOverControl Threshold
hoMarginRxLev adjacentCellHandOver Eligibility
RELATED FEATURES:
B.2.18 Intercell handover on bad downlink level criterion

runHandOver bts
lrxLevULH handOverControl Threshold
hoMarginRxLev adjacentCellHandOver Eligibility
RELATED FEATURES:
B.2.19 Intercell handover on power budget criterion

powerBudgetInterCell handOverControl flag
runHandOver bts
hoMargin adjacentCellHandOver
rxLevDLPBGT adjacentCellHandOver

RELATED FEATURES:
B.2.20 Microcellular algorithm
Attribute Object
runHandOver bts
cellType bts
cellType adjacentCellHandOver
microCellCaptureTimer adjacentCellHandOver
microCellStability adjacentCellHandOver
rxNCellHreqave handOverControl
RELATED FEATURES:
B.2.21 Intercell handover on distance criterion

msBtsDistanceInterCell handOverControl flag
runHandOver bts
hoMarginDist adjacentCellHandOver
RELATED FEATURES:
B.1.4. : cell eligibil.ity parameters
B.2.22 Handover for traffic reasons (V12)
Attribute Object
hoTraffic bsc
hoTraffic bts
hoMarginTrafficOffset adjacentCellHandover

4119001036
B.2.23 Handover decision according to adjacent cell (V12)
Attribute Object
offsetLoad adjacentCellHandover
offsetPriority adjacentCellHandover
B.2.24 General protection against HO PingPong (V12)
Attribute Object
HOPingpongTimeRejection adjacentCellHandover
HOPingpongCombination adjacentCellHandover
timeBetweenHOConfiguration bsc
bts time Between HO Configuration bts
B.2.25 Call clearing
Attribute Object
runCallClear bts
callClearing bts
RELATED FEATURES:
B.2.26 Frequency Band favouring
Attribute Object
early classmark sending bts
multiband reporting bts
cellBarred bts
cellBarQualify bts
hoMargin adjacentCellHandOver
hoMarginDist adjacentCellHandOver
hoMarginRxQual adjacentCellHandOver
hoMarginRxLev adjacentCellHandOver
B.2.27 Minimum Time between Handover (before V12)
Attribute Object
timeBetweenHOConfiguration bsc
bts time between HO configuration bts

B.2.28 Radio resource control at cell level
Attribute Object
radResSupervision bts
radResSupBusyTimer bsc
radResSupFreeTimer bsc
B.2.29 Presynchronised Handover
Attribute Object
synchronised adjacentCellHandOver
preSynchroTimingAdvance adjacentCellHandOver
B.2.30 Interferer cancellation
Attribute Object
interferer cancel algo usage bts
B.2.31 Early HO decision
Attribute Object
HoMarginBeg bts
RxLevHReqAveBeg handOverControl
RxLevNCellHReqAveBeg handOverControl
B.2.32 Maximum RxLev for PBGT
Attribute Object
rxLevDLPBGT adjacentCellHandOver
B.2.33 Uplink Mapping (V12)
Attribute Object
uplinkMappingProcessingMode bsc
uplinkMappingMeasurementMode bts
uplinkMappingFreq bts
uplinkMappingChannelNumber bts

4119001036
B.2.34 Cell Tiering (V12)
Attribute Object
interferferType adjacentCellHandover
intraCell handoverControl
measProcAlgorithm bts
NbLargeReuseDataChannels handoverControl
hoMarginTiering handoverControl
pwciHreqave handoverControl
numberOfPwciSamples handoverControl
selfTuningObs handoverControl


4119001036
Algorithms
2 ALGORITHMS
2.1 INTRODUCTION
This chapter describes major BSS GSM algorithms using OMCR algorithm
parameters, both on the BTS and the MS side.
2.2 CONVENTIONS & UNITS

In this chapter, the following abbreviations are used:
RXQUAL_DL Weighted average for downlink signal quality
(measurements made by the MS)
RXQUAL_UL Weighted average for uplink signal quality (measurements
made by the BTS)
RXLEV_DL Weighted average for downlink signal strength
(measurements made by the MS)
RXLEV_UL Weighted average for uplink signal strength
(measurements made by the BTS)
MS_BS_Dist Weighted average of MS distance from BTS (timing
advance used by the MS)
RXLEV_NCELL(n) Arithmetic average for signal strength on neighbor cell
(reported by the MS)
2.2.1 Units
Thresholds on signal quality are given in Rxqual values. Samples measurements
are also reported in Rxqual values. When internal calculations are performed,
Rxqual values are converted into bit error rates (BER) using mean values and
compared to thresholds which are also converted into bit error rate.
Up to the V8 BSS release, Rxqual thresholds are converted into a mean bit error rate.
From the V9 BSS release, the comparison is done with the upper or the lower limit
of the BER range.

Algorithms
RXQUAL Bit Error Rate

Value
From V9 Up to V8
Lower limit Upper limit Mean value
0 t 0.2 % 0.14%
1 w0.2% t0.4% 0.28%
2 w0.4% t0.8% 0.57%
3 w0.8% t1.6% 1.13%
4 w1.6% t3.2% 2.26%
5 w3.2% t6.4% 4.53%
6 w6.4% t12.8 % 9.05%
7 w12.8% 18.10%
Signal strength thresholds are given in dBm (from 110 dBm to 47 dBm).
Signal strength measurements reported by the mobiles and the BTS are given in the
rxlev format (from 0 to 63).
The average signal strength measurement values, which are compared to the rxlev
thresholds, are the integer part of the average result.
2.2.2 Phase 2 BTS and MS maximum transmitting output powers

Mobile Phase 2 maximum transmitting output power:

Tolerance for
condition

GSM 900 GSM 1800 / GSM 1900 Normal Extreme
CLASS 1: restricted MS CLASS 1: 1W 30 dBm 2 dB 2.5 dB

Phase 1
CLASS 2: 8W 39 dBm CLASS 2: 0.25W 24 dBm 2 dB 2.5 dB

CLASS 3: 5W 37 dBm CLASS 3: 4W 36 dBm 2 dB 2.5 dB
CLASS 4: 2W 33 dBm 2 dB 2.5 dB

CLASS 5: 0.8W 29dBm 2 dB 2.5 dB


4119001036
Algorithms

Base station Phase 2 maximum transmitting output powers:

Tolerance for
condition

GSM 900
GSM 1800 / GSM 1900 Normal Extreme

CLASS 1: [320 640[ W [55 58[ dBm CLASS 1: [20 40[ W [43 46[ dBm 2 dB
2 dB
2.5 dB
2.5 dB

CLASS 2: [160 320[ W [52 55[ dBm CLASS 2: [10 20[ W [40 43[ dBm

CLASS 3: [80 160[ W [49 52[ dBm CLASS 3: [5 10[ W [37 40[ dBm 2 dB 2.5 dB

CLASS 4: [40 80[W

CLASS 5: [20 40[ W
[46 49[ dBm
[43 46[dBm
CLASS 4: [2.5 5[ W [34 37[ dBm 2 dB
2 dB
2.5 dB
2.5 dB

CLASS 6: [10 20[ W [40 43[ dBm 2 dB 2.5 dB
2 dB 2.5 dB

CLASS 7: [5 10[ W [37 40[ dBm
2 dB 2.5 dB
CLASS 8: [2.5 5[ W [34 37[ dBm
Settings will be provided to allow output power to be reduced from its maximum
level to at least six steps of nominally 2 dB with an accuracy of 1 dB to allow a
fine adjustment of the coverage by the network operator. In addition, the actual
absolute output power at each static RF power step (N) shall be 2*N dB below the
absolute output power at static RF power step 0 with a tolerance of 3 dB under
normal conditions and 4dB under extreme conditions. The static RF power step
0 will be the actual output power according to the TRX power class.
2.2.3 GSM Products sensitivity and power
2.2.3.1 MS sensitivity
Considering GSM 05.05 figures applicable from December 1998, the following MS
sensitivity has to be taken into account depending on frequency band.
MS sensitivity
GSM 900 GSM 1800 GSM 1900
104 dBm 102 dBm 102 dBm
Nevertheless, the MS seems to have usually better sensitivity than these figures.

Algorithms
2.2.3.2 DRX based products sensitivity and power
GSM 900: DRX based products sensitivity and power
BTS S8000 Outdoor / S2000 H S2000 L

Indoor
Power amplifier 44.8 dBm (30 W) 43.8 dBm (24 W) 35.6 dBm (3.6 W)
+/ 0.5 dB +/ 1 dB at +/ 1 dB at BTS
antenna feeder
Duplexor loss 1 dBm

(guaranded)
H2D loss 5 dBm

(guaranded)
H4D loss 8.5 dBm

(guaranded)
Cavity + Duplexor Not scheduled
RX Sensitivity 108 dBm/110 dBm* 109 dBm 104 dBm
Expected space 5 dBm** 5 dBm** 3 dBm with

diversity gain at integrated antennas
sensitivity level
Global 113 dBm/115 dBm

performances of
the receiving
system, including
space diversity
* with enhanced coverage option

** Crosspolar diversity gain is 1 dB less

4119001036
Algorithms
BTS S8000 Outdoor / S2000 H S2000 L

Indoor
Power amplifier 44.8 dBm (30 W) 43.8 dBm (24 W) 35.6 dBm (3.6 W)
+/ 0.5 dB +/ 1 dB at +/ 1 dB at BTS
antenna feeder
Duplexor loss 1.2 dBm
H2D loss 5 dBm
H4D loss 8.5 dBm
RX Sensitivity 108 dBm/110 dBm* 109.5 dBm 104 dBm
Expected space 5 dBm** 5 dBm** 3 dBm with

diversity gain at integrated antennas
sensitivity level

performances of
the receiving
system, including
space diversity

Single feeder version (scheduled)
(No diversity)
Unit output power: 29.5 dBm (0.9 W) +/ 1 dB at BTS feeder connector RX
Senditivity guaranteed at BTS feeder connector (including duplexor and combiner
loss): 104 dBm.

Algorithms
BTS S8000 Outdoor only S2000 H S2000 L
Power amplifier 44.8 dBm (30 W) +/ 43.8 dBm (24 W) 35.6 dBm (3.6 W)
0.5 dB +/ 1 dB at +/ 1 dB at BTS
antenna feeder
Duplexor loss 1.2 dB
H2D loss 5 dB
H4D loss 8.5 dB
RX Sensitivity 108 dBm/110 dBm* 109 dBm 104 dBm
Expected diversity 5 dB** 5 dB** 3 dB with

gain integrated
antennas

performances

2.2.3.3 TRX based products sensitivity and power

GSM 900: TRX based products sensitivity and power
BTS S4000 Indoor Stand S4000 Indoor S4000 S2000 E

(1 sect/cab) Compact Outdoor In/Out
(3 sec / 2 cab)
Power 44.8 dBm / 45.4 dBm 45.4 dBm 44 dBm 44 dBm

amplifier hybrid /cavity 0/+3 dB 0/+3 dB
Duplexor 1 dB 1 dB 1 dB
loss
H2D loss 5 dB 5 dB 5 dB
Cavity 4.9 dB
Master +
Duplexor
RX 107 dBm 107 dBm 107 dBm 107 dBm

Sensitivity*
Rx diversity 4 dB 4 dB 4 dB 4 dB
gain

4119001036
Algorithms
BTS S4000 Indoor S4000 S2000 E

Outdoor In/Out
Power amplifier 43 dBm / 44 dBm 43 dBm 43 dBm

hybrid /cavity 0/+3 dB 0/+3 dB
Duplexor loss 1 dB 1 dB
H2D 5 dB 5 dB 5 dB
Cavity Master + Duplexor 4.9 dB
RX Sensitivity* 107 dBm 107 dBm 107 dBm
Rx diversity gain 4 dB 4 dB 4 dB
BTS S4000 Outdoor S4000 S2000 E

only Outdoor In/Out
Power amplifier 43 dBm / 44.8 42 dBm 43 dBm

dBm hybrid /cavity +/1.5 dB
Duplexor loss 1.2 dB 1.2 dB 1.2 dB
H2D 5 dB 5 dB
RX Sensitivity* 107 dBm 107 dBm 107 dBm
Rx diversity gain 4 dB 6.5 dB 4 dB
Antenna gain 18 dBi
Balanced EIRP 59.5 dBm

+/ 1.5 dB
2.2.4 Conversion rules
2.2.4.1 Power conversion

The main power conversion rules are provided below.
P (dB) = P (dBW) = 10 log (PW)

P (dBm) = P (dBmW) = 10 log (PmW)
P (dB) = P (dBm) 30
E (dBV / m) = P (dBm) + 20 log FHz + 77,2

Algorithms
2.2.4.2 Distance timing advance conversion
The table below gives the conversion rules of the timing advance versus the
distance.
One bit corresponds to 554 m and the accuracy is 0.25 bit (i.e 138.5 m)
Timing advance Distance (m) Recommendation

accuracy
0 [0..554[ 25 %
1 [554..1108[ 12.5 %
2 [1108..1662[ 6.1 %
3 [1662.. 3.1 %
...
63 [34 902..35456[ 0.4 %
Due to multipath and to MS synchronization accuracy, the gap of timing

advances between two different MS for a given distance can reach 3 bits
(i.e. 1,6 km).
The value of the timing advance has an impact on decision taking for handover and
call clearing. The timing advance is calculated by taking into account all the rays
coming from a same signal.
The timing advance must be used carefully as a handover and call clearing criteria,
especially in a microcellular configuration.
2.2.5 Accuracy related to measurements

The GSM recommendation specifies the absolute and relative accuracy of the MS
and BTS measurements (Rec. GSM 05.08 8.1.2). The table below provides the
GSM absolute accuracy recommendation.
MS and BTS absolute measurement accuracy
from 110 dBm to 70 dBm under normal conditions 4dB

from 110 dBm to 48 dBm under normal conditions 6 dB
from 110 dBm to 48 dBm under extreme conditions 6 dB
The overlap between the different ranges (see above normal condition cases) are
specified in the recommendation.

4119001036
Algorithms
This recommendation is not restrictive and most of the BTS and MS may provide
better results. However, these figures show that the threshold accuracy handover
and power control field strength may be off by a few dB.
The relative accuracy depends on the gap between measurement levels and sensivity
levels. The table below provides the GSM relative accuracy recommendation of a
difference between two measurements lower than 20 dB.
MS and BTS relative measurement accuracy
lower measured level > sensitivity + 14 dB 2dB; + 2 dB
sensitivity + 14 dB> lower measured level > sensitivity + 1 dB 3dB; +2 dB
sensitivity + 1 dB > lower measured level 4 dB; +2 dB
For example, the level difference between two field strengths, which are higher than
the sensivity + 14 dBm, must be within the range of [2 dB to +2 dB].
Output power tolerance must also be considered in the parameters setting because
the parameters bsTxPwrMax and msTxPwrMax are used in the algorithms. For
example, the output power tolerance of the S2000/S2000E BTS is 2.3 dB.
2.2.6

Frequency band

GSM 900 EGSM RGSM GSM 1800 GSM 1900
uplink band (MHz) 890915 880915 876915 17101785 18501910
downlink band (MHz) 935960 925960 921960 18051880 19301990
bandwith (2*W simplex) 2x25 MHz 2x35 MHz 2x39 MHz 2x75 MHz 2x60 MHz
duplex shift ( W duplex) 45 MHz 45 MHz 45 MHz 95 MHz 80 MHz
number of carriers 124 174 194 374 299

Algorithms
2.3 SELECTION, RESELECTION ALGORITHMS

SELECTION PROCEDURE:
The selection process begins with a signal strength measurement averaging on
the whole frequency band lasting approximately three seconds in order to sort
channels according to their strength.
Then, for the most powerful channel, the MS tries to detect the FCH channel,
then decodes the SCH channel, and if the MNC and MCC are not forbidden, it
listens to SYSTEM INFORMATION 1 to 4 to get full information on that cell
and possibly select it depending on the selection criterion.
If one of the steps fails, the next powerful channel is tried and so on.
RESELECTION PROCEDURE:
Reselection criteria are calculated every 5 to 60 seconds period (depending on the
number of cells for which BCCH is in BCCH Allocation and number of
multiframes between paging) because MS must perform at least 5 measurements
on every cell listed in the BCCH Allocation before averaging is allowed.
For phase 1 MS, C1 path loss criterion is used whereas for phase 2 MS, the C2
criterion is used.
GSM Ref: 04.08/10.5.2.4.
Then, for the most powerful channel, the MS attempts to detect the FCH channel,
then decodes the SCH channel, and if the NCC and BCC are not forbidden, it will
listen to SYSTEM INFORMATION 1 to 4 to get full information on that cell and
possibly select it depending on the selection criterion.
2.3.1 Selection or reselection between cells of current Location Area

(Sel_1)
In Phase 1, MS checks that cellBarred flag is not set to barred before sorting
eligible cells.
In Phase 2, MS checks cellBarred and cellBarQualify flags in order to define the
cells access (normal,low,barred).
C1 is the path loss criterion for unbarred cells of allowed PLMN.
To be selected, a cell must have a positive C1:
C1 = RXLEV rxLevAccessMin Max (B,0) >0

with B = msTxPwrMaxCCH P
P = maximum RF output power of the MS
Received levels must be higher than rxlevAccessMin and if a mobile state has a
classmark lower than msTxPwrMaxCCH, it must get closer to the cell to have
access to it.

4119001036
Algorithms
2.3.2 Criteria for reselection towards a cell of a different Location Area

(Sel_2)
This is an additionnal criteria for reselection towards a y cell having a different
Location Area from the current one. A choice must be made between C1 values for
cell having a different Location Area:
C1(x) < C1(y) cellReselectHysteresis
The value used for the parameter cellReselectHysteresis is theone set in the current
serving cell.
2.3.3 C2 additional reselection criterion (for phase 2) (Sel_3)

In Phase 2, the MS checks cell_bar_access and cell_bar_qualify flags in order to
define the cells access (normal,low,barred).
To activate this feature, the cellReselectInd parameter will be set to True.
The C1 criterion did not provide a way of preventing a fast moving mobile station
from reselecting a fugitive cell nor avoiding pingpong reselection. The idea is
to give a cell a tunable access for reselection and to prevent mobiles from reselecting
a cell if that cell is new to the mobile or if it was recently the serving cell:
C2 = C1 + cellReselectOffset
temporaryOffset * H (penaltyTime t)
for penaltyTime 640
C2 = C1 cellReselectOffset
for penaltyTime = 640
where t is a timer started as soon as a cell enters the mobile best cell list:
t = penaltyTime if the new cell in the list is the previous serving cell
t = 0 otherwise
and H(x) is a function:
H(penaltyTime t) = 0 if t w penaltyTime
H(penaltyTime t) = 1 if t < penaltyTime
temporaryOffset is a negative offset.
By adding an offset (cellReselectOffset) it is possible to give different priorities, for
example, to different types of cells in case of a multilayer network or to different
bands when multiband operation is used.

Algorithms
Cell B
Cell A
. Trajectory
C1 (A)
C2 (A)
C1 (B)
Slow MS
C2 (B)
Start of End of
penalty time penalty time
C1 (A)
C2 (A)
Fast MS
C1 (B)
C2 (B)
Start of End of
penalty time penalty time
Priority of access: cellBarred and cellBarQualify parameters.

The parameters are used to give each cell the authorization to be selected or
reselected, and for all of them a priority of access is given.
The selection procedure is mainly concerned by this priority introduction.
Selection:
For the server cell and the neighboring cells, the C1 algorithm is computed. The C2
algorithm is computed only if cell reselection is used (cellReselInd = True).

4119001036
Algorithms
A priority is affected to each eligible cell and is only applied to Phase II MS.
IF cellBarQualify = TRUE THEN the cell priority is low, whatever the
cellBarred value is.
IF cellBarQualify = FALSE AND IF the cell is barred (cellBarred set to barred)
THEN the cell priority is null (the cell can not be reselected in idle mode).
IF cellBarQualify = FALSE AND IF the cell is not barred THEN the priority is
normal.
For a mobile Phase II: if no cell with NORMAL priority is eligible (cell contained
in the eligible list constituted using the C1 algorithm), then the cells with LOW
priority are scanned. So even if a cell is barred, a phase II mobile is able to select
this cell, but it will not be able to perform a call on it.
For a mobile Phase I: it is not possible to reselect a cell that is barred.
cellBarred cellBarQualify Priority
barred false no selection possible
barred true low
not barred false normal
not barred true low
Note: To forbid the access of a cell to a MS, the cellBarred set to not barred
and incoming handover set to disabled, is not sufficient. Care must be
taken with the cellBarQualify that gives the priority.
Reselection:
There is only one kind of priority which is NORMAL.
IF the cell is barred AND IF cellBarQualify is false THEN the reselection is not
authorized.
cellBarred cellBarQualify Priority

barred false no reselection possible
barred true normal
not barred false normal
not barred true normal
Example of application: in a microcellular network, it is possible to give a priority

of access to a microcell.

Algorithms
2.4 MEASUREMENT PROCESSING
2.4.1 Mp_1: Measurement processing (run by the BTS)
Each sample on the uplink side used by the L1M in the average computation is
composed of measurements performed in Watts on several bursts. So the uplink
samples are first computed in Watts before being translated into dBm.
The general idea is to perform arithmetic averages. These averages are stored, and
each time a decision has to be taken, an other average (weightedaverage) is
computed. This weightedaverage is based on a defined number (Hreqt) of
arithmetic averages, which are weighted in order to favor the latest results.
Examples for Hreqave = 8, Hreqt = 1, run xx = 4
L1M V1
For the first version of the L1M (V1) averages are computed every HreqAve
measures. However if a decision must be taken at a time there is no arithmetic
average, an intermediate average must be computed.
Time
Run Decision with Run Decision with Run Decision with

T
Compute Average
T = 480 ms on TCH Compute & Store Compute & Store

T = 470 ms on SDCCH Average Average
SACCH blocks
L1M V2
In the new version of the L1M (V2), the process of averaging has been based on fully
sliding windows.

4119001036
Algorithms
Time
Run Decision with Run Decision with

DT m1 m9
Run Decision with
m5
m1
m2
m3
m4
m9
DT = 480 ms on TCH
DT = 470 ms on SDCCH
SACCH blocks
mi Compute & Store
Averages
Averaging process for quality and level:

xx_Hreqave:
number of measurement results to compute an arithmetic average.
xx_Hreqt:
number of arithmetic averages necessary to compute a weighted average, each one
being associated to xx_WtsList (highest weight for the most recent data).

Algorithms
mis_xx_Wt:
Weight applied to latest arithmetic average if existing or latest received value to
replace a missing downlink measurement. In case there have been no previous
measurements, a default value is used.
For distance, weighted average applies directly to DistHReqt raw figures.
For neighbor cells, only the arithmetic average is computed. Furthermore, for L1M
V2, when 10 SACCH blocks are missing, that cell is no longer considered and
corresponding data is deleted (for L1M V1, it was when CellDeletionCount
measurement reports were missing); for L1M V2, CellDeletionCount is used as an
eligibility criterion.
Arithmetic averaging is performed with xx_Hreqave period whereas weighted
averaging is done before algorithm processing, thus, weighted average is executed
if run_xx is not a multiple of xx_Hreqave.
Example for Hreqave = 3, Hreqt = 2, run xx = 4
L1M V1

2& 1 3& 4 5& 2
1 2
1 2 3 4 5

4119001036
Algorithms
L1M V2

m6 and m3 m10 and m7 m14 and m11
m1 m4 m7 m10 m13
m2 m5 m8 m11 m14
m3 m6 m9 m12
Note: In the L1M V2, the weighted average is done with the latest not overlapped
arithmetic averages.
Note: Reactivity of the L1M V2 has been improved. The measurements done by
the MS and the BTS during the first SACCH block period is proceeded by
the BTS during the second SACCH block period instead of the third
SACCH block period.
Rescaling:
Measurements are stored along with the MS and BS power level (meas_txpwr)
reported in MEAS RESULT, latest power control (MS or BS) is also stored
(ref_txpwr).
For the L1M V1, rescaling is done as follows. When power control is decided,
uplink or downlink values or averages are rescaled to match new power used:
newLev = oldLev + ((ref_txpwr meas_txpwr) * pwr_to_dbm); such anticipation
of the effects of power control on the present measurements has a beneficial impact
on the number of power changes and handovers.
From the L1M V2, rescaling is done at maximum transmission power (txPwrMax).
It means that the values or averages are adjusted as follows: newLev = oldLev +
((txPwrMax meas_txPwr) * pwr_to_dbm). In this way, handovers are better
anticipated.

Algorithms
2.4.2 Mp_2: Measurement processing in dedicated mode (run by the MS)

On the MS side, every sample is composed of measurements performed on several
bursts in dBm. On the uplink side, measurements are performed in Watts. So the
uplink samples are previously computed in Watts before they are translated into
dBm.
Those two different ways of calculation provide samples which are artificially about
2.5 dB higher for the uplink than for the downlink (see Section Engineering issues:
Diffrence between uplink and downlink levels).
While in dedicated mode, the mobile performs signal strength monitoring on
all BCCH allocation carriers, measurements are usually done every frame,
except on idle frames. Averaging is considered valid when five measurements
are available per reporting period.
On the uplink SACCH, the mobile provides RX level and quality on the serving
cell. The number of blocks involved is different depending on whether the
downlink DTX is used. Two sets of values are reported: full and sub. The mobile
also reports its current Timing Advance and TxPower, and whether uplink DTX
is used, as well as the BSIC of the 6 best adjacent cells along with their received
levels.
While in TCH dedicated mode, the idle frame is dedicated to best cell survey :
among strongest carriers from BCCH allocation list, the mobile tries to get FCH
then decodes SCH channels (to get its bsic). A mobile is obliged to maintain
synchronization with at most 6 best cells of permitted PLMN, and confirm it
at least every 10 seconds. If synchronization with a cell is lost, corresponding
information is kept during at least 10 seconds (in case a handover is requested on
that cell).
Every 2 seconds, the most powerful carriers that do not belong to the 6 best ones
are given a try : if synchronization on one of them is impossible or bsic forbidden,
then the cell is discarded. Otherwise the cell enters the 6 best cell list according to
received power.
2.4.3 Missing Downlink Measurements

In case of Air interface problems, its possible to loose some SACCH blocks. Four
rules of substitution are applied to compensate the missing measurements.
Rule 1: If averaged values are available, missing measurements are replaced by the
latest averaged value multiplied by a weighting factor (missXXWt with
XX= RXQUAL or RXLEV or DIST).
Example:
xxHreqave = 4
r = Measurement Report
m = mean

4119001036
Algorithms
L1MV1
missing measurement report

received measurement report
r1 r2 r3 r4 r5 r6 r7 r8
m1 m2
averaging averaging
time r8 = m1 * missXXWt
L1M V2
received measurement report missing measurement report
r1 r2 r3 r4 r5 r6 r7 r8
m1 m5
m2
m3
m4
time
r8 = m4 *missXXWt

Algorithms
Rule 2: If no average value is available, missing measurements are replaced by the

latest measurement value multiplied by a weighting factor (missXXWt with
XX= RXQUAL, RXLEV or Dist).
Example:
xxHreqave = 4
L1MV1
r1 r2 r3 r4 r5 r6 r7 r8
m1 m2
averaging averaging
time r3 = r2 * missXXWt

4119001036
Algorithms
L1MV2
received measurement report missing measurement report
r1 r2 r3 r4 r5 r6 r7 r8
m1 m2
m2
m3
m4
time r3 = r2 * missXXWt
Rule 3: If no measurement value is available, the missing measurement is replaced

by a default value.
Example:
xxHreqave = 4

Algorithms
L1MV1
r1 r2 r3 r4 r5 r6 r7 r8
m1 m2
averaging averaging
time r1 = default value
L1MV2
missing measurement report received measurement report
r1 r2 r3 r4 r5 r6 r7 r8
m1 m2
m2
m3
m4
r1 = default value
time

4119001036
Algorithms
Rule 4:
L1M V1
For neighbouring cells, a missing measurement is not replaced by the latest received
value ; the next received measurement will be used instead ; while not received, the
latest average which has been computed successfully is used in the algorithms ; so
the substitution is retroactive.
Example:
xxHreqave = 4
r1 r2 r3 r4 r5 r6 r7 r8
m1 m2
averaging averaging
For neighboring measurement,

time m2=m1 and after a successful r9, r8=r9
and m2 is recomputed
L1M V2
In the following, the substitution of a missing value is only done when 6
neighbouring cells are reported during the considered period.
From L1M V2 missing measurements for neighboring cells are replaced as follows;
for both cases, inputs are:
Ncell1 no longer belongs to the list of 6 preferred cells at T+1 period,
T, T+1 correspond to measurement periods.

Algorithms
First case:
IF RxLevNCell1(T) min(RxLevNCell(T+1) of the 6 reported cells)
THEN RxLevNCell1(T+1) = RxLevNCell1(T)
RxLevNCell
* NCell 3
* NCell 2
* NCell 3
* NCell 1 * NCell 1
Missing
measurement
T1 T2
RxLevNCell 1(T2) = RxLevNCell3 (T1)

4119001036
Algorithms
Second case:
IF RxLevNCell1(T) > min(RxLevNCell(T+1) of the 6 reported cells)
THEN RxLevNCell1(T+1) = min(RxLevNCell(T+1)) missOffsetdB
missOffset has a fixed value of 3 dB.
Example:
RxLevNCell
* NCell 3
* NCell 2
* NCell 1
* NCell 3
missOffset
* NCell 1
T1 T2
RxLevNCell 1(T2) = RxLevNCell3 (T2) missOffset (3 dB)

Algorithms
2.5 DIRECT TCH ALLOCATION & HANDOVER ALGORITHMS
2.5.1 General formulas
Let us define the expression named EXP1 used for defining eligible cells:
EXP1(n) = rxLevNCell(n) [rxLevMinCell(n) + Max {0, msTxPwrMaxCell(n)
MSTxPwrMaxCell(n)}] where:
rxLevNCell(n): averaged downlink signal strength of the neighbour cell n
rxLevMinCell(n): minimum RXLEV value required for a MS to handover
towards cell n
msTxPwrMaxCell(n): maximum transmission power level the MS is allowed
to use on a traffic channel in the band0 of the neighbour cell n
MSTxPwrMaxCell(n): maximum transmission power capability of the MS
according to the power class of the mobile and according to the band of the band0
of the neighbour cell n
Let us define the expression named EXP2 used for defining suitable cells:
EXP2(n) = PBGT(n) HO_Margin_XX(n) with HO_Margin_XX(n):
HO_MARGIN_LEV(n) for handover due to RXLEV
HO_MARGIN_QUAL(n) for handover due to RXQUAL
HO_MARGIN_DIST(n) for handover due to DISTANCE
HO_MARGIN(n) for handover due to PBGT
Let us define the expression named EXP3 used from V12 (which allows to decide
if the neighbouring cell signal strength is greater than the minimum value of the
signal strength required to elect the band1/inner zone of this neighbouring cell):
EXP3(n) = rxLevNCell(n) [rxLevMinCell(n) + Max {0, msTxPwrMaxCell(n)
MSTxPwrMaxCell(n)} + biZonePowerOffset(n)] where:
biZonePowerOffset(n) (adjacentCellHandOver object): power offset used for
handover towards the inner zone of a multizone cell (dualband, dualcoupling,
concentric) to take into account the difference of transmission power between the
2 zones of the neighbour cell or/and the difference of propagation between the 2
bands (dualband cell) of the neighbour cell; if the adjacent cell is monozone, this
value shall be set to 63.
Note: For the microcell capture or for a directed retry in a microcellular network,
EXP1 and EXP3 do not include the part Max {0, msTxPwrMaxCell(n)
MSTxPwrMaxCell(n)}

4119001036
Algorithms
Let us also recall the general PBGT formula (computed in the band0 because
HO_MARGIN is always specific to the band0):
PBGT(n) = Min(msTxPwrMax,MSTxPwrMax) RXLEV_DL_band0 + rxLevNCell(n)
PWR_C_D Min(msTxPwrMaxCell(n), MSTxPwrMaxCell(n)) where:
msTxPwrMax: maximum transmission power level the MS is allowed to use on
a traffic channel in the band0 of the serving cell
MSTxPwrMax: maximum transmission power capability of the MS according
to the power class of the mobile and according to the band of the band0 of the
serving cell
PWR_C_D: difference between the maximum transmission power
(bsTxPwrMax) to be used by the BTS and the current transmission level of the
BTS resulting from the BS power control procedure
RXLEV_DL/rxLevNCell(n): correspond to the latest arithmetic averages
biZonePowerOffset (handOverControl object): power offset used to calculate a
virtual measure in the band0/outerzone from a real one in the band1/innerzone
(rxLev_band0 = rxLev_band1+biZonePowerOffset) ; this has to be done
because all handover thresholds are defined according to the outerzone/band0.
2.5.2 Direct TCH Allocation

This chapter describes the new features available from V12 and concerns the
dualband cell, the concentric cell and the dualcoupling cell . From V9 to V11, for
a concentric cell, a TCH resource (in the innerzone) could only be allocated after
verification of 2 criteria (downlink RxLev and TA) and after passing through the
outer zone and moreover the outerzone and the innerzone had 2 different
frequencies set . From V12, it is possible to allocate directly a TCH in the innerzone
for call setup or handover and to reuse the same frequency on both zones .
From V12, the dualband cell feature enables to manage GSM900/DCS1800
frequency bands in the same cell ; in a dualband cell, BCCH and SDCCH are only
defined in band0 ; a dualband cell manages up to 128 frequencies and that means
one frequency band manages up to 64 frequencies.
2.5.2.1 Direct TCH allocation at first TCH allocation
From V12, on SDCCH (always in the large zone), when the serving cell is either
a dualband cell or a dualcoupling cell or a concentric cell, the BSC asks if the call
can be directed to the small zone with a Connection state request message.
The small zone (or band1) is eligible when the following conditions are satisfied:
RxLevDL +BS_Pwr_Att > concentAlgoExtRxLev

Algorithms
And (only for concentric cells)

MS_BS_Dist < concentAlgoExtMsRange (timing advance criterion)
where RxLevDL is the arithmetic average computed according to L1M version and
BS_Pwr_Att is the BS power attenuation resulting from the power control.
The timing advance criterion is disabled for a dualcoupling cell since the algorithm
only needs to check that the BS Tx power in the innerzone is sufficient to maintain
the communication. This criterion is also disabled for dualband cells.
Only one TA measurement is done for concentric cells.
For dualband cells, obviously, a test is also performed on the capability of the mobile
to support the band1.
! Caution:
The BSC does not send the inquiry if the call is established on a signalling TCH.
2.5.2.2 Direct TCH allocation on an adjacent cell
This capability (to handover directly in the innerzone/band1 of the adjacent cell) is
inhibited when biZonePowerOffset(n) is set to 63. Otherwise, it is assumed that
the adjacent cell has a small zone (concentric cell or dualband cell or dualcoupling
cell).
The 3 following conditions shall be satisfied: EXP1>0, EXP2>0, EXP3>0 .
For dualband cells, obviously, a test is also performed on the capability of the mobile
to support the band1.
2.5.3 Handovers
Each runHandOver, after L1M initialisation process for handover, the BTS
performs handover decision process based on regular uplink and downlink
measurements on the current cell (level and quality) and neighbouring cells (level
only); the main steps of this process are:
Triggering: the BTS detects that a handover is needed by comparison with
thresholds: LRxLevXLH for alarm on level; LRxQualXLH for alarm on
Quality; msRangeMax for alarm on distance, there is no triggering for
handover on PBGT
Screening (intercell handover only): the BTS determines what are the n best
suitable cells (n=3 until V11 ; n=6 from V12) for the handover (preferred cells
list) and sends them to the BSC in the Handover Indication message; to be in the
preferred cells list, a cell must first be eligible then suitable; the preferred cells
list is an ordered list of suitable cells.

4119001036
Algorithms
eligible cell: EXP1 shall be positive

(The eligible cells list is systematically computed at each runHandOver;
when a cell is eligible, it means that the signal strength on this cell is great
enough)
suitable cell (from V8): EXP2 shall be positive
(the suitable cells list (and then the preferred cells list) is searched if a
handover on quality, strength or distance is necessary or if
powerBudgetInterCell is enabled; this expression allows to decide whether
the excess signal strength for the neighbouring cell is sufficient to prevent
repetitive handovers or not)
If the HO conditions are met for several causes but the list of suitable cells is
empty for the highest priority cause, the BTS tries to establish a suitable cells
list for the next cause .
From V11, a third criterion shall be satisfied to do a handover on PBGT:
RXLEV_DL + PWR_C_D < rxLevDLPBGT(n)
Selecting: the BSC determines THE target cell according to the resource found
after reducing the preferred cells list to a maximum of three elements
Executing: allocation, activation, assignment of the new channel, switching onto
this channel
All the following handovers may be disabled via associated parameters: intracell
handover, handover on distance, handover on PBGT, handover on SDCCH,
Directed Retry, handover for traffic reasons, automatic cell tiering.
2.5.4 HandOver decision priority
For V11, the HO decision priority order (from the highest to the lowest) is:
Microcell algo A, Directed Retry, Interzone DL, Intracell UL, Intracell DL, Signal
Quality UL, Signal Quality DL, Signal Strength UL, Signal Strength DL, Distance,
Power Budget
For V12, the HO decision priority order (from the highest to the lowest) is:
Directed Retry, Microcell algo A, Signal Quality UL, Signal Quality DL, Signal
Strength UL, Signal Strength DL, Distance, Power Budget, Traffic, Intracell UL,
Intracell DL, Interzone (dualband cell/concentric cell/ dualcoupling cell),
Frequency tiering
One reason of these changes concerns the interzone handover when there is no free
channel in the target zone ; in such a case, the handover would be deadlocked with
the V11 order.

Algorithms
The minimum number of periods before decision are:
Version Minimum number of periods before decision

PBGT HO Max(rxLevHreqaveBeg, rxNCellHreqaveBeg, runHO)
rxQual HO Max(rxQualHreqave*rxQualHreqt, rxLevHreqave, rxNCell-
Hreqave, runHO)
rxLev HO Max(rxLevHreqave*rxLevHreqt, rxNCellHreqave, runHO)
intracell HO Max(rxQualHreqave*rxQualHreqt, rxLevHreqave*rxLev-
Hreqt, runHO)
distance HO Max(rxLevHreqave, distHreqt, rxNCellHreqave, runHO)
capture HO Max(rxNCellHreqave, runHO)
interzone HO Max(rxLevHreqave*rxLevHreqt, distHreqt, runHO)
(not dualband)
interzone HO V12> Max(rxLevHreqave*rxLevHreqt, runHO)
(dualband
cell)
traffic HO V12> Max(rxLevHreqave, rxNCellHreqave, runHO)
cell tiering HO V12> Max(pwciHreqave, runHO)
call clearing Max(distHreqt, runCallClear)
enhanced V12> Max(rxLevHreqaveBeg, runPC)
power control

4119001036
Algorithms
2.5.5 Directed Retry Handover
2.5.5.1 Directed Retry Handover: BSC (or local) mode (Ho_1)
After the initial establishment procedure, if the MS is attached to a SDCCH and if

there is no TCH resource available, a directed retry handover is required.
The following parameters enable this feature:
intraBscDirectedRetry
interBscDirectedRetry
intraBscDirectedRetryFromCell
interBscDirectedRetryFromCell
The Queueing feature must be activated.
This mode is enabled by the bts object parameter directedRetryModeUsed set to

bsc. Until V9, bsc mode could only be applied from a micro cell towards a macro
cell (system rule).
One of the adjacent cells is predefined as the one used for directed retry. The
adjacentCellUmbrellaRef parameter gives the position of this cell in the neighbor
list.
! Caution:
In this mode, there is no check of the RF conditions on the predefined target cell
before the directed retry HO occurs: the predefined cell must cover the whole area
of the current cell.
To ensure that the MS is presynchronised with the predefined target cell (MS has
decoded GSM time and the BSIC), the neighbor cell BCCH must be put in the
adjacentCellReselection parameter bCCHFrequency.
It is mandatory to activate the Queueing when the Directed Retry is enabled.
2.5.5.2 Directed Retry Handover: BTS (or distant) mode (Ho_2)
After the establishment procedure if the MS is attached to a SDCCH and if there is

no TCH resource available, a directed retry handover is required.
This mode is enabled by the bts object parameter directedRetryModeUsed set to
bts. It is used, for example in the case of a high traffic cell covered by several
neighbors.

Algorithms
When the BSC receives the Assign Request message from the MSC, the BSC
requests the BTS through a Connection State Request message to return a list of
eligible neighbor cells generated by the following criteria. This list is immediately
sent through a Connection State Acknowledgement message to the BSC. If the list
is empty, the BTS tries to regenerate it later. The MS remains in a queueing phase
until one cell at least verifies the criteria. The BTS sends the BSC a spontaneous
Handover Indication message with the specific cause Directed Retry.
If RxLevNcell(n) > directedRetry(n) + C
where C = Max(0,Pa)
where Pa = msTxPwrMaxCell(n) P
then cell n is candidate for Directed Retry Handover.
If RxLevNcell(m) = Max(RxLevNcell(n)) then
Neighbour Cell m is chosen by the BSC as the target cell for the Directed Retry
Handover.
! Caution:
The Directed Retry criterion is based on only one measurement of RxLevNcell(n)

and not on HREQAVE_NCELL measurements.
In a microcell network, a directed retry HO may handover a call from a macro cell
to a micro cell even if the stability criteria is not fulfilled (microcellular handover
type A). In this environment, to avoid a pingpong HO, one may put a high value
to the adjacentCellHandOver parameter directedRetryAlgo.
It is mandatory to activate the Queueing when the Directed Retry is enabled.
This feature should only be used with one or two DRX maximum.
2.5.6 Concentric/Dualcoupling/Dualband cell Handover (Ho_3)
From V9 to V11, the concentricCell is a flag defining whether the cell is concentric
or not.
From V12, this parameter may have 4 possible values: monozone, concentric,
dualband or dualcoupling ; so, for example, possible handovers are from V12:
intercell intraband HO (band0>band0 or band1>band1)
intercell interband HO (band0>band1 or band1> band0)

4119001036
Algorithms
intracell intraband HO (band0>band0 or band1>band1)

intracell interband HO (band0>band1 or band1>band0)
intercell intrazone HO (large>large or small>small)
intercell interzone HO (small>large or large>small)
intracell interzone HO (small>large or large>small)
many other combinations (example: from a monozone cell band1 towards the
small zone of a concentric cell band0)
! Caution:
The dualband cell feature is only supported by S8000 I/O and ecell (S2000P)
In a dualcoupling cell, the TRXs are not combined with the same type of combiner
and thus have not the same coupling loss resulting in the 2 different coverage areas;
the most powerful TRXs define the large zone. Such cells are managed with the
concentric cell principle.
Let us call hereafter band0 for all the cases outerzone/large zone corresponding
to the zone/band where the transceivers are carrying the common channels and
SDCCH channels .
2.5.6.1 Interzone handover for a dualband cell (from V12)
This case is very close to the interzone HO for a concentric cell except:
the timing advance (distance between the BTS and the MS) is not used
the dualband capability of the mobile is taken into account
During such HOs, the attenuation is kept (as for concentric cells) but the power of
the new TRX may be lower than the originating one and no power compensation
is done . So, for proposing a handover from the large zone (band0) towards the small
zone (band1), the signal has to be high enough to support a little level drop .
So, the conditions to satisfy for HO band0>band1 are:
RxLev_DL+BS_Pwr_Att > concentAlgoExtRxLev and MS supports band1
and the conditions to satisfy for HO band1>band0 is:
RxLev_DL+BS_Pwr_Att < concentAlgoIntRxLev
where BS_Pwr_Att is the BS power attenuation resulting from the power control.
2.5.6.2 Intercell Handover for a dualband cell (from V12)
The conditions to satisfy for HO are:
HO band X > band0 : EXP1>0 and EXP2>0
HO band X > band1 : EXP1>0, EXP2>0 and EXP3>0
with band X corresponding to the current band in the serving cell.

Algorithms
2.5.6.3 Intracell Intraband handover for a dualband cell (from V12)
The conditions to satisfy for HO band0>band0 or HO band1>band1 are the

normal conditions for intracell HOs.
2.5.6.4 Concentric cell / dualcoupling cell intracell handovers
The MS is permitted to migrate from the large zone to the small zone if:
(only for concentric cells) the MS is close to the BTS (Timing Advance used to
estimate the MS to BTS distance) and
if RF conditions are good enough (RxLev downlink).
The transceiverZone object parameter zoneTxPwrMaxReduction value is always

set to 0 for the large zone, and in the range of [1 to 21]dB for the small zone.
The Concentric/Dualcoupling Cell Handover from Large to Small zone is triggered

if:
RxLev_DL + BS_Pwr_Att > concentAlgoExtRxLev

AND (only for concentric cells)
MS_BS_Dist < concentAlgoExtMsRange
where BS_Pwr_Att is the BS power attenuation resulting from the power control.
The MS is forced to migrate from the small zone to the large one if:
(only for concentric cells) the MS is far from the BTS (Timing Advance, used to
estimate the MS to BTS distance) or
if RF conditions are too bad (RxLev downlink).
The Concentric/Dualcoupling Cell Handover from Small to Large zone is triggered
if:
RxLev_DL + BS_Pwr_Att < concentAlgoIntRxLev
OR (only for concentric cells)
MS_BS_Dist > concentAlgoIntMsRange
where BS_Pwr_Att is the BTS power attenuation resulting from the power control
(and taking into account ZoneTxPowerMaxReduction)
Note that an external priority [0...17 ] can be given to the Concentric Cell Handover
from a Small to Large zone, because of the small to large Zone HO priority
parameter (handOverControl object).

4119001036
Algorithms
! Caution:
Until V11:
It is impossible to begin a call (on TCH) in the small zone (after call setup on
SDCCH in the large zone).
No Intercell HO towards another small zone (see following array) is allowed, but
intercell HO from a small zone to any cell is allowed.
HO from cell A to ... cell Bs large zone cell Bs small zone a non concentric
cell
cell As large zone Possible Impossible Possible
cell As small zone Possible Impossible Possible
2.5.7 Rescue Handover
2.5.7.1 Intracell Handover decision for signal quality (Ho_4)
The interferences are generally related to a specific TDMA. When signal quality is
bad but signal strength is sufficient, the BSC allocates another channel in the current
cell.
Condition to be fulfilled is:
(((RXLEV_UL > rxLevULIH) AND (RXQUAL_UL > Threshold_quality_UL))
OR
((RXLEV_DL > rxlevDLIH) AND (RXQUAL_DL > Threshold_quality_DL))
Until V11:
Threshold_quality_UL = lRxqualULH
Threshold_quality_DL = lRxqualDLH
From V12:
Threshold_quality_UL = rxQualULIH
Threshold_quality_DL = rxQualDLIH

Algorithms
! Caution:
Until V11, these RxQual thresholds are shared with handover on quality.
This feature is enabled by intraCell or intraCellSDCCH flags.
From V8 until V11, channels are allocated according to hopping capacity and
interference level ranking.
From V12, in order to avoid the choice of a more interfered channel, channels are
allocated in the 2 low interference pools (hopping and not hopping) ; if no free
channel is detected among these 2 pools and although queuing is allowed, the
intracell HO must not be done ; if queuing is allowed, the request is queued then
satisfied only after reception of suitable interference level on idle channels
(RF_RESOURCE_INDICATION message) ; when TDMA removals leads to
intracell HO, the first free resource is taken whatever its interference level.
The following counters C1081C1082C1083C1134 show, respectively, the
number of intracell handovers requested, executed, succeeded, and failed.
2.5.7.2 Handover condition for leaving a cell on rxqual (Ho_5)

There is no flag to disable this feature but this can be done by assigning thresholds
rxqual maximum value (7). Thresholds should be set in order to ensure good
subjective quality (rxqual 5 with frequency hopping or rxqual 4 without hopping).
This handover is triggered when quality exceeds signal quality thresholds:
(RXQUAL_DL > lRxQualDLH)
OR
(RXQUAL_UL > lRxQualULH)
Counters C1138/2 and C1138/3 sum up the number of handovers on the TCH
required because of loss of uplink and downlink quality respectively.
2.5.7.3 Handover condition for leaving a cell on rxlev (Ho_6)

There is no flag to disable this feature but this can be done by assigning threshold
RxLev minimum value (110 dBm).
This handover is triggered when the signal strength falls below the following
thresholds:
(RXLEV_DL< lRxLevDLH)
OR
(RXLEV_UL < lRxLevULH)
Counters C1138/0 and C1138/1 sum up the number of handovers on the TCH
required because of loss of uplink and downlink signal strength respectively.

4119001036
Algorithms
2.5.7.4 Handover condition for leaving a cell on distance (Ho_7)

This feature is enabled by the msBtsdistanceIntercell flag.
MS_BS_Dist > MsRangeMax
The C1138/4 counter gives the number of handovers on distance.
2.5.8 Power Budget Handover

2.5.8.1 Power budget formula (Ho_8)
If powerBudgetInterCell flag is set (handover on Power Budget is enabled), the
following formula is used to determine handover condition for power budget
reason. This handover is preventive and ensures best allocation of a serving cell for
a given communication. The formula used to determine handover condition for
power budget reason is:
PBGT(n) hoMargin(n) > 0
The counter C1138/5 gives the number of PBGT handovers.
2.5.8.2 Minimum time between Handover (Ho_9)
This feature changes from V12 and is more general (not restricted to outgoing
PBGT handover). The following description concerns versions till V11. For the new
corresponding feature (from V12) named general protection against HO
pingpong, see the description in a following chapter.
This feature is enabled by the bsc object parameter timeBetweenHOConfiguration.
This feature forbids handovers on Power Budget (Ho_6) towards any neighboring
cells during a certain period of time after a successful intercell handover. The timer
starts at the end of a successfull intercell handover and lasts
btsTimeBetweenHOConfiguration (bts object parameter) seconds.
While t < btsTimeBetweenHOConfiguration,
> no handover for Power budget reason.
! Caution:
Other handovers like Ho_1, Ho_2, Ho_3, Ho_4 are authorized.
This feature applies whatever the reason of the successful intercell handover.
2.5.9 Handover for traffic reasons (from V12)

This feature aims to improve the network behaviour when one or several cells are
overloaded by attempting to redirect the most appropriate calls in progress to
neighbour cells from a PBGT handover procedure.
This feature is enabled by the new BSC object parameter hoTraffic and by the new
BTS object parameter hoTraffic.

Algorithms
For each neighboring cell of each cell (adjacentCellHandover object), a new (from
V12) parameter is defined: hoMarginTrafficOffset defines the offset to
(negatively) apply to the hoMargin linked to the power budget when the cell status
becomes overloaded (if 0, the handover for traffic reason is not allowed for this
adjacent cell (case of cell of another manufacturer for example)).
This features relies on the definition of the overload condition ; a cell overload
condition can only be determined by the radio resource allocator when the detection
mechanism is activated ; it is activated as soon as the handover for traffic reasons
feature or the dynamic barring of access class feature is authorized ; this overload
detection mechanism is based on the number of free resources or the number of
queued TCH requests in the cell ; TCH resources reserved for maximum priority
requests are not taken into account ; in a concentric cell, TCH resources of the small
zone are not taken into account (no queuing procedure in the small zone) ; in a
dualband cell, TCH resources of the band1 are not taken into account (no queuing
procedure in the band1) ; no more operator warning is sent at the beginning and the
end of the overload phase.
When the cell status becomes overloaded, a request is done to the L1M to consider
a new ho_margin (hoMarginhoMarginTrafficOffset) ; this request is sent only to
the TRXs which belong to the large zone/band0 (for concentric/dualband cells).
In case of intraBSS handover (for traffic reasons), the BSC checks the target cell
status during the handover selection phase and if overload condition is set, the BSC
will try on the following cell of the list (a handover between the band0 of a serving
cell and the band1 of a target cell is possible if the eligibility of band1 is indicated
in the handover indication message).
In case of interBSS handover (for traffic reasons), the target cell overload status is
also taken into account but a handover between the band0 of a serving cell and the
band1 of a target cell is not possible (due to the present A interface).
It is advised to set the General protection against HO pingpong feature with this
feature in order to overcome the associated risk of pingpong.
The new counters C1138/14 (HO_REQUIRED_TCH_TRAFFIC), C1139/14
(HO_REQUIRED_SDCCH_TRAFFIC), C1714 (OVERLOAD_DURATION) are
added.
! Caution:
This feature is not applicable for S4000/S2000EDCU2 or

S4000/S2000EDCU2/DCU4.
This feature is applicable for all cases where PBGT handover is possible; so,
handover for traffic reasons is not possible between microcell and macrocell.

4119001036
Algorithms
This feature is applicable to concentric/dualband cells but is restricted to the large

zone/band0 since the thresholds used to define the overload conditions concern the
large zone/band0 ; if a handover indication is received by the BSC with a cause set
to traffic reasons and concerns a communication established in the small
zone/band1 of the cell, the message is discarded.
This feature is not applicable to a network which sets all the TCH request priorities
to the maximum priority since the cell is always overloaded whatever are the cell
overload thresholds.
Since the handover for traffic reasons feature uses the PBGT handover procedure,
the powerBudgetInterCell flag shall be set to True (the BSC does not control this
flag to modify the hoMarginTrafficOffset). The BTS never transmits the Handover
for traffic reasons if this flag is not set.
There is no standby chain updating for the cell overload status ; thus, in case of
switchover, the L1M value for ho_margin_traffic_offset is set to 0 and the cell is
no longer overloaded.
About hoMarginTrafficOffset setting:
Typically, when hoMargin is reduced by 1dB, this affects around 12.5% of the
mobiles, assuming that cell overlapping is larger than the hoMargin; roughly:
1dB of power reduction decreases the coverage by 12.5%
2dB of power reduction decreases the coverage by 24%
3dB of power reduction decreases the coverage by 33.8%
This means that if hoMargin is reduced by 1dB, if traffic is evenly distributed within
the cell and if the outer fringe of the considered cell is overlaid by a neighbour cell,
every call has a probability of 0.125 to be handed over to a neighbour cell.
More generally, if p is the probability for a call to be pushed out of the cell, and
if x is the number of TCH, then the traffic gain (to welcome new MS to an
overloaded cell) is x*p .
Configuration hoMargin p = HO probability traffic gain (Erlang)

reduction
O1 1 dB 0.125 0.875
x = 7 TCH 2 dB 0.24 1.68
O2 1 dB 0.125 1.75
x = 14 TCH 2 dB 0.24 3.36

Algorithms
2.5.10 Handover decision according to adjacent cell priorities and load

(from V12)
The objective of this feature is to optimize the traffic distribution both between
layers according to cell priorities and cells of the same layer according to their
overload conditions.
In the selection phase, the BSC places the cells in descending order according to
their priority (new offsetPriority parameter of the adjacentCellHandover object)
and if cells have the same priority, the order given in the handover indication
message is maintained. Then the BSC calculates the following expression (named
EXP4(n) = EXPi(n) [offset_load(n) * state_load(n)] where EXPi(n) = EXP1(n)
for the handover causes capture or directed retry in distant mode or EXPi(n) =
EXP2(n) for other causes ; EXP1 or EXP2 are added in the handover indication
message from V12 ; offset_load is a neighbour cell parameter in dB and state_load
is an overload status parameter ; state_load=1 for an internal BSS neighbor cell
which is overloaded and 0 otherwise) ; the BSC sorts the cells that have the same
priority by decreasing values of EXP4 before reducing the preferred cells list from
six to three.
offset_load(n) corresponds to the new offsetLoad parameter

(adjacentCellHandover object) ; offsetPriority defines the range of the priority
from 1 to 5 (1 is the highest level).
The overload detection relies on the same principle as that described in the
handover for traffic reasons. If the overload detection is not activated, obviously,
the priority is the only criterion which is taken into account.
With such an algorithm, it can be noticed that the priority parameter is an important
criterion in a multilayer network and that the overload situation is an important
criterion in a network where the cells have the same priority.
For multilayer networks, a problem may occur when the higher priority cell (which
captures traffic) becomes consequently overloaded and then induces HOs for traffic
in the other adjacent cells ; this can be awkward when the overlapping area between
the higher priority cell and its adjacent cells is wide ; in such a case, too much traffic
is captured and this prevents from doing new calls in this cell.
In a network where the cells have the same priority, another problem could be
noticed: the overload condition of adjacent cells is not managed in a uniform way
if the adjacent cells do not belong to the same BSC ; the overload condition for cells
belonging to another BSC is not considered and may induce longer handover
procedure if this one is overloaded.

4119001036
Algorithms
2.5.11 Automatic cell tiering (from V12)
The frequency tiering technique aims at decreasing the global interference level in
a fractional reuse pattern network. It relies on simple dynamic resources allocation
strategies that are intended to allocate the worst communications, in terms of
downlink Carrier on Interference ratio (CIR), to the nonhopping frequencies (like
BCCH), (taking advantage of their larger reuse pattern and consequently of their
better resistance to interference) while the best communications are driven by the
hopping frequencies.
To avoid the introduction of new configuration parameters or thresholds required

by such a function, the associated selftuning functionality enables to set tiering
working parameters at their most relevant values, fitting with cell real radio profile
and dynamically adapted to O&M events or radio environment modifications
ensuring that the gains of the tiering strategy are always optimum.
So, the main benefits could be:

a large capacity increase (by dramatically reducing the global level of
interference and by significantly decreasing the global number of dropped calls)
a better network quality (worst communications, typically at the cell boundary,
do no longer corrupt the other communications)
a better uplink/downlink balancing (the uplink interference cancellation gain is
balanced by a significant downlink cell tiering improvement)
The tiering strategy is based on the estimation of the potential worst downlink C/I
called PWCI which is evaluated via the measures done by the MS on the serving
cell (rxLev_DL) and on the BCCH neighboring cells ; the measurements performed
on neighboring cells BCCHs give the level of the cochannel interference that
would be created on a TCH channel by the neighboring cells if they were
transmitting at full power ; the PWCI formula is computed at the TRX level.
PWCI = (RxLev_DL + BS_Att) (i RxLevNcell(i) + k (RxLevNcell(k)ADC))

with all values expressed in dBm or dB ; in fact, the sum of RxLevNcell are
computed by using values expressed in Watts ; the first concerns downlink signal
strengths measured by the MS on BCCH of a cell using the same TCH frequencies
set than the current cell (indicated by the interfererType parameter of the
adjacentCellHandover object) and the second one for cells using different TCH
frequencies set than the current cell (also indicated by the interfererType parameter
of the adjacentCellHandover object) ; ADC is the first adjacent channel protection
factor (which is fixed in the BTS software typically to 18dB) ; the PWCI value is
the same whatever the effective load (this computation is theoretically valid for
reuse patterns from 1x1 up to 1x3).

Algorithms
The PWCI measurements are averaged (for tiering handover decision) with a PWCI
averaging window size defined by hreqAvePwCI parameter ; the raw PwCI values
allow to trace a PWCI distribution curve for defining low and high HO decision
thresholds (called respectively lCirDLH and uCirDLH) ; the number of values
required to trace the PWCI distribution curve may be modified via MMI with the
nbPwCISamples parameter (whereas cell tiering HO thresholds cannot be tuned
via MMI) ; the lCirDLH is defined from the available TCH resources in the non
hopping layer (because these one will be allocated to communications with PWCI).
In order to manage speech and data interworking, the averaged number of TCHs
reserved for data is defined with the NbLargeReuseDataChannels parameter.
Example for a O4 configuration with:
one non hopping TDMA: 1 BCCH + 1 SDCCH/8 + 5 TCH + 1 data channel
3 hopping TDMA: 23 TCH + 1 SDCCH/8
ratio TCHs on the large reuse pattern = 5/28 ~ 18% (the lCirDLH threshold
should then match the PwCI value for 18% worst cases expected in the cell)
Proba(PWCI<x) versus x
cumulative probability
1
0.9
0.8
0.7
0.6
0.5
0.4
0.3
(PWCI < x)
0.2
0.1
0
5 4 3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Tiering threshold : lCirDLH PWCI value
More generally, the ratio used to deduce lCirDLH is:

(Nb TCHs borne by nonhopping TDMA of the large zone NbLargeReuseDataChannels) / (Total
Nb TCHs in the large zone NbLargeReuseDataChannels) ; large zone standing for outerzone
(concentric cell) or band0 (dualband cell) or cell (monozone).
The uCirDLH threshold is then defined from the following expression:

uCirDLH = lCirDLH + hoMarginTiering

4119001036
Algorithms
Thus, the applied tiering algorithm is:

If the used TCH is hopping and PWCI < lCirDLH, an intracell handover is
triggered to a nonhopping TCH if any available.
If the used TCH is nonhopping and PWCI > uCirDLH an intracell handover is
triggered to an hopping TCH if any available.
In both cases, if no TCH is available, no handover should be made (no queuing)
and a new attempt should occur after some time (as long as the tiering conditions
are satisfied).
The PWCI statistics and uCirDLH/lCirDLH may be transmitted on the Abis
interface according to the selfTuningObs parameter ; these statistics are available
independently of the activation of the feature.
The hoRequiredTch counter C1138 has 2 new screenings 15 (tiering handover from
large pattern to small pattern) and 16 (tiering handover from small pattern to large
pattern) ; two new counters are added: C1802 (hoSuccessTieringTch) and C1801
(hoFailureTieringTchNorr) with 2 screenings each.
The table below gives indicative values for the time required to gather
nbPwCISamples measurements for different cell configurations, assuming the
average TCH occupancy rate is 75% and that one TCH provides 2 PwCI
measurements per second:
Cell configuration 20000 nbPwCISamples 60000 nbPwCISamples

O2 (14 TCH) # 16 min # 48 min
O4 (29 TCH) # 8 min # 24 min
O8 (59 TCH) # 4 min # 12 min
O16 (121 TCH) # 2 min # 6 min
The period between 2 consecutive threshold updates is about the half of time
required to reach a first reliable statistics.
! Caution:
Because it takes advantage of BTS O&M centralization, this feature applies to 2G

products only (equipped exclusively with DRXs).
The activation of this feature implies a previous activation of the L1M V2.
The statistics (for PWCI) are not kept during upgrade and must be gathered again
after the site reconfiguration.

Algorithms
Intracell handover for quality and intracell tiering handover are exclusive (choice
managed with the intracell parameter of the handOverControl object). For mobiles
at cells boundaries, if for PBGT reasons, a handover is decided towards a new cell
on a hopping TCH, a subsequent handover for tiering reasons will be possible
towards a non hopping TCH and so on, so inducing a risk of pingpong handovers ;
this drawback will be avoided with well tuning of hoMarginTiering parameter.
No tiering handover decision is possible if the TDMA bearing the current TCH
belongs to the small zone/band1 of a multizone/dualband cell.
If tiering is activated, no tiering decision is undertaken by the BTS as long as a

reliable statistics has not been gathered (minimum nbPwCISamples for PWCI
measurements); field experiments have shown that at least 20000 PWCI samples
are needed.
The cell tiering behaviour relies on a correct definition of interferers for each cell
via the interfererType parameter.
In V12, statistics are not maintained on the BCF passive chain.
2.5.12 Microcellular Handover
2.5.12.1 Handover peculiarities in microcell environment
Microcellular algorithms were initially defined to avoid issues due to fast moving
mobiles connected to microcells. People thought that fast moving mobiles would
not have enough time to receive handover information coming from the network or
would jump some microcells. To avoid communication failures, specific handover
algorithms were defined to send fast moving mobiles to the macro layer.
However, experiments performed on several microcellular networks demonstrated

that fast moving mobiles linked to outdoor microcells do not present any issues.
Microcellular algorithms are used mainly to split traffic loads on the two layers,
regardless of mobile speed.
Most microcellular algorithms, given as examples in the ETR 05.22 of the GSM
recommendation, are based on a capture threshold. Mobiles linked to a macrocell
perform a handover towards the micro layer as soon as the field strength received
from a microcell is sufficiently high (whatever the field strength received from the
macrocell) for a sufficient duration.
The microcellular handover algorithm type A is also based on the stability of the
signal.

4119001036
Algorithms
2.5.12.2 Ho__A: Microcellular Algo type A
The following table describes permitted handover causes according to the type of
the serving cell and the neighbor cell (NB: the traffic handover is only possible from
a large zone (or monozone)).
neighbor
cell normal macrocell microcell
serving
cell
normal signal quality UL, DL signal quality signal quality
signal strength UL, DL signal strength signal strength
distance distance distance
power budget power budget power budget
traffic traffic traffic
directedRetry (BTS directedRetry directedRetry
mode) (BTS mode) (BTS mode)
forced handover forced handover forced handover
macrocell signal quality signal quality capture

signal strength signal strength directedRetry
distance distance (BTS mode)
power budget power budget forced handover
traffic traffic
directedRetry (BTS directedRetry
mode) (BTS mode)

forced handover forced handover
microcell signal quality

signal strength
signal quality
signal strength
signal quality

signal strength

distance distance distance
power budget directedRetry power budget
traffic
directedRetry (BTS
(BTS mode)
forced handover
traffic

directedRetry

mode) (BTS mode)
forced handover forced handover
The capture handover algorithm can only be defined from a macrocell to a

microcell. However the type of a cell is defined relative to the type of the
neighboring one. It means that the type of a cell A can be a macrocell from the
cell B point of view but can be a microcell from the cell C point of view. This
way, it is possible to use the capture handover algorithm on both sides,
macrocell > microcell and microcell > macrocell.
However the Type A handover algorithm has not been specifically defined to
perform handovers from microcells to the macrocell layer.
At each HRQAVE__NCELL period: Compute RXLEV_NCELL (m).

Algorithms
IDLE
RUN_HANDOVER
Is capture
confirmation running (N)
for microcell n ?
(Y)
Calculate average
RXLEV_NCELL(n)
Reset
RXLEV_NCELL(n) (N) microCellCaptureTimer(n)
> RXLEV_MIN(n) ? and handover process on
(Y) microcell: n
Normal handover
Updating procedure
RXLEV_NCELL_MIN(n)
RXLEV_NCELL_MAX(n) (Y) (Y)
Handover decision ?
(N)
Handover on
RXLEV_NCELL_MAX(n) NORMAL criterion
RXLEV_NCELL_MIN(n) (N)
< MicroCellStability(n) ?
(Y) Micro cell selected for
(Y) capture confirmation ?
(N)
Has
microCellCaptureTimer(n) (N) Microcell m found ?
expired ?
(Y) RXLEV_NCELL(m) (N)
Handover on > RXLEV_MIN(m) ?
CAPTURE criterion (Y)
Set timer
microCellCaptureTimer(m)
IDLE
Figure 21 MICROCELLULAR TYPE A HO ALGORITHM

4119001036
Algorithms
While microCellCAPTURETimer(n) goes on, if a normal handover decision is

verified, a handover towards a cell of the same type or a normal cell is allowed.
While a handover is decided, the list of eligible cells is provided at each
runHandover (microCellCaptureTimer (n) is not reinitialised).
The threshold microCellStability(n) must be put previously to 63 dB. This value
ensures that a handover is performed as soon as the field strength received from the
neighbor cell is higher than the capture threshold. The value can then be reduced
case by case.
! Caution:
The microcellular feature is an OMCR option (must be activated at OMCR

installation).
2.5.13 Forced Handover (Ho_10)

This feature is used to force a handover towards neighboring cells. If a cell is to be
shut down, forcing handovers avoids dropped calls.
It has to be used in addition to the soft blocking feature (barring of incoming
Handover, barring of new calls).
Through a Connection State Request message, the BSC requests that the BTS sends
it a list of eligible neighbor cells. This list, immediately sent through a Connection
State Acknowledgement message to the BSC, is generated by the following criteria:
If RxLevNcell(n) > Forced handover algo(n) + Max(0,

msTxPwrMaxCell(n) MSTxPwrMax)
then cell n is a candidate for a Forced Handover.
By putting a low value to Forced handover algo(n), the HO becomes easier: the cell
is released more rapidly.

Algorithms
! Caution:
A forced HO is possible after a certain communication duration:

duration Max(HREQAVE_RXQUAL*HREQT_RXQUAL,
HREQAVE_RXLEV*HREQT_RXLEV, HREQT_NCELL). Therefore, when
integrating this feature in the soft blocking procedure, the operating mode is the
following:
soft blocking,
wait a certain time (20 seconds),
trigger the forced HO.
There is only one attempt per cell.
Another reason to use a Forced HO with soft blocking is that a Forced HO may
interrupt a Directed Retry HO (if the Connection State Request message of the
Forced HO arrives before the Handover Indication cause Directed Retry message).
One must wait a period of time after the soft blocking so that all calls have time to
move from SDCCH channels to TCH channels.
2.5.14 Early HandOver Decision
2.5.14.1 Problem Description
The time for a mobile to reselect a cell in idle mode is quite long. So, a mobile can
start a communication while camping in another cell, leading to a call drop in the
worst case.
A
MS setting a call
cell A actually selected

4119001036
Algorithms
If the reselection algorithm execution occurs close to the border of cell A. The
mobile can setup a call a short moment after in the cell B while the cell A is still
selected. Unfortunately, the MS has to wait a certain period of time before being able
to make an handover. The system has to perform some measurements before taking
some handovers decisions.
This period of time is quite critical, there are some risks of call drop because of the
low level of the signal.
Another issue is concerned by this feature ; that is the problem of a mobile turning
at a street corner, when the RxLev suddenly decreases in the serving cell and
increases for a neighbour cell.
2.5.14.2 Feature description

The principle is not to speed the selection process but to allow a handover on PBGT
quicker.

dB
Cell B
Cell A

Incoming handover
from cell A
C1/C2 algorithm
Risk of
execution
call drop

Call setup
in cell A
Outgoing handover
toward cell B
Before V11, the L1M, at the beginning of a call, must wait:

level weighted average of serving cell (rxLevHreqave*rxLevHreqt),
quality weighted average of serving cell (rxQualHreqave*rxQualHreqt),
at least 1 level average of neighbor cell (rxNCellHreqave).
To sum up, the L1M does not take any decision before:
Max(rxLevHreqave*rxLevHreqt, rxQualHreqave*rxQualHreqt, rxNCellHreqave).
From V11, two shorter averages are defined for the level of the serving cell
(rxLevHReqaveBeg) and for the level of the neighbouring cells
(rxLevNCellHReqaveBeg). The L1M will use this new shorter averages at the
beginning of the call until Max (rxLevHreqave*rxLevHreqt,
rxQualHreqave*rxQualHreqt) is reached and after loss and recovery of BSIC.

Algorithms
So from V11, the L1M must only wait:

shorter level arithmetic average of serving cell (rxLevHReqaveBeg)
shorter level average of the neighbouring cell (rxLevNCellHReqaveBeg)
Therefore, the handover can be performed more quickly and with less
measurements.
The principle is not to speed the selection process but to allow a handover on PBGT
quicker.
dB

Cell A Cell B
Incoming handover

Decrease of the
call drop risk zone
Call setup
Outgoing handover

It allows to reduce the zone which represents the critical period of time. The first
impact of this feature is to reduce the probability of establishment failure and the
call drop ratio.
A third parameter has been created (HOMarginBeg) in order to compensate the lack
of measurements by increasing the HOMargin.
The parameter rxLevNCellHReqaveBeg is used each time a new cell is detected by
the mobile. Therefore, it increases the system reactivity.
PBGT(n) HOMarginBeg(n) > 0

rxLevHReqaveBeg and rxLevNCellHReqaveBeg are used
until Max(rxLevHreqave*rxLevHreqt,
rxQualHreqave*rxQualHreqt) is reached and after loss
and recovery of BSIC

4119001036
Algorithms
2.5.15 Maximum RxLev for Power Budget

One of the issues to solve, in a microcellular network, is street corner (cross road)
environment:
In case of mobile moving straight the cross road (two orthogonal cells A and B), a
handover for Power Budget may be processed from cell B to cell A. Once the cross
is passed, the mobile is handed again over the cell B.
This pingpong handover shall be avoided as useless handover leads to voice
quality degradation and signalling increase.
Another advantage of this feature is the possibility to reduce unnecessary handovers
at border of Location Area, interBSC or interMSC HO. In this case the need to
perform Power Budget handovers is diminished against the extra load on NSS and
the voice quality.
The feature provides a solution by preventing handover for power budget from the
serving cell if the RXLEV downlink serving cell level exceed a specific threshold
To prevent handovers for power budget from the serving cell if the RXLEV
downlink serving cell level exceed a specific threshold (rxLevDLPBGT), the
following expression used in combination with existing cell selection criteria is
actually:
RXLEV_DL + PWR_C_D < rxLevDLPBGT

with: PWR_C_D = bsTxPowerMax bsCurrentTxPower
PWR_C_D is the difference between the maximum downlink RF power permitted

in the cell and the actual downlink power due to the BSS power control. It is used
to compensate the difference between the full power radio channels (located on the
BCCH TDMA) and the power controlled radio channels.
2.5.16 Presynchronized HO
During an asynchronous handover, the MS repeats the HO access bursts until it
receives the physical information message containing the timing advance of the new
cell. So the speech cut duration may last as long as the MS receives the new TA
(Timing Advance) applied in the new cell.
The presynchronized handover feature allows a Phase 2 MS to make a
synchronized handover between two (2) cells not belonging to the same site but
managed by the same BSC. The procedure is the same as for an intrasite
synchronized hand over, excepted that the TA is set in advance and is transmitted
to the MS at the beginning of the HO procedure.

Algorithms
! Caution:
Only intra BSC synchronized handover are possible.

There are two possibilities to set the timing advance in case of presynchronized
HO: Presynchro with default value or with a determined Timing Advance.
Two parameters are impacted in the adjacentCellHandOver object to enable this
feature:
synchronized is set to the value pre sync HO, with timing advance or pre sync
HO,default timing advance.
presynchroTiming Advance indicates the value of the TA.
By comparing not synchronized handovers with synchronized handover, a phonetic
gain from 20ms to 40 ms is expected. This is due to the Physical_Info message
suppression, which is not necessary because on presynchronized handover, the
timing advance value is carried by the Handover_Command message. Moreover,
only four Handover_Access messages are used on presynchronized handover
instead of more than four in case of not synchronized handover.
2.5.17 Radio channel allocation

The radio channel allocation is based on the interference levels computed on the
BTS free channels (SDCCH and TCH).
Every averagingPeriod the BTS sends RF RESOURCE INDICATION messages to
the BSC. These messages are related to one TRX and contain the level of
interference of the free channels. These interference levels are classified into one
from the five possible interference bands (ThresholdInterference parameter). In
each of the five bands, the resources are sorted from the least to the most recently
used.
At the BSC level the free channels are divided into two new groups depending on
whether their interference level is above or below the RadChanSellIntThreshold
value. Each group is itself divided into two subgroups, depending on whether the
resource supports the Frequency Hopping.

4119001036
Algorithms
! Caution:
If, during three (3) successive RF RESOURCE INDICATION messages, an
incoherency is noticed at the BSC level concerning the avaibility of a radio
channel, the channel is released and is returned free to the allocator.
When a resource is released upon a call termination, it always returns to the pool
of worst interference level, whatever its level before the allocation. The next
measurement received from the BTS for this resource will be used to update the
level and, consequently, to find the appropriate pool.
The inner zone of a concentric cell does not support SDCCH channels. Till V11,
although they belong to the same cell, TCH pools for the inner zone are separated
from the same pools of the outer zone, and there are no possible channel
exchanges between the two zones.
When a SDCCH is requested and no SDCCH is available, the external priorities
are considered as a TCH can be allocated instead of a SDCCH, following the
TCH allocation principles.
If a TCH is requested and the priority threshold is reached, only priority 0
requests will be served. Other priorities will generate negative responses from
the allocator.
2.5.18 Define eligible neighbor cells for intercell handover (except directed
retry) (Ho_11)
When an intercell handover is required, the BTS sends a list of at most n best
suitable cells (n=3 until V11 ; n=6 from V12) according to EXP1 and EXP2
formulas.
The following diagram shows an example of cell interlapping produced by different
values of lRxLevDLH (threshold out of Cell A) and rxLevMinCell (threshold in
Cell B, assuming it is a 2W mobile and msTXPwrMaxcell is set to 33dB). If values
are too restrictive, then Ho_11 will not consider Cell B as an eligible cell for
handover and the call might be dropped. This might be the case especially in rural
areas where cells have little overlap.

Algorithms
Putting a high value for rxLevMinCell(n) or a high value for msTXPwrMaxCell(n)

results in restricting access to that cell (see following diagram).
Cell A Cell B
Ho1 Ho2
98 dBm 92 dBm
100 dBm 95 dBm

IRxLevDLH rxLevMinCell(B)
There is a different margin for each handover cause:

hoMarginDist, hoMarginRxLev, hoMarginRxQual (can be negative),
hoMargin (for power budget), thus compliance to that formula becomes
mandatory i.e a handover can only be performed towards a neigbourCell for
which the (PBGT(n) hoMargin(dist, rxqual, rxlev)) is positive.
2.5.19 Handover to 2nd best candidate when return to old channel (Ho_12)
This feature is triggered by a handover failure during the execution phase.
If HOSecondBestCellConfiguration =
1 > no HO attempt to 2nd best candidate cell
2 > HO attempt to 2nd best candidate cell
3 > HO attempt to 2nd best candidate cell and to 3rd
best candidate cell if the HO attempt to 2nd best
candidate cell fails
When the HO attempt towards the last candidate fails, the bssMapTchoke starts at
the BSC. At the expiry of the timer, the BSC asks the BTS to provide a new list of
eligible cells.

4119001036
Algorithms
2.5.20 Protection against RunHO=1
The objective is to get a more responsive handover detection mechanism. To reach

this goal, the HO algorithm shall be run every 480 milliseconds (i.e runHO=1
SACCH period).
This feature is useful for call drop rate improvement.
With this configuration (runHO=1), a protection shall be implemented to avoid

BSC overload.
In case of saturated network (no free TCH) the request for handover (HOIndication
message) will be repeated every 480 ms by the BTS, even if the target cell list has
not changed.
As a consequence, the HO_Indication shall be repeated every 2 SACCH periods

(1 second) in case of run HO = 1.
If the content of the preferred cell list IE is modified (i.e. the content or the order
of the cell list), the HO_IND message shall be repeated every runHO (even if
runHO=1).
In addition to that, the HO_IND message has also to be sent if the reason for
handover has changed, for the reason that there is no preferred cell list IE in case
of intracell handover for example.
The value of 1 second is justified by the fact that existing operational networks are
currently working with the value of runHO=2, and therefore no strongest protection
is needed.
2.5.21 General protection against HO pingpong (from V12)
This feature allows to easily solve some pingpong handover problems (like
pingpong after directed retry or pingpong microcell>macrocell>microcell or
pingpongs already managed by the previous feature minimum time between
handover).
It is enabled by the BSC object parameter timeBetweenHOConfiguration and by the

BTS object parameter btstimeBetweenHOConfiguration(0 means not used and
value greater than 0 means used).
For each neighboring cell of each cell(adjacentCellHandover object), two

new(from V12) parameters are defined: HOPingpongCombination defines up to
four combinations (incoming_cause, outgoing cause) used in order to define
forbidden handovers and HOPingpongTimeRejection defines the handover
rejection duration used for all combinations.

Algorithms
When the BSC receives from the BTS a Handover Indication, it calculates the time
spent in the cell since the last handover (named connection_time) and removes from
the preferred cells list the eligible cells for which the connection_time is lower than
the corresponding timeRejection and for which the combination (incoming cause,
outgoing cause) corresponds to a combination defined in
HOPingpongCombination.
The incoming causes may be: RXLEV (indifferently for uplink and downlink),
RXQUAL (indifferently for uplink and downlink), DISTANCE, PBGT,
CAPTURE, DIRECTED_RETRY, O&M (for forced handovers), TRAFFIC, ALL
(if the incoming cause matches all the preceding causes).
The outgoing causes may be: RXLEV (indifferently for uplink and downlink),
RXQUAL (indifferently for uplink and downlink), DISTANCE, PBGT,
CAPTURE, O&M (for forced handovers), TRAFFIC, ALL (if the incoming cause
matches all the preceding causes), ALLCAPTURE (if the outgoing cause matches
the CAPTURE cause for all the microcells belonging to the current macrocell),
ALLPBGT (if the outgoing cause matches the PBGT cause for all the neighboring
cells of the current cell ; this cause can be used to restore the Minimum time
between handovers feature used from V9 to V11).
This feature works even if the BSC V12 is in front of BTS V11 or V10.
! Caution:
The parameters HOPingpongCombination and HOPingpongTimeRejection must

be defined at the entering cell (relatively to the first HO of the combination) level,
for the neighbouring cell (adjacentCellHandover object) corresponding to the left
cell (still relatively to the first HO of the combination). Thus, these parameters are
known by the new BSC whatever the type of HO is (intra or interBSC).
For interBSS handovers, if the Cause element is not included in the
HANDOVER_REQUEST message sent from the MSC to the target BSC, then this
feature is not applied except when the incoming_cause in
HOPingpongCombination parameter is set to ALL.

4119001036
Algorithms
During upgrades to V12, if btstimeBetweenHOConfiguration is greater than 0, then

btstimeBetweenHOConfiguration is set to 1, HOPingpongTimeRejection is set to
the previous value of btstimeBetweenHOConfiguration and
HOPingpongCombination is set to (all, allPBGT) and if
btstimeBetweenHOConfiguration is equal to 0, then it keeps the same value,
HOPingpongTimeRejection is set to 0 and HOPingpongCombination is set to
empty.
The C1166 counter related to the Minimum time between handover feature is
removed and replaced by the C1782 counter incremented when a cell is removed
of the preferred cells list (so, for one handover indication message, it can be
incremented several times).
This feature gives no protection against intracell or interzone pingpong handovers
and gives no protection against pingpong handovers between more than 2 cells
except for allCapture or allPBGT outgoing causes.

Algorithms
2.6 HANDOVER ALGORITHMS ON THE MOBILE SIDE

For an intracell handover, the mobile receives an ASSIGNMENT COMMAND
and simply switches to another timeslot belonging to any TDMA of the cell.
For an intercell handover, upon reception of the HANDOVER COMMAND, the
mobile checks if it has the synchronization information. If not a handover failure
is reported and communication remains on old channel.
Then, if it is a synchronized handover, four access bursts are sent on the new
channel before actually switching to it.
If it is a non synchronized handover, the mobile will send contiguous access bursts
on new cell, expecting a PHYSICAL INFORMATION message to be sent back by
the BTS, in order to know the Timing Advance to be used on the new channel and
actually switch to it. If that message is not received within one second, then there
is a handover failure and the mobile returns to the old channel.
Once on the new cell, the mobile tries to establish level 2 connexion (SABM and
UA exchange procedure). If that procedure fails, then the mobile returns to the old
channel, but if it succeeds the synchronization information with previous best cells
is kept for updating with new cell parameters.
To conclude this paragraph, one realizes that a handover can be a rather lengthy
process, which should not be performed too late in order to ensure its success and
not too often to maintain a smooth voice or data flow.

4119001036
Algorithms
2.7 POWER CONTROL ALGORITHMS

The aim of the Power Control feature is to reduce the average interference level on
the Network and to save mobile batteries.
2.7.1 Power control performed by the BTS (Step by step) (Pc_1)

This algorithm is a step by step full path loss compensation. The algorithm
determines the gap between the received level and the power control threshold
(L_RXLEV_XX_P) and compensates the path loss step by step until the received
level reaches L_RXLEV_XX_P.
The basic idea of the step by step power control algorithm is:
to reduce transmitted power when reception level is high and quality is good
to increase transmitted power (if not at the maximum level) when the reception
level is low or quality is poor
This feature is activated at the BTS level by setting the following parameters:
powerControl object: uplinkPowerControl = enabled and bsPowerControl =
enabled
BTS object: new power control algorithm = step by step
At every runPwrControl event, an averaging is performed and the following tests
are computed:
Mobile transmitted power control:
if ((RXLEV_UL>uRxLevULP) AND (RXQUAL_UL < uRxQualULP))

then reduce MS tx_power of PowerRedStepSize.
if ((RXLEV_UL<lRxLevULP) OR (RXQUAL_UL > lRxQualULP))
then increase MS tx_power of PowerIncrStepSize.
Base Station transmitted power control:
if ((RXLEV_DL>uRxLevDLP) AND (RXQUAL_DL <

uRxQualDLP))
then reduce BS tx_power of PowerRedStepSize.
if ((RXLEV_DL<lRxLevDLP) OR (RXQUAL_DL > lRxQualDLP))
then increase BS tx_power of PowerIncrStepSize.

Algorithms
Note: Increase BS tx_power is always limited by bsTxPwrMax.
Note: Increase MS tx_power is always limited by Min(msTxPwrMax,P) where P

is MS power depending on its class.
2.7.2 One shot power control (Pc_2)

The enhanced power control is a one shot partial path loss compensation algorithm.
The one shot power control algorithm determines the optimal transmit power by
calculating a partial path loss compensation and compensates it in one step.
This feature is activated at the BTS level by setting the following parameters:
enabled
BTS object: new power control algorithm = one shot
The MS broadcast in measurement report its current power. The L1M sends it the
newly computed absolute output power to follow.
Concerning the BTS, the attenuation (difference between current power and max
power) is considered. The L1M computes and sends to the BTS the new attenuation
to follow.
MSPWR = PWR_MAX K_UL*(RXLEV_UL + Pms lRxLevULP)

BSATT = K_DL*(RXLEV_DL ATTCUR lRxLevDLP)
with:
MSPWR: New MS power in dBm
Pms: Min(msTXPwrMaxCell(n) , MSTxPwrMax) Current MS power
K_UL, K_DL: Factor which depends on L_RXQUAL_XX_P value
BTSATT: BTS attenuation
ATTCUR: Current BTS attenuation
XX: UL or DL
PWR MAX: Maximum MS Power
The values of K_UL and K_DL depend on the activation of frequency hopping and
of L_RXQUAL_XX_P. Here are the values of K, which come from simulation
results, considering L_RXQUAL_XX_P = 7

4119001036
Algorithms
RXQUAL 0 1 2 3 4 5 6 7
K with FH 0.9 0.8 0.7
K without FH 0.7 0.6 0.5
FH: frequency Hopping

If L_RXQUAL_XX_P is lower than 7, K_XX becomes equal to 0 each time the
weighted average RxQual_XX becomes higher than this threshold.
If RxQual_UL > lRxQualULP > K_UL = 0

If RxQual_DL > lRxQualDLP > K_DL = 0
If K_UL = 0 then the MS power becomes equal to the maximum power possible in
the cell (Min(msTXPwrMaxCell(n), MSTxPwrMax)).
If K_DL = 0 then the BTS power becomes equal to the maximum static power
possible.
Up to V11, the BTS will neither increase nor decrease its power by more than 8 dB.
With an attenuation greater than 8 dB, some mobiles would lose the BTS. From
V12, this limitation applies only for decrease.
2.7.3 Fast power control at TCH assignment (Pc_3)

This V12 feature is an improvement of the one shot power control (described
above). One shot power control reactivity is improved by deciding power control
on SDCCH allocation and on TCH allocation with only rxLevHreqaveBeg
measurements. With this feature, attenuation (possibly decided on SDCCH) is kept
at TCH assignment and for each channel switchover (start on SDCCH, SDCCH
to TCH or TCH to TCH), the few first measurements (from rxLevHreqaveBeg to
max(rxLevHreqave*rxLevHreqt, rxQualHreqave*rxQualHreqt)1 may be used to
decide powercontrol.
This feature is activated by setting the following parameters:
enabled
BTS object: newpowercontrolalgorithm = enhanced one shot.
The activation of the one shot power control is quicker than it was because it is done
with the rxLevHreqaveBeg measurements.

Algorithms
Until max(rxLevHreqave*rxLevHreqt, rxQualHreqave*rxQualHreqt) is reached,

the attenuaton is computed with the compensation factor K for uplink and
downlink. This factor no more depends on the rxQualHreqave measurements but
only on the frequency activation:
Attenuation(n+1) = K(RxLev + Attenuation(n)

lRxLevxLP)
Where:
K = 0.5 in case of non hopping channel,
K = 0.7 in case of hopping channel,
lRxLevxLP = lRxLevULP for upling path and lRxLevDLP for downlink path.
If RxLevHreqaveBeg > max(rxLevHreqave*rxLevHreqt,
rxQualHreqave*rxQualHreqt) then this feature is not activated.
When max(rxLevHreqave*rxLevHreqt, rxQualHreqave*rxQualHreqt) is reached
the usual average of the one shot power control described before is computed with
the K value depending of the rxQualHreqave measurements.
! Caution:
This feature is not supported with DCU2 boards or with a mix of DCU2/DCU4
boards.
2.7.4 Power control on mobile side (Pc_4)

In Rach phase, the MS power is equal to MIN (MSTxPwrMax, msTxPwrMaxCCH).
When the MS switches from RACH to SDCCH or TCH, it keeps the same power.
In dedicated mode, the mobile transmits at the power required in the POWER
COMMAND message transmitted in the layer1 header of SACCH blocks. This
command will be received at the end of a reporting period (102 frames in SDCCH,
104 in TCH). It will be applied at the beginning of the following period at a rate of
2dB per 13 frames.
Before triggering an intercell handover due to uplink causes (RXQUAL or
RXLEV) and only step by step power control and for L1M V1 (only), the BTS
should request the MS to transmit to its maximum power capability. In such cases,
if the MS can increase its transmit power, no Handover Indication is transmitted by
the BTS.

4119001036
Algorithms
In the case of a handover, the maximum transmitted power allowed in the target cell
is sent to the mobile in the handover command message (msTxPwrMaxCell).
In case of intracell handover, the power reduction is kept.
The current txpwr value is saved so that it can be sent in the next transmitted uplink
SACCH. For the BTS, the duration of the entire process (from order to
acknowledgment) is three multiframes.
BTS sends PC and TA BTS receives

commands in L1 header One SACCH reporting period the Measurement
of SACCH block 26*4 = 104 frames (480 ms) Report
SA0 SA1 SA2 SA3 SA0 SA1 SA2 SA3 SA0 SA1 SA2 SA3
26 frames, SACCH MS starts applying MS starts transmitting

sent on frame 12 new PC and TA SACCH concerning
previous multiframe
MS has the SACCH block MS builds a L1 header stating
new values of PC and TA
Time (Number of measures)
10 to 18 measures *
1 to 5 measures *
4 to 13 measures *

Algorithms
2.8 TCH ALLOCATION MANAGEMENT
2.8.1 TCH Allocation and Priority
2.8.1.1 Allocation and priority (run by the BSC) (All_1)
Up to GSM08, the priorities are handled by the BSC. From GSM08, the MSC
manager priorities.
An external priority is defined for each type of TCH allocation request in signalling
mode (emergencyCall, answerPaging, otherServices, allOtherCases) or in traffic
mode (assign request, interCellHO inter and intra BSC intraCellHO, small to
large zone HO and directedRetry). This priority is transformed into an internal
priority (0 to 7) via an OMCR table (allocPriorityTable) when queueing is used
or not.
Note that handover procedures (inter and intra cell) and assignRequest
procedure are requests on TCH in traffic mode.
On the contrary, all the other procedures are requests on SDCCH or TCH in
signalling mode. If no SDCCH are free, all the requests are on TCH
considering all the internal priorities.

4119001036
Algorithms
Channel Request
SDCCH available ?
yes no
Internal Priority Evaluation
number of free TCH u Allocpriority Threshold ?

yes no
internal priority = 0 ?
yes no
number of free TCH 1 ?

yes no
SDCCH allocation TCH allocation (signalling) Request not allowed
Note that there is no priority relation for external priorities, but this is only a mean
to indicate the procedures that will have the same internal priority level, via the
mapping table called allocPriorityTable. On the contrary, for internal priorities, the
lower the internal priority value n the higher the priority of the procedure.
A number of TCH (see allocPriorityThreshold) can also be reserved for TCH
allocation request which has an internal priority equal to 0. Note that only the total
number of reserved TCH channels is defined in this case, but no specific TCH
channels are allocated to procedures with an internal priority equal to 0.
Internal Priority = 0 a TCH allocation request is acknowledged when at least one
(1) TCH is free
Internal Priority u 0 a TCH allocation request is acknowledged when at least
(allocPriorityThreshold + 1) TCH is free

Algorithms
TCH request with priority = 0

are acknowledged
TCH request with priority 0

are acknowledged
0 1 Free TCH
allocPriorityThreshold = 2
Priorities can be driven by the OMC or by the MSC. The MSC external priorities
are defined for the assignRequest messages (refer to rec. GSM 08.08).
There is a change of number between the external priority of a procedure at the MSC
level and the external priority of the same message at the BSC level:
External priority at BSC level = (External priority at MSC level) 1
The four (4) external priorities left at the BSC level (14 to 17) can be reserved only
by the other procedures.
However, the different types of a assignRequest are considered only when the
queueing is activated with the MSC driven option.

4119001036
Algorithms
14 external GSM priorities + 4 external priorities reserved for BSS internal use are
converted on 8 internal priorities
MAPPING Internal Priorities

MSC External Priorities
TABLE (07)
MSC level (1 14) BSC level (0 13)

Priorities 14 17 are reserved for BSS internal use
O&M External Priorities MAPPING Internal Priorities

( 0 17 ) TABLE (07)
Priorities 14 17 are reserved for BSS internal use
The call priorities defined at O&M may be different when MSC external
priorities are used or when O&M external priorities are used
It is important to note that priorities associated with procedures are completely

independant from queueing. It means that channels can be reserved for procedures
(internal priority = 0) without queueing.
However, from the point of view of parameters, if queueing is used usually for
TCH allocation for conversation setup, it is a good idea to reserve some channels
for incoming handovers.
Below are two examples of internal priorities associated with external priorites.
External Priorities 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17
OMCR Internal priorities
table
allocPriorityTable 0 1 2 2 2 2 2 3 1 2 1 2 2 2 0 0 2 2
Procedures External priority
answerPaging 02
assignRequest 10
callReestablishment 14
emergencyCall 15
interCellHO inter BSC 00

Algorithms
Procedures External priority
interCellHO intra BSC 00
intraCellHO 08
otherServices 07
allOtherCases 07
small to large zone HO 08
directedRetry (new V12) 08
This table indicates that the procedures associated with external priorities 0, 14
and 15 (see allocPriorityTable) will have an internal priority equal to 0. Specific
TCH channels can be reserved for these procedures (see allocPriorityThreshold)
which are: callReestabllishment, emergencyCall and interCellHO (inter and intra
BSC).
In the same way the procedures associated to external priorities 1, 8 and 10 will have
an internal priority equal to 1: assignRequest, intraCellHO, small to large zone HO
and directedRetry.
The procedures associated to external priorities 2, 3, 4, 5, 6, 9, 11, 12, 13, 16 and

17 will have an internal priority equal to 2: answerPaging.
The procedures associated to external priorities 7 will have an internal priority equal
to 3: otherServices and allOtherCases.
Note that if queueing is activated with MSC driven, the parameter assignRequest
is not significant since the 14 causes of assignRequest can have different internal
priorities. In the other cases, the parameters assignRequest defines the same internal
priority for all 14 causes.
2.8.2 Queueing
There is no queueing for TCH in signaling mode.
Queuing is used to put TCH allocation request into a waiting queue when no TCH
resource is available (see previous Section 2.8.1.1 All_1). The activation of the
Queueing must be viewed as a solution to prevent an exceptionnal saturation of
TCH. For the waiting queue, a maximum waiting time (allocWaitTimer) and a
maximum number of TCH allocation requests affected to this queue and the queues
of greater priorities (allocWaitThreshold) are defined via OMCR parameters.

4119001036
Algorithms
However, note that queueing is not available for all procedures. For example,
intercell handover procedures can not be queued. When Queueing is activated,
solutions must be found to avoid a bad quality of service for the MS in
communication (see Section 3.14).
Furthermore, note that when an assignRequest is queued the MS is still attached to
a SDCCH channel and the measurement process keeps on going, to allow the MS
to perform a handover on SDCCH (if the feature is enabled).
2.8.2.1 Queueing driven by the MSC (available since DMS GSM08) (All_2)
Queueing may be used according to the Assignment Request message coming from
the MSC. If the MSC requires queueing, the external priority [0 to 14] is taken from
the MSC and transformed into internal priorities, corresponding to queue numbers.
With MSC driven eight (8) queues are available for the procedure assignRequest,
intraCellHO, small to large zone HO and directedRetry. Each cause of
assignRequest is associated with a queue. Then, 14 causes of assignRequest and
three procedures (intraCellHO, small to large zone HO and directedRetry) can be
queued simultaneaously in 8 queues. Please note that the number of TCH allocation
requests in a queue could fluctuate, depending on the filling of the other queues (if
they are full or not).
Caution: the size of each queue (allocWaitThreshold) indicates the maximum
number of potential requests that could be queued in this queue and the queues
of greater priorities. The difference of size between two consecutive queues
(size of the internal priority (n) minus size of the internal priority (n1))
represents the maximum number of requests assured to be queued in this
queue (see example Section 2.8.2.2 All_3).
Remark: A simple way of using the parameter allocWaitThreshold is to assign

the same value to all priorities: then this value is the upper limit of all
the channel requests that can be queued simultaneously, scattered over
some priority queues.

Algorithms
Caution: check which cause of assignRequest is allowed to be queued (at the

MSC side).
TCH allocation request Comment

BSC side
answerPaging no queueing an internal priority is defined
assignRequest not significant (see Section 2.8.1.1 All_1)
callReestablishment no queueing an internal priority is defined
emergencyCall no queueing an internal priority is defined
interCellHO inter BSC no queueing an internal priority is defined
interCellHO intra BSC no queueing an internal priority is defined
intraCellHO queueing is allowed an internal priority is defined
otherServices no queueing an internal priority is defined
small to large zone HO queueing is allowed an internal priority is defined
directedRetry queueing is allowed an internal priority is defined
Three steps can be established for the queueing of procedures. At first, there is a test
to know if a procedure can be queued or not. Then, if it is queued, another test occurs
to determine when it is aknowlegded. Finally, a queued procedure can be removed
from the queue.

4119001036
Algorithms
An internal priority equal to X for a TCH allocation

request is put in the waiting queue number X:
When X = 0 if no TCH is free and the number of requests
in the queue 0 is less than the maximum for
queue 0. It means there is at least one place
free in the queue.
When X > 0 if less than allocPriorityThreshold TCH are
free and the number of requests in all the
waiting queue P (with P<X) is less than the
maximum for queue X.
An internal priority X for a TCH allocation request,
which is queued in the waiting queue X, is acknowledged:
When X = 0 if at least one (1) TCH resource is free
When X > 0 if no TCH allocation request, which priority P
is higher than X (i.e PtX) is queued and at
least (allocPriorityThreshold + 1) TCH
resources are free.
A TCH allocation request (with internal priority P) is
removed from the queue when the duration exceeds the
maximum waiting time.
2.8.2.2 Queueing driven by the BSC (All_3)
With OMC driven, a unique queue is allowed, though four (4) different
procedures can be queued. However, in both cases, a number between 0 and 7
must be chosen for the queue number, which corresponds to the internal
priority associated with the queue.
Queueing is managed by the BSC whatever queueing information coming from the
MSC are. Only the Assignment request (when the MS is attached to an SDCCH
channel) the intracell handover request, the directedRetry and the
small large zone HO can be queued in the unique waiting queue.

BSC side

answerPaging no queueing an internal priority is defined

assignRequest queueing is allowed an internal priority is defined

callReestablishment no queueing an internal priority is defined

emergencyCall no queueing an internal priority is defined

interCellHO inter BSC no queueing an internal priority is defined

Algorithms

BSC side

interCellHO intra BSC no queueing an internal priority is defined

intraCellHO queueing is allowed an internal priority is defined

otherServices

no queueing an internal priority is defined

small to large zone HO queueing is allowed an internal priority is defined

directedRetry queueing is allowed an internal priority is defined
Three steps can be established for the queueing of procedures. At first, there is a test
to determine if a procedure can be queued or not. Then, if it is queued, an other test
occurs to determine when it is aknowledged. Finally, a queued procedure can be
removed from the queue.
An internal priority equal to X for a TCH allocation

request is put in the waiting queue number X:
When X = 0 if no TCH is free and the number of requests
in the queue 0 is less than the maximum for
queue 0. It means there is at least one place
free in the queue.
When X > 0 if less than allocPriorityThreshold TCH are
free.
An internal priority X for a TCH allocation request,
which is queued in the waiting queue X, is acknowledged:
When X = 0 if at least one (1) TCH resource is free.
When X > 0 if at least (allocPriorityThreshold + 1) TCH
resources are free.
A TCH allocation request (with internal priority P) is
removed from the queue when the duration exceeds the max-
imum waiting time.

4119001036
Algorithms
Assign Request / HO intra Cell /

small to large zone HO /
directedRetry
Internal Priority Evaluation
number of free TCH u Allocpriority Threshold ?

yes no
Queueing ? no
yes
internal priority = 0 ? internal priority = 0 ?

yes no no yes
number of free TCH 1 ? number of

free TCH 1 ?
yes no
no yes
Queueing available ? Queueing available ?
no yes
yes no
TCH allocation Queueing NOK TCH allocation
Example of configuration for Queueing with OMC driven

(bscQueueingOption = forced)
Lets take an example of a 3 TRX cell with the following configuration:
First TDMA: BCCH SDCCH/8 TCH TCH TCH TCH TCH TCH
Second TDMA: TCH TCH TCH TCH TCH TCH TCH TCH
Third TDMA: SDCCH/8 TCH TCH TCH TCH TCH TCH TCH
It means a cell with 16 SDCCH and 21 TCH channels.
Hypothesis
Queueing is activated for assignRequest, intraCellHO, small to large zone HO
and directedRetry one queue is available:
queue number 2
queue maximum size 8
queue maximum waiting time 10 seconds

Algorithms
Furthermore, two (2) TCH channels are reserved for handover (interCellHO),
callReestablishment and emergencyCall, which procedures are then set to
internal priority 0.
The other procedures are associated to the same external priority, and have an
internal priority equal to three (3), to be with less priority than the queued
procedures.
The table below sums up these hypotheses.
Procedures Queueing External priority Internal priority
answerPaging No 17 3
assignRequest Yes 16 2 (queueing)
callReetablisment No 14 0
emergencyCall No 14 0
interCellHO inter BSC No 14 0
interCellHO intra BSC No 14 0
interCellHO Yes 16 2 (queueing)
allOtherCases No 17 3
otherServices No 17 3
small to large zone HO Yes 16 2 (queueing)
directedRetry Yes 16 2 (queueing)
Number of TCH reserved for request with internal priority equal to 0 = 2.

Parameter setting
to define the queue number 2, maximum size equal to 8, maximum waiting time
equal to 10 seconds:
allocWaitThreshold = 0 0 8 0 0 0 0 0
allocWaitTimer = 0 0 10 0 0 0 0 0
to reserve two (2) TCH channels for procedures with internal priority equal to 0,
the parameter allocPriorityThreshold must be set to:
allocPriorityThreshold = 2.
finally, to allocate the queue number 2 to the queued procedures (external
priority 16), and the internal priority 3 to procedures indexed to external
priority 17, allocPriorityTable has to be set to: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 3

4119001036
Algorithms
The table below shows a sumup of the final parameter setting.
External priority 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Comments

allocPriorityTable 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 3
Queue number 0 1 2 3 4 5 6 7
allocWaitThreshold 0 0 8 0 0 0 0 0
allocPriorityTimers 0 0 10 0 0 0 0 0
allocPriorityThreshold 2 Priority 0
allOtherCasesPriority 17 (for priority number = 3)
answerPagingPriority 17 (for priority number = 3)
assignRequestPriority 16 (for priority number = 2) Queueing
callReestablishment- 14 (for priority number = 0)

Priority
emergencyCallPriority 14 (for priority number = 0)
interCellHOExtPriority 14 (for priority number = 0)
interCellHOIntPriority 14 (for priority number = 0)
intraCelHOIntPriority 16 (for priority number = 2) Queueing
otherServicesPriority 17 (for priority number = 3)
small to large zone 16 (for priority number = 2) Queueing

HO
directedRetry 16 (for priority number = 2) Queueing
2.8.3 Barring of access class
On SYS INFO messages, the list of mobile access classes that can not start a call
on the cell is broadcast. Up to V8, this list is represented by the OMCR parameter
notAllowedAccessClasses. From V9, a feature allows the modification of what is
sent on SYS INFO in case of congestion.
! Caution:
The MS reads SYS INFO messages every 30 seconds in idle mode. If the MS did
not read the message before the cell selection, it could start a call.

Algorithms
2.8.3.1 Dynamic barring of access class (All_4)
The mechanism consists of temporarily forbidding cell access to some of the

mobiles (according to their access class) when a congestion situation is observed.
The congestion condition is based on:
The number of free TCH channels.
Note that TCH resources reserved for maximum priority requests (internal
priority = 0) are not considered as free TCH channels.
The parameters are numberOfTCHFreeBeforeCongestion and
numberOfTCHFreeToEndCongestion.
or
The number of queued requests in the cell.
The parameters are numberOfTCHQueuedBeforeCongestion and
numberOfTCHQueuedToEndCongestion.
The feature is enabled at bsc level by the attribute
bscMSAccessClassBarringFunction.
The feature is enabled at bts level by the attribute
btsMSAccessClassBarringFunction.
Principle:
In case of noncongestion, only the list of mobile access classes in
notAllowedAccessClasses is not allowed to select the cell.
In case of congestion, the list of mobile access classes in
accessClassCongestion is not allowed.

4119001036
Algorithms
Congestion ?
No Yes
notAllowedAccessClasses accessClassCongestion
forbidden in the cell forbidden in the cell
Congestion determination:
To enter a congestion state, either the number of free TCH must be less than
numberOfTCHFreeBeforeCongestion or the number of queued TCH
requests must be greater than numberOfTCHQueuedBeforeCongestion.
To leave a congestion state, either the number of free TCH is greater than
numberOfTCHFreeToEnd Congestion or the number of queued TCH
request is less than numberOfTCHQueuedToEndCongestion.

Algorithms
Example with a one TRX cell where one time slot is reserved for requests with an
internal priority equal to 0:
bscMSAccessClassBarringFunction = enabled numberOfTCHFreeBeforeCongestion = 1

bscMSAccessClassBarringFunction = enabled numberOfTCHFreeToEndCongestion = 3
Beginning of congestion
BCCH
Reserved TS (priority 0)
BCCH
numberOfTCHFreeToEndCongestion = 3
Congestion
End of congestion
0 1 2 3 4 5 6 7 TS
Used TCH Free TCH
Note:
As mobile stations read BCCH system information about every 30 seconds, there
will be a time window where nonauthorized mobiles will still be allowed.
A congestion situation may be detected each time one of the following events
occurs:
allocation of a TCH resource
queueing of a TCH resource request
blocking of a TCH resource (O&M action)
TDMA removal for defense or O&M reason
detection thresholds modification

4119001036
Algorithms
End of congestion situation may be detected each time one of the following
events occurs:
release of a TCH resource
a queued TCH resource request is served or aborted
unblocking of a TCH resource (O&M action)
TDMA attribution
detection thresholds modification
2.8.4 Radio link failure process (run by the MS) (Rlfms)

It is performed by the MS in dedicated mode on SACCH blocks.
RLC counter is initialized to radioLinkTimeout at the beginning of a dedicated
mode.
good SACCH block: RLC = Min (RLC+2, radioLinkTimeout)

bad SACCH block: RLC = RLC 1
If RLC reaches 0, then call is dropped
and reestablishment is tried if reselection
is made on a cell with CallReestablishment set.
2.8.5 Radio link failure process (run by the BTS) (Rlfbs)

The OMCR control of BTS RLF algorithm is offered in V8 CM141.
The FrameProcessor sets the CT counter to 0 at

channel activation
On each correct SACCH:
if (CT = 0) then CT=4*rlf1 + 4 else
CT=min(4*rlf1 + 4,CT+rlf2)
On each incorrect SACCH:
CT = max(0,CTrlf3)
When CT reaches 0, a connection Failure
Indication is sent to the BSC every
T3115, until a Deactivate Sacch or
RF Channel Release message is received.

Algorithms
This process is started when the first SACCH frame is received correctly, and the
CT counter is set to rlf1 value. If SACCH frame is not received, then the radio link
failure process is not started, CT value is kept to zero and is not modificated.
Interest of the algorithm
The quality of an uplink communication is now considered for the decision to cut
a communication.
2.8.6 Call reestablishment procedure (Cr)

The call reestablishment procedure allows a mobile station to resume a connection
in progress after a radio link failure, possibly in a new cell and possibly in a new
location area.
So this feature avoids losing calls, improving in that way the quality of service.
Moreover, in case of call drop, it reduces the SICD load by avoiding the subscriber
to hang off and on.
The Call Reestablishment can be launched following 2 different procedures
depending on the entity which detects the radio link failure:
a) The radio failure is first seen at the MS side (RadioLinkTimeOut value):
The mobile sends a callreestablishment on a selected cell (previous one or new
one) and the MSC reallocate new resources. The old resources are free by the
BSS after the rlf1 timer has expired.
b) The radio failure is first seen at the BSS side:
The BTS send a radio_link_failure message to the BSC after rlf1 has expired, the
BSC releases the radio resources and in the same time the MSC activates the
T3109 timer and waits a callreestablishment. Then, when the MS has detected
the radio link failure as well, it performs the selection and sends a channel request
on the selected cell.
To attempt a call reestablishment on a cell, the parameter callReestablisment of the
cell will be set to allowed and the cell will not be barred.
The mobile station is not allowed under any circumstance, to access a cell to attempt
call reestablishment later than 20 seconds after it detects the radio link failure
causing the call reestablishment attempt.
The mobile station shall perform the following algorithm to determine which cell
to use for the call reestablishment attempt within 5 seconds max.:
1) The level measurement samples taken on the serving cell BCCH carrier and on
neigbhor cells carriers (carriers indicated in the BA (SACCH) received on the
serving cell) received in the last 5 seconds shall be averaged.
The carried with the highest average received level is selected.

4119001036
Algorithms
2) On this carrier the MS shall attempt to decode the BCCH data block containing
the parameters affecting cell selection.
3) If the parameter C1 is greater than zero call reestablishment shall be attempted
on this cell.
4) If the MS is unable to decode the BCCH data block or if the call reestablishment
is not allowed, the carrier with the next highest average received level shall be
taken, and the MS shall repeat steps 2) and 3) above.
5) If the cells with the 6 strongest average received level values have been tried but
cannot be used, the call reestablishment attempt shall be abandoned.
Beware, during a reestablishment attempt the mobile station does not return to
idle mode, thus no location updating is performed even if the mobile is not
updated in the location area of the selected cell, however the mobile station will
update its location area at the end of the call.
Generally a call reestablishment procedure lasts from 4 seconds to 20 seconds max.
Note that some TCH can be reserved for Call Reestablisment. For this reason the
priority 0 is recommended for this procedure.
2.8.7 Call Clearing Process (run by BTS) (Cc)
This process is used to drop calls with mobiles which are located too far away from
a serving cell and that may disturb other communications on adjacent time slots.
Every runCallClear:
if (MS_BS_Dist > CallClearing)
then call needs clearing.
2.8.8 Interference Management (BTS and BSC) (If)
All interference measurements performed by the BTS on the idle channels are
performed in Watts. Each sample is computed in Watt before being translated in
dBm and sent to the L1M. This method of calculation provides a result which is
2.5 dB higher than the one directly performed in dB.
Every averagingPeriod, BTS computes Interference levels of idle channels

(SDCCH and TCH) according to the 4 defined thresholdInterference (resulting in
5 Interference ranges) and sends this information to the BSC. It is therefore possible
to monitor interference levels at the OMC.

Algorithms
From V8 (TF131), the BSC will use RadChanSelIntThreshold parameter in order

to sort available channels according to their interference level. Thus the BSC will
allocate channels using the following priority:
Hop and low_IF
NoHop and low_IF
Hop and (high_IF or just released)
NoHop and (high_IF or just released).
2.8.9 DTX
DTX is possible both downlink and uplink, but configuration and activation are
uncorrelated in the 2 mechanisms.
2.8.9.1 DTX uplink
1. Activation
Parameter: dtx mode
The MS can transmit discontinuously if:
dtxmode =msShallUseDtx or msMayUseDtx depending on MS decision or
capability
Object: bts
The MS is allowed DTX uplink.
2. Configuration
When DTX uplink is activated on the network, MS gets the information from the
BTS (activation parameter). Then it is allowed to perform DTX uplink, i.e. to
transmit discontinuously only a subset of TCH bursts.
If the MS perform DTX on a call, the minimum number of transmitted bursts is 12
(out of 104 for a complete reporting period of 480ms).
The 12 bursts correspond to the 4 SACCH + 8 fixed positioned TCH bursts.

4119001036
Algorithms
Compared to a full TCH frame (120ms to be multiplied by 4 for a complete

message):
12 bursts TCH 1 SACCH 12 bursts TCH 1 Idle
The MS will transmit (x4):
1 fixed TCH 1 SACCH 1 fixed TCH 1 Idle
(given fixed positions are only examples; for speech, a SID frame (Silence
Descriptor frame: used to describe comfort noise) made of 8 consecutive TSs shall
be sent at the start of every inactivity period and more are sent regularly, at least
twice per second, as long as inactivity lasts)
Full frame x 4:
(24 TCH + 1 SACCH + 1 idle) x 4 = 96 TCH + 4 SACCH + 4 Idle = 104 bursts.
With DTX:
(1 SACCH) x4 + 8 TCH = 12 bursts minimum.
Then, depending on the communications (presence of silences), the MS can use
DTX or not.
Remark: To the minimum number of bursts (12) can be added other transmitted
bursts depending on some criteria (user traffic activity and
interleaving depth).

Algorithms

12 bursts min. (over 104) +
optional bursts
Algorithm
The MS sends to the BTS 2 kinds of measurements, RxQual/RxLev Full, and

RxQual/RxLev Sub.
RxQual/RxLev Full correspond to an average of measurements performed over

100 out of 104 frames in a SACCH reporting period. These measurements are
valid if DTX has not been used by the MS.
RxQual / RxLev Sub correspond to an average of measurements performed over

12 frames (instead of 100), these 12 frames being fixed as explained previously.
These measurements are valid if DTX has been used by the MS.
With these measurements, the MS has to send to the BTS a notification that it has
performed DTX or not (uplink DTX status), so that the BTS can choose the average
which is valid (RxQual / RxLev Full or Sub) for L1M purposes. This notification
is done via the DTXused bit in the Measurement Report.

1) Measurements downlik (RxLev /
RxQual Full and sub)
2) DTX uplink Status (used or not)

4119001036
Algorithms
2.8.9.2 DTX downlink
1. Activation
In the same way, the BTS can transmit discontinuously.
The activation of downlink DTX follows an algorithm depending on both OMCR
flags and MSC configuration.
1. If CellDtxDownLink = False
DTX is off
2. If CellDtxDownLink = True
DTX activation depends on the contents of the Assign Request or HO request at
the origin of the TCH attachment. Fields concerned are downlink DTX use
and Channel Type:
2.1. If Downlink DTX use field is unset, the DTX is activated
2.2. If Downlink DTX use field appears:
2.2.1. If transmitted data is non transparent, the DTX is activated without further
consideration for the value of Downlink DTX use flag
2.2.2. If transmitted data is voice, the DTX is activated depending on

Downlink DTX use flag (false or true)
Remark: With transparent data, DTX doesnt exist because in this case, it is
difficult to assess when user data transmission can be suspended
without degrading the service.

Algorithms
Assign Request
MSC HO Request
Bts:
cellDTXdownlink
2. Configuration
For the case of downlink DTX, the BTS does not need to notify the MS about the
activation (downlink DTX status). The activation information is stored by the BTS,
and attached downlink measurements sent back by the mobile in order to be
processed by L1M.

1) DTX downlink Status (stored
by the BTS)
2) Measurements uplink
(RxLev / RxQual Full and sub)
performed by the BTS

4119001036
Algorithms
L1M computation summary
As a summary, for L1M purposes, the BTS combines:

uplink DTX Status and downlink measurements sent by the MS in MEASREP
downlink DTX status and uplink measurements done by the BTS
Downlink
1) DTX downlink Status

2) Measurements uplink

Uplink
1) DTX Uplink Status

2) Measurements downlink
L1M

Algorithms
2.9 PCH AND RACH CHANNEL CONTROL
2.9.1 Paging command Process (Pag)
Paging process is triggered by the system when a mobile needs to be found

(incoming calls or short messages) in a location area (LA). The paging command
is broadcast over all the cells of the LA where the mobile is located. In idle mode,
the mobile listens to the broadcast channel (BCCH).
Paging messages are carried by the CCCH which is a subchannel of the BCCH.
It is divided into 3 logical channels:
uplink:
RACH (Channel Request)
downlink:
AGCH (Immediate assignment)
PCH (Paging command)
Four (4) CCCH frames are necessary to transmit a complete paging message due
to bursts interleaving.
For the mobile, listening to the broadcast channels is batteryconsuming. Therefore

the paging messages broadcast has been optimized (Rec 05.08). Instead of listening
continuously to the paging channel, the mobile waits for specific occurrences of
paging message. A set of mobiles are associated to a specific occurrence of the
paging channel, they belong to a socalled paging group.
In order for a mobile to find its associated paging group among N groups, the
following rule is applied:
Nb of paging group = (IMSI mod1000) mod N
Dimensioning the paging means determining the number of paging groups needed
to meet incoming calls requirements inside a specific LAC. Two basic factors are
taken into account:
the number of subscribers
the average amount of paging messages per subscriber ] average number of
subscribers that receive a paging message at the same time.

4119001036
Algorithms
Paging channel configuration:
According to the required number of paging groups, the CCCH configuration is

consequently tuned. This configuration depends on the TDMA model and on 2
parameters:
TDMA Model: is the BCCH combined or not?
noOfBlockForAccessGrant: bts object parameter (class 2)
noOfMultiframesBetweenPaging: bts object parameter (class 2)
1. Consequences of the TDMA Model
The number of CCCH occurrences depends on the BCCH model, i.e., if the BCCH
is combined or not. If the BCCH is combined, there are less Frames dedicated to the
CCCH.
BCCH combined case:
FN 0 1 2 3
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
BCCH
BCCH
BCCH
BCCH
FCCH
FCCH
SCH
SCH
50
SDCCH/4(0)
SDCCH/4(0)
SDCCH/4(0)
SDCCH/4(0)
SDCCH/4(1)
SDCCH/4(1)
SDCCH/4(1)
SDCCH/4(1)
SDCCH/4(2)
SDCCH/4(2)
SDCCH/4(2)
SDCCH/4(2)
SDCCH/4(3)
SDCCH/4(3)
SDCCH/4(3)
SDCCH/4(3)
SACCH/4(0)
SACCH/4(0)
SACCH/4(0)
SACCH/4(0)
SACCH/4(1)
SACCH/4(1)
SACCH/4(1)
SACCH/4(1)
FCCH
FCCH
FCCH
IDLE
SCH
SCH
SCH
BCCH Multiframe representation in combined configuration

When using a TDMA model with BCCH combined, there are 3 occurrences of
CCCH per multiframe of 51 frames.
Nb of first frame of blocks carrying CCCH: 6, 12, and 16.

Algorithms
BCCH not combined case:
FN 0 1 2 3
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
BCCH
BCCH
BCCH
BCCH
FCCH
FCCH
SCH
SCH
4 5 6 7 8 9
50
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
FCCH
FCCH
FCCH
IDLE
SCH
SCH
SCH
BCCH Multiframe representation in not combined configuration

When not combined, a BCCH multiframe carries 9 CCCH occurrences.
Nb of first frame of blocks used for CCCH: 6, 12, 16, 22, 26, 32, 36, 42, 46.
2. Consequences of NoOfBlocksForAccessGrant.
Up to V8, when different than 0, NoOfBlocksForAccessGrant defines the number
of blocks (i.e. the multiple of 4 CCCH occurrences) that are booked to transmit
Immediate Assignment messages. E.g., with BCCH combined, the
NoOfBlocksForAccessGrant describes how many blocks out of 3 cant be used for
paging, because they are reserved for I.A.

4119001036
Algorithms
Example with BCCH combined, and NoOfBlocksForAccessGrant = 1:
CCCH frames: 6-9 12-15 16-19 51
CCCH block booked for AGCH
If NoOfBlocksForAccessGrant = 0, then Immediate Assignment are transmitted as

soon as possible, using the first CCCH block available. When both Immediate
Assignment and paging messages are to be transmitted at the same time, a decision
must be done to choose which message to broadcast.
Moreover, paging messages and Immediate assignment are repeated, so the system
has to deal with fresh paging messages (messages never sent), old paging messages
(messages already sent and so repeated), fresh Immediate assignment and finally
old Immediate assignment.
The following priority table is applied to distribute the CCCH resources:
Priority 1: Immediate assignment message never sent
Priority 2: Paging message never sent
Priority 3: Immediate assignment message already sent
Priority 4: Paging message already sent
The management of paging messages repetition is described in chapter 2.9.4.
From V9, the behaviour of the system depending on NoOfBlocksForAccessGrant
has been changed. The aim was to use when needed the preemption mechanism
which is better than booking a specific CCCH for Immediate Assignment.
If NoOfBlocksForAccessGrant = 0, the mechanism is the same as in V8.
If NoOfBlocksForAccessGrant 0 0, AGCH messages overlap on PCH channels
each time AGCH channels are full. It means that it has been defined to be sure
AGCH will be treated as soon as possible in any configuration. In that case, a new
priority table is applied. This table gives the possibility of a higher priority for
paging messages repetitions if required on the network.
Priority 1: Immediate assignment message never sent
Priority 2: Paging message never sent

Algorithms
Priority 3: Paging message already sent

Priority 4: Immediate assignment message already sent
Note:
See Chapter 3.20 for more information on this parameter advised values.
SMSCB use has some influence on noOfBlocksForAccessGrant value (see
Chapter 4.12).
3. CCCH configuration: consequences of NoOfMultiframesBetweenPaging
This parameter defines the frequency of a paging group occurrence. For instance,
if NoOfMultiframesBetweenPaging = 3, 1 multiframe out of 3 will carry an
occurrence of a paging group.
Using the same example as above with:
BCCH combined, NoOfBlocksForAccessGrant = 1,
NoOfMultiframesBetweenPaging = 2
CCCH frames: 6-9 12-15 16-19 51
A A
A CCCH block carrying paging message for the paging group A
One out of 2 multiframes wont transmit paging messages for the paging group A.
This space is necessary to locate several paging groups.
This parameter is deeply involved in the time needed to establish a call when a
paging message is coming. For instance, if a paging command is to be transmitted
in a paging group P1 just after the paging group P1 occurrence, the paging command
will have to wait for at least NoOfMultiframesBetweenPaging x 240ms to be
transmitted. If NoOfMultiframesBetweenPaging = 8, the time waited to transmit
a paging message can be of 2 seconds without any other delays.

4119001036
Algorithms
From the configuration, paging group occurences are determined . In the previous
example, the paging groups will be split as follows:
CCCH frames: 6-9 12-15 16-19 51
A A
Paging groups numbers: 0 1 2 3 0 1
The following rules applies:
Nb of Paging groups = (na nb) x nc

where na = nb of CCCH groups per BCCH multiframe
nb = NoOfBlocksForAccessGrant
nc = NoOfMultiframesBetweenPaging
Note:
See chapter 3.20 for more information on this parameter recommended values.
NoOfMultiframesBetweenPaging has also an influence on mobile battery
consumption and on reselection reactivity (see Chapter 4.11).
2.9.2 Paging command repetition process (run by BTS) (Pag_rep)

Paging messages are systematically repeated. From V8, three (3) parameters will
manage paging message repetitions:
nbOfRepeat
delayBetweenRetrans
retransDuration
NbOfRepeat defines the number of times a paging message will be repeated by the
BTS.
delayBetweenRetrans defines the number of occurrence between 2 repetitions of
the same paging group.

Algorithms
retransDuration defines the maximum time allocated to broadcast a paging

message.
The following rule is checked at the OMCR:
retransDuration > (delayBetweenRetrans + 1) x nbOfRepeat
This inequality is to insure at least nbOfRepeat paging transmissions when there is
no blocking on paging channel.
(See Chapter 3.20 to find engineering rules to set these parameters)
2.9.3 Request access command process (RA)

RACH are used when mobiles request a channel to establish a communication (both
terminated and initiated calls, see Chapters 5.9 and 5.10). Request management is
configurated (nb of repetitions, time between repetitions...) at the OMCR thanks
to different parameters.
2.9.4 Request access command repetition process (RA_rep)

After sending the initial CHANNEL REQUEST message, the MS starts a timer
(T3120) and listens to AGCH logical channel. When this timer expires and number
of retransmissions does not exceed maxNumberRetransmission (bts object
attribute), the MS repeats the CHANNEL REQUEST.
For phase 1 mobiles , when the timer is started, a random value n is drawn with equal
probability between 0 and N1 where N is:
for the initial access: max (8, numberOfSlotsSpreadTrans)
for next attempts: numberOfSlotsSpreadTrans
T3120 is set so that there are n RACH slots between T1 and the expiry of T3120.
T1 is a fixed delay thanks to the configuration of the BCCH:
before initial access, T1 = 0
after initial access, T1 = 250 ms (for non combined CCCH)
after initial access, T1 = 350 ms (for combined CCCH)

4119001036
Algorithms
V ariable delay f rom 0 to

(numberOfSlotsSpreadTrans1) RACH slots
RA CH First repetition
Fixed Dela y whose va lue

depends on whether or not the
BCCH is combined
tT 1 Time
Figure 22 CASE OF PHASE 1 MOBILES
For phase 2 mobiles , Rec 04.08 have been modified to avoid double allocation (see
engineering rules, Chapter 3.20).
V ariable delay set according

to numberOfSlotsSpreadTrans
RA CH First repetition
Fixed Delay whose value depends

on BCCH configuration and
numberO fSlotsSpr eadTrans
tS tS+ T1 Time
Figure 23 CASE OF PHASE 2 MOBILES

Algorithms
When the timer is started, a random value n is drawn with uniform probability
distribution in the interval [S, S+1, ..., S+T1]:
where T is numberOfSlotsSpreadTrans
where S depends on the BCCH configuration and on T (see Table 21).
numberOfSlotsSpreadTrans S (noncombined S (combined BCCH)

(T) BCCH)
3, 8, 14, 50 41 55
4, 9, 16 52 76
5, 10, 20 58 109
6, 11, 25 86 163
7, 12, 32 115 217
Table 21 TIMER RANGE

4119001036
Algorithms
2.10 FREQUENCY HOPPING
2.10.1 Frequency hopping principles

Basically, Frequency Hopping aim is to spread the spectrum of the signal to
minimise the impact of potential interferers. Frequency Hopping consists in
changing the frequency used by a channel at regular intervals.
In GSM, the transmission frequency remains the same during the transmission of
a whole burst. Thus, it is possible to have different frequencies on each burst of a
frame. The radio interface of GSM uses then slow Frequency Hopping.
According to the type of coupler used in the BTS, two (2) main types of Frequency
Hopping mechanism can be used:
Synthesised mode for Hybrid couplers with duplexers (hopping time slots
can hop on a large band of frequencies).
Baseband mode using Cavity couplers with duplexers (hopping time slots can
hop on a set of frequencies limited by the number of TRXs) Only available with
S4000 BTS.
Remark:
Using frequency hopping allows to adapt and maximise the frequency reuse
pattern efficiency by maximising the capacity in term of offered Erlang/Mhz/km2.
The pattern to use will depend on the available frequency band and the traffic
requirement.
Remark:
It is possible (and recommended) to mix different frequency reuse technique, as
4:12 for BCCH and 1:3 or 1:1 for TCH. Indeed, a traditional 4:12 reuse pattern is
appropriate to a wide spectrum allocation as for BCCH frequency (only one
frequency per cell is needed). However, in order to increase the number of TRX per
cell with a given frequency band, while keeping a low interference level, the only
solution is to use more restricting reuse pattern, as 1:1 or 1:3.
2.10.2 Main benefits of frequency hopping

the higher the number of frequencies in the hopping law, the smaller the Fading
margin taken into account in the link budget (due to Rayleigh fading).
the smaller the mobile speed and the higher the number of frequencies, the higher
the benefit of the frequency hopping.
the higher the number of frequencies in the hopping law, the narrower the Rxqual
distribution. However Rxqual mean remains the same (see figure below). Hence
the Frequency Hopping eliminates the number of bad Rxqual samples but it also
reduces the number of good Rxqual ones.

Algorithms
RXQUAL cdf versus SFH (1km/h, 104 dBm)

cdf = cumulative distribution function
100
90
80
70
60
50
40 NO FH
4 freq
30 8 freq
16 freq
20
10
0
0 2 4 6 8 10
BER %
Increase resistance to Rayleigh fading:

recentred RxQual distribution for slow moving mobiles
better stability of the received signal level (smoothing effect)
Completion of diversity task on uplink and full benefit on downlink
high improvement for areas of weaker signal strength (inside buildings and on
street level)
Resistance to interference
spread of interference over all RF spectrum
spread of interference over time
highly loaded sites benefit from lower load on adjacent sites
more efficient error correction gain from digital processing
2.10.3 Synthesised frequency hopping

Using synthesised frequency hopping, each TX is associated to one FP (TDMA) and
can transmit on all the frequencies. It is used with hybrid coupling systems then
more frequencies than TRXs can be used.
The main issue is to ensure that the frequency BCCH is transmitted all the time (on
all the TS of the TDMA) at a constant power even if there is no call to transmit (no
voice or data burst). This is done by a specific configuration which consists in
dedicating a TRX to the BCCH frequency (so the TDMA called BCCH does
not hop).

4119001036
Algorithms
Generally, the number of frequencies is greater than the number of TRX in order
to have the smallest Fading margin in the link budget.
FH bus
FP1 TX1
FP2 TX2
FP3 TX3
The TDMA configurations in case of synthesised frequency hopping are defined as

follows:
F1 is the BCCH frequency.
the other two TDMA of the cell have the same MA. HSN and MAIO can be
different.
2.10.4 Baseband Frequency Hopping
2.10.4.1 Principle
Using baseband frequency hopping, each TX is dedicated to one frequency and is

connected to all the Frame Processor (TDMA) via the FH bus. It is used with cavity
coupling system. It uses exactly the same number of frequencies as TRXs.
The filling is done by the FP according to the configuration of the TDMA (all the
parameters for the frequency hopping are static and not per call basis; so even if
there is no call the FP knows if it has to transmit on the BCCH frequency).
Moreover the TX can have a carrier filling functionality which is not useful for
the BCCH frequency (Carrier filling is already done by the FP) but which can be
used in case of other frequencies carrier filling with the use of a specific BCF load.

Algorithms
BCCH Freq
FP1 TX1
FP2 TX2
FP3 TX3
FP4 TX4
Filling burst when there is no information

to transmit on the BCCH frequency
Figure 24 BASE BAND FREQUENCY HOPPING MECHANISM
For a given cell with the previous configuration (4 TRX), one Mobile Allocation
should be defined:
MA0 contains all the frequencies except the BCCH frequency (3 frequencies in
the exemple).
The baseband frequency hopping configuration is the following:
hopping on TCH, no hopping on BCCH
TS 0 1 2 3 4 5 6 7
TDMA 0 F1 F1 F1 F1 F1 F1 F1 F1 MAIO = 0
TDMA 1 MA0 MA0 MA0 MA0 MA0 MA0 MA0 MA0 MAIO = 1
with:
MA: Mobile Allocation (list of hopping frequencies for a TRX)
MAIO: Mobile Allocation Index Offset between 0 and (Nb of Freq in MA 1).
F1: BCCH frequency

4119001036
Algorithms
! Caution:
It is not recommended to hop on BCCH frequency when using baseband frequency

hopping, because it can lead to some troubles when downlink DTX or downlink
power control are enabled.
2.10.4.2 Reconfiguration procedure
With the baseband frequency hopping mechanism, it is possible to reconfigure the

frequencies in certain cases. In case of equipment failure/recovery within a TRX,
the BSC starts the reconfiguration process for a Radio Cell which supports
frequency hopping and uses the Frequency Management GSM function.
This function is supported by the TRX and allows the BSC to configure or to reset
a frequency on a TX which is identified by the TEI of the corresponding TRX. The
loss of one TX implies the loss of one frequency (which is not the BCCH) and of
one TDMA (the one defined with the lowest priority) if no redundant TRX.
Two symmetric mechanisms are managed by the BSC to handle the automatic
frequency reconfiguration in the case of frequency hopping cavity coupling BTS:
loss of a frequency: the cell is stopped and restarted with new set of frequencies.
This may lead to release the calls if there is more live TX than
btsThresholdHopReconf.
recovery of all frequencies: an automatic reconfiguration is triggered by the BSC
when all the frequencies are recovered. This may lead to release the calls.
There will be a reconfiguration if the flag bscHopReconfUse = True (defined at BSC
level) and if there are more frequencies than the threshold btsThresholdHopReconf
(defined at BTS level). Otherwise the cell is badly configured.
When a end of fault occurs if the flag btsHopReconfRestart = True and if there are
more frequencies than the threshold (btsThresholdHopReconf), there is a complete
cell reconfiguration.

Algorithms
2.11 BSC OVERLOAD MANAGEMENT MECHANISMS

The aim of such a feature is to avoid BSC restart or crash because of overload
conditions.
Without defense mechanism, an overload of one of the BSC boards will imply a
suicide of the active chain, a switch to the passive chain and at last a suicide of the
new active chain. This implies a suppression of all the communications and an
interruption of service.
2.11.1 Mechanism up to V.11

In order to avoid a restart of the BSC, four different overload management
mechanisms ensure that if there is more mobile subscriber activity than the BSC can
cope with, requests of the BSC are rejected (for example mobile originated calls):
CPUMPU/BIFP overload management mechanism
CPUSICD&SICD8V overload management mechanism
OMUSUPSWC overload management mechanism
BSCB overload management mechanism
These overload management mechanisms are based on the following principles:
Each board monitors its own load and makes decisions independent of all others
Based on estimated CPU load for MPU/BIFP (predictive mechanism) only used
for traffic reason
Based on current CPU load only for SICD board
Memory resources not supervised (except for OMUSUPSWC and BSCB
V08_01E11)
BSCB / TSCB / OMU boards not monitored
2.11.1.1 CPUMPU/BIFP overload management mechanism
Principle
This mechanism is based on a counter which is incremented on the estimated
processing cost of various procedures (Mobile Originated calls, Mobile Terminated
calls, Location Updating, external Handover incoming, Paging Request) on each
CPU (MPU and BIFP). When the counter reaches a predefined value, new
transactions are refused according to an increasing defence level (or priority level).
A timer (Trec = 2sec) is triggered between two successive defence levels to wait
for corrective effect of previous level before incrementing defence level. Hence, if
the estimated load is lower than overload threshold, then current defence level is
unblocked each second according to decreasing defence level.

4119001036
Algorithms
Even if a cost is counted when a Rach is refused, an important flow of Rach may
increase significantly the BIFP load. From V10.4 on, three new thresholds have
been added (level 5, 6 and 7) to protect the BIFP boards by filtering Rach at SICD
level.
There are seven levels of priority.
1) Filtering of Paging Response & PagingRequest (i.e. MTC are the first to be
barred)
2) Filtering of Location updating
3) Filtering of any other random access (Mobile Originated calls) excluding
emergency calls
4) Filtering of incoming external handover (last to be barred)
5) Filtering of 25 % of Rach (at SICD level)
How does it work ?
When the BIFP stays more than two seconds (Trec) at overload level 4, the
mecanism enters in overload level 5. Two seconds after if the overload condition
is still verified, the mecanism enters in overload level 6. The same behaviour applies
to the transition 6 to 7. At each transition, a message is sent by the BIFP board to
all SICD boards in order to reduce the numbers of RACH whatever their content.
This GSM elementary procedures reject order can neither be changed by an operator
nor by Nortel System Upgrade teams.
Two parameters can be set, the counter threshold (A) and the counter decrement step
value (K).
The transactions do not all take the same ratio of MPU/BIFP CPU processing. This
may vary significantly depending on the call profile and the BSC type (1 or 2 BIFP).
Parameters must be set for each BSC because the call profile depends on the location
of the cells (on the border of an LA for example). For this reason a call profile
must be defined for each BSC.
From Version 8 the OMCR provides predefined values for CPU load as defined
in the following table.

Algorithms
Parameter K S = 2K A % of the theoretical CPUBIFP

value mean load
CPU120/C CPU66
PU133
0 10240 20480 8000 80
1 8960 17920 7000 70
2 7680 15360 6000 60
3 6400 12800 5000 50
4 5120 10240 4000 40
5 3660 7320 2850 29 80
6 3200 6400 2500 25 70
7 2740 5480 2150 21 60
8 2250 4500 1790 18 49
9 1830 3660 1430 14 40
Where:
K is the maximum load one BIFP board can support. This is defined to ensure that
the mean load will not exceed x% of the CPU. The algorithm uses it as the
decrement steps for each evaluation.
A is the threshold above which an overload situation is declared.
S=2K is the lower boundary considered for instantaneous CPU load.
Choosing parameters :
Use the subscriber profile to calculate the BIFP and MPU load. The parameters
selected depend on whether the BIFP or the MPU is more heavily loaded, as shown
in the two examples below. Then the parameter processorLoadSupConf is set at
the OMCR.
Example 1
According to a specific call profile, the BSC capacity tool gives the load repartition
on the two entities as follows: BIFP = 70% ; MPU = 50%
According to the previous table, the parameter (which indicates the BIFP load) to
choose is: parameter = 1 for a CPU 120 or parameter = 6 for a CPU 66
Example 2
According to a specific call profile, the BSC capacity tool gives the load repartition
on the two entities as follows: BIFP = 50% ; MPU = 70%
According to the previous table, the parameter (which indicates the BIFP load) to
choose is: parameter = 3 for a CPU 120 or parameter = 8 for a CPU 66
The load repartition between BIFP and MPU will be determined by processing the
call profile and the load of elementary procedures.

4119001036
Algorithms
In Example 1 the observation counters will show a 70% load for the BIFP when the
overload mechanism is activated.
In Example 2 the overload mechanism will be activated when one of the two BIFPs
reaches 50%. This doesnt mean that the MPU load will be at 70%; both BIFP
boards must be loaded to 50% simultaneously for the MPU to be loaded to 70%.
Therefore you need to be careful how you interpret the observation counters.
Defence against BSC pingpong switchover (V10.4 & from V11 on)
Following a chain restart or a BSC switchover, the BSC is considered at this time
in a virtual overload situation (the BIFP overload mecanism is initialized with a
level 7) during 30 sec, before to unblock incoming traffic by successive level (i.e.
progressive rising of CPU load due to traffic management).
That means for the incoming traffic to be totally unblocked 37sec after a
BSC switchover !
By this way the BSC is protected against pingpong switchover.
2.11.1.2 CPUSICD&SICD8V overload management mechanism
Principle
This mechanism is based on the control of message flow generated:

by the call establishments, by intercepting the establishment attempts (RACH) in
the SICD(/SICD8V) to suppress all messages consecutive to this RACH
normally exchanged by the SICD(/SICD8V). Note the ermergency calls are also
rejected.
by the SMSCell Broadcast, by suppressing the message in the SICD(/SICD8V).
by the paging.
by intercepting the paging request in the SICD(/SICD8V).
by limiting the message flow at the BIFP level between the BIFP and the SICD
(but not the SICD8V board) board to 100 (resp. 80 from V10.4 on) paging
messages every 2 sec consecutively.
None of the previous messages are accepted (not rejected) if the mean load during
the 2 previous seconds was higher than 100%.
The previously underlined values can be modified at the OMC level by NMC TAS
through the BSC configuration table (in the BSC Data Configuration files).
This algorithm still does not take into account the load from O&M, from Call Trace
and Call Path Tracing (the load due to these procedures has not been quantified),
from software downloading.

Algorithms
Consequently in the case of excessive load generated from theses O&M procedures,
SICD Overload management mechanism can be triggered. The result of this is a
decreasing traffic signalling (not a descreasing O&M signalling...).
Moreover, the SYS INFO emission is shifted in time (emission at time t for the first
cell and at time t+1 for the second one and so one) in order to avoid that all the SYS
INFO messages are emitted all at the same time.
Remark:
Since a SICD is limited to 23sec before a trap, the overload control mechanism
will attempt to limit the maximum overload period to 22sec.
A peak load of up to 100% during a few seconds (< 22sec) is a normal situation.
Problems only occur when the load is kept to 100% during 23sec consecutively.
Note on SICD&SICD8V overload
When the BSC triggers its SICD Overload mechanism, the following events are
filtered:
RACH: this mechanism decreases the peak load but induces some repetitions
which are more and more stressful for the BSS,
PAGING: the same remark as above could be made.
These situations induce a lower Quality of Service which is directly perceived by
endusers.
To sum up, the purpose of SICD Overload mechanism is to ensure the BSS
robustness only, and the purpose of the Eng rules is to ensure the overall network
quality of service. In other words, the activation of this overload mechanism does
not prevent from applying proper engg rules.
2.11.1.3 OMUSUPSWC overload management mechanism
Principle
To establish a phone call and to execute an handover (whatever its type), connexion
orders are sent by BIFPTMG through OMUSUPSWC slave mechanism :
1) BIFPTMG sends a connexion request to OMU,
2) OMU buffers the sending connexion request and sends it to SUP if previous
acknowledgement request has been received by SUP board,
3) SUP board transfers the MB2 based OMU frame to HDLC based SWC frame,
SWC establishes links within its switching matrix.
4) SUP sends an acknowledgment to the OMU board which can send another
connexion request...

4119001036
Algorithms
If this mechanism is not wellslaved, connexion request can potentially be queued

in the OMU (before emission) during a certain amount of time...
Thus the OMUSUPSWC Overload is based on the estimated degradation of
Quality Of Service inherent to message management through OMUSUPSWC
chained boards.
The OMU message waiting queue (inherent to OMUSUP message management)
is divided into two regions: near capacity (1 < nbOfWaitingMsg < 10 ) and above
capacity (10 < nbOfWaitingMsg).
The mechanism implemented allows to count the number of waiting frames in the
OMU buffer and to associate a virtual load to the SUP ; a reject mechanism
(implemented in the BIFP) corresponds to this virtual load:
If the average number of waiting messages is near capacity (1 <
nbOfWaitingMsg < 10 ) on 3 consecutively seconds, those following messages
are not accepting on the current second at the BIFP level: Channel_Required (all
the new call establishments, including Location Update and Paging_Response
except emergency calls)
If the average number of waiting messages is above capacity (10 <
nbOfWaitingMsg) on 3 consecutively seconds, those following messages are not
also accepting on the current second at the BIFP level :
Channel_Required (all the new call establishments, including Location
Update and Paging_Response except emergency calls)
Handover_Indication (for handOver intraBSC)
Handover_Request (for incoming handOver interBSC)
Associated observation counters :
SUP_OVERLOAD_REJECT_CALL (1703)
screening0:Channel_Required (paging response)
screening1:Channel_Required (excluding emergency Calls and
Paging_Response)
screening2:Handover_Indication (for handOver intraBSC) and
Handover_Request (for incoming handOver interBSC)
SUP_OVERLOAD_HOLD_TIME (1704)
screening0:Overload holding time during filtering of Channel_Required
(paging response)
screening1:Overload holding time during filtering of Channel_Required
(excluding emergency Calls and Paging_Response)
screening2:Overload holding time during filtering of Handover_Indication
(for handOver intraBSC) and Handover_Request (for incoming handOver
interBSC)

Algorithms
Alarm triggering:
Each BIFP generated the OMUSUPSWC alarm when it detects an overload
situation.
The alarm management is similar to BIFP overload alarm triggering:
beginning of alarm triggering when overload situation during consecutively 8
seconds (i.e. more than 1 message in the OMU waiting queue each second during
consecutively 8 seconds)
ending of alarm triggering when no overload situation during consecutively 8
seconds (i.e. less than 1 message in the OMU waiting queue each second during
consecutively 8 seconds)
Remark:
From V11.3 on, code optimization has been done to increase the number of
connexion request to be sent within a single OMUSUP frame (which decreases
in fact the number of connexion orders in the OMU waiting queue). Therefore
OMUSUPSWC Overload threshold can be raised...
2.11.1.4 BSCB overload management mechanism

Capacity overview
As the information exchanged on LAPD channels are made at 64Kbit/s, the highest
rate can reach 64 x 4 = 256 Kbit/s in the case of the concentrated links, which should
require in this case more than the maximum channel capacity available for this type
of link: 64 Kbit/s. Its obviously impossible.
On each BSCB link, buffer sized to 30 messages is used to store messages if the
server is busy.
Principle with firmware V08_01E06 release
When the CPU load on the BSCB is equal to 100% during at least 2sec (overload
during 2sec), a BSCB reset, initiated by ECI board is done, and a switch to a
redundant BSCB board is triggered without service loss.
In some cases, this peak load is transferred to the redundant board which should also
be resetted.
This can lead to a service interruption on all Sites concentrated by this BSCB.
Because no overload management mechanism was implemented within this
firmware release, BSCB engg limit threshold recommanded in the BSC Capacity
Tool is 40% !
Remark:
As 300 applicatives msg/s correspond to 80% of CPU load, all dimensioning aspect
with BSCB prom V08_01E06 should be done with 150msg/s maximum limit (40%
of the max processing limit before discarding some items).

4119001036
Algorithms
Principle with firmware V08_01E11 release

A Local Control Method has been implemented in this firmware release :
Each second the CPU load is monitored: the peak load on the the BSCB can be
equal to 100% during infinite time without BSCB reset triggered by ECI board.
Each second the memory ressources are monitored:
when 80% of memory resources occupancy has been reached, an alarm
beginning of congestion is triggered
when 100% of memory resources occupancy has been reached, additional
events must be discarded
when memory resources occupancy has been decreased below 25% , an alarm
end of congestion is triggered
Remark:
When an alarm is triggered, it does not mean messages have been discarded.
In Overload situation, BSCB board will always remain operational and in the
worst case, will discard messages.
As the LAPD protocol repeats 3 times to send a same message before
disconnection, discarding a message is not very important but should be in the
case of LAPD disconnection
A Local Control Method based on monitored resources leads to a robust and
reliable system. It is now possible to use this board at 100% CPU load without any
risk that the
board restarts. The BSCB robustness increases significantly.
The software has been optimized and can now handle 600 applicative messages per
second (1200 HDLC frames per second if we take into account the LAPD RR
frames) without any event trashed.
The monitoring of CPU load and memory ressources makes this prom ready for
V12 Overload management mechanism based on real load feature...
Because of this new overload management, the BSCB threshold recommanded in
the BSC Capacity Tool can be increased up to 70%.
Remark :
As 600 applicatives msg/s correspond to 100% of CPU load (without any events
discarded), all dimensioning aspect should be done with 420msg/s maximum limit
(i.e. 70% of the max processing limit before discarding some items).
2.11.2 Mechanism defined from V12 on

Except for the BSCB&TSCB local Overload control mechanism, previous
mechanisms are superseeded by this new one based on a centralized overLoad
control method.

Algorithms
This overLoad management mechanism is based on the following principles:

Current CPU load for MPU / BIFP / OMU / SICD and memory resources are
supervised (including also OMUSUPSWC chained boards)
Resources fluctuation trends are analysed and taken into account for anticipation
purpose
Each board monitors its own load and neighboring involved board load, and
makes decisions dependent of all others
Decisions are taken only on traffic stimuli, not O&M stimuli
Such a mechanism is able to take into account not only traffic CPU load but O&M
CPU load and to trigger an upstream or downstream protection (but based only on
traffic stimuli).
2.11.2.1 Principle
Local card synthetic load
Based on a 3sec average, a local card synthetic load is generated each second by
each board. This synthetic load is given as the result of:
the CPU load occupancy,
the memory resource occupancy,
the resources fluctuation trends (only positive variations of CPU/memory
occupancy values according to the previous one are taken into account for
anticipation purpose)
For a given board, the synthetic load is based on the maximum between CPU load
and memory resources, balanced, accelerated by the difference between the last past
2 seconds if the load is higher than 50% and lastly averaged on the last past
3 seconds.
Remark: CPU or memory resource occupancy is corrected to give the higher

weight to the more critical factor (i.e. a lack of timer may lead to a BSC
switchover, thus timers have a weighting factor more important than
CPU load).
Local card overLoad level
This local card synthetic load, compared with the overLoad threshold value
associated with current board, is converted into a local card overLoad level [levels
0..3] and sent to a centralized overLoad control task located on the OMU board.
OMUSUPSWC chained boards

4119001036
Algorithms
The load of the OMUSUPSWC chain is affected only by the number of switching
connection messages received at the OMU level and transmit to the SWC via the
SUP board. Each second, the overLoad level of the chain is evaluated using the
number of switching messages in the OMU waiting queue:
if there was 1 message in average in the last 3 seconds, then the overLoad level is
equal to 1,
if there was 10 messages in average in the last 3 seconds, then the overload level
is equal to 3.
Remark: Level 2 is not applicable for the OMUSUPSWC chain.
GSM Object & Operation overLoad level

Thus firstly, this centralized task collects and computes different overLoad levels
to determine:
the overLoad level of each cellGroup, showing the overLoad level of each BIFP
board (used for instance by TMG to select BIFP board to propagate a
pagingRequest from AI/F or an incoming external handover)
the overLoad level of each CELL, showing the highest overLoad level between
SICD boards handling this GSM object instance
the overLoad level of each SITE, showing the highest overLoad level between
the overLoad level of each TCU, showing the highest overLoad level between
Computed information redistributed

Then secondly, this centralized task collects and computes different overLoad levels
to determine the overLoad level of the operation family (i.e Paging Request,
Network Access, Location Updating...) indicating the highest overLoad level
between potentially impacted boards OMU / MPU / SICD / BIFP /
OMUSUPSWC.

Algorithms
OverLoad level control

Lastly, before processing any operation, each board (i.e. each applicative task
located on this board, impacted by this operation) must check:
its local overLoad level,
the overLoad level associated to the current operation,
the overLoad level of the impacted object instances
Example:
Before processing a pagingResponse at BIFP level, TMG (TMGRAD and
TMGCNX located on BIFP board) checks:
its local overLoad level (i.e.its own overlLoad level... at BIFP level)
the overLoad level of the network access operation family (i.e. overLoad
levels of OMUSUPSWC, OMU and MPU boards involved)
the overLoad level of the each CELL impacted by this operation (i.e. overLoad
levels of the impacted SICD board)
List of the operations to be filtered

Despite the fact, this mechanism is defined as a centralized overLoad control
method, actions are triggered at local level (i.e. by each board).
Following actions can be done only on traffic reduction purpose according
overLoad level and operation type:
overLoad level 1: traffic reduction around 33% by filtering 1 request out of 3 of
the following messages:
Paging Request,
Channel Request with cause different from Emergency call,
All First Layer 3 messages with cause different from Emergency call,

4119001036
Algorithms
HandOver for traffic reason,

HandOver for O&M reason,
directed retry.
overLoad level 2: traffic reduction around 66% by filtering 2 requests out of 3 of
the previous messages.
overLoad level 3: no new traffic is accepted by screening all previous and
following messages:
All First Layer 3 messages,
All Channel Request (including causefor Emergency Call),
All Handover Indication,
All Handover Request.
Remark: When communications need to be filtered to reduce the load of the

BSC, it can be done for all the BTSs or CELLs supported by the
overLoaded board !
2.11.2.2 Protection at starting or switching
During the first 30mn of a BSC restart, all thresholds are decreased by 30%, in order
to give more power to the O&M operations.
When a BSC is in simplex mode, all thresholds are decreased by 20%, in order to
reduce the risk of outage in this phase.
2.11.2.3 Choosing parameters
The overload threshold levels is determined by one parameter,

processorLoadSupConf, settable by the operator.
Engineering recommends to use the nominal (0) value whatever the Call
Profile is.
Three overload levels are defined in the BSC. Each level corresponds to the load
level of the BSC processors. According to the overload level , some amount of new
traffic requests are filtered (nominal parameter):
level 1: 80% of processor load ; 33% of offered traffic is filtered
level 2: 90% of processor load ; 66% of offered traffic is filtered
level 3: 100% of processor load ; no offered traffic is accepted
Remark: There are additional values that are defined as well. They correspond
to special operational modes, like loss of redundancy, BSC restart
mode, exceptional events generating huge traffic (3 to 5 times the
normal busy hour traffic).

Algorithms
2.11.2.4 Capacity impact
As new overLoad mechanism is based on real measurement, robustness has been

increased as rejected rate for incoming calls. In other terms, same traffic can be
carried by the BSC but with higher rejected rate for incoming calls.
2.11.2.5 Alarm notification
Previous alarm notification numbers 1255 (SUP Overload) and 1263 (BIFP
Overload) are superseded by this new one: 1490 BSC OverLoad.
This alarm is triggered for the first card which is in overLoad level 3 for 5sec at less
and ended when all cards are under the OverLoadLevel 3 for 5sec at less.
Remark: OverLoadLevel 1 or 2 can be reached for a certain amount of time (>

5sec) without any alarm triggering !
2.11.2.6 Associated observation counters

C1835
average and maximum of synthetic load for boards CPUM(OMU),
CPUE(MPU&BIFP), SICD
C1506: per MPU (TMG_MESsage)
C1506/0: number of rejected Paging Request
C1506/1: number of rejected interBSC Incoming HO
C1803: per BIFP (TMG_RADio)
C1803/0: number of rejected Paging Request
C1803/1: number of rejected Channel Request
C1803/2: number of rejected Establish Indication
C1803/3: number of rejected HandOver Request
C1834: per SICD
C1834/0: number of rejected Channel Request

4119001036
Algorithms
2.12 CABINET OUTPUT POWER SETTING

This section aims at describing the way to determine the output power of a BTS
knowing its coupling and its associated parameter setting. As described in
Figure 25, two OMC parameters are involved: bsTxPwrMax (powerControl
object) and from V9, attenuation (btsSiteManager object).
2.12.1 Cabinet power description
(OMC) Attenuation (since V9)

DLU Attenuation
(until V8)
OR
TX
Antennae
Translation connector
bsTxPwrMax Pc Pr Coupling
S
table Ps
System
* Pc=bsTxPwrMax + DLU/OMC Attenuation

* A translation table gives Pr
* Ps = Cabinet output power
Figure 25 POWER IN CABINET DESCRIPTION
There are three steps in the cabinet output power evaluation.

Algorithms
2.12.2 Pr computation
This is the table for correspondance between the bsTxPwrMax and the Pr for S8000
product (in function of the coupling system).
S8000
Coupling system Dp TxF H2D H4D
DLU attenuation or 1 1 4 8
OMC attenuation
BsTxPwrMax Pr Pr Pr Pr

51 Nack Nack Nack Nack
43 Pmax Pmax Nack Nack
42 Nack Nack
41 Pmax 2 Pmax 2 Nack Nack
40 Pmax Nack
39 Pmax 4 Pmax 4 Nack
38 Pmax 2 Nack
37 Pmax 6 Pmax 6 Nack
36 Pmax 4 Pmax
35 Pmax 8 Pmax 8
34 Pmax 6 Pmax 2
33 Pmax 10 Pmax 10
32 Pmax 8 Pmax 4
31 Pmax 12 Pmax 12
30 Pmax 10 Pmax 6
29 Nack Nack
28 Nack Nack Pmax 12 Pmax 8
27 Nack Nack
26 Nack Nack Nack Pmax 10
25 Nack Nack Nack
24 Nack Nack Nack Pmax 12
23 Nack Nack Nack
0 22 Nack Nack Nack Nack
Table 22 PR VS BSTXPWRMAX

4119001036
Algorithms
BTS (V9+) => S4000 (except 30W GSM 1800)

S2000 (E) / S4000 smart
S4000 smart S2000E S4000Indoor S4000Indoor S4000Outdoor S4000Indoor
S4000Outdoor S4000Outdoor S4000Indoor (25W)
Coupling system => Smart Dp Cavity Cavity H2D H4
Dp Dp H2/H2D/Dp
DLU attenuation or 0 1 2 3 4 7
OMC attenuation =>
bsTxPwrMax Pr Pr Pr Pr Pr Pr
51 Nack Nack Nack Nack Nack Nack
44 Pmax Nack Nack Nack Nack Nack
43 Pmax Pmax Nack Nack Nack Nack
42 Pmax2 Pmax Pmax Nack Nack Nack
41 Pmax2 Pmax2 Pmax Pmax Nack Nack
40 Pmax4 Pmax2 Pmax2 Pmax Pmax Nack
39 Pmax4 Pmax4 Pmax2 Pmax2 Pmax Nack
38 Pmax6 Pmax4 Pmax4 Pmax2 Pmax2 Nack
37 Pmax6 Pmax6 Pmax4 Pmax4 Pmax2 Pmax
36 Pmax8 Pmax6 Pmax6 Pmax4 Pmax4 Pmax
35 Pmax8 Pmax8 Pmax6 Pmax6 Pmax4 Pmax2
30 Nack Pmax12 Pmax12 Pmax10 Pmax10 Pmax6
29 Nack Nack Pmax12 Pmax12 Pmax10 Pmax8
28 Nack Nack Nack Pmax12 Pmax12 Pmax8
27 Nack Nack Nack Nack Pmax12 Pmax10
26 Nack Nack Nack Nack Nack Pmax10
0 > 22 Nack Nack Nack Nack Nack Nack
Table 52bisPR VS BSTXPWRMAX
Note: Codano 1067 The Tx has not acknowledged the power consign request.

Algorithms
In the previous table, we could see that Pmax is obtained for:
Bts Type bsTxPwrMax

S8000 Dp 42 or 43
S8000 Tx Filter 42 or 43
S8000 H2D 39 or40
S8000 H4D 35 or 36
Table 23 BSTXPWRMAX VS BTS TYPE
2.12.3 Ps computation
Then, the effective cabinet output power is:
Ps = Pmax (+/ 0.5dB) Lcables Lcoupling
2.12.3.1 Power Amplifier 30W
The nominal output power output for PA is 44.8 dBm (+/ 0.5dBm). This nominal
output is the same for all frequencies.
2.12.3.2 Coupling system
To know the input power, its important to know the system coupling losses:
Max guaranted losses (dBm)

GSM 900 GSM 1800 GSM 1900
Duplexeur (Dp) 1 1.2 1.2
Tx FILTER (TxF) 1 1 1
H2D 5 5 5
H4D 8.5 8.5 8.5
2.12.3.3 Cables loss
RF/IO Cable
It is the RF cable connecting the Antenna connector of the duplexer to the output
connector (to connect the antenna feeder).
Each cable is specifically dedicated to a frequency band. This particularity is due
to the quarter wave lightning protector which must be adapted to the frequency
band. This quarter wave is evenly a protection against lightning.

4119001036
Algorithms
S8000 Example:
Maximum insertion attenuation (guaranted):
GSM 900: 0.2 dB Outdoor BTS, 0.25 dB Indoor BTS
GSM1800&1900: 0.3 dB Outdoor BTS, 0.35 Indoor BTS
Characteristic impedance: 50
Total length: 290 mm
Maximum cable diameter: 7 mm
Cable between PA and coupling system
It is the RF cable connecting the PA (Power Amplifier) output connector to the input
connector of the Hybrid combiner.
S8000 Example:
Maximum insertion attenuation (guaranted):
Cable total length: L 305 mm
GSM 900 0.25 dB Outdoor BTS, 0.35 dB Indoor BTS
GSM1800&1900: 0.40 dB Outdoor BTS, 0.5 dB Indoor BTS
Characteristic impedance: 50
Maximum cable diameter: 5.5 mm

Algorithms
2.12.3.4 Ps Computation
Losses coupling Losses in the cables Total losses

900 1800&1900 900 1800&1900 900 1800&1900
Diplexeur 1 1.2 0.2 0.25 = 0.45 0.3 0.4 = 0.7 1.45 1.9
TxFilter 1 1 0.2 0.25 = 0.45 0.3 0.4 = 0.7 1.45 1.7
H2D 5 5 0.2 0.25 = 0.45 0.3 0.4 = 0.7 5.45 5.7
H4D 8.5 8.5 0.2 0.25 = 0.45 0.3 0.4 = 0.7 8.95 9.2
Table 24 S8000 OUTDOOR
Losses coupling Losses in the cables Total losses

900 1800&1900 900 1800&1900 900 1800&1900
Diplexeur 1 1.2 0.25 0.35 = 0.6 0.35 0.5 = 0.85 1.6 2.05
TxFilter 1 1 0.25 0.35 = 0.6 0.35 0.5 = 0.85 1.6 1.85
H2D 5 5 0.25 0.35 = 0.6 0.35 0.5 = 0.85 5.6 5.85
H4D 8.5 8.5 0.25 0.35 = 0.6 0.35 0.5 = 0.85 9.1 9.35
Table 25 S8000 INDOOR
Example:
Calculation for S8000 Outdoor coupling diplexeur GSM900
Ps = 44.8 (+/ 0.5dB) (0.2+0.25) 1= 43.35dB (+/0.5dB)
Calculation for S8000 Indoor H2D GSM1800
Ps = 44.8 (+/0.5dB) (0.35+0.5) 5 = 38.95 dB (+ /0.5dB)

4119001036
Algorithms
2.13 DUAL BAND HANDLING

The purpose of this feature is to allow an operator with licenses in several frequency
bands to support the use of multiband mobile stations in all its bands. In addition,
it also allows the operator to support the use of single band mobile stations in each
band of the license. The specification indicates that GSM900 and GSM1800
frequency bands can be combined. No frequency band is treated as the primary
band. However, parameter setting can help multiband MS to give a higher priority
to one of the bands.
! Caution:
It has been experimented that with some mobile brands a delay in the other band
neighbor cells reports occurs, i.e.: a minimum time is necessary for those mobiles
to send measures from neighbors transmitting of the other band to the current cell.
2.13.1 Multiband mobile station

A multiband mobile station is a mobile station which:
supports more than one band
has the functionality to perform handover, directed retry, channel assignment,
cell selection and cell reselection between the different bands in which it can
operate (within the PLMN)
has the functionality to make PLMN selection in the different bands in which can
operate
has 2 receivers, one specific to each band
has 2 transmitters, one specific to each band
2.13.2 Impact on existing procedures

One message has been modified (SYS INFO 3), two new SYS INFO messages have
been created (SYS INFO 2ter and 5ter).
2.13.2.1 Modified SYS INFO 3

Two new fields have been added to SYS INFO 3:
Early_Classmark_Sending_Control: it indicates if multiband MS is authorized
to send the early Classmark Change message to the BSC via the BTS. This allows
the MSC to receive as soon as possible the multiband information and to pass it to
the target BSC. It will speed up call setups and allows to perform Handover and
directed retry when needed. The Classmark Change indicates the frequency
bands supported by the MS and MS power classes to perform HO procedures in
the best conditions.

Algorithms
The corresponding parameter is the class 3 attribute early classmark sending

belonging to bts objects. If it is set to enabled, the Classmark_Change message
is sent just after the SABM and UA frames exchange on the Immediate_Assignment
procedure. This message makes interband handover procedures possible. In single
band networks, early classmark sending will be set to disabled.
Note: Indeed monoband network may forbid a dual band mobile to use the Early
Classmark sending procedure in order to prevent phase 2 mobiles to send
useless information to the network, and to cope with any potential problems
with this feature in the mobiles.
Sys_Info_2ter_Indicator: it is used to inform multiband MS that SYS INFO 2ter

information is available.
2.13.2.2 New SYS INFO messages

The neighbouring cell lists for handover and cell reselection are broadcast towards
multiband and single band mobile stations. The frequencies of neighbouring cells
in other frequency bands than the current cell will be carried by new SYS INFO
messages:
SYS INFO 2ter for reselection neighbours.
SYS INFO 5ter for handover neighbours.
A single band mobile station will only use frequencies from SYS INFO 2 and 5 and
if necessary, 2bis and 5bis for reselection and handover purposes, i.e. frequencies
from the frequency band it supports. The BSC selects neighbour cells from the other
band out of the neighbour list and sends them in SYS INFO 2ter and 5ter (see table
below).
Sys info 2 Sys info 2bis Sys info 2ter

Sys info 5 Sys info 5bis Sys info 5ter
GSM900 cell GSM900 nei list GSM1800 nei list
GSM 1800 cell GSM1800 nei list GSM1800 nei list GSM900 nei list
Neighbour cell list in SYS INFO

The new SYS INFO 2ter and 5ter messages carry parameters which are needed by
multiband mobile stations to perform respectively cell reselection (2ter) and
handover (5ter) towards cell from another band:
Multiband Reporting: indicates to multiband MS the minimum number of cells
to report in their measurement report outside the current frequency band. Its
value is equal to the Multiband reporting parameter in the SYS INFO 5ter
message.
Neighbouring Cells List: coding of the frequencies of neighbouring cells.

4119001036
Algorithms
! Caution:
1) Some single band mobiles are disturbed by the receipt of SYS INFO 5ter. They
react by sending an RR status message, that can load the BSC. To avoid this, the
sending of these messages is controlled by the BTS. On the opposite, single band
mobile stations are not disturbed by 2ter messages because they ignore them.
2) No field called Sys_Info_5ter_Indicator exists. To know if 5ter messages are
sent, SACCH filling messages are used.
3) The parameter CellBarQualify is not used by some dual band MS in selection
and reselection algorithms.
2.13.2.3 Multiband reporting
Multiband mobile stations report cells from different frequency bands according to
Multiband Reporting parameter (corresponding to class 3 attribute multi band
reporting of bts objects) broadcast in SYS INFO messages:
the six strongest cells: default value. The multiband MS reports the six strongest
allowed cells regardless of the frequency band.
1, 2, 3: the multiband MS reports the strongest or the two, three strongest allowed
cells outside the current frequency band. The remaining space in the report is
used to give information about cells in the current frequency band. If there are
still some remaining positions (not enough neighbours in the current frequency
band), these positions are used to report cells outside the current frequency band.
! Caution:
A maximum of six cells will be reported. Only a maximum of n best cells
(according to the L1M algorithm) will be transmitted to the BSC by the L1M in a
Handover_Indication message (n = 3 before V12 ; n = 6 from V12).
2.13.2.4 Other procedures
The handling of multiband MS did not need specific changes in L1M. Main changes
are on MS side. However, main procedures can be reviewed with the differences that
occur in V10.
PLMN selection:
A single band MS only selects a PLMN from its frequency band. A multiband MS
can select PLMNs of both bands.
Cell selection & reselection:
A single band MS only selects or reselects cells from its frequency band. A
multiband MS can select or reselect cells of both bands. Priority can be given to
one band (see chapter 1).

Algorithms
Handovers:
A new attribute is introduced in both adjacentCellReselection and
adjacentCellHandover objects. Its name is standardIndicator Adjc and tells the
type of network where the neighboring cell operates (gsm or dcs or gsmdcs or
dcsgsm).
A single band MS only performs handovers towards cells from its frequency band.
A multiband MS can perform handovers towards cells of both bands if classmark
3 is supported on NSS side (GSMO7).
If local mode directed retry is chosen, as it is performed towards a specific
neighbour, one type of single band MS (the one which does not support the
frequency band of adjacentCellUmbrellaRef) will not use this feature.
For multiband MS, formulas like PBGT or thresholds are the same as single band
ones, their power class is replaced according to the band of the cell they are in.

4119001036
Algorithms
2.14 CPU/BIFP LOAD SHARING

Before V.12, the CPUBIFP load sharing was based on the lowest number of TEI.
As a consequence, if the TRX1 supporting an important traffic is on CPUBIFP1
while the TRX2 with less traffic is on CPUBIFP2, then an addition of a third TRX
was attributed on CPUBIFP1, so there was an unbalanced load on the 2 CPUBIFP
boards.
It is why this feature has been introduced in V.12.
2.14.1 Feature principle

Before any site creation, the operator has the choice:
Either to let the BSC determine the BIFP board (old method),
Or to attach the new site to a BIFP according to the BIFP boards load and the site
configuration. (new method)
To determine the BIFP board identity, operator can:
Either use the observation counter,
OR use the engineering tools CT5000/CT7000 that share automatically the sites
over the 2 BIFP boards.
Remark:
For this new feature a new parameter (CpueNumber) has been introduced. To see
the values taken by this parameter, have a look at algorithm parameters.
This feature is only useful for BSC with several BIFP boards, i.e. type 3, 4 and 5
BSC.
Because the maximum number of objects per BSC does not change, a control by
OMCR is done. Hereunder are the maximum numbers of objects for BSC
12005:
Total site: 138
Site per cell group: 100
Total cell: 160
Cell per cell group: 120
Total TDMA: 320
TDMA per cell group: 200
Total TRX: 320
TRX per cell group: 200
2.14.2 Customer/service provider benefits

This feature allows to have a well balanced between the 2 BIFP boards and thus to
use at its optimum the BSC processor capacity. It leads to a BSC capacity
improvement for network with large sites.

Algorithms
2.15 EXTENDED CCCH

This V.12 feature consists in the implementation of the extended CCCH feature The
need of this feature has been identified in some configuration where only one CCCH
is not sufficient, due to a high rate of paging and immediate assignment.
2.15.1 Customer/service provider benefits

This feature allows increasing the rate of paging and immediate assignment mes-
sages related to a cell and thus:
Allows managing large location area with up to 16 TRX per cell,
Gives the ability to manage multilayers networks (microcells or multiband
networks),
Allows managing GPRS traffic.
2.15.2 Feature functional description

Up to V.11, only one CCH could be configured at the OMCR. From V.12 you can
allow the configuration of extended CCCH on TS 2, 4 and 6 of the BCCH TDMA.
The following CCCH configurations are now available:
CCCH_Conf = 0:
TS 0 = FCCH+SCH+BCCH+CCCH,
CCCH_Conf = 1:
TS 0 = FCCH+SCH+BCCH+CCCH+SDCCH/4+SACCH/4
CCCH_Conf = 2:
TS 2 = BCCH+CCCH,
CCCH_Conf = 4:
TS 2 = BCCH+CCCH,
TS 4 = BCCH+CCCH,
CCCH_Conf = 6:
TS 2 = BCCH+CCCH,
TS 4 = BCCH+CCCH,
TS 6 = BCCH+CCCH,
Remark: By increasing the number of CCCH, we decrease the number of TCH,
so it leads to reduction of the capacity. For example, an O8 with 1
BCCH has a capacity of 48,65 Erlangs (with 2% of blocking rate);
with 4 CCCH its capacity drops to 45,88 Erlangs.

4119001036
Algorithms
2.15.3 Counters used

C1026: Number of decoded RACH access from the mobile,
C1027: Number of decoded RACH access forwarded to the BSC,
C1028: Number of paging messages sent without delay,
C1029: Number of paging messages sent with one slot delay,
C1030: Number of paging messages sent with two slot delay,
C1031: Number of paging messages sent with more than two slots delay,
C1033: Average level of nondecoded RACH access,
C1604: Average number of messages waiting in queue for transmission on
PCHAGCH,
C1605: Number of paging messages queued up not transmitted.

Algorithms
2.16 PCM ERROR CORRECTION

This V.12 feature has been introduced in order to reduce the number of errors due to
PCM.
This feature concerns a new frame coding (16 kbits/s) between the subsystem and
the TCU subsystem allowing detection and correction of faults on Abis and Ater
PCM.
This new frame coding called ETF (Enhanced TRAU Frame) is an option and an
alternative to the ETSI recommendation 08.60.
2.16.1 Feature principle

The principle of this feature is quite simple; it is to replace the ETSI TRAU frames
and to define a new frame (ETF) by introduction of a CRC on the uplink and the
downlink path in order to detect and correct erroneous frames due to PCM error rate.
The ETF can be used for the following frames:
Full rate,
Enhanced full rate,
Data up to 14.4 kbit/s
The CRC is designed for three functions:

Firstly, it synchronizes the ETF (CRC 26),
Then, it detects errors on the received ETF,
And it corrects them until 2 pairs of bits.
According to the frame transmission direction (downlink or uplink), the functions

of the BTS and the TCU are different:
On uplink direction: the BTS(DRX boards) build the frame(ETF) while the
TCU(TCB2 boards) synchronizes, detects, corrects and monitors the frame. If an
error is not corrected, the TCU mutes the frame. At the end of the
communication, the RF_channel_Release_Ack message carries the synthetic
information about the PCM link status.
On downlink direction: the BTS(DRX boards) synchronizes, detects, corrects
and monitors the frame while the TCU builds the frame. If an error is not
corrected, the BTS sends a filled frame to the MS.
During a BSC HO, if the TCU losses the frame synchronization, the communication
is cut until the synchronization is found back (duration around 1 or 2 frames: it
means around 20 or 40 ms). Moreover, if the BSC manages different frame formats
(ETSI TRAU 8.620, ETF), the PCM error correction performance on the voice
depends on the transmission direction:
On uplink direction: no degradation in relation to the current state
On downlink direction: 60 ms of supplementary muting

4119001036
Algorithms
! Caution:
This feature is only available at the OMCR if all TCB2 boards have V.12 software.
2.16.2 Feature benefits

For users, the benefits of this feature are:
Improvement of the voice quality,
Better data transmissions.
2.16.3 Parameters and counters associated with this feature
2.16.3.1 Parameters
This feature needs to be activated at two levels: the BSC one and the BTS one. At the
BSC level, the parameter enhancedTRAUFrameIndication is set to available,
only if the transcoder boards of all the related TCUs are on TCB2 boards type with
V12 software.
Moreover, at the BTS level pcmerrorCorrection must be set to 1. But it can only be
set to 1 if the enhancedTRAUFrameIndication is set to available or active.
2.16.3.2 Counters
There are several new counters for this feature:
For ETF monitoring:
C1717: received downlink TRAU frames number,
C1718: corrected ETF number,
C1719: muted frames number,
For FER monitoring:
C1720: received uplink radio frames number,
C1721: frame erasure ration number.

Algorithms
2.17 UPLINK MAPPING

This BSS feature is available from V11.4 for GSM 1800 networks and from V12.4
for GSM 900 and 1800 networks.
2.17.1 Functional description
2.17.1.1 Principles
The uplink mapping feature follows this principle:
A mobile tool composed of a transmitter, a test MS and a GPS moves through the
network.
The transmitter broadcasts a predefined frequency f0 which is a continuous
sinusoidal signal.
The test MS is listening to the BTSs and is coupled to a positioning system
(typically a Dead Reckoning Global Positioning System: DRGPS) to record the
position of the transmitter and information on the serving cell.
The uplink level corresponding to f0 is monitored by all the cells composing the
network and level measurement are sent:
By the BTSs to the BSCs,
By the BSCs to an external data server.
This data server collects all the data transmitted by the BSCs and merges these
ones with the data recorded by the mobile tool to obtain the coverage maps.
Remark: The data server is connected through a LAN to all the BSCs concerned
by this operation (the whole network or just a part of the network).

4119001036
Algorithms
In order to synchronize MS data and BTS data, the frame number, sent by the
serving cell, is used. It is recorded by the mobile tool and is also included in the
measurements sent by the BTS.
For each cell, for the uplink channel in idle mode, one timeslot belonging to the
BCCH TDMA is set at the frequency f0: it is the monitored TS.
The BTS sends the uplink level measurements for the monitored TS when the chan-
nel is idle. Every 60s, a message containing 125 measurements (480ms * 125 = 60s)
correlated to a frame number and a cell identity (CI, LAC) is sent by the BTS to the
BSC.
At the BSC level, measurements sent by the BTSs are routed from the SICD card to
the OMU card to be transmitted to the uplink mapping data server via the Ethernet
port.
Note: The frequency f0 must not belong to the cell allocation of any cell of the
network.
Remark:
No data are sent to the OMCR, all the measurements messages are routed
towards an external data server,
No data are stored at BSS level, the data server is in charge of collecting, storing
and computing the data,
There is a minimal impact on the BSC load, no data are processed by MPU/BIFP
boards

Algorithms
! Caution:
BTSs equipped with DCU2 boards or with a mix of DCU2 and DCU4 boards do not
support the Uplink Mapping feature.
2.17.1.2 Progress of the measurements
For each cell, the BSS provides the following data every minute (RxLevUL
depending on the time):
BSC time stamp

LAC + CI
Frame number (T)
RxLevUL (T)
RxLevUL (T + 480 ms)

RxLevUL (T + 124*480 ms)
The mobile tool provides the following data (position depending on time):
Time Position FN Cell Id

T0 Pos(T0) Frame Number(T0) LAC + CI (T0)
T1 = T0 + 1 s Pos(T1) Frame Number(T1) LAC + CI (T1)

Tm = T0 + m s Pos(Tm) Frame Number(Tm) LAC + CI (Tm)
After merging the above data, the data server provides uplink received levels corre-
lated to location information: (c stand for cell and p for position)
Geographical Cell 1 Cell 2 Cell N

Position
Pos. 1 RxLevUL(c1, p1) RxLevUL(c2, p1) RxLevUL(cN, p1)
Pos. 2 RxLevUL(c1, p2) RxLevUL(c2, p2) RxLevUL(cN, p2)

Pos. M RxLevUL(c1, pM) RxLevUL(c2, pM) RxLevUL(cN, pM)

4119001036
Algorithms
2.17.2 Main benefits
2.17.2.1 Customer/Service provider benefits

The main benefit of this feature is to make available coverage maps and conse-
quently interference matrixes based on field measurements. These interference
matrixes are then used to compute a better BCCH frequency plan, which is a manda-
tory step in a microcellular or dense urban network optimization.
In dense urban places where the networks are strongly interfered, this feature will
lead to a 75% gain in time for the frequency plan building and 10% gain in capacity.
2.17.2.2 Enduser/subscriber benefits

The improvement of the BCCH frequency plan provides a better quality in the net-
work. So a better quality of service can be offered to the subscribers.

Algorithms

4119001036
Algorithm parameters
3 ALGORITHM PARAMETERS
3.1 INTRODUCTION
This chapter lists parameters, sorted according to their group, as they were defined
in the previous Chapter.
The following information is provided for each parameter:
a brief description
value range and unit
the recommended value: takes the best benefit of the feature in a standard
network configuration and environment.
process in which it is used (refering to Chapter 2)
some engineering rules that must be considered for the parameter setting
the object that contains this parameter
the default value. Most of the time, the default value inhibits the feature
characterized by this parameter
if possible OMCR counters affected by that parameter
corresponding GSM name
GSM Recommendation
parameter type and OMCR class (see note below)
Remark: The recommended value is established from Nortel experience and
studies. This value has to be adapted according to the network
specificities.
This value is not contractual, and it could change with Nortel new studies results
and experience growth.
Note: The following types of parameters can be distinguished:
Customer engineering parameters:
Addressing: relative to an object
Design: contract characteristic
Optimization: network tuning
Operation: network operation
Manufacturer parameters:
System: modifying such a parameter seriously impacts system behaviour
Product: parameters related to the current system release
DP: stands for permanent data

OMCR class gives rules to be followed when modifying a parameter:

CLASS

Class 0 Implies reconstruction of the BDA
Rules

Class 1 Put BSC out of service (i.e. BSC state set to locked), takes new
parameters into account by resetting active chain and passive

chains.

Class 2 Declares the object (or its parent) temporarily outofservice
before modification

Class 3 Modification is dynamically taken into account

4119001036
3.2 CELL SELECTION AND RESELECTION PARAMETERS
cellReselectHysteresis Class 3C1
Description : Hysteresis to reselect towards cell with different Location

Area
Range value : [0 to 14, by steps of 2] dB

Object : bts
Default value : 6
Type : DP , Optimization
Recommended value : 4 dB (rural), 6 dB (urban)

Used in : Sel_2 (Cf page 211).
Engineering Rules : A high value prevents the MS from making frequent
location updates and may also prevent an MS from
performing adequate location updates, thus risking not
receiving calls. The level variation of the signal is more
important in an urban context, so a higher value of
hysteresis should be set. To avoid frequent location
updates, there is also a timer forbidding the reselection of
the previous server cell. For a reselection with change of
location area, the value is 15 seconds (GSM
recommendation).
Counters : (CPU load, LU) C1400C1193/1
GSM : CELL_RESELECT_HYSTERESIS , ETSI GSM 04.08
cellReselectOffset Class 3C2 V8
Description : Encouragement to reselect a cell (C2 criterion) for phase

2 MS

Object : bts
Default value : 0
Recommended value : Between 4 and 10


Engineering Rules : Otherwise, if there is no privileged layer, the

recommended value remains the same for both sites,
between 4 dB and 10 dB.
GSM : CELL_RESELECT_OFFSET , ETSI GSM 05.08
cellReselInd Class 3 C3 V8
Description : Whether cell reselection criterion (C2) use is authorized

Range value : [true / false]
Object : bts
Default value : False
Recommended value : True

Engineering Rules : See chapter 2.3
msTxPwrMaxCCH Class 3M1
Description : Maximum MS transmission power in a cell CCCH

The BSC relays the information to the mobiles in the Abis
CELL MODIFY REQUEST message.
Range value : [5 to 43, by steps of 2] dBm (GSM 900, GSMR, EGSM,
and GSM 900 GSM 1800 networks)
[0 to 36, by steps of 2] dBm (GSM 1800 and
GSM 1800 GSM 900 networks)
[0 to 33] dBm (GSM 1900 network)
Object : bts
Default value : Typical value of 33 dBm for GSM 900 handhelds, 30 dBm
for GSM 1800 and 1900
Recommended value : 33 dBm for GSM 900, 30 dBm for GSM 1800 and 1900
Used in : Sel_1 (Cf page 210),
Sel_2 (Cf page 211),
Sel_3 (Cf page 211).

4119001036
Engineering Rules : In GSM 900, msTxPwrMax = msTxPwrMaxCCH. In

GSM 1800 or 1900, msTxPwrMaxCCH msTxPwrMax.
Both are verified at OMCR level. This value is related to
typical mobile (handheld or vehiclemounted) and
assumed an environment (urban, rural). If the cell is rural,
it is possible to put a higher value because lot of mobiles
have car kits (can transmit at a higher power). In urban
environment, the density of mobile increases and care
should be taken to reduce interferences. Furthermore, the
major part of the mobile market are handsets.
GSM : MS_TXPWR_MAX_CCH , ETSI GSM 04.08
penaltyTime Class 3 P1 V8
Description : Timer used by an idle mobile before reselecting a cell (C2
criterion)
Range value : [20 to 640, by steps of 20] seconds. The value 640 is
reserved and indicates that the temporary offset is ignored
in the reselection criterion (C2) calculation. It also changes
the sign in the C2 formula (See Sel_3).
Object : bts
Default value : 20
Recommended value : 20
Engineering Rules : The longer this timer is, the longer a penalty is applied for
reselecting that cell. The value should be correlated with
the expected mobiles speeds, which are to be managed by
that cell.
Default value : 640
Counters : None, because internal MS algorithm
GSM : ETSI GSM 05.08

rxLevAccessMin Class 3 R1
Description : Minimum signal strength level received by the mobiles for
being granted access to a cell. The information is sent to
MS prior to registering.
As an example, a threshold level of 104 dBm corresponds
to an acceptable BER of approximately 102 (minimum
recommended value).
Range value : [less than 110, 110 to 109, ... , 49 to 48, more
than 48] dBm
Object : bts
Default value : less than 110 dBm
Recommended value : GSM 900: 101 to 100 dBm, GSM 1800/1900: 99

to 98 dBm
Used in : Sel_1 (Cf page 210),
Sel_2 (Cf page 211),
Sel_3 (Cf page 211).
The difference between GSM 900 and GSM 1800/1900 is
due to MS sensitivity (104 dBm (GSM 900), 102 dBm
(GSM 1800/1900)).

4119001036
Example:
R1 100 dBm
R2
99 dBm
RxLevAccessMin 1 = 100 dBm

RxLevAccessMin 2 = 99 dBm
A rough calculation gives the following impact on the cell
access surface:
Access Zone 1 = Access Zone 2 x 1.2
Engineering Rules : Main parameter for selection or reselection. Notice that the
tuning of this parameter strongly depends on the operator
strategy. Decreasing the value eases the access to the
network by reducing the quality. This parameter defines
the cell access size.
Default value : 101 to 100 dBm
Counters : (RACH, TCH, SDCCH) C1026C1027C1033,
C1051/0C1051/1C1051/2,
C1034C10351036C1193/2.
GSM : RXLEV_ACCESS_MIN , ETSI GSM 04.08
temporaryOffset Class 3T1 V8
Description : Negative offset applied during Penalty Time for

reselecting a cell (C2 criterion)
This negative offset is applied during the entire
penaltyTime duration and allows to prevent speeding
mobiles from selecting the cell. Refer to the
cellReselectOffset entry in the Dictionary.

Object : bts
Default value : 70
Recommended value : 0 (microcell & macrocell in monolayer)

70 (macrocell in multilayers)
Engineering Rules : The value prevents a mobile from reselecting a cell during
PenaltyTime. By giving the highest possible value, which
is higher than the field strength range (0 to 63), we ensure
that the mobile will not reselect the cell before the timer
expires. Then, the value 70 means the applied offset is
infinite.
It could be dangerous on a microcell or macrocell in a
monolayer environment to have a high value, because it
slows down the reselection process. However, on a
macrocell in a multilayers environment, it is
recommended to prevent from reselecting a cell (value 70),
inkeeping a low value for penaltyTime (20 seconds).
Counters : none, because internal MS algorithm

4119001036
3.3 RADIO LINK FAILURE PARAMETERS
callReestablishment Class 3 C4
Description : Whether call reestablishment in a cell is allowed when the

radio link is broken off for propagation reasons
The information is broadcast to the mobiles at regular
intervals on the cell BCCH.
On receipt of a CHANNEL REQUIRED message with
cause call reestablishment, the BSC attempts to
allocate a TCH in one of the cells where call
reestablishment is allowed. Then, if no TCH is available
the BSC attempts to allocate a SDCCH.
Range value : [allowed / not allowed]
Object : bts
Default value : not allowed
Recommended value : allowed (from GSM08 for DMSMSC)

Used in : Rlfms (Cf page 279),
Cr (Cf page 280).
Engineering Rules : Enabling or not this feature is a MSC capability issue
Counters : C1051C1193/2
GSM : CALL_REESTAB , ETSI GSM 05.08
radioLinkTimeout Class 2
Description : Maximum value of the counter (S) associated with the

downlink SACCH messages, beyond which the radio link
is cut off. It is lower than or equal to t3109.
Mobiles comply with system operating conditions when
the counter (S) is assigned a value lower than or equal to
t3109.
If the receiver is unable to decode a downlink SACCH
message (BTS-to-MS direction), the counter is decreased
by 1. If the message is received, the counter is increased
by 2. When the counter goes down to zero, the radio link
is declared faulty.

radio link failure

decoded expected but not decoded
Range value : [4 to 64, by steps of 4] SACCH frames (1 unit = 480 ms

on TCHs, 470 ms on SDCCHs)
Object : bts
Default value : 20 SACCH
Type : DP , Design
Used in : Rlfms (Cf page 279).
Engineering Rules : radioLinkTimeOut < t3109.
If surrounding cells accept reestablishment (from
GSM08 for DMS MSC), overall process should not be too
long.
Small value: call might be dropped before a move to a
more favorable environment could occur.
High value: in case of permanent bad conditions, users
anger and taxation increase before actual calls end or
reestablishment.
Counters : (Call drop on RLF) C1164/14
GSM : RADIO_LINK_TIMEOUT , ETSI GSM 05.08

4119001036
rlf1 Class 2 R2 V8
Description : Value to compute the initial and maximum value of the

(CT) counter used in the BTS radio link control algorithm
The FP runs the following algorithm to monitor the uplink

SACCHs (MS-to-BTS direction):
The CT counter is reset to zero when the FP receives a
CHANNEL ACTIVATION message.
On each occurence of an uplink SACCH, the following
occurs:
if the channel is decoded and CT = 0, then CT = 4 *
rlf1 + 4
if the channel is decoded and CT 0, then CT = min
(rlf1, CT+rlf2)
if the channel is not decoded, then CT = max (0,
CTrlf3)
When the CT counter goes down to zero, the radio link
is broken and the BTS sends a CONNECTION
FAILURE INDICATION message to the BSC.
Range value : [0 to 15]
Object : bts
Default value : 4
Used in : Rlfbs (Cf page 279).
Engineering Rules : The resulting CT value is the same as radioLinkTimeOut
value. There is no reason to recommend to cut a
communication more rapidly in the uplink or downlink
direction. In a network with a lot of traffic or with many
zones of interference, a lower value (between 2 and 4) of
this parameter is recommended. Typically the value, in
such a case should be 2.
Default value : 4

rlf2 Class 2 R3 V8
Description : Step value by which the (CT) counter is increased by the
radio link control algorithm when an uplink SACCH is
decoded
Refer to the rlf1 entry.
Range value : [1 to 4] SACCH frames
Object : bts
Default value : 2
Engineering Rules : The value should be higher than rlf3 value, in order to
encourage the continuity of service. The higher the value,
the longer an MS will keep a bad quality communication
in a disturbed zone. The choice of this value must be made
by the operator, in keeping with its service quality level.
Default value : 2
rlf3 Class 2 R4 V8
Description : Step value by which the (CT) counter is decreased by the
radio link control algorithm when an uplink SACCH is not
decoded
Refer to the rlf1 entry.
Range value : [1 to 4] SACCH frames
Object : bts
Default value : 1
Engineering Rules : It is recommended to fix this value to 1. This allows the use
of the rlf1 value to set the maximal duration of consecutive
nonreception of SACCH frame.
Default value : 1

4119001036
3.4 SIGNAL QUALITY AVERAGING PARAMETERS
missRxQualWt Class 3 M2
Description : Weight applied to missing Quality measurement

The missing measurement is replaced by the latest
computed arithmetic average, or by the latest received raw
measurement if no average value is available, weighed by
this corrective factor when calculating the average bit error
rate in the radio link.
The range of permitted values makes missing quality
measurements not favored.
Range value : [100 to 200] %
Object : handOverControl
Default value : 110

Used in : Mp
Engineering Rules : The higher the value is, the higher the missing
measurement will be weighted.
Counters : (Ho on Quality) C1138/2C1138/3C1138/8C1138/9
GSM : MISS_RXQUAL_WT
rxQualHreqave Class 3 R5
Description : Number of bit error rate measurements performed on a

radio link, used to compute arithmetic bit error rate
averages in handover and power control algorithms
Range value : [1 to 10] number of measurement results
Default value : 8
Recommended value : 4 in urban environment ; > 8 in rural environment

Used in : Mp

Engineering Rules : In order to minimize calculation of temporary averages it

is better if runHandOver and runPwrControl are multiples
or sub multiples of rxQualHreqAve. Length of weighed
average window should be reduced when the cell is small
or environment requires quick reactivity. Studies have
shown that a reduction of the window size value (from 8
to 4 for instance) does not increase the number of
handovers on a network and does not change handover
causes.
However, it has a positive impact, because it leads to a
greater reactivity. Then, the weighed average window size
(rxQualHreqAve * rxQualHreqt) has to be correlated to the
hoMargin value to keep a low pingpong probability. The
larger the window size, the lower the hoMargin should be.
GSM : RXQUAL_HREQAVE
rxQualHreqt Class 3 R6
Description : Number of arithmetic averages taken into account to
compute the weighted average bit error rate in handover
and power control algorithms. Each is calculated from
rxQualHreqave bit error rate (BER) measurements on a
radio link.
Default value : 1
Used in : Mp
Engineering Rules : The quality and signal strength weighed average window
should encompass the same period. For the sake of
simplicity, the default value disables weighting. The
weighed average window size (rxQualHeqAve x
rxQualHreqt) must be correlated to the hoMargin value to
keep a low pingpong probability. The larger the window
size, the lower the hoMargin should be.
Default value : 1
GSM : RXQUAL_HREQT

4119001036
rxQualWtsList Class 3 R7
Description : List of up to sixteen weights used to compute the average
bit error rate on a radio link
Default value : 100

Used in : Mp
Engineering Rules : Values add up to 100. If there are several values, the biggest
weights must be used for more recent reports.
In rural environment, rxLev and rxQual weighed average
window will not refer to the same time window (see
Section 3.5).
Default value : 100
GSM : RXQUAL_WT

3.5 SIGNAL STRENGTH AVERAGING PARAMETERS
missRxLevWt Class 3 M3
Description : Weight applied in case of missing signal strength

measurement report
The missing measurement is replaced by the latest
computed arithmetic average, or by the latest received raw
measurement if no average value is available, weighed by
this corrective factor when calculating the average signal
strength in the cell.
Selecting the greatest value makes missing strength
Default value : 90
Used in : Mp
Default value : 90
Counters : (HO PBGT, HO Rxlev) C1138/5, C1138/0C1138/1
GSM : MISS_RXLEV_WT
rxLevHreqave Class 3 R8
Description : Number of signal strength measurements performed on a

serving cell, used to compute arithmetic strength averages
in handover and power control algorithms
Default value : 8
Recommended value : 6 for small cells (Dintersite < 800m)

between 8 and 10 for large cells (Dintersite > 1600m)
Used in : Mp

4119001036
Engineering Rules : In order to minimize calculation of temporary averages it

is better if runHandOver and runPwrControl are multiples
or sub multiples of rxQualHreqAve. In a urban
environment, the window size should be minimized and
the hoMargin value should be high. However, choosing too
small a value leads to averaging meaningless measures in
case of DTX activation uplink or downlink. Then, in an
urban environment, according to building density, antenna
height and global environment, the window size can
fluctuate between 6 and 8. The minimum value, 6, may be
preferred, because it ensures a good reactivity without bad
influence if the parameter hoMargin is well chosen.
Default value : 8
GSM : RXLEV_HREQAVE
rxLevHreqaveBeg Class3 R9 V11

Description : Number of measurement reports on current cell for signal
strength arithmetic average for early handover mechanism
Default value : 2
Engineering Rules : rxLevHreqaveBeg < rxLevHreqave
This parameter has to be coupled with hoMarginBeg and
rxNCellHreqaveBeg.
This parameter is only available for DCU4 or DRX
transceiver architecture.

rxLevHreqt Class 3 R10
Description : Number of arithmetic averages taken into account to

compute the weighted average signal strength in handover
and power control algorithms. Each is calculated from
rxLevHreqave signal strength measurements on a serving
cell.

Default value : 1
Used in : Mp
Engineering Rules : In a urban environment, the window size should be
minimized and the hoMargin value should be high.
For the sake of simplicity, weighted averaging is disabled

by default value.
! Caution:
The weighted average is not used for the PBGT.
The weighed average window size (rxLevHreqAve *
rxLevHreqt) has to be correlated to the hoMargin value to
keep a low pingpong probability. The larger the window
size, the lower the hoMargin should be.
GSM : RXLEV_HREQT
rxLevWtsList Class 3 R11
Description : Values of weights to be used for signal strength weighed

average

Default value : 100

4119001036

Used in : Mp
Engineering Rules : Arithmetic law to be preferred, biggest weight for most
recent reports
GSM : RXLEV_WT

3.6 NEIGHBOR CELL AVERAGING PARAMETERS

cellDeletionCount Class 3 C5
Description : Number of consecutive Measurement Result messages
which, if not received from a given neighbor cell, will
cause all previously stored information related to that cell
to be deleted.
From V12, this number corresponds to the number of
missing measurement reports after which this neighbour
cell is no more eligible. The measurements related to this
neighbour cell are not deleted as far as less than 10
consecutive measurements are missing.
Object : bts
Default value : 5 in rural environment, 2 in microcell environment
Type : DP , Design
Recommended value : 5 in rural, 2 in urban environment

cf. Section 4.7 about neighbor cells stability
Used in : Mp
Engineering Rules : As there is no weighting factors on neighboring cells, low
values of cellDeletionCount are advised and so the rule
cellDelectionCount < rxNcellHrequave. A mobile is
required to keep synchronization information at least
10 seconds after a cell was removed from the best cells list.
This synchronisation becomes quickly obsolete in the case
of fast moving mobiles.
Counters : (HO)
GSM : CELL_DELETE_COUNT
rxNCellHreqave Class 3 R12

Description : Number of measurement results used in the PBGT
algorithm to compute the average neighboring signal
strength
Default value : 8

4119001036
Recommended value : = rxLevHreqAve

6 for small cells (Dintersite < 800m)
between 8 and 10 for large cells (Dintersite > 1600m)
Used in : Mp
Engineering Rules : In the PBGT formula, the RXLEV_DL is the last
arithmetic signal strength on the current cell. In order to
use the same time base, we should have rxNcellHreqAve =
rxLevHreqAve.
Counters : (Ho) from C1138/0 to C1138/9
GSM : NCELL_HREQAVE
rxLevNCellHreqaveBeg Class 3 R13 V11

Description : Number of measurement results used in early handover
algorithm to compute the average neighboring signal
strength
Default value : 2
Engineering Rules : rxNCellHreqaveBeg < rxLevNCellHreqave
This parameter has to be coupled with hoMarginBeg and
rxLevHreqaveBeg.
Default value : 2

3.7 DISTANCE AVERAGING PARAMETERS

distHreqt Class 3 D1
Description : Number of distance measurements, used to compute the
weighted average MS-to-BTS distance in handover
algorithms
Default value : 4
Used in : Mp
Engineering Rules : For distance handover and Call Clearing, a weighted
average of the MSBS distance is computed from
timingadvance results.
Counters : (HO Dist) C1138/4
GSM : DIST_HREQT , ETSI GSM 05.08
distWtsList Class 3 D2
Description : List of no more than sixteen weights, used to compute the
average MS-to-BTS distance from distHreqt
measurements
Default value : 40 30 20 10
Recommended value : 40 30 20 10
Used in : Mp
Engineering Rules : A supply weights to distHreqt values, highest value for
latest measurements. Choosing an arithmetic law enables
to enhance latest values while not putting too much weight
upon the period of time which might not be representative
of the current trend.
GSM : DIST_WT , ETSI GSM 05.08

4119001036
missDistWt Class 3 M4
Description : Weight applied to missing Distance measurement
The missing measurement is replaced by the latest received
raw measurement weighed by this corrective factor when
calculating the average MS-BTS distance.
The range of permitted values makes missing distance
Default value : 110
Used in : Mp
Engineering Rules : The higher the value is, the higher the missing
measurement will be weighted.
GSM : MISS_DIST_WT

3.8 HANDOVER (GLOBAL) PARAMETERS
biZonePowerOffset Class 3 B1 V12

Description : Power offset between the inner TRXs and the outer TRXs
of the adjacentCellHandOver object of a dualband,
dualcoupling, or concentric cell.
Offset added in calculation formula to draw up the list of
eligible cells for handover towards a dualband,
dualcoupling, or concentric cell inner zone to take into
account the difference of propagation models between the
two bands of the cells and the difference of transmission
power between TRXs of the two zones due to either BTS
configuration or coupling.
Range value : [63 to 63] dB
Object : adjacentCellHandOver
Default value : 63
Note : This parameter is only available for S8000 or ecell BTS DRX
Recommended value : 63 (monozone)

3 dB (otherwise)
Engineering Rules : Shall be 63 for a monozone adjacent cell.
It is advised to set a value higher than the max offset (in
rxLevDL band 0) corresponding to the biggest difference
of coverages between the 2 bands (for the adjacent cell)
otherwise a handover would be wrongly decided.
The higher (in positive) is the value, the more difficult it
will be to handover in the inner zone of the adjacent cell.
Used for intercell handover (whatever the type of adjacent
cell except for monozone) to control whether the inner
zone is eligible.

4119001036
biZonePowerOffset Class 3 B2 V12
Description : Power offset between inner and outer TRXs of the

handOverControl object of a dualband, dualcoupling, or
concentric cell.

Default value : 0
Note : This parameter is only available for S8000 or ecell BTS DRX
Recommended value :
concentric cell:
zoneTxPwrMaxReduction (inner zone)
dualcoupling:
D/H2D: max (0, bsTxPwrMax40)
H2D/H4D: max (0, bsTxPwrMax36)
dualband:
3dB + x (for gsmdcs)
3dB + x (for dcsgsm)
where x =
max (0, bsTxPwrMax40) for D/H2D
max (0, bsTxPwrMax36) for H2D/H4D
0 otherwise
Engineering Rules : Used to harden the handover margins for an intercell
handover decision from the inner zone of a multizone cell
(dualband, dualcoupling or concentric) [handover
thresholds are defined according to band0/outer zone]; it
takes into account the difference of propagation models for
dualband cells and the possible difference of transmission
power between TRXs of the 2 zones (dualcoupling,
dualband, concentric) due to either BTS configuration or
coupling.

bts time between HO configuration Class 3 B3 V9

Description : Whether the HOPingpongTimeRejection timer can be
used at bts level when processing handovers
Range value : [0 to 60] second for V9 to V11
[0 / 1] for V12
0: The timer is disabled.
1: The timer is used.
Object : bts
Default value : 0
Recommended value : 1 (or old value V9, if range [0 to 60])

Used in : Ho_11 (Cf page 253).
Engineering Rules : New semantic in V12
In order to restore the minimum time between HO
feature (TF218, V9):
timeBetweenHOconfiguration = used
bts time between HO configuration = 1
ho Pingpong combinaison = (all, allPBGT)
ho Pingpong Time Rejection > 0
(previous V9 value for bts time between HO
configuration)
see the detailed feature General Protection against HO
Pingpong in chapter Algorithms.
Counters : Tchoke, Tminho.
forced handover algo Class 3 F1 V9

Description : Minimum signal strength level received by the mobiles to
be granted access to a neighbor cell in case of forced
handover
Range value : [less than 110, 110 to 109, ..., 49 to 48, more
than 48] dBm
Default value : less than 110
Recommended value : = rxLevMinCell 1

4119001036
HandOver from signalling channel Class 3 H1

Description : Authorization to perform intercell handovers on signalling
channels (SDCCH or TCH in signalling mode)
Range value : [enabled / disabled]
Default value : disabled
Type : DP , Design
Recommended value : disabled

Used in : Ho
Engineering Rules : It is recommended to enable this feature when queueing is
activated.
Counters : (HO on SDCCH) from C1139/0 to 1139/9
GSM : SDCCH_USED
hoMargin Class 3 H2
Description : Margin to use for PBGT handovers to avoid subsequent
handover, in PBGT formula
Default value : 4
Recommended value : between 4 and 6 for small cells (4 in an 1:1 pattern, 5 or 6

otherwise),
5 for large cells.

Engineering Rules : As a general rule, this parameter enables to harden access

to a new cell in order to avoid a subsequent return to the
current cell (provided rxLevMinCell is set to its minimal
value and does not already take into account pingpong
handover protection).
Up to V8 excluded, this margin is used for all handover
causes, then it will be used for PBGT handovers only, other
causes using their own margins. Handover cause Power
Budget: since this is a preventive handover, we must be
sure a subsequent handover will not be generated
afterward, thus a large margin is justified. This parameter
is on a per neighbor cells basis.
The value of this hoMargin must be correlated to the
window size value to keep a low pingpong probability. In
case of pingpong, handover hoMargin value must be
incremented, and the window size value must be
decremented.
For a dual Band Network where one frequency band is
privileged, it is advised to increase this value in
neighbouring objects with a frequency belonging to the
low priority frequency band. Thus, these neighbours will
be underprivileged.
Counters : (HO on PBGT) C1138/5
GSM : HO_MARGIN , ETSI GSM 05.08
hoMarginBeg Class 3 H3 V11

Description : Margin to be added to hoMargin until rxLevHreqave for
early handover mechanism in order to compensate the lack
of measurements
This parameter is coupled with hoMargin and
rxLevHreqaveBeg.
Object : bts
Default value : 4
Recommended value : 4 dB
Engineering Rules : This parameter is only available for DCU4 or DRX

4119001036
hoMarginDist Class 3 H4 V8
Description : Margin to be used for Distance Handovers

Default value : 24 dB
Recommended value : 2 dB. Depends on the environment and on the value of the
msRangeMax Threshold.
Engineering Rules : Because the priority of the handover on Distance cause is
lower than the Quality and Strength causes, it is performed
while the quality and the signal strength on the current cell
are still acceptable. Setting a negative value decreases the
interference.
! Caution:
PBGT hoMargin in the target cell should be set in order to
avoid a pingpong handover.
be underprivileged.
Counters : (HO on Dist) C1338/4
GSM : HOMARGIN
hoMarginRxLev Class 3 H5 V8
Description : Margin to be used for signal strength Handovers


Recommended value : From 3 to 6 dB in urban environment,

from 1 to 3 in rural environment.
Depends on the environment and the value of
lRxLevXXH. threshold.
Engineering Rules : In rural environments, the hoMargin value on signal
strength should be between 1 and 3.
On the contrary, due to fast radio signal variations in urban
environments, this criteria must be selective to allow good
reactivity. Furthermore, this criteria can be selective due to
site density in urban environments.
The value of this hoMargin must be correlated to the
window size value to keep a low pingpong probability. In
case of pingpong handover, hoMargin value must be
incremented, and the window size value must be
decremented.
This parameter, defined per neighbor, is used to select and
sort neighbors.
Because the constraint to select a neighboring cell is higher
from V8, hoMarginRxLev must be lower than the value of
hoMargin generally set up to V7 (4 dB to 6 dB). So a first
estimate recommends a value of 3 dB. However the setting
of hoMarginRxLev depends of the gap between
RxLevMinCell and LRxLevXXH. The higher the
difference between these two values is, the higher the
hoMarginRxLev.
be underprivileged.
Counters : (Ho on Rxlev DL + UL) C1138/0C1138/1
GSM : HOMARGIN

4119001036
hoMarginRxQual Class 3 H6 V8
Description : Margin to be used for Signal Quality Handovers
Recommended value : in [2; 0] without SFH

in [1; (hoMargin2)] with SFH (# 2 or 3)

Engineering Rules : Handover cause on Signal Quality: case where access to
another cell should be encouraged, provided target cell
field strength is not much lower than the current one. If bad
quality remains there is a risk of return handover but there
is nothing much to be done.
! Caution:
PBGT hoMargin in target cell should be set in order to
avoid a pingpong handover.
This parameter, defined per neighbor, is used to select and
sort neighbors.
be underprivileged.
Counters : C1138/2C1138/3
GSM : HOMARGIN
hoMarginTrafficOffset Class 3 H7 V12

Description : Minimum signal strength margin with the serving cell that
allows to select the best neighbor cell when a handover is
triggered for overload reasons

Recommended value : 2 dB (if overlapping exists)

Engineering Rules : Since the HO for traffic reasons uses the PBGT HO
procedure, the parameter powerBudgetInterCell shall be
enabled.
It is advised to set the General protection against HO
pingpong feature (see parameters:
timeBetweenHoConfiguration,
btstimeBetweenHOConfiguration,
HOPingpongCombination, HOPingpongTimeRejection,)
with HOPingpongCombination including (traffic, all
PBGT).
This parameter shall be set at a value which guarantees
that cell overlapping exists with (hoMargin
hoMarginTrafficOffset).
See subchapter 2.5.9 Handover for traffic reasons in the
Algorihms part for more details.
When set to 0, be handovers for traffic reasons are not
allowed in the adjacent cell.
! Caution:
Only applicable to BTSs equipped with non mixed DCU4,
or DRX boards.
HOPingpongCombination Class3 H8 V12

Description : List of couples of causes (HOInitialCause and
HONonEssentialCause) indicating the causes of pingpong
handovers in the overlapping areas
The following causes are defined with regard to the
neighboring cell:
HOInitialCause indicates the essential handover cause
which leads to enter the neighbor cell (cause of incoming
handover).
HONonEssentialCause indicates the nonessential
handover cause which leads to leave the cell (cause of
outgoing handover).
This parameter defines the combinations for which the
HOPingpongTimeRejection attribute is used.

4119001036
Range value : [rxQual, rxLev, distance, powerBudget, capture, directe-

dRetry, OaM, traffic, all, allCapture, allPowerBudget]
Restrictions :For the moment the essential and non essential causes taken into
account are the following:
Only rxQual and rxLev causes apply to HOInitialCause.
Only powerBudget and capture causes apply to HONonEssentialCause.
Note :
The HOPingpongCombination list can hold up to 4 couples of causes.
allCapture cause (only applying to HONonEssentialCause)matches the capture
cause for all the microcells belonging to the current macrocell . This cause has
to be used in order to prevent pingpong handovers between micro and macro
layers.
allPowerBudget cause (only applying to HONonEssentialCause) matches the
powerBudget cause for all the neighboring cells of the current cell. This cause
is used in order to restore the Minimum time between handovers (feature
TF218).
Recommended value : (all, PBGT)

Engineering Rules : This parameter shall be known by the new BSC (whatever
the type of HO is: intra or inter BSC) ; so, it must be defined
at the entering cell (relatively to the first HO of the
combination) level, for the neighbouring cell
(adjacentCellHandover object) corresponding to the left
cell (still relatively to the first HO of the combination).
Example: if you perform a handover from cell A to cell B
for quality reaon and you want to protect against pingpong
HO for PBGT reason (from B to A), you have to declare
(rxQual, PBGT) as one of the forbidden handover
combinations at cell B level (for the neighbouring cell A).

! Caution:
No protection against intracell or interzone pingpongHO.
No protection against pingpong HO between more than 2
cells except for allcapture / all PBGT causes.
Directed retry can only be an initial cause.
timeBetweenHOConfiguration and
btsTimeBetweenHOconfiguration shall be set
accordingly in order the feature to be activated.
HOPingpongTimeRejection Class 3 H9 V12
Description : Time before a new handover attempt can be triggered
Refer to bsc object timeBetweenHOConfiguration and

bts object bts time between HO configuration attributes
in this Dictionary of Parameters for this timer activation.
Refer to adjacentCellHandOver object
HOPingpongCombination attribute in this Dictionary of
Parameters for the combinations for which this timer
applies.
To avoid pingpong handovers this new timer is started
after a successful handover. Up to the expiration of this
timer, the receipt of HANDOVER INDICATION message
is ignored.
Range value : [0 to 60] s
Recommended value : between 8 and 30

Engineering Rules : The value of HOPingpongTimeRejection may be
between 8 and 30 to have a real impact. The following rule
can be applied: HOPingpongTimeRejection = 50% TCH
occupancy average in a cell.
If the rescue handovers are disabled in the network a too

high value can result in dropped calls.
The value depends on the speed of the mobile, the size of
the cell and the type of cell (micromicro etc).

4119001036
For an area where there are pingpong handovers on

Quality cause (the first HO occurs on Quality reason,
the second one on PBGT), the value corresponds to the
distance between the interference point and the limit of the
cell.
Care must be taken for small cells with high speed mobiles.
HOSecondBestCellConfiguration Class 3 H10 V9

Description : Number of neighbor cells in which the BSC immediately
attempts to perform a new handover when the previous
handover attempt failed with return to the old channel
Giving the attribute a value greater than 2 allows the BSC
to renew the handover request without waiting for a new
set of radio measurements (the first attempt is included in
this count). The same list of neighbor eligible cells is used
to process the request (no new list is provided by the BTS).
Object : bsc
Default value : 1
Type : DP , Design
Engineering Rules : The value 1 means no new attempt after a handover failure,
2 means one new attempt and 3 corresponds to another new
attempt if the first new attempt has failed. The
recommended value optimizes the handover completion
rate.
Comment about the process: when all handover attempts
have failed, the mobile returns on the previous channel.
The measurement history is then complety lost, and the
BTS will wait until the next (HReqAve x HReqt) period to
relaunch a handover request.
Counters : C1167 C1168 C1169 1170

hoTraffic Class 3 H11 V12

Description : Whether handovers for traffic reasons at bsc level are
allowed.
Range value : [disabled / enabled]
Object : bsc
Recommended value : enabled (only if hot spotcells linked to the BSC)

Engineering Rules : See parameter hoMarginTrafficOffset and
subchapter 2.5.9 Handover for traffic reasons in the
Algorithms part.
hoTraffic Class 3 H12 V12

Description : Whether handovers for traffic reasons at bts level are
allowed.
Object : bts
Recommended value : enabled

Engineering Rules : enabled will be effective only if it is also enabled for
the bsc object.
In order to activate the feature handover decision
according to adjacent cell priority and load (TF716),
either hoTraffic shall be enabled or
btsMSAccessClassBarringFunction shall be enabled
(with also bscMSAccessClassBarringFunction).
See parameter hoMarginTrafficOffset and
subchapter 2.5.9 Handover for traffic reasons in the
Algorithms part.

4119001036
msTxPwrMax Class 3 M5
Description : Maximum MS transmission power in a serving cell. It is
equal to msTxPwrMaxCCH in a GSM 900 network, it
can be greater in a GSM 1800 or 1900 network.
[0 to 36, by steps of 2] dBm (GSM 1800 and
GSM 1800 GSM 900 networks)
Object : bts
Default value : Typical value of 33 dBm for GSM 900 handhelds and
30 dBm for GSM 1800 and 1900 handhelds
Recommended value : 33 dBm for GSM 900 in urban environment

39 dBm for GSM 900 in rural environment handhelds
and 30 dBm for GSM 1800 and 1900 handhelds
Used in : Ho_6 (Cf page 236),
Pc_1 (Cf page 259).
Engineering Rules : We must have msTxPwrMax = msTxPwrMaxCCH for
GSM 900 Networks and msTxPwrMaxCCH
msTxPwrMax for GSM 1800 and 1900 Networks (check
done at OMCR). This parameter is adapted to mobile
classes taken into account in Network Design.
GSM : MS_TXPWR_MAX , ETSI GSM 05.08
msTxPwrMaxCell Class 3 M6
Description : Maximum MS transmission power in a neighbor cell. It is
equal to msTxPwrMaxCCH when the cell is declared as
a serving cell on the network (the value must be checked
by users).
[0 to 36, by steps of 2] dBm (GSM 1800 network
and GSM 1800 GSM 900)
Default value : Typical value of 33 dBm for GSM 900 handhelds and

Recommended value : msTxPwrMaxCell = msTxPwrMaxCCCH of the current

cell.
Typical value of 33 dBm for GSM 900 handhelds and
Ho_6 (Cf page 236).
Engineering Rules : If this value is higher than the actual MS classmark, then
MS will apply its own capability.
GSM : MS_TXPWR_MAX(n)
offsetLoad Class 3 O1 V12
Description : Load offset applied by the bsc to the cell selection process
Engineering Rules : When set to 0, no offset is effective.
This parameter is set to 0 for the cells that do not belong
to the related bsc object.
This parameter allows to put a disadvantage to overloaded
eligible cells for HO (for cells with the same offset
priority).
In order to take into account this parameter, the overload
detection must be activated ; so either hoTraffic shall be
enabled (bsc and bts objects) or
btsMSAccessClassBarringFunction shall be enabled
(with also bscMSAccessClassBarringFunction).
A bad offset load parameter tuning can induce a risk of
pingpong HO or longer handover procedures; so, it is
advised to set the General protection against HO
pingpong feature with HOPingpongCombination
including (traffic, all PBGT).
See also the subchapter 2.5.10 Handover decision
according to adjacent cell priorities and load in the
Algorithms part.

4119001036
offsetPriority Class 3 O2 V12

Description : Priority offset applied by the bsc to the cell selection
process
Engineering Rules : 1 is the highest priority.
This parameter allows to classify eligible cells according
to its value ; so, it is used to optimize the traffic distribution
between layers.
See also the subchapter 2.5.10 Handover decision
according to adjacent cell priorities and load in the
Algorithms part.
powerBudgetInterCell Class 3 P2
Description : Authorization to perform intercell handovers for power
budget
Default value : enabled

Engineering Rules : Handover on PBGT should be enabled, because for an
optimized network it ensures the best quality of service.
runHandOver Class 3 R14

Description : Number of Measurement Results messages that must be
received before the handover algorithm in a cell is
triggered.
Range value : [1 to 31] SACCH frames (1 unit = 480 ms on TCHs,
470 ms on SDCCHs)
Object : bts
Default value : 1
Type : DP , System !

Recommended value : 1 (from V11), 2 (until V10)

Used in : Ho
Engineering Rules : Should be run as often as possible, main impact is upon
BSS load.The V11 feature protection against
runHO = 1 allows some protections in order to avoid
that the setting of this parameter to 1 leads some
overload problems (SICD overload).. Therefore,
runHandOver may be set to 1 in some environments where
the reactivity is crucial (microcell, highspeed
environment). So from V11, it is recommended to set
this parameter to 1. However, this parameter setting must
be done in accordance with the value of handover
thresholds, margins and timers.
Counters : (HO, CPU load) from C1038/0 to C1038/9 C1400
GSM : RUN_HANDOVER
rxLevMinCell Class 3 R15

Description : Minimum signal strength level received by MS for being
granted access to a neighbor cell
than 48] dBm
Default value : 95 to 94 dBm (GSM 900), 93 to 92 (GSM 1800)
Recommended value : 95 to 94 dBm (GSM 900), 93 to 92 dBm (GSM 1800)

in urban environment
RxLevMinCell = lRxLevDLH if HOmargin 0 in rural
environment.

4119001036
Engineering Rules : A method to estimate this value is to use MS sensitivity

(104 dBm in GSM 900 for handheld, and 102 dBm in
GSM 1800/1900 for handheld, otherwise 104 dBm) and
applying a margin to it.
However, in 3 particular cases,these recommended values
can be decreased:
most of communications are handled in an indoor
environment
overlap between cell coverage is not sufficient, because
it helps to anticipate the HandOver in rural
environment, then it leads to a decrease of the dropped
calls
hoMargin > 0
privileged, it is advised to set this parameter to a lower
value in neighbour cells belonging to the priority
frequency band. Thus, this band will be preferred.
However, it may be greater than the value
rxLevAccessMin. Thus the recommended value is 99
to 98 dBm (GSM900) or 97 to 96 dBm (GSM1800) for
neighbour cells belonging to the priority frequency band.
Studies have shown that the subjective quality depends on
the way erroneous bits are spread into each frame.
Experiments have shown that with frequency hopping in
TU3 (Typical urban at 3 Km/h) up to Rxqual = 5 the
subjective quality seems to be good, on the other hand
without frequency hopping Rxqual = 4 seems to be the
maximum value for which subjective quality is good.
The higher the mobile speed, the better the subjective
quality is.
The chart below gives examples of the margins that could
be taken into account for an infinite C/I and for different
mobile speeds.

t 50 km/h u 50 km/h u 80 km/h

t 80 km/h
margin 2 dB 2 dB 2 dB
with FH
margin 5 dB 4 dB 2 dB 2 dB
without FH
The chart below shows the different margins that could be

taken into account in a slow mobile area depending of
the C/I.
C/I= 35 C/I= 20 C/I= 15

with FH
without FH
Counters : (HO, CD) from C1138/0 to C1138/9C1164/14

GSM : RXLEV_MIN(n) , ETSI GSM 05.08

4119001036
synchronized Class 3 S1S2

Description : Whether the neighbor cell and the associated serving cell
are synchronous, that is attached to the same BTS
Range value : [not synchronized cells / synchronized cells /
pre sync HO with timing advance / pre sync HO,
default timing advance]
not synchronized cells: the neighbor cell and the
serving cell are not attached to the same BTS.
synchronized cells: the neighbor cell and the serving
cell are attached to the same BTS
pre sync HO with timing advance: the handover
procedure between the neighbor cell and the serving
cell is presynchronized with the GSM Real Time
Difference between the neighbor cell and the serving
cell in the HANDOVER COMMAND message
pre sync HO, default timing advance: a predefined
timing advance is used in the presynchronized
handover procedure between the serving cell and the
neighbor cell. Refer to preSynchroTimingAdvance
parameter.
Engineering Rules : It is recommended to use presynchronized HO in

microcellular environment because in small cells the
timing advance when handovers are triggered is generally
a low value (less than 3).
It is also interesting to use this feature for determined path
such as railways, highways, and tunnels where handovers
between two cells happen always at the same place.
In these cases, Presynchonized Ho is a good solution to
speed up handover and to decrease (up to 80 ms) the speech
cut duration.
timeBetweenHOConfiguration Class 3 T2 V9
Description : Whether the HOPingpongTimeRejection timer can be
used in a BSS when processing handovers
Refer to bts object bts time between HO configuration
and adjacentCellHandOver object

HOPingpongTimeRejection attributes in this Dictionary

of Parameters.
Range value : [used / not used]
Object : bsc
Default value : used
Type : DP , Design
Recommended value : used

Engineering Rules : See engineering rules for the parameter
btstimeBetweenHOConfiguration

4119001036
3.9 INTRACELL HANDOVER PARAMETERS
intraCell Class 3 I1
Description : Whether intra-bts handovers on TCH are allowed in a cell

for interference reasons or CellTiering reasons
Range value : [cellTieringHandover / intraCellHandover /

handoverNotAllowed]
cellTieringHandover: the intra bts handovers are
allowed for CellTiering reason
intraCellHandover: the intra bts handovers are
allowed for interference reason
handoverNotAllowed: the intra bts handovers are not
allowed
Type : DP , Design
Recommended value : handoverNotAllowed or cellTieringHandover

Engineering Rules : For monoTRX cell, do not enable intracell handover
(handoverNotAllowed).
As the MS power is not checked before performing an
intracell handover, it is not advised to enable this feature
as intraCellHandover. It would lead to a high ratio of
intracell handover.
In V7, the resource allocator does not classify free TCH
resources according to their interference level. From V8,
the channel is selected from the best not empty pool.
To enable tiering, the cell tiering conditions shall be
fulfilled and the cell tiering advantages shall be estimated
as well (see subchapter 2.5.11, the Automatic cell
tiering, in the Algorithms part, chapter 2 and ho Margin
Tiering parameter.
Counters : (Ho on quality)
C1138/8C1138/9C1081C1082C1083C1134
GSM : INTRACELL_USED , ETSI GSM 05.08

intraCellSDCCH Class 3 I2 V8
Description : Whether intra-bts handovers on SDCCH are authorized in
a cell for interference reasons

Engineering Rules : None except system ability.
Note that, some mobiles have been reported to drop the call
when that feature is performed.
Counters : (SDCCH intracell Ho)
C1154C1155C1156C1157C1139/8C1139/9
rxLevDLIH Class 3 R16

Description : Maximum interference level in BTS-to-MS direction,
beyond which an intra cell handover may be triggered
than 48] dBm
Recommended value : 85 to 84 dBm

Engineering Rules : lrxlevDLH < rxLevDLIH <= lRxLevDLP
! Caution:
Path balance must be considered for this threshold
parameter setting.
Counters : C1081C1082C1083C1134C1138/9
GSM : RXLEV_DL_IH , ETSI GSM 05.08

4119001036
rxLevULIH Class 3 R17

Description : Maximum interference level in MS-to-BTS direction,
beyond which an intra cell handover may be triggered
than 48] dBm
Recommended value : 85 to 84 dBm

Engineering Rules : lrxlevULH < rxLevULIH <= lRxLevULP
! Caution:
Path balance must be considered for this threshold
parameter setting.
Counters : C1081C1082C1083C1134C1138/8
GSM : RXLEV_UL_IH , ETSI GSM 05.08
rxQualDLIH Class 3 R18 V12
Description : Bit error rate threshold in BTStoMS direction for

intracell handover, above which a handover may be
triggered.
Range value : [less than 0.2, 0.2 to 0.4, 0.4 to 0.8, ... , 6.4 to 12.8, more
than 12.8] %
Recommended value : rxQualDLIH lRxQualDLH

Engineering Rules : From V12, intracell HO for signal quality uses a different
threshold than the intercell one and intracell HO can only
use either hopping channels having low interference or non
hopping channels having low interference. This should
improve the voice quality and the performance.
The possible drawback could be to increase queueing at
BSC level for networks experiencing interferences.
During upgrade, the default value will be lrxQualDLH.
To favor intracell HO for quality (compared to intercell
HO for quality), the following rule shall be satisfied:
rxQualDLIH < lRxQualDLH.
From V12, the intracell HO has a lower priority than the
intercell HO for quality.
rxQualULIH Class 3 R19 V12
Description : Bit error rate threshold in MStoBTS direction for

intracell handover, above which a handover may be
triggered.
than 12.8] %
Recommended value : rxQualULIH lRxQualULH

Engineering Rules : From V12, intracell HO for signal quality uses a different
threshold than the intercell one and intracell HO can only
use either hopping channels having low interference or non
hopping channels having low interference. This should
improve the voice quality and the performance.
The possible drawback could be to increase queueing at
BSC level for networks experiencing interferences.
During upgrade, the default value will be lrxQualULH.
To favor intracell HO for quality (compared to intercell
HO for quality), the following rule shall be satisfied:
rxQualULIH < lRxQualULH.
From V12, the intracell HO has a lower priority than the
intercell HO for quality.

4119001036
3.10 INTERCELL HANDOVER THRESHOLDS

lRxLevDLH Class 3 L1
Description : Signal strength threshold in BTS-to-MS direction, below
which a handover may be triggered
than 48] dBm
Default value : 101 to 100 dBm (GSM 900)
99 to 98 dBm (GSM1800/1900)
Recommended value : 95 to 94 dBm in urban environment (900 MHz)

101 to 100 dBm in rural environment (900 MHz)
Engineering Rules : This threshold, must be set from the MS sensitivity. A
margin must be taken to consider shadowing, fast fading
and MS measurement accuracy.
At least, a 3 dB margin can be taken into account in a rural
environment and a 10 dB margin in an urban environment.
! Caution:
where the cell is declared as a neighbor, we should have:
lRxLevDLH < rxlevMinCell
Furthermore, path balance must be considered for this
threshold parameter setting.
GSM : L_RXLEV_DL_H , ETSI GSM 05.08
lRxLevULH Class 3 L2
Description : Signal strength threshold in MS-to-BTS direction, below
which a handover may be triggered
than 48] dBm
Default value : 101 to 100 dBm (GSM 900)
99 to 98 dBm (GSM 1800/1900)

Recommended value : 95 to 94 dBm in urban environment (900 MHz)

101 to 100 dBm in rural environment (900 MHz)
Engineering Rules : These thresholds depend on BTS sensitivity. Then, values
should be increased if one of the following points is
verified:
the thresholds on quality are permissive
runhandover 3 scarce
mobile speed is high
initial tuning causes frequent level strength handover
failure rate
At least, a 3 dB margin can be taken into account in a rural
environment and a 10 dB margin in an urban environment.
! Caution:
Where the cell is declared as a neighbor, we should have:
lRxLevDLH < rxlevMinCell
GSM : L_RXLEV_UL_H , ETSI GSM 05.08
lRxQualDLH Class 3 L3
Description : Bit error rate threshold in BTS-to-MS direction, above

which an inter cell handover may be triggered
than 12.8] %
Default value : 1.6 to 3.2 %
Recommended value : 1.6 to 3.2 % (4 in rxqual GSM unit) without frequency

hopping.
See Engineering Rules in case of frequency hopping.
Ho_2 (Cf page 231).

4119001036
Engineering Rules : According to some experiments and studies, 4 in GSM unit

is the upper limit for TU3 no hopping, while 5 in GSM unit
for TU3 hopping. Suggested values become 4 in GSM unit
(no frequency hopping or MS speed > 80km/h) and 5 in
GSM unit (frequency hopping and low urban speed). High
BER rate for threshold is dangerous (risk of handover
failure). On the contrary, if a tight rxqual threshold is
linked with a short averaging period, the risk is that a single
bad quality report will affect the whole result (ie : if 8
samples without weighting and a threshold of 2 in GSM
unit: if 7 of these samples are 2 in GSM unit and 1 of them
is 5 in GSM unit, handover decision will be taken on a
wrong basis). Experience shows whatever the MS speed,
rxQual = 6 does not provide a comfortable voice quality.
The average in the above is equal to:
(7 * 0.57 + 4.53) B 8 = 1.065 greater than 0.57 (2 in GSM
unit).
In case of using synthesized frequency hopping, this
threshold has to be increased in order to limit the increase
of the number of hand over on quality criteria.
In a 1:1 pattern, it is advised to set this value to 5 or 6 (3.2
to 6.4 % or 6.4 to 12.8 %).
In case of a 1:3 pattern, the recommended value is 4 or 5
(1.6 to 3.2 % or 3.2 to 6.4 %).
! Caution:
From V9 the comparison is made with the upper or the
lower limit of the BER range. So, the same value of
lRxQualDLH between V8 (or previous release) and V9
releases will not trigger a handover at the same moment.
Counters : C1138/2C1138/3C1139/2C1139/3
GSM : L_RXQUAL_DL_H, ETSI GSM 05.08
lRxQualULH Class 3 L4
Description : Bit error rate threshold in MS-to-BTS direction, above
which an inter cell handover may be triggered
than 12.8] %
Default value : 1.6 to 3.2 %

Recommended value : 1.6 to 3.2 % (4 rxqual GSM unit)without frequency

hopping.
See Engineering Rules in case of frequency hopping.
Used in : Ho_1 (Cf page 231) and
Ho_2 (Cf page 231).
Engineering Rules : According to some experiments and studies, 4 in GSM unit
is the upper limit for TU3 no hopping while 5 in GSM unit
for TU3 hopping. Suggested value becomes 4 in GSM unit
(no frequency hopping or MS speed > 80km/h) and 5 in
GSM unit (frequency hopping and low urban speed). High
ber rate for threshold is dangerous (risk of handover
failure). On the contrary, if a tight rxqual threshold is
linked with a short averaging period, the risk is that a single
bad quality report will affect the whole result (ie: if 8
samples without weighting and a threshold of 2: if 7 of
these samples are 2 and 1 of them is 5, handover decision
will be taken on the wrong basis).
In case of using synthesized frequency hopping, this
threshold has to be increased in order to limit the increase
of the number of hand over on quality criteria.
In a 1:1 pattern, it is advised to set this value to 5 or 6 (3.2
to 6.4 % or 6.4 to 12.8 %).
In case of a 1:3 pattern, the recommended value is 4 or 5
(1.6 to 3.2 % or 3.2 to 6.4 %).
! Caution:
lower limit of the BER range. So, the same value of
lRxQualDLH between V8 (or previous release) and V9
releases will not trigger a handover at the same moment.
Counters : C1138/2C1138/3C1139/2C1139/3
GSM : L_RXQUAL_UL_H, ETSI GSM 05.08

4119001036
rxLevDLPBGT Class 3 R20 V11

Description : Downlink signal strength threshold above which handover
for power budget are inhibited
Range value : [less than 110, 110 to 109,..., 49 to 48, more
than 48] dBm
Engineering Rules : rxLevDLPBGT > lRxLevDLH

This parameter has to be managed carefully because it can
prevent all the handover for powerbudget. Moreover, the
setting of this parameter has to be done with the help of
some radio measurement campaigns.
This parameter shall be disabled by setting the value to
more than 48 (dBm).
transceiver architecture. It shall be disabled for DCU2
architecture.

3.11 HANDOVER FOR MICROCELLULAR NETWORK

PARAMETERS
To activate microcellular algorithm, do not forget to set the corresponding
parameter in the omcservices.cfg of the OMC.
cellType Class 3 C6
Description : Type of the adjacent cell
Range value : [normalType / umbrellaType / microType]
Default value : normalType
Type : DP , Design
Recommended value : normalType

Used in : Ho__A (Cf page 245).
Engineering Rules : To run a capture handover (umbrella to micro) on a
neighbor, which must be microType, the bts must be
declared as umbrellaType. It is possible to manage a three
layer network by declaring cell A and cell B as
umbrellaType, neighbor B and neighbor C as microType
for cell A, neighbor A as umbrellaType and neighbor C as
microType for cell B, and finally neighbor B as
umbrellaType for cell C.
cellType Class 3 C7
Description : Type of the serving cell
Range value : [normalType / umbrellaType / microType]
Object : bts
Default value : normalType
Type : DP , Design
Recommended value : normalType

Engineering Rules : o run a capture handover (umbrella to micro) on a
neighbor, which must be microType, the bts must be
declared as an umbrellaType. It is possible to manage a
three layer network by declaring cell A and cell B as

4119001036
umbrellaType, neighbor B and neighbor C as microType

for cell A, neighbor A as umbrellaType and neighbor C as
microType for cell B, and finally neighbor B as
umbrellaType for cell C.
microCellCaptureTimer Class 3 M7 V8
Description : Time used to confirm a capture (signal strength stability)
when using microcell Algorithm type A
Range value : [0 to 255] multiple of <runHandOver>
Default value : 0
Condition : To define if A handover algorithm is activated
Type : DP , Design
Recommended value : 8s, whatever runHandOver value (8 if runHandOver = 2,

16 if runHandOver = 1)
Engineering Rules : Experiments done in urban areas show that a timer of
8 seconds to 10 seconds allows a better use of the capture.
Counters : C1138/6
microCellStability class 3 M8
Description : Strength Level Stability Criterion for Capture
Algorithm A
Default value : 10
Condition : To define if A handover algorithm is activated
Type : DP , Design
Engineering Rules : To allow handovers on capture this parameter has to be
set at a value greater than 0. A value of microCellStability
equal to 63 dB has to be set first, because with such a value,
the stability constraint are always verified. The value of
this parameter can then be decreased case by case.
Counters : C1138/6

3.12 DISTANCE MANAGEMENT PARAMETERS

callClearing Class 3 C8
Description : Maximum distance betwen MS and BTS before call is
cleared
It is greater than msRangeMax.
This distance defines the cell maximum coverage area.
Range value : [2 to 35] km (nonextended mode)
[2 to 120] km (extended mode)
Object : bts
Default value : 35 in nonextended mode , 90 in extended mode
Type : DP , Product
Recommended value : Depends on the environment, typical value = (1.5 * cell

diameter) + 2 km or best cell distance coverage server
Generaly for nonextended mode:
7 km for urban
35 km for rural
Used in : Cc (Cf page 281).
Engineering Rules : The value should be related to the current cell coverage. A
margin is taken by using the 1.5 coefficient. A 2km margin
is also considered to compensate lack of mobile timing
advance accuracy.
If the observation counter shows a high number of call
clearings, it may mean that handover parameters on that
cell are too permissive or badly tuned.
At the OMCR, a control exists: callClearing >
msRangeMax
Counters : (CD on Dist) C1164/12
GSM : MS_RANGE_MAX_CLEAR
extended cell Class 2 E1 V9

Description : Whether the cell is extended (up to 120 km large) or not
The cell working mode governs the upper limit of the
following attribute values (refer to theses entries in the
Dictionary):
callClearing, msRangeMax, and
rndAccTimAdvThreshold attributes of the bts object

4119001036
concentAlgoExtMsRange and
concentAlgoIntMsRange attributes of the associated
handOverControl object if the bts object describes a
concentric cell
Range value : [true (extended) / false (normal)]
Object : bts
Engineering Rules : Extended cells will be used to reach mobiles that are far
from the BTS (in the case of sea shores and pleasure boats,
for example).
In an extended cell, two consecutive time slots are reserved
for each channel. The capacity is then decreased.
! Caution:
Up to V10, an extended cell cannot be concentric.
Whatever the MSBTS distance is, two consecutive
time slots are reserved on Air interface.
Recommended value : See Engineering Rules
msRangeMax Class 3 M9
Description : Maximum MS-to-BTS distance beyond which a handover
may be triggered. It can be set to 1 for a microcell and is
less than callClearing in all cases.
If the associated serving cell is a concentric cell, the
following inequality, that is not checked by the system,
must be true (refer to this entry in the Dictionary):
msRangeMax concentAlgoExtMsRange
Default value : 34 in nonextended mode, 89 in extended mode
Recommended value : = callClearing 1 km


Engineering Rules :
! Caution:
callClearing > msRangeMax is controled at the OMC level
Must be adapted to current cell extent in order to be an
efficient preventive handover. If value is too small, there
is a big risk of pingpong handover.
! Caution:
Due to lack of mobile timing advance accuracy this
parameter must not be set at a too low value (not < 2).
Generaly for nonextended mode:
6 km for urban
34 km for rural
Counters : C1138/4
GSM : MS_RANGE_MAX_HAND
msBtsDistanceInterCell Class 3 M10
Description : Whether inter-bts handovers are allowed in a cell for

distance reasons

Engineering Rules : Due to the imprecision of some MS on Timing Advance
(see table on Timing advance in Section 5.2) and due to the
delay spread in a very urban environment, it is possible to
set this parameter to disabled (in an urban environment).
However, for all cells with a radius of more than 1 km,
handover on distance must be authorized.
Counters : C1138/4
GSM : MS_BS_DIST_USED

4119001036
preSynchroTimingAdvance Class 3 P3 V10

Description : Predefined timing advance used in a presynchronized
handover procedure between the serving cell and this
neighbor cell.
Range value : [1 to 35] (km)
Object : adjacentCellHandOver, adjacentCellReselection
Type : DP , Design
Recommended value : see Engineering Rules

Engineering Rules : This value of timing advance is used when the parameter
synchronizedCell is set to pre sync HO with timing
advance. A predefined timing advance can be defined
when phase 2 MSs always handove from the serving cell
to this neighbor cell approximately at the same place
(railway, highway).
If the parameter synchronized is set to presyncho HO,
default timing advance, the default TA value is 1
(554 m).
If the parameter synchronized is set to presyncho HO,
with timing advance, the parameter
preSynchroTimingAdvance must be tuned to the estimated
value of TA.
! Caution:
preSynchroTimingAdvance value is not controlled at the
OMCR
rndAccTimAdvThreshold Class 3 R21 V8

Description : MS-to-BTS distance beyond which mobile access requests
to a cell are refused.
Object : bts
Default value : 35 (nonextended cell), 90 (extended cell)
Recommended value : msRangeMax (= call clearing 1km = 1.5* cell diameter

+ 2 km 1 km)

Generally for nonextended mode:

6 km for urban
35 km for rural
Engineering Rules : The maximum authorized value will inhibit the feature. By
adjusting the value to the size of the cell (see recommended
value), parasite RACH (noise which is decoded by the
system like a RACH) are filtered. This avoids the
unnecessary assigment of SDCCH.
Counters : 1185/0, 1702
runCallClear Class 3 R22

received before the call clearing algorithm in a cell is
triggered
Range value : [1 to 31] SACCH frames (1 unit = 480 ms on TCHs, 470
ms on SDCCHs)
Object : bts
Default value : 16
Used in : Cc (Cf page 281).
Engineering Rules : It is not necessary to run Cc too often, since those calls are
going to be ended anyway. Nevertheless, traffic out of a
cells range interferes on other cells or timeslots.
Counters : (CD on Dist) C1164/12
GSM : RUN_CALL_CLEAR

4119001036
3.13 POWER CONTROL PARAMETERS

The parameters uRxLevULP, uRxLevDLP, uRxQualULP, uRxQualDLP,
powerRedStepSize, powerIncStepSize are only used for step by step power control
algorithm.
Attenuation Class 2 A1 V9
Description : Attenuation due to coupling system losses. This value

depends on the BTS configuration and should not be
modified by the operator.

Object : btsSiteManager
Default value : Depends on the equipment
Recommended value : Depends on the equipment

Engineering Rules : If the Attenuation parameter is not set (value = NULL),
then the DLU attenuation value is used (for V8 BTSs, the
DLU attenuation value is always used). This parameter
should also be NULL for configurations with hybrid
coupling and for Dual Band configurations.
If the Attenuation parameter is set [0 to 14] then it replaces

the DLU attenuation value
bsMsmtProcessingMode Class 2 B4
Description : Whether radio measurements collected by the mobiles for

a cell are processed by the BTS or the BSC
Range value : [preProcessedMeasurementReporting (BTS) /

basicMeasurementReporting (BSC)]
Object : bts
Default value : preProcessedMeasurementReporting
Type : DP , Product
Recommended value : preProcessedMeasurementReporting

Engineering Rules : Since radio measurements are always preprocessed by the
BTS, changing this attribute has no meaning.

bsPowerControl Class 3 B5
Description : Whether BTS transmission power control is allowed at cell
level
Object : powerControl

Used in : Pc_2 (Cf page 260).
Engineering Rules : Not useful for monoTRX cells, because BTS power
control on BCCH frequency is not allowed.
! Caution:
During a measurement field campaign, it can be normal to
disable this feature in order to have the real signal strength
and not the adjusted one.
Counters : (HO on Quality UL) C1138/2C1138/8C1138/5
GSM : BTS_PWR_USED
bsTxPwrMax Class 3 B6
Description : Maximum theoretical level of BTS transmission power in
a cell
Range value : [2 to 51] dBm
Default value : 43
Recommended value : Depends on the equipment

4119001036
Engineering Rules : This power is used to calculate the cabinet output power.
Until V8, the choice of the value depends on the
attenuation in the DLU. From V9, it depends on the
attribute Attenuation of btsSiteManager objects from
V9 (see Chapter 2.12), because the value of the parameter
Attenuation is then taken into account as DLU
attenuation.
GSM : BS_TXPWR_MAX
Counters : C1400C1164/14
lRxLevDLP Class 3 L5
Description : Signal strength threshold in BTS-to-MS direction, below

which the power control function increases power. It is
lower than uRxLevDLP.
than 48] dBm
Recommended value : 95 to 94 dBm (step by step)

85 to 84 dBm (one shot)
Engineering Rules : The difference between lower and upper thresholds must
be greater or equal to max (powerIncrStrepSize,
powerRedStepSize), because it is controled at the OMC
level.
lRxLevDLP > lRxLevDLH, up to V7, because power

Control and handover algorithms are decorrelated.
lRxLevDLP w lRxLevDLH from V8 because handover
cannot be triggered if MS or BTS power is not maximum
(for step by step).
Counters : (Ho on Rxlev DL, Call drop on RLF) C1138/1,C1164/14
GSM : L_RXLEV_DL_P , ETSI GSM 05.08

lRxLevULP Class 3 L6
Description : Signal strength threshold in MS-to-BTS direction, below

lower than uRxLevULP.
than 48] dBm
Recommended value : 95 to 94 dBm (step by step)

85 to 84 dBm (one shot)
Engineering Rules : lRxLevULP > lRxLevULH, up to V7, because power
Control and handover algorithms are decorrelated.
lRxLevDLP w lRxLevDLH from V8 because handover
cannot be triggered if MS or BTS power is not maximum
(for step by step).
The difference between lower and upper thresholds must
be greater or equal to max (powerIncrStrepSize,
powerRedStepSize).
Counters : (Ho on Rxlev UL, Call drop on RLF) C1138/0,C1164/14
GSM : L_RXLEV_UL_P , ETSI GSM 05.08
lRxQualDLP Class 3 L7
Description : Bit error rate threshold in BTS-to-MS direction, above

greater than or equal to uRxQualDLP.
than 12.8] %
Default value : 0.4 to 0.8
Recommended value : 0.8 to 1.6 % (RxQual = 3 in GSM unit) without SFH

3.2 to 6.4 % (RxQual = 5 in GSM unit) with SFH

4119001036
Engineering Rules : This value must be lower than lRxQualDLH in order to

maintain priority between power control and handover.
! Caution:
lower limit of the BER range. So a same value of
lRxQualDLP between V8 (or previous releases) and V9
releases will not trigger a power control at the same
moment.
GSM : L_RXQUAL_DL_P , ETSI GSM 05.08
lRxQualULP Class 3 L8
Description : Bit error rate threshold in MS-to-BTS direction, above

greater than or equal to uRxQualULP.
than 12.8] %

Engineering Rules : This value must be lower than lRxQualULH in order to
! Caution:
lRxQualULP between V8 (or previous releases) and V9
release will not trigger a power control at the same
moment.
Counters : (Ho on Quality, CD on RLF)
C1138/3C1138/2C1138/8C1138/9,C1164/14
GSM : L_RXQUAL_UL_P, ETSI GSM 05.08

msTxPwrMax2ndBand Class 2 M11 V12

Description : Maximum MS transmisssion power in the band 1 of the
dualband cell depending on the network type (BCCH is
only defined in band 0)
Range value : [0 to 36, by steps of 2] dBm (GSM 900 GSM 1800
network)
[5 to 43, by steps of 2] dBm (GSM 1800 GSM 900
network)
Object : bts
Recommended value : 33 dBm for dcsgsm

30 dBm for gsmdcs
Engineering Rules : This parameter is only used for power control.
The attribute value is within the range [0 to 36] and even
when the bts object standardIndicator attribute is
gsmdcs.
The attribute value is within the range [5 to 43] and odd
when the bts object standardIndicator attribute is
dcsgsm.
! Caution:
This parameter is only supported for S8000 DRX
transceiver architecture or for ecell.
new power control algorithm Class 3 N1 V9

Description : Algorithm used by the BTS to control power in a cell
Range value : [step by step / one shot / enhanced one shot]
As a result, the amount of mobiles emitting at Pmax is
reduced.
Object : bts
Default value : stepbystep
Recommended value : one shot (if DCU2 boards) or enhanced one shot
(otherwise)
Used in : Pc

4119001036
Engineering Rules :
! Caution:
Enhanced one shot is not supported with DCU2 boards
or with a mix of DCU2/DCU4 boards.
powerControlIndicator Class 3 P4
Description : Whether MS signal strength measurements include
measurements on BCCH
Range value : [include BCCH measurements / do not include BCCH
measurements]
This parameter should only be used with cavity coupling.
Object : bts
Default value : include BCCH measurements

Engineering Rules : BCCH measurements must not be included when the
following two conditions are met:
The radio channel hops at least on two different
frequencies, including the BCCH frequency.
Power control on the downlink is used.
! Caution:
This parameter should only be used with cavity coupling.
powerIncrStepSize Class 3 P5
Description : Step for increasing MS or BTS txpwr when using step by
step algorithm
Range value : [2, 4, 6] dB
Used in : Pc_1 (Cf page 259),
Pc_2 (Cf page 260).

Engineering Rules : A high step size is required to be reactive in increasing the

power when entering an area where propagation is not
acceptable.
Counters : C1601, C8052, C1198, C8050, C1602, C8053, C1199,
C8051
GSM : POW_INC_STEP_SIZE , ETSI GSM 05.08
powerRedStepSize Class 3 P6
Description : Step for reducing MS or BTS txpwr when using step by

step algorithm
Range value : [2, 4] dB

Used in : Pc_1 (Cf page 259),
Pc_2 (Cf page 260).
Engineering Rules : Small steps are enough to adapt two subsequent changes in
quality and strength. Moreover, calls become sensitive to
low MS or BS txPower.
Counters : C1601, C8052, C1198, C8050, C1602, C8053, C1199,
C8051
GSM : POW_RED_STEP_SIZE , ETSI GSM 05.08
runPwrControl Class 3 R23

received before the power control algorithm in a cell is
triggered.
Range value : [1 to 31] SACCH frames (1 unit = 480 ms on TCHs, 470

ms on SDCCHs)
Object : bts
Default value : 4

4119001036
Counters : (CPU load) C1400, C1601, C8052, C1198, C8050, C1602,
C8053, C1199, C8051
GSM : RUN_POWER_CONTROL
uplinkPowerControl Class 3U1 V8

Description : Whether power control in the MS-to-BTS direction is
authorized at cell level
uRxLevDLP Class 3 U2
Description : Upper strength threshold for BTS txpwr decrease for step
by step algorithm
It is greater than lRxLevDLP.
than 48] dBm
Recommended value : = lRxLevDLP + Max (powerIncrStepSize,

powerRedStepSize) typically
Engineering Rules : Difference between the lower and upper thresholds must
be greater or equal to the maximum power step size.
Not used in one shot power control.
Counters : (Ho on Rxlev DL, Call drop on RLF) C1138/1,C1164/14
GSM : U_RXLEV_DL_P , ETSI GSM 05.08

uRxLevULP Class 3 U3
Description : Upper strength threshold for MS txpwr decrease for step
by step algorithm
It is greater than lRxLevULP.
than 48] dBm
Recommended value : lRxLevULP + Max (powerIncrStepSize,

powerRedStepSize) typically
Engineering Rules : Difference between the lower and upper threshold, must be
greater or equal to the maximum power step size.
Not used in one shot power control.
Counters : (Ho on Rxlev UL, Call drop on RLF) C1138/0,C1164/14
GSM : U_RXLEV_UL_P , ETSI GSM 05.08
uRxQualDLP Class 3 U4
Description : Upper quality threshold to reduce BTS txpwr for step by

step algorithm
It is lower than or equal to lRxQualDLP.
than 12.8] %

4119001036

Engineering Rules : This value must be lower than lRxQualDLH in order to
Not used with one shot power control.
! Caution:
moment.
Counters : (Ho on Quality, CD on RLF)
C1138/3C1138/2C1138/8C1138/9,C1164/14
GSM : U_RXQUAL_DL_P , ETSI GSM 05.08
uRxQualULP Class 3 U5
Description : Upper quality threshold to reduce MS txpwr for step by

step algorithm
It is lower than or equal to lRxQualULP.
than 12.8] %

1.6 to 3.2 % (RxQual = 4 in GSM unit) wtih SFH
Engineering Rules : This value must be lower than lRxQualULH in order to
There is no reason why this value should differ from
uRxQualDLP.
Not used with one shot power control.

! Caution:
moment.
GSM : U_RXQUAL_UL_P, ETSI GSM 05.08

4119001036
3.14 TCH ALLOCATION MANAGEMENT PARAMETERS
accessClassCongestion Class 3 A1 V9
Description : List of access classes that are not authorized in a cell during
TCH congestion phase (class 10 not included)
Range value : [0 to 9] User classes

[11 to 15] Operator classes
Object : bts
Default value : 0123456789
Type : DP , Design

Used in : All_4 (Cf page 276).
Engineering Rules : Usually, in a low capacity cell (between 1 and 2 TRXs),
many classes must be forbidden in case of congestion (few
resources available). In a high capacity cell, only a few
classes must be forbidden.
allocPriorityTable Class 3 A2
Description : Table of eighteen elements that define the internal

priorities for processing TCH queued allocation requests
for each external priority defined (among them, fourteen
are GSM priorities)
TCH is always allocated using the internal priority.

Range value : [0 to 7]. 0 defines the highest priority.
Object : bts
Default value : 000000000000000000
Recommended value : 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 2
Used in : All_1 (Cf page 264),
All_2 (Cf page 269),
All_3 (Cf page 271).

Engineering Rules : The default set means that all TCH allocation requests have
the same priority, which is equal to 0.
When queueing is activated, set the following parameters

in order not to disadvantage the interCell handover
procedures:
Priority for interCell handover: 0
Priority for other procedures: 0

allocPriorityThreshold > 0
allocPriorityThreshold Class 3 A3
Description : Number of free TCHs needed for processing a TCH

allocation request with an internal priority higher than 1
These channels are reserved to allocation requests with a

maximum internal priority (priority 0).
The TCH allocation is performed according to this
algorithm:
Number of free 1 Number of free TCH Number of free TCH >

TCH = 0 allocPriorityThreshold allocPriorityThreshold
TCH queueing if defined TCH allocated TCH allocated

request of or
priority 0 reject
TCH queueing if defined queueing if defined TCH allocated

request of or or
priority > 0 reject reject
Range value : [0 to 2147483646]

Object : bts
Default value : 0
Type : DP , Design
Recommended value : n, with n TRX


4119001036
Engineering Rules : When TCH channels are reserved and the internal priority
for assignRequest is 0, the capacity for incoming calls
decreases:
Example:
1 TRX, 7 TCH, 2 % blocking rate,
capacity for incoming calls = 2,88 Erlang
1 TRX, 7 TCH, 2 % blocking rate,
capacity for incoming calls = 2,23 Erlang
Queueing spreads out the TCH allocation request. As
incoming handover requests are not queued, such requests
are disadvantaged. A solution is to reserve 1 TCH channel
(for 1 or 2 TRXs) or 2 TCH channels (for at least 2 TRX)
for calls of internal priority 0, and set the priority 0 for
incoming handovers only.
Note that when TCH channels are reserved for handovers,
the capacity for incoming calls decreases.
allocPriorityTimers Class 3 A4
Description : Table of eight timers that defines for each internal
processing priority the maximum waiting time of TCH
allocations requests
Range value : [0 to 2147483646] seconds
Object : bts
Recommended value : 0 0 3 0 0 0 0 0
Engineering Rules : The maximum waiting time in the queue must be lower
than:
tnt2 t3107
Where:
tnt2 is the DMS MSC timer, which represents the
maximum duration between the assign request message
(sent by the MSC) and the assign complete message
(received from the BSC),

t3107 is the timer set on the transmission of the assign

command message and reset on the receipt of the assign
complete.
Maximum_waiting_time tnt2 t3107
MS BTS BSC MSC

Assign Request start tnt2
queueing
Maximum
Waiting Time
Assign Command
Start t3107
Assign Complete
A high value of timer is not realistic, since a subscriber will

not wait unless the last TCH is available quickly.
Counters : C1163/30, C1164/30
allocWaitThreshold Class 3 A5
Description : Table of eight elements that defines for each internal
processing priority, the maximum number of TCH
allocation requests that can be queued
A TCH request of priority Pi, P0<PiP7, is queued if the
total number of requests of priority Pj, with ji, already in
the queue does not exceed the waiting threshold of the
queue i (element i of the allocWaitThreshold table).
Range value : [0 to 2147483646]
Object : bts

4119001036
Recommended value : 0 0 n 0 0 0 0 0 , for 2n SDCCH subchannels

Engineering Rules : The maximum size in each queue must be lower than the
number of SDCCH channels in the cell.
For an incoming call, when the assignRequest is queued,
it remains on the SDCCH subchannel.
Counters : C1039, C1058
allOtherCasesPriority Class 3 A6
Description : Index in the allocPriorityTable that defines the processing
priority of TCH allocation requests with cause other
cases
This priority is used in primo-allocations or when an
SDDCH cannot be allocated for overload reasons.
Object : bts
Default value : 0
Engineering Rules : The associated internal priority is 0. A TCH allocation
request (in signaling mode) whose cause is other case is
acknowledged when at least allocPriorityThreshold + 1
channels are free.
answerPagingPriority Class 3 A7
priority of TCH allocation requests with cause reply to
paging
This priority is used in signaling mode on TCH only.
Object : bts

Default value : 17
Engineering Rules : The associated internal priority is 0. A TCH allocation
request (in signaling mode) whose cause is reply to
paging is acknowledged when at least
allocPriorityThreshold + 1 channels are free.
assignRequestPriority Class 3 A8
priority of TCH allocation requests with cause immediate
assignment
This priority is used when radio resource allocation
queueing is not requested by the MSC or not authorized in
the BSS (refer to the bscQueueingOption entry in the
Dictionary).
Object : bts
Default value : 17
Engineering Rules : When queueing driven by the MSC is used, this parameter
is not significant.
It is recommended not to associate an internal priority
equal to 0.
When queueing (run by the OMC) is used and intra cell
handover is enabled, the index must be the same as
intracellCellHOIntPriority in order to point to the same
unique queue.
There is no queuing for TCH in signaling mode.

4119001036
bscMSAccessClassBarringFunction Class 3 B7 V9
Description : Enable or disable dynamic barring of access class at the bsc
level
Object : bsc
Type : DP , Design
Recommended value : enabled, see Engineering Rules

Engineering Rules :
Set to disabled, this parameter allows to inhibit the
dynamic barring of access class feature for the whole
BSC whatever the values of the other parameters related
to All_4 are.
If queueing or directed retry is activated, the following
parameters must be used. (See Section All_4,
page 276).
numberOfTCHQueuedBeforeCongestion
numberOfTCHQueuedToEndCongestion
bscQueueingOption Class 1 B8
Description : Whether radio resource allocation requests are queued in
the BSC when no resources are available
If no resource is available when an allocation request is
received and queueing is not allowed, the allocation
request is refused immediately.
Range value : [allowed (MSC driven) / forced (O&M driven) / not
allowed]
Object : signallingPoint
Type : DP , Design
Recommended value : forced (O&M driven)

allowed (MSC driven), if MSC is able to manage
queueing.

Engineering Rules : When queueing is activated, the queued procedures

(assignRequest and intraCellHO if OMC driven)
statistically take advantage on the other procedures. If all
the TCH channels are already allocated, the queued
procedures stay in the queue during a defined time (see
allocPriorityTimer), when the others are rejected.
Suppose the operator expects to enable the queueing later.
Due to the class of the parameter bscQueueingOption, it is
recommended not to set not allowed. Otherwise, the
BSC will need to be switched off to implement the feature.
btsMSAccessClassBarringFunction Class 3 B9 V9
Description : Enable or disable dynamic barring of access class at the bts

level
Object : bts
Type : DP , Design

Engineering Rules : To enable dynamic barring of access class at the bts level,
this parameter and the bscMSAccessClassBarringFunction
parameter of the corresponding bsc must be set to enabled.
This feature globally reduces the cell capacity. The fewer
the number of TRXs on the cell, the more the capacity is
reduced.
callReestablishmentPriority Class 3 C9

priority of TCH allocation requests with cause call
reestablishment
Object : bts
Default value : 17

4119001036
Engineering Rules : The value that must be given should correspond to a
priority 0.
cellBarQualify Class 3 C10 V8

Description : Cell selection priority used in the C2 algorithm in Phase II
Range value : [true (low priority) / false (normal priority)]
Object : bts
Recommended value : False

Engineering Rules : To be defined (Cf page 211).
cellBarred Class 3 C11

Description : Whether direct cell access are barred to mobiles
Range value : [barred / not barred]
Object : bts
Default value : not barred
Recommended value : not barred

Engineering Rules : See Chapter 2.3.3.
channelType Class 2 C12

Description : Type of logical channel supported by a radio time slot
Range value : [tCHFull (traffic) / sDCCH (traffic) / mainBCCH /
mainBCCHCombined (with SDCCH) /
bcchSdcch4CBCH / sdcch8CBCH / cCH (V12)]
Object : channel

Recommended value : See Enginering Rules

Engineering Rules :
SDCCH rule:
2 SDCCH/8 for 3 TRXs at the boundary of the LAC,
1 SDCCH/8 for 3 TRXs at the center of the LAC.
Notice :The default rule is 2 SDCCH/8 for 2 TRXs.
CBCH:
The CBCH can be combined with an SDCCH/8 or a
BCCH+SDCCH/4. It takes place of SDCCH No.2 in all
cases.
emergencyCallPriority Class 3 E2
Description : Index in the table allocPriorityTable for a TCH allocation
request whose cause is emergency call
Object : bts
Default value : 17
Engineering Rules : The internal priority associated is 0. A TCH allocation
request (in signaling mode) whose cause is emergency
call is acknowledged when at least 1 channel is free.
interCellHOExtPriority Class 3 I3

priority of incoming inter-bss handovers in a cell
This priority is used when radio resource allocation
queueing is not requested by the MSC or not authorized in
the BSS (refer to the bscQueueingOption entry in the
Dictionary).

4119001036
Object : bts
Default value : 17
request (in signaling mode) on interBSC handover is
aknowledged when at least 1 channel is free.
When queueing is used, it is recommended to give the
priority 0 and reserve the TCH channels
(allocPriorityThreshold) since it disadvantages requests
that cannot be queued.
interCellHOIntPriority Class 3 I4
priority of incoming intra-bss handovers in a cell
This priority is always used, whether radio resource
allocation queueing is authorized in the BSS or not.
Object : bts
Default value : 17
request (in signaling mode) on intraBSC handover is
aknowledged when at least 1 TCH is free.
When queueing is used, it is recommended to give the
priority 0 and reserve the TCH channels
(allocPriorityThreshold) since it disadvantages requests
that cannot be queued.

intraCellHOIntPriority Class 3 I5
priority of an intra-bts handover in a cell
Object : bts
Default value : 17
Engineering Rules : When queueing (run by the BSC) is used and intra cell
handover enabled, the index must be the same as
assignRequestPriority in order to point to the same unique
queue.
intraCellQueueing Class 3 I6
Description : Whether intra-bts handover requests are queued for a cell.
This parameter is significant only when queuing radio
resource allocation requests is allowed in the BSS.
Object : bts
Recommended value : Enabled

minNbOfTDMA Class 2 M12

Description : Minimum number of TDMA frames that must be working
in order for the cell itself to be working.
The frame carrying the cell BCCH must be among them
and is successfully configured.

4119001036

Object : bts
Default value : 1
notAllowedAccessClasses Class 3 N2
Description : List of mobile access classes that are forbidden in the cell,
except case of congestion.
Range value : List of mobile access class:
[0 to 9]: user classes
[11 to 15]: operator classes
Object : bts
Type : DP , Operation
Recommended value : null (empty list)

Engineering Rules : This parameter contains the list of forbidden access
classes. Usually all users are authorized, in this case, the
list must be empty.
numberOfTCHFreeBeforeCongestion Class 3 N3 V9
Description : Minimum number of free TCHs which triggers the
beginning of the TCH congestion phase and the beginning
of the traffic overload condition
Range value : [0 to infinite]
Object : bts
Default value : 0
Type : DP , Design
Recommended value : 1 for cells with 12 TRXs

2 or 3 for cells with more than 3 TRXs
Engineering Rules : Note that the congestion feature does not distinguish
between reserved or unreserved TCHs. A reserved TCH is
a TCH booked for a priority 0 procedure. Setting this
parameter must consider the number of reserved TCHs.

numberOfTCHFreeToEndCongestion Class 3 N4 V9
Description : Threshold that gives the number of free TCHs, which
triggers the end of TCH congestion phase and the end of
the traffic overload condition.
Object : bts
Default value : 0
Type : DP , Design
Recommended value : 2 for cells with 12 TRXs

3 or 4 cells with more than 3 TRXs
Engineering Rules : numberOfTCHFreeToEndCongestion >
numberOfTCHFreeBeforeCongestion
Note, this inequality is not checked at the OMC.
numberOfTCHQueuedBeforeCongestion Class 3 N5 V9
Description : Maximum number of TCH allocation requests queued
which triggers the beginning of the TCH congestion phase
and the beginning of the traffic overload condition
Object : bts
Default value : 0
Type : DP , Design
numberOfTCHQueuedToEndCongestion Class 3 N6 V9
Description : Maximum number of TCH allocation requests queued
which triggers the end of TCH congestion phase and the
end of the traffic overload condition
Object : bts
Default value : 0
Type : DP , Design

4119001036
otherServicesPriority Class 3 O3
Description : Index in the table allocPriorityTable for a TCH allocation
request (in signaling mode) whose cause is other
services
Object : bts
Default value : 17
request (in signaling mode) whose cause is other
services is acknowledged when at least
allocPriorityThreshold + 1 channels are free.
priority Class 2 P7
Description : Priority level of a TDMA frame.
Object : transceiver
Engineering Rules : Among the set of TDMA frames attached to a cell, the one
carrying the cell BCCH must always be allotted the highest
priority [0].
For the others TDMA frames, the engineering rules have
to be defined.

Algorithms parameters
3.15 DIRECTED RETRY HANDOVER PARAMETERS

adjacent cell umbrella ref Class 3 A9 V9
Description : Identifier of the adjacentCelHandOver object that
describes the neighbor cell towards which a directed retry
will be triggered in BSC mode
Object : bts
Type : DP , Design
Recommended value : Identifier of the adjacentCellHandOver of the macrocell

which totally covers the micro cell.
Engineering Rules : Bsc mode is especially used in a two layer network. For
micro cells, directed retry needs to be triggered towards the
macro cell. However, if the recovering of each micro cell
is good enough, adjacentUmbrellaRef can identify a micro
cell. To facilitate the procedure, the BCCH frequency of
the target neighbor cell must be in the reselection list.
directedRetry Class 3D3 V9

Description : Minimum signal strength level received by the mobiles to
be granted access to the neighbor cell, used in processing
directed retry handovers in BTS mode
than 48] dBm
Default value : >48 dBm
Recommended value : = rxLevMinCell + 3 to 25 dB

Engineering Rules : The choice of recommended value has to be done
regarding the general design of the network. A 3 dB margin
must be considered as a minimum on a network to
eliminate field strength bumps effect due to multipath.
However, this margin must be increased in an urban
environment or with the use of reuse pattern (overall for a
1:1 pattern) because of the generated interference when the
MS is not on the best server cell.
See Section 4.4.1 for an example of parameter setting.

4119001036
! Caution:
Directed retry is not allowed between 2 zones of a
concentric cell.
privileged, it is possible to set this parameter to a higher
value in neighbour cells belonging to the low priority
frequency band. Thus, this band will be underprivileged.
However, it will impact the directed retry for monoband
MS on this band (less directed retry).
directedRetryModeUsed Class 3 D4 V9
Description : Specify how directed retry handovers are processed in a

cell either directly by the BSC (microcells only) or by
querying the BTS first
Range value : [bsc / bts]

Object : bts
Default value : bts
Type : DP , Design

Ho_9 (Cf page 237).
Engineering Rules : In V9, bsc mode can only be applied from a micro cell
towards a macrocell (system rule).
Note : The micro cell should be entirely covered by the macro cell
in order to use efficiently the bsc mode.
The use of the bts mode is recommended in a hot spot when

these are several micro cells under the umbrella. The bts
mode allows the use of micro cells to rescue the umbrella
cell and also avoids a saturation of the umbrella cell.
The bts mode is also recommended for all other cases.
directedRetryPrio D5 V12
Description : Defines the number priority for directed retry handovers

Object : bts
Engineering Rules : Before V12, the directed retry used the incoming handover
priority which is the highest priority ; to avoid this, this
new priority is introduced. See the TCH Allocation
management chapter 2.8, in the Algorithms part.
interBscDirectedRetry Class 3 I7 V9
Description : Whether inter-bss directed retry handovers are allowed in
a BSS
Object : bsc
Default value : allowed
Type : DP , Design
Recommended value : allowed

Ho_9 (Cf page 237).
Engineering Rules : Queueing must be activated at BSC level: see 4.4.
If the value is not allowed then, the value of
interBscDirectedRetryFromCell must be set to not
allowed for the concerned cells.
If the value is set to allowed intraBscDirectedRetry and
interBscDirectedRetry are allowed.
concentric cell.
interBscDirectedRetryFromCell Class 3 I8 V9
Description : Whether inter-bss directed retry handovers are allowed in
a cell
Object : bts

4119001036

Ho_9 (Cf page 237).
Engineering Rules : If the value is allowed then the value of
interBscDirectedRetry must be allowed.
Queueing must also be activated at BSC level.
concentric cell.
intraBscDirectedRetry Class 3 I9 V9
Description : Whether intra-bss directed retry handovers are allowed in
a BSS
Object : bsc
Default value : allowed
Type : DP , Design

Ho_9 (Cf page 237).
Engineering Rules : Directed retry is not allowed between 2 zones of a
concentric cell.
Queueing must be activated at BSC level: see 4.4.
If the value is not allowed then, the value of
intraBscDirectedRetryFromCell must be set to not
allowed for the concerned cells.
intraBscDirectedRetryFromCell Class 3 I10 V9

Description : Whether intra-bss directed retry handovers are allowed in
a cell
Object : bts


Ho_9 (Cf page 237).
Engineering Rules : If the value is allowed then the value of
intraBscDirectedRetry must be allowed.
Queueing must be activated at BSC level.
concentric cell.
modeModifyMandatory Class 3 M13 V9

Description : Whether a CHANNEL MODE MODIFY message should
be sent to the mobile after a directed retry handover in the
BSS
Range value : [used (yes) / not used (no)]
Object : bsc
Default value : not used
Recommended value : used

Engineering Rules : This message is only useful for mobiles belonging to spe-
cial brands that are not able to switch directly from signal-
ing information to speech information. They need to
receive a CHANNEL MODE MODIFY message. The
value must be set to used if all types of mobile stations
are welcome on the network even if it can load the system
(messages sent for all the mobiles not only the ones that
need the message).

4119001036
3.16 CONCENTRIC CELLS PARAMETERS
concentAlgoExtMsRange Class 3 C13 V9
Description : MS to BTS distance below which a handover is requested

from the large zone to the small zone if the level criteria is
verified
Default value : 1
Condition : To define if the associated bts object describes a concentric
cell.
Type : DP , Design
Recommended value : 34 (urban)

Engineering Rules : See previous parameter. A good solution is to apply:
concentAlgoExtMsRange = concentAlgoIntMsRange 1 km
Constraints:
concentAlgoExtMsRange < concentAlgointMsRange

concentAlgoExtMsRange < msRangeMax
concentAlgoExtRxLev Class 3 C14 V9

Description : The level of the MS signal strength from below which a
handover is requested from the large zone to the small zone
than 48] dBm
Default value : 95 to 94
/ dualband / dualcoupling cell
Type : DP , Design

Recommended value : RxLevLimitInt + zoneTxpowerMaxReduction where:

RxLevLimitInt = RxLevLimitExt + Q
Q is the RxLevAccessMin difference between the two
areas
Engineering Rules : The recommended value depends on the network design.
This design gives an average level at the external limit of
a cell (large zone) and gives also a value for the
zoneTxPwrMaxReduction. (See 4.5).
The following rule must be fulfilled
concentAlgoExtRxLev concentAlgoIntRxLev.
concentAlgoIntMsRange Class 3 C15 V9
Description : MS to BTS distance from which a handover from the small
zone to the large zone will be requested
Default value : 2
/ dualband / dualcoupling cell.
Type : DP , Design
Recommended value : 0.4 * large zone radius for omnisectorial sites (C/I = 12)
0.7 * large zone radius for trisectorial sites (C/I = 12)
Engineering Rules :
concentAlgoIntMsRange > concentAlgoExtMsRange

concentAlgoIntMsRange < msRangeMax
The calculated distance between the MS and the BTS is
based on timing advance TA, which has an accuracy of
3 bits (corresponding to more than 1.5 km), due to the shift
of synchronisation of some MSs. Thus, this parameter is
not very useful in urban areas where the cell size is
relatively small and due to the multipath effect, the MS_BS
distance is not very accurate. But this parameter can be
useful in rural areas or suburban areas.

4119001036
Then, the value to take depends on the network design

(see 4.5). A compromise must be found between a low
value to avoid interference and a high value to avoid the
influence of the bad accuracy of the TA.
The recommended values are used for 1:3 reuse
frequency profile. Simulations show that for this profile,
the small zone surface is 35% of the large zone surface for
omnidirectional sites with a 6 dB margin taken on C/I,
and 50% for trisectorial sites with a 8 dB margin.
Experimental results give a possible small zone surface
of 70%.
concentAlgoIntRxLev Class 3 C16 V9

Description : Level of the MS signal strength below which a handover
is requested from the small zone to the large zone
Range value : [less than 110, 110 to 109, ... , 49 to 48, more than
48] dBm
Condition : To define if the associated bts object describes a concen-
tric/dualband/dualcoupling cell
Type : DP , Design
Recommended value : concentAlgoExtRxLev Hysteresis Margin

Engineering Rules : The recommended value depends on the network design.
This design gives an average level at the limit of the small
zone (deduction of the average level at the external limit
of the large zone). The margin permits the avoidance of
pingpong handovers. A recommended value for this mar-
gin is 5 dB. (See 4.5).
The following rule must be fulfilled
concentAlgoExtRxLev concentAlgoIntRxLev.

concentric cell Class 2 C17 V9

Description : Whether the cell is monozone, concentric, dualband or
dualcoupling
Range value : [true / false] for V9 to V11
[monozone / concentric / dualband / dualcoupling] for V12
Object : bts
Default value : monozone

Engineering Rules :
concentric cell:
from V12, it is possible to allocate directly a TCH in
the innerzone for call setup or HO and to reuse the
same frequency an both zones
up to V10 (included), it is impossible to use extended
cell with concentric cell (check OMCR) ; anyway, it
is not interesting to combine extended cell and
concentric cell due to waste of resources
from V12, the same frequencies set are used in both
zones and hopping concerns the total available
number of frequencies
dualband cell:
the dualband combining into one cell allows to save
up to one SDCCH in particular configurations, the
combining of GSM 900 / GSM 1800resources into
one pool allows to increase the traffic capacity ; it is
only supported in presence of V12 COAM but not on
S4000 with DCU2/DCU4, S4000 with DCU2,
S4000 with DCU4
dualcoupling cell:
the DLU attenuation shall be used : so configure the
Attenuation parameter (btsSiteManager object) to
null, configure the max power for the cell to the
desired max power (power for the outer zone) and
configure zoneTxPwrMaxReduction for the inner
zone to the delta value

4119001036
zone Tx power max reduction Class 2 Z1 V9

Description : Attenuation vs bsTxPowerMax that defines the maximum
TRX/DRX transmission power in the zone
Range value : large zone = [0] dB, small zone = [1 to 55] dB
Object : transceiverZone
Default value : 0
Type : DP , Design
Reminder : The transceiverZone objects are only created for bts objects that
describe concentric cells.
Recommended value :
concentric cell:
16dBQ for omnidirectional sites (C/I=12dB)
11dBQ for trisectorial sites (C/I=12dB)
(where Q would be the RxLevAccessMin difference
between the 2 areas if 2 distinct cells were considered)
dualcoupling cell: 0
dualband cell:
0 if coupling is homogeneous and the wanted
coverages for the 2 bands are identical
same rule as for dualcoupling cell if coupling is
heterogeneous and the wanted coverages for the 2
bands are identical
same rule as for concentric cell if coupling is
homogeneous and reuse of inner zones
frequencies is an objective
Engineering Rules : Concerning concentric cells, the recommended values are
used for 1:3 reuse frequency profile, with a 6 dB margin
for omnidirectional sites and 8 dB for trisectorial sites.
Reminder : The transceiverZone objects are only created for bts objects that
describe concentric cells.

3.17 INTERFERENCE LEVEL PARAMETERS
averagingPeriod Class 2 A10
Description : Number of SACCH multiframes over which the

interference levels are averaged. This averaging will be
performed immediately before the transmission of the
RESSOURCE INDICATION message.
This attribute, together with the thresholdInterference
attribute, allows users to manage interferences in radio
cells. Refer to this entry in the Dictionary.
Range value : [0 to 255] SACCH frame (1 unit = 480 ms on TCH, 470 ms
on SDCCH)
Default value : 20
Used in : If (Cf page 281).
Engineering Rules : Performing this message broadcast has a great impact on
the system load and should not be done too often.
Reducing this value speedsup the channel allocation
algorithm, since it checks temporary channel interference
non frequently. However, the main purpose of this
algorithm is to take into account long term interference and
not short term interference which do not have a statistically
large impact on call quality.
Counters : (CPU load) C1400
radChanSelIntThreshold Class 3 R24 V8
Description : Maximum interference level on free radio channels, below

which the channels are ranged in the group of priority
allocation channels
The information is used to first allocate the free channels
with the lowest interference level. The levels depend on the
thresholdInterference attribute value defined for the
cell. Refer to this entry in the Dictionary.

4119001036
The BSC distributes the free radio channels among two

groups:
The first group contains the list of channels with a
measured averaged interference level equal to or lower
than the defined level.
The second group contains the list of channels with a
measured averaged interference level higher than the
defined level, and recently released channels for which
no measurement is available.
Four resource pools are defined for each SDCCH or TCH
type of channel:
low interference level radio channels that are authorized
to hop
low interference level radio channels that are not
authorized to hop
high interference level radio channels that are
authorized to hop
high interference level radio channels that are not
authorized to hop
Default value : 1
Recommended value : 3, 1 (for 1:1 & 1:3)

Engineering Rules : A high value for this parameter means a tolerant interfer-
ence sorting.
It is simpler to change the value of this pointer than to tune

the thresholds themselves since the thresholds are used in
the lower layer of signal processing at the BTS.
The radChanSellIntThreshold counter can be set after
interference counters monitoring. Ideally, it should depend
on the average traffic load expected on the cell and on the
interference distribution.

With low Traffic per TCH, radChanSellIntThreshold can

be set to 1. This means that the selection of the non
interefered channels is very selective. The few TCH
selected are sufficient for the traffic to be carried.
RadChanSellIntThreshold can be decreased to 1 when
using 1:1 or 1:3 reuse pattern in order to use as more BCCH
resources as possible.
With high Traffic per TCH, radChanSellIntThreshold can
be set to 4. This means that the selection of the non
interfered channels is not selective, instead, the rejection
of channels is. Only the very bad channels are rejected
since we cannot afford to reject more of them with such
high traffic.
Taking into account the quality vs interference level in the
cell is interesting but also complex to predict. The operator
could obtain some clues by measuring the correlation
between these two indicators during the network life.
thresholdInterference Class 2 T3
Description : List of four thresholds defined in ascending order, used to

sort idle channels on the basis of measured interference
levels
This attribute, together with the averagingPeriod
attribute, allows to manage interferences in a radio cell.
The classification is used by the radio resource allocator.
The interference processing algorithm for a cell is as
follows:
For each idle radio channel, the BTS permanently
measures the signal strength level RXLEV.
When averagingPeriod Measurement results
messages have been received, the L1M function in the
BTS calculates interference level averages, sorts the
idle channels according to the five defined interference
levels (Level 0 corresponds to the lowest interference
level), and sends the information to the BSC.

4119001036
128 0
dBm
th. 1 th. 2 th. 3 th.4
Level 0 Level 1 Level 2 Level 3 Level 4
The BSC tallies the interference levels and, if the

temporary interference observation is running for the
bsc object, sends the channelIdleLevelMax and
channelIdleLevelEch counters every
<mdGranularityPeriod> minutes to the OMCR
agent.
Refer also to C1619 permanent observation counters.
Range value : [128 to 0] dBm
Default value : 100 90 80 70
Recommended value : 114, 112, 108, 100

Engineering Rules : Those values define 5 interference level ranges, so free
channel classification can be displayed at the OMCR
level.
The setting of the threshold Interference level should be
linked to the interference level distribution in the cell.
As a first definition, thresholds can be evenly distributed
over the defined range.
Counters : (CPU load) C1400

3.18 RADIO RESOURCES CONTROL AT CELL LEVEL
radResSupBusyTimer Class 3 R25 V8
Description : Maximum time that SDCCH or TCH can be continuously

occupied without generating an alarm
Range value : [1 to 18] hours
Object : bsc
Default value : 3
Recommended value : 10 or 3 (see below)

Engineering Rules : Useful, for example, to see problems of resource dealloca-
tion. The value must be correlated with what is assessed:
10 during busy day for high traffic area, 3 for other cases
(at night, in rural areas).
radResSupervision Class 3 R26 V8
Description : Indicates whether radio resources are controlled at the cell

level (both busy resources and free resources)
Object : bts
Default value : true
Recommended value : True

Engineering Rules : It is recommended to use this control mainly after a fre-
quency plan update, to regularly supervise the network.
Note : radResSupBusyTimer and radResSupFreeTimer can be set
automatically by the OMCR calendar function.
The activation of this feature does not induce any signaling
or CPU overload. Only the BSSOMCR link is over-
loaded at a rate of radResSupBusyTimer or radResSup-
FreeTimer.

4119001036
radResSupFreeTimer Class 3 R27 V8

Description : Maximum time an SDCCH or TCH can be continuously
free without generating an alarm
Range value : [1 to 18] hours
Object : bsc
Default value : 18
Recommended value : 10 or 3 (see below)

Engineering Rules : Useful, for example, to see problems of design at busy
hours or if some channels are jammed. The value needs to
be correlated with what is assessed: 10 during night day for
low traffic areas (rural), 3 for other cases (high traffic
areas, during the day).

3.19 BSS TIMERS

bssMapT1 Class 1 B10
Description : A interface timer triggered by the BSC in the BSSMAP
management procedure.
It is started on transmission of BLOCK or UNBLOCK by
the BSC and canceled on receipt of BLOCK
ACKNOWLEDGE or UNBLOCK ACKNOWLEDGE
sent by the MSC.
Object : bsc
Default value : 5
Recommended value : 5, 60 (if using DMS switch)

management procedure. This timer is used with a Phase I
MSC only.
It is started on transmission of RESET CIRCUIT by the
BSC and canceled on receipt of RESET CIRCUIT
ACKNOWLEDGE sent by the MSC.
Object : bsc
Default value : 5
Recommended value : 5, 60 (if using DMS switch)

management procedure.
It is started on receipt of RESET sent by the MSC. On
elapse, the BSC sends RESET ACKNOWLEDGE to the
MSC.

4119001036

Default value : 32
Object : bsc
bssMapT19 Class 1 B13 V8

management procedure. This timer is used with a Phase II
MSC only.
It is started on transmission of RESET CIRCUIT by the
BSC and canceled on receipt of RESET CIRCUIT
Object : bsc
Default value : 60
bssMapT20 Class 1 B14 V8

management procedure
It is started on transmission of CIRCUIT GROUP BLOCK
or CIRCUIT GROUP UNBLOCK by the BSC and
canceled on receipt of CIRCUIT GROUP BLOCK
ACKNOWLEDGE or CIRCUIT GROUP UNBLOCK
Object : bsc
Default value : 60


It is started on transmission of RESET and canceled on
receipt of RESET ACKNOWLEDGE sent by the MSC.
On elapse, the BSC sends RESET.
Object : bsc
Default value : 60

It is started on transmission of HANDOVER REQUIRED
and canceled on receipt of HANDOVER COMMAND,
RESET, RESET CIRCUIT, CLEAR COMMAND or
HANDOVER REQUIRED REJECT.
Object : bsc
Default value : 7

management procedure. It is greater than t3103 for each
cell managed by the BSC
It is started on transmission of HANDOVER COMMAND
and canceled on receipt of CLEAR COMMAND sent by
the MSC or HANDOVER FAILURE sent by MS.

4119001036

Object : bsc
Default value : 15
Engineering Rules : It is greater than t3103 for each cell managed by the BSC.
bssMapTchoke Class 1 B18
Description : A interface timer triggered by the BSC in the handover

It is started by the BSC when the last neighbor cell in the
list is rejected. On elapse, the BSC asks the MSC to provide
a new list of eligible cells.
Object : bsc
Default value : 4
Engineering Rules : It is hardly recommended not to modify this value.
bssSccpConnEst Class 1 B19
Description : A interface timer triggered by the BSC in the handover

It is set on transmission of CONNECTION REQUEST and
canceled on receipt of CONNECTION CONFIRM or
CONNECTION REFUSED.
Range value : [5 to 360, by steps of 5] seconds
Object : signallingPoint
Default value : 5

Engineering Rules : A high value is dangerous in case of slowing down on A
interface. Then, the minimum value (5 s) must be chosen
for this parameter ; it is hardly recommended not to modify
this value.
t3101 Class 3 T4
Description : BSC timer triggered during the immediate assignment
procedure. Use the suggested system value.
It is set on transmission of CHANNEL ACTIVATION by
the BSC and canceled on receipt of ESTABLISH
INDICATION sent by the BTS.
Object : bts
Default value : 3
Engineering Rules : Most of the time, the timer expires in the case of double
allocation (i.e, when two RACHs are sent by the same
mobile to the network). The higher the timer is the longer
unnecessary signaling resources are reserved. Up to 30%
of signaling resources are allocated for a second RACH for
phase 1 MS according to numberOfSlotsSpreadTrans (32).
To optimize signaling resources (especially in case of
Queueing), it could be useful to decrease the timer value.
The minimum time between the two messages is 600 ms
and the maximum for a lightly loaded BSS is
almost 1.8 seconds when MS is answering.
Counters : C1163/5
t3103 Class 3 T5
Description : BSC timer triggered during the handover procedure. Use
the suggested system value.
It is set on transmission of HANDOVER COMMAND by
the BSC and canceled on receipt of either HANDOVER

4119001036
COMPLETE or HANDOVER FAILURE sent by the MS

(intra-bss handover), or CLEAR COMMAND sent by the
MSC (inter-bss handover). At expiry of T3103, the
channel is released.
Range value : [2 to 255] seconds (t3103 < bssMapT8)
Object : bts
Default value : 5 seconds
Recommended value : 5 seconds

Engineering Rules : Since the longest procedure is the inter BSS handover, it
is the example that was taken. The timer is set on receipt
of the HO command and reset on clear complete (the
resource of the previous BSC is free). It means that as long
as the timer runs, 2 channels are kept: one on the
originating BSC and one on the target BSC.
If the timer is too long, two resources are used which can
be a bad in case of capacity problems.
Testing showed that if NSS timers are properly set, the
handover procedure never lasts more than 5 seconds. So,
it is advised to change the default value to 5 seconds if
capacity problems may be encountered.
t3107 Class 3 T6
Description : BSC timer triggered during the assignment command
It is set on transmission of ASSIGN COMMAND by the
BSC and canceled on receipt of either ASSIGN
COMPLETE or ASSIGN FAILURE sent by MS.
Object : bts
Recommended value : 10 seconds in a network without any capacity problems. If

not, the value can be decreased. The maximum theoretic
value is 5 seconds.

Engineering Rules : At expiry of the timer, the mobile is assumed to be lost and
its resource can be used by another mobile. The most
constraining case where t3107 is used is the one where the
mobile is on SDCCH: the timer T200 leads to a 230 ms wait
instead of 180 ms on TCH, before repeating a message. At
each new Assign Command, t3107 is reset.
In the example of the case where no message is repeated,
this procedure lasts about 1 second. However, if the radio
link is bad, it is necessary to repeat some messages. The
maximum time before resetting t3107 is approximately
5 seconds: after this time, the timer will expires: no new
message will be received to reset t3107.
The default value of 10 seconds is then a good value to
ensure that the link is not cut too early. However, it is
shown that resources are occupied for no reason during a
few seconds. It can be critical in the case of a network with
problems of capacity. Furthermore, from data gathered
from live networks, it appears that either Assign
Complete messages are encountered in less than 2 seconds
or the assign command has failed.
Counters : C1163/6
t3109 Class 3 T7
Description : BSC timer triggered during the SACCH deactivation
procedure . Use the suggested system value.
It is set on receipt of DEACTIVATE SACCH
ACKNOWLEDGE sent by the BTS and canceled on
receipt of RELEASE INDICATION sent by the BTS. If the
timer expires, a RF CHANNEL RELEASE message is sent
to the BTS and a RF CHANNEL RELEASE ACK is
expected.
Range value : [2 to 255] seconds (t3109 radioLinkTimeout)
Object : bts
Recommended value : 12 seconds (related to radioLinkTimeOut value)

Engineering Rules : On receipt of the Deactivate SACCH message, the radio
link control algorithm will lead to a decrease on the value

4119001036
of the radioLinkTimeOut timer and this on MS side or

on BTS side according to the situation. t3109 added to
t3111 must be greater than radioLinkTimeOut and greater
than the time corresponding to rlf1:
t3109 radioLinkTimeOut
If t3109 is too small, the ressources could be allocated even
if radiolinkTimeOut did not reach zero yet.
t3111 Class 3 T8
Description : BSC timer triggered during the radio resource clearing
It is set on receipt of RELEASE INDICATION sent by the
BTS. On elapse, the BSC sends RF CHANNEL
RELEASE.
Object : bts

Engineering Rules : This timer is used to delay the channel deactivation after
disconnection of the main signalling link. Its purpose is to
allow time for the possible repetition of the disconnection
by the BTS to the MS.
After Release Indication, resources are kept until t3111
expires. In case of capacity problems, t3111 must be as
little as possible. The smallest possible value is 2 seconds
(range 2255 seconds).The minimum theoretic value is 5
times the repetition time which is less than 2 seconds No
advantage has been found to have a higher value than the
smallest possible one.
t3122 Class 3 T9
Description : Minimum time that mobiles must wait before issuing a
channel allocation request when an immediate assignment
has failed

Object : bts

Engineering Rules : This value is broadcast to the mobile stations. When an
immediate assignment reject command is received (when
no SDCCH and no TCH in signaling mode is available or
when the Ainterface is down), mobile stations wait t3122
seconds before sending the request again. In case of BSC
Overload, t3122 is automatically increased or decreased
between its value set by O&M and 30s according to a
specific algorithm.
This parameter can be used to solve a problem of a load
pick. By increasing the value, the access to the network is
regulated.
timerPeriodicUpdateMS Class 3 T10
Description : Time between two location update requests
Range value : [0 to 255] 1/10th of hour. 0 means that no periodic loca-
tion update is requested.
Object : bts
Default value : 60
Recommended value : 10 (not loaded network)

20 (loaded network)
Engineering Rules : Location updatings are performed when initiating a call or
when entering a new location area in idle mode. When
those events do not occur, timerPeriodicUpdateMS is used
to ensure a maximum time between two location update
requests. The value of this timer should be set regarding the
value of the same timer used in the switch (attach mobile
audit for a DMS)
If the value chosen is low, the load of the BSC is severely
increased. On the contrary, a too high value would lead to
a smaller reactivity of the mobile (e.g. if a mobile is in a
hole of coverage and a short message is sent to it, it will be
aware of it only at the next location update which could be
several hours later). A good tradeoff is 2 hours.

4119001036
3.20 PAGING PARAMETERS
delayBetweenRetrans Class 2 D6 V8
Description : Number of occurences of a paging sub-group that separates
two transmissions of the same paging message.
Object : bts
Default value : 0
Engineering Rules : The recommended value is 0 because the time between two
paging commands broadcast must not be too long, other-
wise there is a risk of double allocation. This phenomenon
occurs when the suscriber answers and hangs up very
quickly. In that case, the mobile is ready to receive a new
paging message, for example the previous one if it is
resent. The value of this parameter is linked to the values
of the nbOfRepeat and retransDuration parameters. Fur-
thermore, the following inequality, that is not checked by
the system, must be true:
retransDuration (delayBetweenRetrans + 1) x nbOfRepeat
maxNumberRetransmission Class 3 M14

Description : Maximum number of RACH burst retransmissions
allowed in a call in case of nonsystem response
intervals on the cell BCCH. It defines the maximum
number of times a mobile can renew access requests to the
BTS on RACH.
Range value : [one / two / four / seven]
Object : bts
Default value : two
Recommended value : two in noninterfered areas

four in interfered areas

Engineering Rules : In interfered areas, it is necessary to repeat RACHs

because of bad conditions. Even if it increases a little
overall noise, the gain in decreasing the number of RACHs
not received should be significant (under study).
In noninterfered areas, the value of two is sufficient.
one is not advised because mobile stations can be in holes
of coverage due to multipath fading and, in these cases, at
least one retransmission is necessary.
nbOfRepeat Class 2 N7 V8
Description : Maximum number of times that paging messages are
repeated to mobiles that belong to the same paging
subgroup
It is set to 3 in former BSS versions (static configuration
parameter).
The following inequality, that is not checked by the
system, must be true (refer to these entries in the
Dictionary):
Object : bts
Default value : 3
Engineering Rules : The value of 3 ensures a good quality of service. With less
repetitions, paging messages can be lost, and, as the repeti-
tions are performed systematically, a signicantly higher
value would increase the load of the system and the risk to
page a mobile twice. The value of this parameter is linked
to the values of the delayBetweenRetrans and
retransDuration parameters.
noOfBlocksForAccessGrant Class 2 N8
Description : Number of CCCH blocks not used for paging
Range value : [0 to 2] if the cell uses a combined BCCH, [1 to 7]
otherwise. 0 means that PCH blocks are used for sending
immediate assignment messages as and when needed.

4119001036
Object : bts
Default value : 0
Recommended value : 0 if no SMS_CB or SMS_CB with combined BCCH

1 if SMS_CB with noncombined BCCH
noOfMultiframesBetweenPaging Class 2 N9
Description : Number of occurences of a paging sub-group
Range value : [2 to 9] multi-frame of fifty-one frames

Object : bts
Default value : 2
Recommended value : 6 for rural environments, 2 or 4 for urban environments

Engineering Rules : This parameter has an impact on the use of mobile batteries
(determine when an MS needs to listen to paging channels)
and on reselection selectivity. For this operation, fre-
quency of measurements performed on idle neighbours
thanks to the formula: mesurements done every Max
(5 seconds, ((5*nb of idle neighbors + 6) DIV 7) * noOf-
MultiframesBetweenPaging /4).
Regarding mobile batteries, a value of 6 is sufficient to

have a tradeoff between the saving of energy and effective
paging. In rural environments, the maximum size of
reselection list is usually 4/5. 5 seconds is then the
maximum in the formula, so it does not slow down the
reselection mechanism. The value of 6 is then advised.
In urban environments, the size of the list is a bit higher.
Furthermore, in this kind of environment, reselection
reactivity is a key issue. The way to avoid having more than
5 seconds in the formula is to decrease
noOfMultiframesBetweenPaging to 2 or 4 even if it
increases battery consumption. Some studies are in
progress to determine the value with more accuracy.

numberOfSlotsSpreadTrans Class 3 N10

Description : Number of radio time slots over which RACH
transmission access are spread in a random way to avoid
collisions
Range value : [3 to 12, 14, 16, 20, 25, 32, 50] time slots
Object : bts
Default value : 32
Engineering Rules : From Rec 04.08, numberOfSlotsSpreadTrans
(TX_INTEGER) has a different meaning for phase 1 and
phase 2 mobiles. For phase 1 mobiles, if the value is too
small, two resources may be allocated to the same mobile
(double allocation). For phase 2 mobiles, it is different.
The best tradeoff is to take 32 which is very good for
phase 2 mobiles and not too bad for phase 1 mobiles.
pagingOnCell Class 3 P8 V9
Description : Enable or disable paging requests in a cell
Object : bts
Recommended value : enabled but can be disabled on special occasions (see Eng.
Rules)
Engineering Rules : When pagingOnCell is set to disabled, the BSC does not
send any PAGING_COMMAND to the cell. This feature
is used when operators want to forbid mobile terminated
call setup in specific cells. It can be useful during special
events or in places like cinemas, theaters...
retransDuration Class 2 R28 V8

Description : Maximum number of occurrences of a same paging
sub-group that separates the first and the last transmissions
of the same paging message.

4119001036
Object : bts
Default value : 10
Engineering Rules : If many paging commands must be broadcast, repetitions
of old paging messages are delayed because fresh paging
has a higher priority. Therefore, repetitions could be so
delayed that it leads to double paging. By setting this
parameter to an accurate value retransDuration , the risk
of sending very old paging messages is limited. Anyway,
the value of this parameter is linked to the ones of nbOfRe-
peat and retransDuration. Furthermore, the following
inequality, that is not checked by the system, must be true:

3.21 FREQUENCY HOPPING PARAMETERS
bscHopReconfUse Class 1 B20 V8
Description : Whether frequency hopping reconfiguration is authorized

in BTSs that use cavity coupling

Object : bsc
Default value : True
Type : DP , Design
Recommended value : True (for BSC that manages both cavity and hybrid
coupling), False (mandatory for hybrid coupling)
Engineering Rules : If the value is True then the value of
btsHopReconfRestart must be true in case of cavity
coupling in the BTS.
However, when enabling frequency hopping, it is

advised to use hybrid coupling and synthesized
frequency hopping.
In order to facilitate the further use of frequency
hopping in the network, the parameter
bscHopReconfUse can be set to True, even if
frequency hopping is not used yet.
btsHopReconfRestart Class 2 B21 V8
Description : Whether hopping frequency reconfiguration is authorized

on TX restart in a cell

Object : bts
Default value : true
Recommended value : True (for cavity coupling), False (mandatory for hybrid
coupling)

4119001036
Engineering Rules : If the value is True then the value of bscHopReconfUse

must be true.
However, when enabling frequency hopping, it is
advised to use hybrid coupling and synthesized
frequency hopping.
With cavity coupling, in order to facilitate the further
use of frequency hopping in the network, the parameter
btsHopReconfRestart can be set to True, even if
frequency hopping is not used yet.
btsIsHopping Class 2 B22

Description : Whether frequency hopping is allowed in a cell
Range value : [hopping / noHopping / hoppingWithCarrierFilling (V8) /
noHoppingWithCarrierFilling (V8)]
Object : bts
Default value : noHopping
Type : DP , Design
Recommended value : hopping

Engineering Rules : The two main advantages of using Frequency Hopping are
interferer and frequency diversities. Enabling frequency
hopping allows to adapt and maximize the frequency reuse
efficiency by maximizing the capacity in terms of offered
Erlang/MHz/km. Moreover enabling frequency hopping
makes easier the task of frequency planning and TRXs
addition.
! Caution:
When TRX are hopping, it is highly recommended to
modify some TDMA configuration. Channel SDCCH
must be set on time slot 1 of the concerned TDMA.
Moreover this modification can be introduced before
enabling frequency hopping.
It is also recommended not to use Power Control with
Frequency Hopping in case of cavity couplers. Indeed,
with cavity couplers, the BCCH frequency can be part of
the Mobile Allocation List (that is not possible in case of
Hybrid couplers) and then the gap between the emitted
power of two adjacent bursts could be at its maximum.

btsThresholdHopReconf Class 2 B23 V8
Description : Minimum number of frequencies that must be working in

a cell to allow frequency hopping reconfiguration

Object : bts
Default value : 1
Engineering Rules : This parameter is checked before reconfiguration is
started, for cavity coupling. If there are less remaining
frequencies than the value of this parameter, the cell is
deconfigured. The minimum value (1) allows a cell to be
reconfigured even if there is only one frequency still
available.
cellAllocation Class 2 C18
Description : List of no more than sixty-four frequencies allotted to a cell

in the network frequency band
Range value : [1 to 124] (GSM 900 network), [0 to 1023]

(GSMR / Extended GSM network), [512 to 885] (GSM
1800 network), [512 to 810] (GSM 1900 network)
Object : bts

Engineering Rules : This list must include all the frequencies used by TRX of
the cell, even the BCCH frequency.
With cavity couplers, two (2) consecutive frequencies

must be spaced of at least 600 kHz in order to avoid
interference, because of material constraints.
With hybrid couplers, two (2) consecutive TCH
frequencies may be spaced of 400 kHz, though BCCH
frequencies must be spaced of 600 kHz.

4119001036
fhsRef Class 2 F2
Description : Identifier of the frequencyHoppingSystem object that

defines the frequency hopping management parameters
for the radio time slot

Object : channel
Condition : To define if the time slot hops in frequencies.

Engineering Rules : It is advised to use only one (1) fhsRef per cell (when the
Mobile Allocation is the same for all its TRX), because it
is time saving for creation at the OMC.
hoppingSequenceNumber Class 2 F3
Description : Hopping sequence number used by a radio time slot which

obeys frequency hopping laws.
Select different HSNs for nearby cells that use the same set
of frequencies.
Object : frequencyHoppingSystem
Recommended value : See Engineering Rules and Chapter 4.18 for more details
Engineering Rules : In case of synthesized frequency hopping, whatever the
fractional reuse pattern for TCH, using a unique HSN per
site allows to avoid frequency collisions. However, it leads
to a specific MAIO plan, more restricting than with the use
of different HSN in cells (needs more frequencies). Indeed,
the frequency load would be higher with different HSN.
But it is possible to reach the maximum frequency load
(value limited by RF constraints to 20 % for 1:1 pattern and
50 % for 1:3 pattern) with a unique HSN per site and then
systematically avoiding frequency adjacencies.

maio Class 2 M15
Description : Index in the list of frequencies allotted to a radio time slot

which obeys frequency hopping laws.
Setting this attribute, together with the fhsRef attribute,
allows the time slot to obey frequency hopping laws.
This offset allows to differentiate channel objects that
reference frequencyHoppingSystem objects with identical
attributes (orthogonality principle).
Range value : [0 to N1] N is the number of frequencies ( 64) allotted
to the time slot.
Object : channel
Recommended value : See Engineering Rules and Chapter 4.18 for more details
Engineering Rules : The MAIO must be different for each TRX within a cell in
order to avoid frequency collision. If the Mobile Alloca-
tion contains adjacent frequencies, the difference between
two TRX MAIO within a cell must be greater or equal than
two (2). Thus, it means that the number of frequencies in
the MA would be at least twice greater than the number of
TRX.
However, for a 1:3 pattern, it is possible to use the same
MAIO sequence in all cells of a same site. Moreover, for
such a pattern, if each list of MA frequencies does not
contain adjacent frequencies, adjacent MAIO can be used.
For a 1:1 pattern, different MAIO for each TRX must be
used and no adjacent MAIO if there are adjacent
frequencies in the MA list.
mobileAllocation Class 2 M16
Description : List of up to sixty-four frequencies allotted in the network

frequency band to a radio time slot which obeys frequency
hopping laws
Range value : [1 to 124] (GSM 900 network), [0 to 1023]
(GSMR / Extended GSM network), [512 to 885]
(GSM 1800 network), [512 to 810] (GSM 1900 network)
Object : frequencyHoppingSystem

4119001036

Engineering Rules : This list must include all the hopping frequencies used by
a TRX. As the first TRX of a cell does not hop, then is not
related to a MA (TRX channels frequency is BCCH). The
following TRXs may have a common MA containing all
the hopping frequencies (not including the BCCH fre-
quency).
traffic PCM allocation priority Class 2 T11 V9

Description : Allocation priority of a TDMA frame on the covering site
PCMs
Object : transceiver
Recommended value : 0 for the TDMA supporting the BCCH, 255 for the others

3.22 BSC LOAD MANAGEMENT PARAMETERS
lapdTerminalNumber Class 0 L9
Description : BSC SICD port assigned to the LAPD link
Range value : [0 to 7] (BSC type 1)
[0 to 15] (BSC type 2)
Object : lapdLink
Engineering Rules :
lapdTerninalNumber = 4 x number of the mother SICD4

board [0 to 9] + port number [0 to 3]
lapdTerninalNumber = 8 * number of the mother SICD8
board [0 to 4] + port number [0 to 7]
To avoid overload on one SICD board due to high spot

traffic, it is recommended:
to balance the distribution of the sites on the SICD
boards in term of number of Erlangs (from the design of
the network)
to optimize the Location Areas, then to avoid that two
(2) adjacent cells on two (2) different LAs at the frontier
of the two (2) LAs are on the same SICD board.
processorLoadSupConf Class 3 L10 V8

Description : Threshold used in the load control algorithm by the BSC
The table herafter gives the % of the theorical load usable
values for each type of board.
value OMU (level 1, 2, 3) Other boards Comments
0 8090100 8090100 nominal value

1 8090100 90100100 permissive value

4119001036
value OMU (level 1, 2, 3) Other boards Comments
2 8090100 758595 restrictive value
3 100100100 100100100 simplex mode (see Note 1)
4 8090100 8090100 nominal value (see Note 2)
5 8090100 90100100 permissive value (see Note 2)
6 8090100 758595 restrictive value (see Note 2)
7 8090100 506070 exceptional value (see Note 3)
8 8090100 8090100 reserved value (see Note 4)
9 8090100 90100100 reserved value (see Note 4)
Note 1: This value must be used when the operator wants to decrease the impact
induced by the simplex mode.
Note 2: For these attribute values (4, 5, and 6), the CPU weighing factor of the
OMU board is more restrictive than for the attribute values 0 to 2, and this factor
must be used in case of high load on this board.
Note 3: This value must be used in case of exceptional events, in order to manage
high blocking rate on the Air and A interface.
Note 4: The thresholds of these two sets of parameters are modifiable by using the
BSC data config functionality.
Object : bsc
Default value : 1
Engineering Rules : See corresponding chapter 2.11 in the Algoritms part ;
the value 7 should only be used as a backup solution in
case of special events ; the V12 overload control
mechanism has been built to adapt the BSC to any call
profile with the single value 0 (even for special events).

3.23 DUAL BAND PARAMETERS

early classmark sending Class 3 E3 V10
Description : Whether Early classmark sending procedure initiated by a
multiband MS is allowed.
Range value : [Not Allowed, Allowed]
Object : bts
Default value : Not Allowed
Type : DP , Design
Recommended value : Allowed (for dual band network)

Engineering Rules : When this parameter is set to enabled, the Class-
mark_Change message is sent just after the SABM and UA
frames exchange on the Immediate_Assignment proce-
dure. This message enables interband handover proce-
dures (handovers on TCH and SDCCH, Directed Retry).
In single band networks, early classmark sending will be
set to disabled.
multi band reporting Class 3 M17 V10

Description : Minimum number of cells that multiband MSs must report
in their radio measurements in each frequency band
Range value : [the six strongest cells / the strongest cell out band / the two
strongest cells out band / the three strongest cells out band]
six strongest allowed cells irrespective of their
frequency band
the strongest allowed cell outside the current frequency
band
the two strongest allowed cells outside the current
frequency band
the three strongest allowed cells outside the current
frequency band
Object : bts
Default value : the six strongest cells
Recommended value : The two strongest cells out band (case of privileged band),
the six strongest cells (case of no privileged band)

4119001036
Engineering Rules : For values indicating the one (1), two (2) or three (3) stron-
gest cells out band, the multiband MS respectively reports
the one, two or three strongest allowed cells outside the
current frequency band. The remaining space in the report
(at least 5, 4 or 3 cells) is used to give information about
cells in the current frequency band. If there are still some
remaining positions, they are used to report cells outside
the current frequency band.
When the operator wants to privilege one of the frequency
band, it is advised to report two (2) cells outside the current
frequency band, for cells in the privileged frequency band.
Then, neighbour cells in the priority frequency band will
be privileged. Actually, if multibandReporting is set to
1, the risk is to report five (5) priority frequency band
neighbour cells with a bad quality or signal strength (near
priority frequency band boundaries for example) and one
(1) good neighbour cell in the low priority frequency band,
but under congestion. Thus the MS will not make a
handover toward a good neighbour cell and the quality of
service may be impacted.
For cells outside the privileged frequency band, it is
advised to report three (3) cells outside the current
frequency band. Thus, it ensures the report of all (if less
than 3) or at least three (3) neighours in the priority
frequency band.
In case no frequency band is preferred, the report of the
the six strongest cells allows to make a handover toward
the best neighbour cell, whatever the current cell is.
standard indicator AdjC Class 2 S3 V10

Description : Type of network in which this neighbor cell is working
Range value : [gsm / extended gsm / dcs1800 / pcs1900 / R gsm /
gsmdcs (V12) / dcsgsm (V12)]
Object : adjacentCellHandover
Default value : gsm

Engineering Rules : The indicated standard indicator must have the same value
in adjacentCellHandover or adjacentCellReselection
objects and in the associated neighbour bts object.

standard indicator AdjC Class 2S4 V10

Description : Type of network in which this neighbor cell is working
Range value : [gsm / extended gsm / dcs1800 / pcs1900 / R gsm /
gsmdcs (V12) / dcsgsm (V12)]
Object : adjacentCellReselection
Default value : gsm

Engineering Rules : The indicated standard indicator must have the same value
in adjacentCellHandover or adjacentCellReselection
objects and in the associated neighbour bts object.

4119001036
3.24 DTX PARAMETERS

cellDtxDownLink Class 3 C19
Description : Whether the use of discontinuous transmission in
BTS-to-MS direction is allowed in a cell
Object : bts

Engineering Rules : DTXDownLink is particularly interesting in case of low
interfered networks with fractional reuse patterns for
frequency plan. In this case, it is recommended to uses a
reactive configuration with a short delay between HO
decision (runHO = 1) and with short average windows
(Hreqt = 1, HreqAve = 4). Ho margins can also be lowered.
! Caution:
Using this feature may create a more sensitivity to bad
values (fading, frequencies collision). This can be
compensated by margin values.
! Caution:
Activation of DTXDownlink when DTX is already used
leads to a diminution in the precision of the measurement
on the cell, on quality and on level.
dtxMode Class 3 D7
Description : MS control of the discontinuous transmission mechanism
in a cell
Range value : [msMayUseDtx / msShallUseDtx / msShallNotUseDtx]
Object : bts
Default value : msShallNotUseDtx
Recommended value : msShallUseDtx

3.25 MISCELLANEOUS
baseColourCode Class 2 B24
Description : Base station Color Code assigned to a serving cell. It is
broadcast on the cell SCH and is used to distinguish cells
that share the same BCCH frequency.
Object : bts
cpueNumber Class 0 C20 V12

Description : Number of the CPU/BIFP board chosen for managing the
radio site and its related equipment.
BSC CPUE 0 CPUE 1
BSC 12000/6000 BIFP0 BIFP 1

types 3, 4, 5
Range value : [noValue / 0 / 1]

noValue: let BSC determine BIFP board number on
which the new site is attached
0: attach the new site to BIFP0
1: attach the new site to BIFP1
Engineering Rules : It is advised to use the observation counters to well balance

the sites on the 2 CPUBIFP.
Nortel engineering tools can be used to optimize the
distribution.
! Caution:
This parameter only applies to type 3 to type 5 BSCs.
measurementProcAlgorithm Class 2 V12

Description : Whether the new L1M interface is used
Range value : [L1MV1, L1MV2]

4119001036
L1MV1: the older L1M is used

L1MV2: the newer L1M is used
Object : bts
Recommended value : L1MV2

Engineering Rules : L1MV2 not supported on DCU2.
It is not recommended to set L1MV2 on a DCU2/DCU4

BTS mixed configuration since the enhancements offered
will be available only on part of the site so with a call
processing not homogeneous on the whole
communications.
Major benefits are:
ability to support advanced capacity and coverage
features such as Automated cell tiering
capture process more reactive
less handover failure (better updating of eligible cells)
early decisions more accurate (0.5 s saved on the
processing delay of first measurements)
siteGsmFctList Class 2 S5
Description : List of up to fourteen elements that identify the GSM

functions configured in a site BCF
Range value : [entityMgt / download / siteMgt / abisSig / abisTraf /

rfTrans / rfRecep / cellMgt / fhMgt / tdmaMgt / tsMgt /
gsmTime / car0Fil / freqMgt]
Default value : [entityMgt / download / siteMgt / abisSig / abisTraf /
rfTrans / rfRecep / cellMgt / fhMgt / tdmaMgt / tsMgt /
gsmTime / car0Fill / freqMgt]
Recommended value : [entityMgt / download / siteMgt / abisSig / abisTraf /

rfTrans / cellMgt / fhMgt / tdmaMgt / tsMgt]

Engineering Rules : It is always useless to put the elements rfRecep,

gsmTime and car0Fill in the list because these
functions are not yet implemented.
The function freqMgt must be included in the list only
when using cavity coupling.
It is advised to put the function fhMgt even if frequency
hopping is not used in the network, in order to avoid a class
2 parameter change when introducing this feature.
Description : Correlation ratio of the input signals received from the
normal and diversity antennas. This ratio enables to adapt
the SPU software (the interferer cancellation algorithm) to
the propagation conditions. Correlation ratio = 0 means
that the interferer cancellation algorithm is inactive.
Object : bts
Default value : 0
Type : DP , Design

4119001036
3.26 PCM ERROR CORRECTION PARAMETERS

enhancedTRAUFrameIndication E4 V12
Description : Whether the BTS uses the Enhanced TRAU Frame (ETF)
for TCU
Range value : [notAvailable / available / active]
Object : bsc
Type : DI , Optimization
Note :
This attribute is set to available only if the transcoderBoards of all the related
TCUs are of TCB2 board type and their softwares are V12.
This attribute is set to active only if the pcmErrorCorrection attribute of one
bts object related to the BSC is set to 1.
Only BTSs equipped with non mixed DCU4 or DRX transceiver architecture can
support the Enhanced TRAU Frame.
pcmErrorCorrection Class 2 P9 V12

Description : Whether the bts uses the new ETF (Enhanced TRAU
Frame) frame (set to 1) or the ETSI Rec 08.60 frame
(set to 0).
Range value : [0 / 1]
Object : bts
Default value : 0
Note : This parameter is only available for BTSs equipped with non mixed
DCU4 or DRX transceiver architecture.
Engineering Rules : To benefit from the PCM Error Correction feature during
intra BSC HO, it is advised to use the ETF for all cells
linked to the BSC.
This attribute can be set to 1 only if
enhancedTRAUFrameIndication attribute is set to
available or active.
! Caution:
All related TCUs shall be of TCB2 board type and their softwares
shall be V12.

3.27 UPLINK MAPPING PARAMETERS

uplinkMappingChannelNumber Class 2 U6 V12
Description : Channel number used for uplink mapping as the
monitored TS
Object : bts
Default value : 7
Recommended value :
Engineering Rules : The attribute must contain an even value in case of an
extended cell (2, 4, 6). In case of a multi CCCH cell it must
contain an odd value (1, 3, 5, 7).
This channel number correspond to a time slot number
belonging to the BCCH TDMA ; it shall be chosen
according to the TDMA model.
See also subchapter 2.17 Uplink mapping in the
Algorithms part.
! Caution:
The Uplink mapping feature is only supported with BTS equiped
with non mixed DCU4 or DRX transceiver architecture.
uplinkMappingFreq Class 2 U7 V12

Description : Frequency (f0) used for uplink mapping
Object : bts
Default value : 0
Recommended value : This frequency must not belong to the cell allocation of any
network cell.
To ensure viable measurements, f01 and f0+1 should be
withdrawn from the frequency plan or, at least, they must
not correspond to BCCH frequencies.
See also subchapter 2.17 Uplink mapping in the
Algorithms part.

4119001036
! Caution:
uplinkMappingMeasurementMode Class 2 U8 V12
Description : Whether uplink mapping is active on the BTS or not

Object : bts

Engineering Rules : See also subchapter 2.17 Uplink mapping in the
Algorithms part.
! Caution:
uplinkMappingProcessingMode Class 3 U9 V12
Description : Whether uplink mapping is active on the BSC or not

Object : bsc

Engineering Rules : See also subchapter 2.17 Uplink mapping in the
Algorithms part.
! Caution:

3.28 CELL TIERING PARAMETERS
hoMarginTiering Class 3 V12

Description : Hysteresis between the uPwCIDLH and lPwCIDLH
tiering thresholds to avoid pingpong handovers
(expressed in dB)
Engineering Rules : See subchapter 2.5.11 Automatic cell tiering in the

Algorithms part.
It is an hysterisis between uCirDLH and lCirDLL tiering
thresholds to avoid pingpong handovers.
interferenceType Class 3 V12

Description : Type of interference created by neighbour cell
Range value : [not applicable / adjacent / coChannel]
Object : adjacent CellHandOver
Default value : 0

Algorithms part.
To define this parameter, it is advised either to use the
OMC shell based tool or to use CT1000 tool (the second
solution is preferable since the considered cells are not
restricted to cells managed by one OMCR).
nbLarge Reuse Data Channels Class 3 V12

Description : Mean number of logical channels belonging to the large
frequency reuse pattern and used at the same time for data
communications
Range value : [16 to +16]

4119001036
Object : bts
Default value : 0

Algorithms part.
This parameter gives the mean number of radio TS in the
large reuse pattern (BCCH) used for data communications
(and consequently not available for tiering).
numberOfPwciSamples Class 3 V12

Description : Minimum number of PwCI samples required to reach a
reliable distribution (representative of the real distribution
in the whole cell) * 1000
Default value : 20

Algorithms part.
It is the minimum number of thousands of Pwci samples
required to reach a reliable distribution.
Some experiments have shown that at least 20 x 1000
samples are necessary.
pwciHreqave Class 3 V12

Description : Averaging window size for PwCI
Default value : 8

Algorithms part.
It defines the number of measurement reports for PWCI
arithmetic averaging.

selfTuningObs Class 3 V12

Description : Parameter indicating that the BTS is in charge of sending
pwCi distribution on Abis interface
Range value : [pwCi distribution not sent
pwCi distribution sent after gathering
one pwCi distribution sent per hour]
pwCi distribution not sent: pwCi distribution is
gathered but not sent onto Abis interface
pwCi distribution sent after gathering: pwCi
distribution is gathered and sent onto Abis interface
each time a new tiering threshold is computed
one pwCi distribution sent per hour: pwCi distribution
is gathered and sent onto Abis interface when a new
tiering threshold is computed but no more than 1
message every hour can be sent
Default value : 0
Note : pwCi distribution may be gathered and sent onto Abis interface inde-
pendantly of tiering activation

Algorithms part.

4119001036
Engineering issues
4 ENGINEERING ISSUES
4.1 HOW TO OPTIMIZE POWER CONTROL USE?

As it is shown on the diagram below the probability of a mobile (resp. a BTS)
decreasing its transmission power is correlated to the area of zone 1. To increase the
probability of transmitting at low power the area must be as wide as possible.
Note: Values in parameters are given as examples.
RXQUAL RXQUAL
lRxQualxxH
lRxQualxxH (4)
(4) lRxQualxxP
uRxQualxxP
lRxQualxxP (3)
(3) Power Power
Power
uRxQualxxP Power
(2)
Zone 1 Zone 1
RXLEV RXLEV
lRxLevxxH lRxLevxxP uRxLevxxP lRxLevxxH lRxLevxxP
(100 dBm) (88 dBm) (82 dBm) (100 dBm) uRxLevxxP
(88 dBm)
Since power control does not involve an increase of the signalling messages
number, there is no requirement to increase the probability of the mobile modifying
its TX power during a call.
By reducing the difference of (lRxLevxxP uRxLevxxP) of Max
(powerIncrStepSize, powerRedStepSize) and increasing the value of uRxQualxxP
(until lRxQualxxP), it is possible to optimize the power control use.

Engineering issues
4.2 ONESHOT POWER CONTROL

The oneshot power control algorithm allows high path loss compensation.
However, some mobiles are perturbed by high received signal strength variations
and hence, several of their measurements are wrong. If the mobile is near the base
station antenna, with a few types of mobiles the BTS will first decrease in a
oneshot its transmit power, and then, because of wrong measurements performed
by the mobile, will increase its power to its maximum, this is an oscillating effect.
Due to this effect, a maximum variation step of 8 dB has been introduced. During
each SACCH period, the power can be modified by 8 dB. From V12, the 8dB
limitation applies only for decrease.
One of the V8 stepbystep power control improvements consists of correlating
both handover and power control algorithms. However, this is not the case for the
oneshot power control algorithm (V9), hence it is possible to handoff even if the
MS (or BTS) does not transmit at its maximum power. This difference is due to
the fact that the oneshot power control algorithm should be reactive enough to be
decorrelated from the handover algorithm.
With the stepbystep power control algorithm, an order to transmit at maximum
power is sent as soon as a handover is triggered. With the oneshot power control
algorithm, the same order is sent as soon as the power control is triggered.
The non correlation between both algorithms will not lead to avoid the increase of
the power before a handover. So the L_RXQUAL_XX_P shall be lower than
L_RXQUAL_XX_H. A difference of one dB between both values provides an
effective power control and keeps a good reactivity for handovers.
Example:
L_RXQUAL_XX_P = 3
L_RXQUAL_XX_H = 4
A rapid variation of the quality (from 2 to 5) will trigger the handover algorithm and
not the power control algorithm. In the above example, a value equal to 4 for the
power control threshold (L_RXQUAL_XX_P) would be insufficient to keep a good
reactivity for handovers.
During the algorithm validation period, a comparison was made between one shot
power control algorithm and stepbystep one. The conclusions were expressed
as follows:

4119001036
Engineering issues
The one shot power control is correctly implemented according to functional

specifications. Without any deterioration of uplink and downlink quality, one shot
power control activation contribues to the following advantages:
more power attenuation globally in the cell,
quicker decrease to low power,
quicker increase to maximum power.
Furthermore, the reactivity of the algorithm allows to set the one shot power control
thresholds to the stepbystep low ones without any impact on uplink and downlink
quality.
One shot QOS metrics are also better than stepbystep ones.

Engineering issues
4.3 MINIMUM TIME BETWEEN HANDOVER

Different cases of handovers are given, and for each, the parameter setting influence
is described.
MICRO CELLULAR NETWORK
Handover microcell > microcell: avoiding handover pingpong is important
but a mobile could cross a cell in 2 or 3 seconds. A delay
(btsTimeBetweenHOConfiguration) should not be used in this case
(see Figure 41).
mobile
microcells
Figure 41 MICROMICRO HANDOVER
The parameter setting should be:

bscTimeBetweenHOConfiguration = true, because the feature may be important for
other cells in the BSS.
btsTimeBetweenHOConfiguration = minimal value
(= rxLevHreqave*rxLevHreqt*0.48 sec)
Actually, even in such configuration, the value of the delay depends on the speed
of the mobiles. If the speed is low and the mobile speed in the cell is homogeneous
then the delay can be significant and have an action on pingpong handover. If the
speed is non homogeneous then the most rapidmoving mobiles must be
considered for the value of the delay, though pingpong handovers could occur. The
lower the most rapid moving mobiles speed, the more important the delay is. Then
btsTimeBetweenHOConfiguration is a function of the cell size and the mobile
speed.
In the case of Figure 42, the value of the time is L/speed.

4119001036
Engineering issues
L = street width
Figure 42 EXAMPLE OF A CROSSROAD
In such situation, the problem of field variation (see Figure 43) is solved. If the
mobile speed is low then the delay will help to avoid a pingpong handover. If the
mobile speed is high, the averaging will not show all these variations.
server cell
neighbor cell
Figure 43 PROBLEM OF FIELD VARIATIONS
Handover microcell > macrocell

This kind of handover is only triggered on alarm cause. So, in this case the delay
is not very useful.
Considering a case similar to the previous one (see Figure 42), with a macrocell,
the delay can be used for the microcell. As shown below (see Figure 44) a
mobile that goes from microcell A to macrocell B will perform a handover (on
alarm cause). Then, it is worth setting a delay on cell A to avoid a pingpong
handover (between A and C).

Engineering issues
Therefore, this delay is beneficial for a mobile in cell C that turns into the street of
cell A. The same is true in opposite direction.
The only restriction is for a mobile coming from macro B and going to micro C. The
delay has a negative influence for the handover microAmicroB. It is the same case
as before (see Figure 44).
macrocell B
microcell A
microcell C
Figure 44 MICROMACRO HANDOVER
Handover macrocell > macrocell

The timer is usefull for a cell intersection where there is much interference.
Lets take the example shown in Figure 45.
Handover with cause quality is triggered from macrocell A towards
macrocell B. But just after this change of cell, a handover with cause power
budget is attempted. Using an appropriate delay, depending on the speed of the
mobile, many pingpong handovers may be avoided.

4119001036
Engineering issues
Interference = HO with cause Quality
macrocell A macrocell B
equivalence point
field level
Delay
zone of PBGT HO
Figure 45 MACROMACRO HANDOVER
This case can be applied to a non microcell network.

The solution is the use of the minimum time between handover. The value of the
delay depends on the distance between the interference point and the point where
macroA and MacroB have the same level. With the hypothesis that the following
neighbor cell is far away, the value of the delay depends on the minimun speed of
the mobile.
It is not really obvious to recommend a value because it is a question of interference
point position. So, before test and measurement results, the recommended value is
the default value: 16, that corresponds to 8 seconds.
There are two ways to determine the best value:
*system test: the counters show that pingpong handovers exist. With a little
variation of the delay (btsTimeBetweenHOConfiguration), it is possible to see the
influence (always with counters). So with only some steps of delay variation the best
value to avoid pingpong handover and radio link failure can be found.
*measurements: with mobile measurements, the point of interference and the
equivalence point can be found. Then the delay value can be deduced from the
distance between both points.

Engineering issues
Constraint:
The following light constraint is applied to the value of the delay:
average time of a mobile in the cell (weighted if nedeed for each speed) >
btsTimeBetweenHOConfiguration.
This constraint could also be a way to find the best value of minimum time between
handover.
: HO
: No HO on Power Budget possible
during btsTimeBetweenHOConfiguration seconds

4119001036
Engineering issues
4.4 DIRECTED RETRY HANDOVER
4.4.1 Directed Retry benefit

This paragraph provides theorical studies results of the benefit that Directed Retry
can provide in mono and multilayers Networks.
The Directed Retry is mainly a benefit in the case of small congestion zone in the
network. In others cases the network is either underdimensioned or the queuing
gives better results (see figure below).
long duration
Network is
Directed Retry underdimensioned !
Duration
of congestion
(time)
normal situation Call Queueing
short duration
Surface of congestion
small surface (space) large surface
Benefit of feature on monolayer structure
Hypothesis:
12 macrocells with 3 TRX/cell
Noncombined BCCH
22 TCH available for the 12 cells
9 cells with 41% use rate (i.e. 9 TCH/22) and 3 overloaded cells with 26 channels
requested for 22 available (i.e. 24% of blocking rate)
25% of cell overlapping
The carried capacity is:
9 cells * 9 TCH + 3 * 76% * 26= 140 Erlang
the highest blocking rate is over 24%

Engineering issues
With Directed Retry:

The added carried capacity is:
25% cell overlapping => 25% * (24% * 26 requests * 3) = 4,7 Erlang
the highest blocking rate is over 18%
With Directed Retry and 25% overlapping: gain on traffic 3,3% on the whole set
of 12 cells of this example and gain on blocking rate.
Benefit of feature on multilayers structure
Hypothesis:
blocking rate of 2% max on the macrocell
3 TRX (22 TCH) with 9 TCH used / 22 (41% use rate)
1 TRX per cell with not combined BCCH
10 requests for 6 TCH on the cell (48% of blocking rate)
Without Directed Retry:

Carried capacity of n cell under 1 macrocell:
= n cell * 52% 10 + 1 macro * 9 * 100%
For n cell under 1 umbrella cell:
Number of carried Erlangs = 5,2n + 9
If n = 1, we have carried 14,2 Erlangs.

9 requests from the Macrocell
5.9 requests from the cells
Then, the mcells keep:
X% * ((n mcell * 10) 5.9)

If n = 1, the Erlang law gives X = 87.6% (a blocking rate of 12.4%)
the carried traffic is:
14.9 + 87.6% * (105.9) = 18.5

Gain 30% on ONE cell and the highest blocking rate is over 12.4% (instead of
48%).

4119001036
Engineering issues

If several n cell transfert their calls into one umbrellacell, and with the
hypothesis of our example, the gain should be (en = enabled, dis = disabled):
Erl carried DR(en)

Gain (%) = 1
Erl carried DR(dis)
X(n) * (10n 5.9) (5,2n + 9)

Gain (%) =
5,2n + 9
Gain (%) = (number of cells under one umbrella)

35% 50.0%
45.0%
30%
40.0%
25% 35.0%
Gain (%)
30.0%
20% Blocking Rate
25.0%
15%
20.0%
10% 15.0%
10.0%
5%
5.0%
0% 0.0%
1 2 3 4 5 6 7 8 9 10
Directed Retry Handover is absorted when TCH resources are released from
previous calls and become available for new allocation (when the HO command
is not yet sent).
Interaction with Queueing:
TCH allocation requests remains on the waiting lists, in case Directed Retry
proved unsuccessful. Queueing must be activated on the current cell, thus TCH
channels must be reserved on this cell.
Interaction with Handover (V9):
Just like Directed Retry, a normal HO (quality, power budget...) from SDCCH
to another cell may only be performed if TCH ressources are available in this
target cell (when queueing is activated for instance).

Engineering issues
Interaction with HO to second best candidate:

It is advised to couple the Directed Retry with this feature to enhance the
probability to find an available candidate cell (distant BTS mode).
Interaction with minimum time between HO:
To avoid pingpong handover after a Directed Retry, it is advised to activate this
feature on the neighboring cells.
The best cells to implement directed retry are the cells that have potential problems
due to a lack of TCH resources (detected thanks to tchFrResourceFailure/C1039
& allTchFrAllocatedTime/C1057 observation counters). Directed Retry may
solve the problem of load if the cell is the only one to have this kind of problem in
the close area. If the entire area is congested, almost no improvement will be
observed.
For the selected cell, queueing MUST be implemented. No queueing would mean
that the Directed Retry feature would not be activated.The parameter setting of the
queueing should lead to queues of size 3 and a waiting timer of 6 seconds in the
candidate cell.
The last value to set is the rxLev threshold used in the feature to choose a good
neighbor cell (distant mode). As the decision is taken on the basis of one
measurement, a margin of a few dBs needs to be taken to deal with multipath fading.
Then, the advised value should be at least rxLevMinCell + 3 dB.
Example of possible configurations:
At BSC level:
interBscDirectedRetry = allowed
intraBscDirectedRetry = allowed
modeModifyMandatory = used
bscQueueingOption = forced
timeBetweenHOConfiguration = true
HOSecondBestCellConfiguration = 3
At Cell level (where directed retry is implemented):
allocPriorityTimers = 0 0 6 0 0 0 0 0
allocWaitThreshold = 0 0 3 0 0 0 0 0
directedRetryModeUsed = bts
interBscDirectedRetryFromCell = allowed
intraBscDirectedRetryFromCell = allowed

4119001036
Engineering issues
At neighbor cell level:

directedRetry = rxLevMinCell + 3 dB
At cell level for neighbor cells:
btsTimeBetweenHOconfiguration = 30

Engineering issues
4.5 CONCENTRIC CELLS

Two cases are considered:
the first is the case of a new network. No sites are existing. The parameter setting
is based on radio design input.
the second is the case of an existing network, sites are existing and commercial
launch has been done. The parameter setting is based on counters study.
NEW NETWORK
Two prerequisites are required:
First prerequisite
The radio design of the network has given the reuse frequency plan. With that
information, it is possible to recommend a maximal size of the small zone and then
the attenuation of the tranceiver of this small zone to avoid interference between
close small zones using the same frequency.
Examples of design recommendations:
Two configurations are given in the Figure 46 and Figure 47 below.
(1) The first one is the omnidirectional sites configuration, where one same
frequency f0 is reused in several small zones (see Figure 46).
f0
f0
f0
Figure 46 OMNIDIRECTIONAL SITES
Hypothesis: The objective is to obtain in the small zone a C/I>=12 dB with a 6 dB

margin. Only the first 6 closest interferers are considered. All other
interference is ignored.
Results: The small cell range is 35%of the large cell range, and the small cell
power should be 16 dB Q reduced.
Q is the RxLevAccessMin difference between the two areas.

4119001036
Engineering issues
(2) The second case is the trisectorial directional sites configuration, where
three frequencies are reused in the small cells (see Figure 47). The three
frequencies f1, f2, and f3 should be spaced at 3 frequency channel separation
(600 kHz) to avoid interference of adjacent channels between the three cells of
the same site, at least 400 kHz which is the minimum frequency channel
separation to be kept.
f1
f3
f1 f2
f3
f1
f2
f3
f2
Figure 47 TRISECTORIAL DIRECTIONAL SITES
Hypothesis: The objective is to obtain in the small zone a C/I>=12 dB with a 8 dB

margin. Only the first 6 closest interferers are considered. The other
interferences are ignored.
Results: The small cell range is 50%of the large cell range, and the small cell
power should be 11 dB Q reduced.
Q is the RxLevAccessMin difference between the two areas.

Engineering issues
Second prerequisite
Another prerequisite is the average value of the strength field at the limit of a cell.
It is a cell planning input.
field strength at the

limit of the cell
small zone
large zone
This value is noted rxLevLimit.
Recommended values
Level threshold:
levLimit_LtoS_zone: field received by MS from a large zone TRX at the limit
between both zones.
levLimit_StoL_zone: field received by MS from a small zone TRX at the limit
between both zones.

4119001036
Engineering issues
B
large zone
A
small zone
At the limit of the cell (external limit of the large zone) the value of the field is
rxLevLimit.
The attenuation of the TRX of the small zone is zoneTxPwrMaxReduction.
Considering these inputs, the value of the field at the limit between the small and
the large zone (when the MS receives the field from a TRX of the large zone)
is: levLimit_LtoS_zone = rxLevLimit + zoneTxPwrMaxReduction
This value should be the value of the ConcentAlgoExtRxLev parameter.
ConcentAlgoExtRxLev = levLimit_LtoS_zone
Once the handover has been done, the mobile receives the signal from a TRX of the
small zone. It receives levLimit_StoL_zone.
The ConcentAlgoIntRxLev value should be levLimit_StoL_zone margin.
This margin is used to avoid pingpong handovers, 5 dBm should be a good value.
ConcentAlgoIntRxLev = levLimit_StoL_zone margin
Example
rxLevLimit = 70 dBm
zoneTxPwrMaxReduction = 16 dBm (omnisectorial sites)
Then:
levLimit_LtoS_zone = 54 dBm
ConcentAlgoExtRxLev = 54 dBm
levLimit_StoL_zone = 70 dBm
ConcentAlgoIntRxLev = 75 dBm

Engineering issues
NETWORK ALREADY INSTALLED

The goal is to obtain n Erlang of trafic in the small zone and m erlang of traffic in
the large zone.
small zone
m large zone
Depending on the number of TRXs in the cell and the part of them that will be used
inside the small zone, it is possible to fix the ConcentAlgoExtRxLev value. This
value will fix the limit of the small zone, and will also separate the quantity of traffic.
Using some counters, it is possible to have a graph as the representation of number
of mobile versus rxLevUPL. With a correlation between the number of MS and the
traffic (depending on profil user, hot spot in the cell), the graph can show the value
of ConcentAlgoExtRxLev to be taken.
Many graphs can exist. Three examples are given below.
number of MS
graph 1
graph 2
graph 3
BS_RxLev
graph 1: constant repartition of the MS.

graph 2: gaussian repartition, centred on the BTS.

4119001036
Engineering issues
graph 3: gaussian repartition, centred on a circular hot spot.

Example: two TRX in the cell. Graph 1 is used.
In such a case n=m, and the best value of parameter leads to a small zone range equal
to 50% of the large zone range.
But this result must be compatible with the design recommendations.
It is most important to respect these recommendations because the frequency plan
depends on it.
If so, and if it is possible to go further, that is to optimize the feature in terms of
traffic, a compromise is to be found.
TESTS ON AN EXISTING NETWORK

Some tests have been done with concentric cells in order to observe the behaviour
of frequency reuse in the small zone. These tests were carried out in rural areas.
The algorithm One Shot Power Control was always used.
Signal level
In the large zone:
measures for concentric cell configuration show a decrease on downlink signal
level in comparison with non concentric configuration because calls with high
level perform a handover to the small zone. Only the calls with weak level remain
on the large zone.
On the uplink signal level, the trend was to remain stable comparing to a non
concentric cell configuration.
In the small zone:
the same behaviour was observed in the uplink and downlink ways: the smaller
the zone area, the greater the average signal level.
Quality level
In the large and small zones, the uplink and downlink quality remains stable
comparing to a non concentric cell configuration.

Engineering issues
Power control
Large zone:
less attenuation of the MS power has been observed when using concentric cell
than without concentric cell. But this attenuation depends on the small zone area
size. The greater the small zone, the less attenuation the MS power.
Small zone:
more attenuation on BS and MS power have been observed in the small zone,
because the mobiles are close to BTS.
Then, considering the whole cell (small + large zone), the averaged MS power
attenuation remains stable and the BS power is more attenuated compared to a
configuration without concentric cell.
Global results with a 3 TRX concentric cell

The following figure gives BS and MS averaged Power attenuation, and the
percentage of samples with uplink and downlink quality upper to 4. The first
measurement is for a non concentric cell configuration, the other measurements are
for concentric cell configurations.

4119001036
Engineering issues
BS Pwr Att. Meas 1 : non concetric cell

Meas 2 ...8 : concentric cell
RxQual UL > 4
MS Pwr Att.
RxQual DL > 4
20 2,5%
18
16 2,0%
14
12 1,5%
10
8 1,0%
6
4 0,5%
2
0 0,0%
Meas 1 Meas 2 Meas 3 Meas 4 Meas 5 Meas 6 Meas 7 Meas 8
SML Zone LGE Zone Cell

RxQual UpLink > > >
RxQual DownLink > > >
RxLev UpLink > > >
RxLev DownLink > > >
Avg BS Power Att + > +
Avg MS Power Att + >
Call Drop >
+: increase, : decrease, >: stable
The global result of this table is that at cell level (small zone + large zone for a
concentric cell), the introduction of concentric cells has positive effects. It leads to
an increase of the averaged BS power attenuation.
Furthermore, RxLev and RxQual remain stable whatever the cell configuration
(concentric or not, small or large zone).
Some remarks can be given after these tests.

Call Start

Engineering issues
All calls start in the large zone. For the call setup in the small zone area, the power
control is activated twice later than without concentric cell because:
the MS has not spent enough time on the large zone for the power control
activation
after an interzone handover, a super average must be done on the small zone
BS and MS dynamic power, frequency reuse
The tests show a decrease for BS and MS dynamic powers on the TDMA dedicated
to the small zone, in comparison with a non concentric cell configuration. Thus it
favours the frequency reuse in the small zone. No interference has been observed
on the TDMA using the same frequency.
Despite a more aggressive reuse pattern, no impact has been noticed on rx level
and quality for both uplink and downlink ways.
However, the definition of the thresholds as ConcentAlgoExtRxlev,
ConcentAlgoIntRxlev and TxPwrMaxReduction that determines the small zone
area is very depending on traffic (density and location).

4119001036
Engineering issues
4.6 IMPACT OF DTX ON AVERAGING

The RXLEV_FULL measured on a dedicated channel is the arithmetic mean of 104
received time slots power, excepted in the case of DTX: then it is the arithmetic
mean of only 12 received time slots power.
A study was done to compare the difference (RXLEV_FULL RXLEV_SUB). It
was based on 10800 measurements from a single network, characterized by a great
proportion of microcells and a high RXLEV mean value.
The following array presents the results of this study. We considered the difference
(RXLEV_FULL RXLEV_SUB), without averaging (1 measurement), and then
with averaging on 2, 3, 4 and 8 measurements.

number of values for averaging 1 2 3 4 8

meanvalue of (rxlev_fullrxlev_sub) (dB) 0.15 0.15 0.15 0.15 0.15
standard deviation (dB)

2.12 1.48 1.19 1.03

0.72
The results show that, for an averaging on 4 measurements, the standard deviation
is only 1 dB. This is insignificant enough to consider that we can run simulations,
and analyze the measurements with one of the two levels, if we dont know which
one is used.
Moreover, the measurement processing used for the neighbor cells is close to the
process used in the case of DTX: it is the arithmetic mean of about (104/N) received
time slots power, where N is the number of neighbor cells declared,
between 1 and 32.
If 6vNv12, which is often the case, the two processes are quite comparable.
This means that the RXLEV_NCELL(i) measured on a neighbor cell, is close to the
RXLEV that would be measured if it was the current cell.

Engineering issues
4.7 BEST NEIGHBOR CELLS STABILITY

The parameter CELL_DELETE_COUNT is used to keep a neighbor cell eligible,
even if a few measurements are lost.
A study was done with a measurement file of 2 hours, without handover. Each time
one of the 6 best neighbor cells disappeared, the time before it reappeared, called
absent_time, was calculated. 420 absent_times were found; that follow this
distribution:

0.66

absent_time (s)
1.18
% cumulate
1.18

1.32 1.89 3.07

1.98 4.01 7.08
2.64 5.42 12.5
3.3 1.89 14.39
3.96 4.01 18.4
4.62 4.48 22.88
5.28 1.65 24.53
5.94 1.42 25.94
6>11 8.02 33.96
>11 66.04 100
Note: absent_time values are multiples of 0.66 seconds.
For instance, for the recommended value 5 and according to these measurements,
in 12.5 percent of the cases the neighbor cell concerned is accessible after 2.4
seconds, in 87.5 percent, it is still missing.

4119001036
Engineering issues
4.8 TCH ALLOCATION GENERAL RULES

1) When no queueing is allowed, as no request can be treated by the BSC at the
same time, there are two (2) kinds of TCH allocation requests:
priority 0 the request is acknowledged if there is at least one (1) free TCH
priority 00 the request is acknowledged if there is at least
allocPriorityThreshold + 1 free TCHs
If allocPriorityThreshold equals 0, all the requests are treated in the same
manner.
2) If queueing is in forced mode (run by the BSC), incoming handovers cannot be
queued. The highest priority must be given to incoming handovers.
Call Attempt TCH release Incoming HO
Time

No Queueing
Free TCH Call failure

No TCH
Handover successful

Queueing Call in the queue
Free TCH Call successful

No TCH Handover failure
The queueing plays a part when, there is not enough TCH resources. When traffic
increases to a blocking state, the queueing has no impact on the total ratio of TCH
allocation success: the more call attempts that are acknowledged, the more
incoming handovers are refused.
The queueing is prefered when all TCH resources are busy during a short time; it
cannot replace a resource.

Engineering issues
4.9 GENERAL RF RULES

1) In dB, the path loss slope with distance, decreases as 1/D. This means that the
received signal variation, in dB/m, is greater at the close vicinity of the base
station and decreases with the distance. It depends directly on the propagation
exponent.
2) We can assume stationnarity (during some seconds) of the median path loss
in dB, assumption is more and more valid since the MS is far from its antenna
cell, close to the handover area.
3) Shadowing is due to obstruction of the signal paths, created by obstacles. It is
known that these obstacles create log_normal variations of the received signal,
ie the received power at a distance, expressed in dBm, fluctuates as a gaussian
random variables.
4) The shadowing depth is strongly linked to the position of the mobile as
compared with the dominant building, and as a consequence, that shadowing
decorrelates when different buildings are involved. With a building mean width
d = 30m, shadowing can be considered completely decorrelated.
5) The higher the mobile speed, the smaller the impact of the shadowing on the
average signal.
6) The higher the average window size is, the smaller the impact of the shadowing
on the average signal is.
7) The variance of the signal due to the Rayleigh fading, depends on the speed of
the mobile and of the frequency in use. About 30 to 50 wavelengths must be
spanned to filter out the fading variations with a residual error less than 1 dB.
If the number of samples is equal to N = 10 the mean matches the true local mean
to within 2 dB at 90%.
8) Whatever the mobile speed, from a certain window size the increase of the size
does not modify the average Rayleigh standard deviation. From 8 to 16 samples,
even at a very low speed the gain is inferior than 0.5 dB.
9) The dispersion of two MRC combined Rayleigh is decreased by more than 1.5
dB for an MRC order 2, compared to a single channel. It means that diversity
reception can help average out the fading faster than a single channel, i.e the
local mean is tracked faster. If d > 20 l, an efficient 2 order space diversity has the
same effect as multiplying the speed by 3 to 4.
10)With Rayleigh fading, it is known that the mean in dB of samples in Watts is
greater than the mean in dB of samples in dBm. The limit is 2.5 dB, that means
that the RXLEV tends to be artificially 2.5 dB higher for the uplink than for the
downlink.
11) The RXLEV_FULL as measured on a dedicated channel is the arithmetic mean
of 104 received time slots power, in the case of DTX, only 12 times.

4119001036
Engineering issues
4.10 DIFFERENCE BETWEEN UPLINK AND DOWNLINK LEVELS

At the BTS, averages are performed from measurements made in Watts before . On
the contrary, some MS make measurements in dBm and then, perform their
averages. In Rayleigh environment, the first method of calculating can be up to 2.51
dB higher than the second method.
This comes from the fact that in Rayleigh fading environment, the information goes
through several paths (at least two) between the BTS and the MS. At the antenna,
according to the phase of the signal, the different path can add up or not. This varies
with time and it can vary from complete cancellation (hole) or, on the contrary,
perfect adding. This effect is called multipath fading.
This effect implies that received levels follow a Gaussian law and its mean has an
exponential density. The evaluation of the bias between the mean of the decibels and
the mean in decibels is then:
10 .Log(e) = 2.51 dB
This comes from the following expression that relates the mean of the natural
logarithm of an exponential random variable of mean one to the Euler constant ():

0 ln(x)exp(x)dx = = 0.57721
The 10.Log(e) factor just accounts for the base 10 log.

In this normalised example:
averaged mean of Watt samples converted in dB = 0 = BTS calculation
averaged mean of dB samples = 2.51 dB = MS calculation
So, the maximum difference between the two ways of calculating the average power
is 2.51 dB. The uplink value will be the higher.
However, here, the hypothesis of the Rayleigh fading lead to deal with two paths,
if there are many paths, the value of the correction needs to be decreased.

Engineering issues
4.11 EFFECTS OF NOOFMULTIFRAMESBETWEENPAGING

ON MOBILE BATTERIES AND RESELECTION REACTIVITY
The parameter NoOfMultiframesBetweenPaging [29] determines how often the
mobile must listen to its paging group. It has a great influence on the mobile
batteries. Therefore, this value should be raised as far as possible, so the mobile will
consume less energy by listening to the paging messages channel less often.
Changing NoOfMultiframesBetweenPaging from 2 to 6 leads to a gain of at least
18% of the batteries duration.
On the other hand, this parameter is involved in the computation of the
measurements number that a mobile averages in idle mode over reselection list.
The exact formula is: Max(5, ((5xN+6)DIV7)x NoOfMultiframesBetweenPaging
/4) seconds with N = number of BCCHs to monitor.
Two (2) different cases must be studied in order to find a tradeoff: urban
environment and rural environment.
In a rural environment, the reselection list usually contains a maximum of 5
reselection neighbours. Up to 5 reselection BCCHs, a
NoOfMultiframesBetweenPaging equal to 6 does not slow down the reselection
mechanism too much. So it is possible to advise an increase of the default value.
In a urban environment, cells size and mobiles speed generate an important
constraint in terms of reactivity. Moreover, an urban cell has much more BCCH
frequencies in its reselection list. Therefore, NoOfMultiframesBetweenPaging
should not be too high to keep a good reselection reactivity.
The following curves have been drawn using the formula Max(5, ((5xN+6)DIV7)x
NoOfMultiframesBetweenPaging /4) seconds with N = number of BCCH to
monitor, to compute the periodicity of reselection measurements average.
Please note that the parameter NoOfMultiframesBetweenPaging is also called
BS_PA_MFRMS in GSM Recommendations.

4119001036
Engineering issues
Periodicity of reselection measurements in seconds

depending on BS_PA_MFRMS
25,00
BS_PA_MFRMS = 2
BS_PA_MFRMS = 4
BS_PA_MFRMS = 6
20,00
15,00
10,00
5,00
0,00
0
1
2
3
4
5
6
7
8
9
10
12
13
14
15
16
17
18
19
20
11
Number of BCCH to monitor
From the previous curves, we can define a value of

NoOfMultiframesBetweenPaging that doesnt slow down the reselection
mechanism depending on the number of BCCH to monitor in the reselection list:

Engineering issues
Numbers of BCCH in reselection list NoOfMultiframesBetweenPaging that

doesnt slow down the reselection

mechanism

4 6

6

4

13

from 13 to 32 none
With more than 13 neighbours in the reselection list, any value for
NoOfMultiframesBetweenPaging will slow down the reselection mechanism.
Therefore, with a cell that has up to 4 BCCHs in its reselection list, it is advised to
set NoOfMultiframesBetweenPaging = 6. In that case, the lost of reselection
reactivity will correspond to 10% (5,57 seconds instead of 5), and the gain for
batteries is very important.

4119001036
Engineering issues
4.12 EFFECTS OF SMSCB USE ON NOOFBLOCKSFOR

ACCESSGRANT
If the SMSCB feature is activated, SMSCB messages are carried on the CBCH,
a sub channel of the SDCCH. The TDMA model mapping of the SDCCH becomes
SDCCHCBCH/8, and the CBCH occurs from frame number 8 to frame number
11 of the SDCCH multiframe.
If NoOfBlocksForAccessGrant = 0, then a paging message can be transmitted on
frames number 8 and 9.
Then, if the SDCCH is transmitted on the Time Slot 0 of another TDMA than the
one carrying the BCCH, a collision will occur.
1 2 3
FN 0
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
BCCH
BCCH
BCCH
BCCH
TDMA carrying the BCCH

FCCH
FCCH
SCH
SCH
FN 0
CCCH
CCCH
BCCH
BCCH
TDMA carrying the SDCCH
SD0 SD1 SD2
In that case, the mobile must choose between an incoming call and a SMSCB, by
selecting one kind of data to listen.

Engineering issues
CCCH frames: 69 1215 1619 51
PCH block
2 messages on FN 8 & 9
1 paging and 1 short message
SDCCH frames: 811
CBCH block
Figure 48 COLLISION BETWEEN PAGING AND SMSCB IF

NOOFBLOCKSFORACCESSGRANT = 0.
Setting NoOfBlocksForAccessGrant to a value superior or equal to 1 avoids this
problem: only AGCH can be transmitted on that block. This rule
(NoOfBlocksForAccessGrant > 1) is a Recommendation requirement on not
combined CBCH.

4119001036
Engineering issues
CCCH frames: 69 1215 1619 51
2 messages on FN 8 & 9
1 Imm. Ass. and 1 short message
SDCCH frames: 811
Figure 49 EXAMPLE OF AGCH AND CBCH COLLISION WITH

NOOFBLOCKSFORACCESSGRANT = 1
In that case, on the frame number 8 and 9, the MS can just receive an Immediate
Assignment. If an Immediate Assigment message is transmitted, it means that the
mobile has sent a channel request, and is not in idle mode any more. Therefore, the
MS wont listen to the CBCH channel.

Engineering issues
4.13 IMPACT OF THE AVERAGING ON THE HANDOVERS

The following study applies only to L1M V1.
Simulations have been performed with NMC Engineering tools to determine the
impact of some BSS parameters values in terms of handover reactivity. The
simulations were performed from real RF measurements and network field
configuration.
Four Simulations have been performed with the following sets of parameters:
runHandOver Hreqt
1 2 2
2 2 1
3 1 2
4 1 1
The results are spread on three items:

1) Global statistics: number of HO in each configuration.
2) Study of reactivity: impact of parameters on reactivity.
3) Reactivity vs pingpong.
4.13.1 Global statistics

The Figure 410 shows the amount of HO during the whole simulation for each
set of parameters.

4119001036
Engineering issues
90
80

runHO=2 HreqT=2

70

runHO=2 HreqT=1

60

runHO=1 HreqT=2 Impact of runHO & HreqT

Number of HO
runHO=1 HreqT=1 Amount of HO per cause

50

40

30
20

10

0
Lev_DL Capture PBGT Qual_DL Total
Figure 410 REPARTITION OF THE HO FOR EACH SET OF PARAMETERS
Interpretation
HO cause PBGT and Quality DL
For each of the four sets of parameters presented, the amount of HO on quality DL
and PBGT is the same.
HO cause Level DL
The modification of the parameters has a low impact on the total amount of HO
detected on Level DL cause.
HO cause Capture
For each of the four sets of parameters used, the total amount of handovers is the
same. The difference is not significant because microCellCaptureTimer*runHO is
kept constant.

Engineering issues
Conclusion
The simulations show that:
1) Setting Hreqt=1 instead of 2 has a very low impact on the total amount of
handovers (less than 4%)
2) Same conclusion for runHO=1 instead of 2
4.13.2

The second item of the study is to show the impact of runHO and Hreqt on the
reactivity: how much sooner do the handovers occur ?
The following array shows the impact of parameters on the reactivity of the
simulated HO, taking runHO=2 and Hreqt=2 for reference.
runHandOver 2 2 1 1
Hreqt 2 1 2 1
No change: same cause at reference 85% 100% 85%

the same moment
reference reference 15% 0% 15%
Regarding reactivity, the impact of Hreqt is decisive, 15% of handover have been
advanced by a different set of parameters. The following array shows statistics on
the advance of these HO.
runHandOver 2 1
Hreqt 1 1
Average advance (sec) 1,6 1,5
Std deviation (sec) 0,6 0,8
Interpretation
runHandOver=1
The simulations show that such a value of runHO has low impact on reactivity
compared to runHO=2. The increase of reactivity due to runHO=1 is less than or
equal to 0,5 second.

4119001036
Engineering issues
Hreqt=1
The influence of Hreqt on reactivity is much more decisive, 15% are being advanced
by setting Hreqt=1 (hoMargin unchanged).
There can be two reasons why the HO are advanced by Hreqt=1:
1) After the beginning of communication on a new TCH, L1M waits for a fixed
delay before a new HO: HreqAve*Hreqt*0,48 sec. Among the HO performed
within 8 seconds1 after a callsetup or another HO, 45% are advanced thanks to
Hreqt=1.This can be very helpful if, for example, the callsetup was initiated on a
bad cell, because of Reselection failure.
2) Reducing the length of the weighted averaging window can make the variations
of the weighted average less smooth. This effect is observed for only 2% of the
HO. For this particular case, it is still possible to tune hoMargin. The low impact
of this measure can be explained as follows.
Hreqt=2 do not always double the size of the averaging window.
Example: runHO=1 HreqAve=4 Hreqt=2
Every runHO, the L1M calculates a weighted average based on the last average
stored and the sliding average of the moment. These two averages can have up to
3 measures in common as shown below.
stored stored stored stored

average average average average
hreqave=4 hreqave=4 hreqave=4
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
sliding sliding
average average
t=5: super average t=16: super average

on 5 measures on 8 measures
1 8s = time needed for average + trans delay MS>BS + delay

HOcommand>HOcomplete + margin = Hreqt*HreqAve*0,48 (=4s) + 1,5 s
+ 0,5 s + 2 s

Engineering issues
Conclusion
The simulations show that:
1) Hreqt=1 is an efficient way to increase reactivity for 15% of the HO.
2) Among the HO performed within 8 seconds (after call setup or another HO),
45% are performed sooner with Hreqt=1 (in average 1,6 sec sooner).
3) Among the HO performed long after the beginning of the communication,
only 2% are performed sooner because Hreqt=1 makes the weighted average
less smooth.It is still possible to tune hoMargin.
4) RunHO=1 can not advance HO of more than 0,5 sec.
4.13.3 Ping pong vs Reactivity

Among the 15% of HOs that were advanced for more than 1 second by Hreqt=1,
simulations show that without changing hoMargin, no supplementary ping pong
handover was observed.

4119001036
Engineering issues
4.14 IMPACT OF CALL REESTABLISMENT ON THE NETWORK
4.14.1 Impact on capacity

The CallReestablishment feature has a big impact on the MSC resources
occupation. Without Call Reestablishment, T3109 (MSC timer) is usually set to
a small value (> rlf1) in order to free resources as soon as possible after a radio link
failure (cf Engineering Rules).
Setting a large value to T3109 for Call Reestablishment leads the MSC to freeze
the resource for the call waiting for a Channel Request from the MS. Therefore, if
the MS is unable to select a destination cell, or if the radio link failure is due to
coverage limits (border cells), the resource is frozen for nothing.
=> Call Reestablishment should not be activated on border cells, or the impact
could be reduced by decreasing the value of T3109 on these specific locations.
4.14.2 Impact on call drops

The Call Reestablishment doesnt decrease the amount of call drops from a counter
point of view, even if it improves the quality of service. The subscriber is satisfied
to get back his communication after few seconds instead of totally loosing it, but
this procedure is launched after a call drop detection, counted by the system.

Engineering issues
Moreover, the Call Reestablishment can increase in some cases the overall number
of call drops. For instance, when a temporary destination cell is selected by the MS
without providing a long term solution:
Call drop 1 Call drop 2
The signal The call is

down to a reestablished
call drop on the same cell
The operator can deduce that Call Reestablishment has a bad influence on call
drops amount. Actually, the communication lasts longer, maybe allowing the
subscriber to end his call properly.

4119001036
Engineering issues
4.15 FREQUENCY SPACING BETWEEN TWO TRXS OF THE

SAME AREA
4.15.1 No frequency hopping case
The cavity couplers technology imposes to have at least 600kHz spacing between
two frequencies assigned to such a coupler. This is not imposed in the case of hybrid
couplers technology, but our experience brought us to two rules:
(a) for a given site, the beacon frequency carriers of the cells are, at least, spaced
of 600 kHz
(b) for a given cell, the carriers are spaced, at least, of 600 kHz
Example: a cell with two TRXs (TX1 and TX2) emitting respectively at
frequencies f1 and f2. Those two mobiles communicate respectively
with Tx1 and Tx2.
TX1 TX2
D1 D2
MS1
MS2
The C/I ratio of the second TRX, will be:

C/I = C2/ (N+ Ik) C2/I1.
In the most restrictive case of no power control and where the two mobiles emit
with the same power, only the differences of propagation loss can be taken :
C/I a.Log(D1/D2),
where Di is the MSi to TXi distance.
Application :
urban at 1800 MHz with: a = 35 (given value), D1 = 0.1 km, D2 = 1.5 km
we obtain C/I 41.1 dB.

Engineering issues
But, GSM 05.05 standards limits recommend:

for 200 kHz adjacent frequency, C/Ia1 = 9 dB
for 400 kHz adjacent frequency, C/Ia2 = 41dB
for 600 kHz adjacent frequency, C/Ia1 = 49 dB
Beacon frequency case
In this case, there is no power control on downlink, but the 2 TRXs belongs to two
different cells of a same site. The demonstration above is still useful in the recovery
zone. It brings us to the (a) rule.
Case of frequencies in a same cell or site
The reasoning must be used carefully for the following reasons:

the power control limits the interferences;
intracellular handover which allows a MS to change of carrier when the received
power is too high, and the measured quality too low;
interferences generated by the surrounding/other existing sites are not taken into
account;
it is useful to add margins to the GSM standards interferences ratio in order to
take the radio channel tolerance into account.
It brings us to the (b) rule.
4.15.2 Frequency hopping case
With the hybrid technology, the frequency spacing can down to 200 kHz with the
1:1 or 1:3 frequency reuse pattern.
4.15.3 Summary for the frequency spacing
Using cavity couplers technology, frequency spacing is at least 600 kHz.

Using hybrid couplers technology, Nortel recommend 600 kHz spacing without
frequency hopping, but this spacing may be reduce to 400 kHz.
Using hybrid couplers with frequency hopping allows to use down to

200 kHz spacing in 1:1 or 1:3 frequency reuse pattern.

4119001036
Engineering issues
4.16 LINK BUDGET (LB)

The Link Budget is composed of the Uplink & Downlink gains and losses, and of
system and propagation parameters, to determine the path loss.
Uplink budget: MS_pwr + MS_ant_gain (BTS_sen BTS_ant_gain Others_UL_gains + Others_UL_losses)

where: Others_UL_gains = BTS_div_gain,
Others_UL_losses = BTS_feeder_loss + Body_loss
Downlink budget: BTS_pwr + BTS_ant_gain Others_DL_gains + Others_DL_losses (MS_sen MS_ant_gain)

where: Others_DL_losses = BTS_feeder_loss + XP_loss + Body_loss
XP_loss is for slant polarization loss when using crosspolarized antennas
Others_XX_gains and Others_XX_losses (XX stands for UL or DL) represents all

the margins that can be taken into account in the LB. Those margins can be grouped
into 3 major groups which are:
Gains and losses on the BTS side margins,
Design margins,
Environmental factors margins.
Gains and losses on the BTS side margins are composed of
Diversity: it can be seen as a quality improvement. There are three

kinds of diversity : space diversity (mostly used), angle
diversity, and polarization diversity.
The space diversity uses two antennas far apart enough (10 is a minimum value).
The two received signals suffer uncorrelated degradation, allowing to extract a
diversity gain from their simultaneous process.
This technique is used to decrease the Raleigh fading for slow moving mobiles, fast
moving mobiles being less disturbed by this fading. Therefore, this technique is
mostly used in suburban and urban areas. More generally, it is applicable in all
contexts where the gain brought by diversity can be useful to balance the link
budget.
Mast head equipment: in order to reduce the feeder loss, the PA can be deported
to the mast equipment.
For the reception part, LNAs are not deported anymore for costreduction reasons
(they are placed in the RF combiner). This is not a problem given the good
sensitivity of the BTS.

Engineering issues
Combining strategies: a combiner allows several frequencies to be handled by the

same antenna.
Those losses are taken into account in the BTS_sen, NORTEL giving its BTS
sensitivity at the antenna connector
Design margins are composed of
Overlapping margin: designed to prevent the field of the current cell from
dropping under a critical value before the MS locks on the
next cell. The value given for this margin depends mainly
on two factors : the speed of the mobile and the speed of
decreasing signal experienced by the mobile.
Penetration factors: they can be defined with average value based on

measurements.
Incar: designed to take into account a MS used in a car in
standard conditions.
Indoor: designed to take into account a MS used in a
building, using an outdoor network.
Note: In the calculation of the link budget, only consider the maximum of
(overlapping margin + incar penetration factor) and (indoor penetration
factor).
Environmental factors margins are composed of
Those factors are due to the fact that a radio signal wont propagate the same way
in a rural environment or in an urban one.
Shadow margin: Shadowing effects due to obstacles have been studied in
many articles and its probability is described as a
Lognormal law. The mean square value depends on the
environment (terrain variation and vegetation) and
frequency.
This margin allows the determination of an x% coverage over the cell surface
(typically 90%) by the integration of the Lognormal law over this surface.
For a cell without a surrounding cell, coverage is provided by one server only. Thus,
there can have many uncovered areas (behind buildings in an urban environment
for example), requiring a high shadow margin. In a multiple servers configuration,
the probability of coverage is increased, and a better coverage continuity is achieved
at cell edges. The delay introduced in the handover process reduces this gain.

4119001036
Engineering issues
Environment correction factor
this factor exists because for the same output power, the signal will propagate much
farther in a rural environment than in an urban one, creating more interference.
This parameter is defined upon field measurements and a high level of experience
is needed to evaluate this value when no measurement is available. If its badly
defined, it can have a dramatic effect on the coverage range.
Notice:
It is always possible to add more margin to increase the quality of coverage but :
it will increase the interference level,
a system limit exists on the quality of service (around 98%) due to high number of
handovers, neighboring cells to declare... The last percentage of coverage are
very expensive to get, and local solutions, as repeaters and microcells, would be
cheaper to implement.
Link budget balance or disbalance ()
= DL_budget UL_budget
The worst link budget between uplink and downlink will be taken as path loss in
order to do the cell planning.
If = 0 : the link budget is balanced, so take either DL_budget or UL_budget
as path loss,
If > 0 : the link budget is uplink limited, take the UL_budget as path loss,
If < 0 : the link budget is downlink limited, take the DL_budget as path loss.

Engineering issues
Example of a link budget calculation with Nortel values for the S8000 Outdoor BTS
using duplexor, in GSM1800:
Downlink Uplink
BTS MS
BTS_pwr 43.3 dBm MS_pwr, incl. 30 dBm
TX_loss
BTS_ant_gain 17 dBi MS_ant_gain 2 dBi
BTS_feeder_loss 2 dB Body_loss 3 dB
EIRP 58 dBm EIRP 28
MS BTS
MS_sen 102 dBm BTS_sen 110 dBm
MS_ant_gain 2 dBi BTS_ant_gain 17 dBi
Body_loss 3 dB BTS_div_gain 5 dB
BTS_feeder_loss 2 dB
DL_budget UL_budget
Link Budget 155.3 155
Importance of a good link budget
In the following table, it appears that a path loss increase of 1 dB can improve the
coverage range by 7% and reduces the number of sites by 12%, but 5 dB less in the
path loss is traduced by a coverage range cut by 28% and a number of sites increased
by 90% (figures are slightly higher for linear coverage, typically road coverage).
Worst Link Coverage Range Coverage Area Number of sites

Budget
125 dBm 72 % 52 % 190 %
129 dBm 93 % 88 % 114 %
130 dBm 100 % 100 % 100 %
131 dBm 107 % 114 % 88 %
135 dBm 132 % 190 % 52 %

4119001036
Engineering issues
4.17 MINIMUM COUPLING LOSS (MCL)

Definition:
The Minimum Coupling Loss is the minimal value recommended in the link budget
to avoid problems in the transmission.
The MCL is calculated to avoid the two major problems which may occur,
broadband noise and blocking. It is mainly used in a microcellular and
picocellular environment where MSs are likely to operate in the vicinity of the
BTS antennas.
Broadband noise
The Broadband noise takes into account all kinds of noise which disturb the BTS
and the MSs.
According to GSM Recommendation 05.05, the MS must keep its output noise level
60 dB below its power level (for a frequency spacing of 600 kHz). On the BTS part,
the received noise level must be at least 9 dB below its sensitivity.
The decoupling value is the difference between the maximum output noise level and
the maximum received noise level.
Considering a S2000L BTS and a GSM 1800 MS, values are the following in both
uplink and downlink:
Broadband Noise UPLINK DOWNLINK
Transmitter Max Power A (dBm) 30 33
Output Noise Level Margin B (dB) 60 60
Max Output Noise Level C (dBm) = A B 30 27
Receiver Sensitivity D (dBm) 104 101

Input Noise Level Margin E (dB) 9 9
Max Input Noise Level F (dBm) 113 110
Noise Decoupling Value G (dB) = C F 83 83
As we can notice in the results of the upper table, the values are the same for uplink
and downlink.

Engineering issues
Blocking
The Blocking takes into account the interferences generated by the others MSs.
The BTS can handle, for the 600 kHz adjacent frequency, a received signal strength
35 dB below the maximum received power of the current frequency. Over this
value, a phenomenon of flashing occurs.
The flashing phenomenon consists in a BTS or a MS which would emit at a very
high value, and would by this way interfere the communication of the others MSs.
The effect of this phenomenon is the deterioration of the wanted signal.
The decoupling value is the difference between the maximum output power and the
maximum received signal level.
Considering an S2000L BTS and a GSM 1800 MS, values are the following in both
uplink and downlink:
Blocking UPLINK DOWNLINK
Transmitter Max Power A (dBm) 30 33
Max Received Signal Strength B (dB) 35 44
Decoupling Value C (dB) = A B 65 77
Moreover, in the blocking case, the probability of collision of the burst between MS
and BTS must be taken into account.
In the blocking case, the downlink is more affected than the uplink. However, this
difference is not very important (except if the study is done at the frequency of the
interferer) since the decoupling value for the Broadband noise is more restricting
than the decoupling values for blocking.
How to improve the MCL
If the MCL is not respected, the communications will be deteriorated and will have
a poor quality. To improve that quality (or decrease the probability of such problems
to occur), its to say respect the MCL, solutions consist in increasing the frequency
spacing between the cell and the neighboring cells and/or ensure a better decoupling
between BTS antenna and MS.

4119001036
Engineering issues
4.18 GENERAL RULES FOR SYNTHESISED FREQUENCY

HOPPING
4.18.1 Nortel choice between Baseband and Synthesised Frequency

hopping
In case of cavity (or filter) coupling system, the only way to perform frequency
hopping is to use baseband frequency hopping. The wideband coupling system
(duplexer or hybrid2ways and duplexer) allows the use of both types of frequency
hopping; however, it is more appropriate with synthesised frequency hopping.
Here below are listed the main comparison points between baseband and
synthesised frequency hopping. It allows to decide the most appropriate frequency
hopping mechanism.
Use of downlink DTX and downlink power control
Tests have shown that if DTX downlink and Power Control downlink are activated
simultaneously when using baseband frequency hopping, it could lead to quality
degradation and eventually to call drops for some mobile brands.
With synthesised frequency hopping, this behaviour has never been encountered
whatever the mobile brand is. So with simultaneous activation of these two features,
interference are significantly reduced.
Beside, PowerControl DownLink associated with Baseband frequency hopping
may lead to interference, because the BCCH frequency included in the hopping
sequence does not perform power control.
Parameter settings
The parameter setting for the synthesised frequency hopping with a fractional
reuse pattern is easily performed due to the fact that the set of frequencies is the
same for each cell (1*1 pattern) or a group of cells (for example 1*3 pattern).
Implementation of new sites implies a new frequency planning for the BCCH layer,
but is not needed for the TCH layer.
On the contrary, two different MA per cell are needed when using baseband
frequency hopping:
one for the TS0 of all the TRXs except the one carrying the BCCH, without the
BCCH frequency
one for the TS1 to TS7 for all the TRXs, including the BCCH frequency

Engineering issues
TS 0 1 2 3 4 5 6 7
TDMA 0 F1 MA1 MA1 MA1 MA1 MA1 MA1 MA1 MAIO = 0
Capacity and quality impact in case of TRX loss

In case of baseband frequency hopping, the number of used frequencies is equal to
the number of TRX. As a result, in case of TRX loss, the capacity of the site will
be reduced, and the number of frequencies in the hopping sequence is also reduced
by one. Therefore, the overall benefit of the frequency hopping (i.e. voice quality)
is reduced.
In case of synthesised frequency hopping, the capacity of the site is also reduced,
but the overall load of the fractional pattern is reduced (the number of frequency
in the hopping sequence is still the same, but the number of inservice TRX is
reduced by one) ; the frequency hopping gain will be maintained.
MTBF impact of the coupling system

Cavity combiners, which are mechanical equipment, have smaller MTBF than
hybrid coupler combiners which are passive equipment. Therefore, the synthesised
solution with wideband coupling system shall be more reliable than the baseband
solution with cavity coupling system.
Coupling loss impact

On one hand, cavity coupling systems have an insertion loss around 4,5 dB ; on the
other hand, duplexer and hybrid 2ways coupling systems have a respective
insertion loss of 1,3 dB and 4,8 dB. Therefore, when using duplexers, a lower loss
in the downlink budget allows to have a lower downlink budget (3.2 dB) to balance
the path loss. Otherwise, the use of hybrid 2ways coupling systems does not badly
impact the link budget, in comparison with cavity coupling systems.
Frequency hopping efficiency

For limited frequency spectrum networks, the maximum configuration of BTS is
limited to few TRX in case of baseband frequency hopping. This means that every
timeslot is hopping on a few frequencies (often less than 4).
When using synthesised frequency hopping, every timeslot (except those of the
BCCH TRX) is hopping on more frequencies (not limited by the number of TRX).

4119001036
Engineering issues
Fading diversity: from Nortel experience, to get the full benefit of frequency
hopping, a minimum of six (6) different frequencies shall be used in each cell. This
benefit is increased up to 8 frequencies available within the hopping sequence
concerning fading effects.
RXLEV cdf versus SFH
100
NOHOP
2freq
4 freq
8 freq
% 10
1
2 1 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
FADING MARGIN * (dB)
Figure 411 SIMULATION FOR A MS WITH A 1 KM/H SPEED CDF: CUMULATIVE

DISTRIBUTION FUNCTION
* Fading Margin: protection against rayleigh fading
Interferer diversity: beyond 8 frequencies, the additional interferer benefits are still
increasing.
TRX addition in a given cell
In case of synthesised frequency hopping, it is not always mandatory to stop a sector

when adding a TRX in this sector (it only requires that this additional TRX was
previously declared within the OMC database).
On the contrary, in case of baseband frequency hopping, this is not possible due to
the fact that every time a TRX is added, the quantities of frequencies used in the cell
have to be increased.
Then it is easier to add a TRX in a cell using Synthesised Frequency Hopping (add
TRX la carte) as long as the FrequencyLoad of the cell is under the upper limit.

Engineering issues
4.18.2 Fractional frequency load

The fractional reuse pattern which can be implemented on a network depends on
the fractional frequency load.
NbHopTRXCell
FrequencyLoad =
Nhfcell
With:
NbHopTRXCell: number of hopping TRX in a cell
Nhfcell: number of hopping frequencies in a cell (= number of frequencies in the
MA)
It is obvious that the defined frequency load is not comparable in a 1:1 pattern and
a 1:3 pattern. In both cases there are three (3) times more TRX in a trisectorial site
than in each of its cell. However, though there are also three (3) times more TCH
frequencies in a trisectorial site than in each if its cell for a 1:3 pattern, there is the
same number of hopping frequencies in a trisectorial site than in each of if its cell
for a 1:1 pattern.
Then, in order to study the capacity (number of TRX per cell) according to the type
of pattern, with a given frequency band and a minimum of interference, a new
function must be defined:
NbHopTRXCell
FreqLoadSite =
Nhfsite
With:
NbHopTRXCell: number of hopping TRX in a cell
Nhfsite: number of hopping frequencies in a site

4119001036
Engineering issues
According to the previous equations for 1:1 and 1:3 patterns, the new function
FreqLoadSite can be related to the usual frequency load:
FrequencyLoad = FreqLoadSite
for a 1:1 pattern
FrequencyLoad = 3 * FreqLoadSite
for a 1:3 pattern

The table below shows the fractional reuse pattern that can be implemented
according to the maximum fractional frequency load. The results in this table come
from simulations and field experience. Then they have to be understood as
maximum values for a good RF quality * in the network. They are available only
in case of using power control and DTX, both uplink and downlink. Otherwise, the
maximum fractional frequency load would be smaller.
* (FER 2% or 10% worst FER 5%)
Fractional reuse pattern FrequencyLoad max FreqLoadSite max
1:1 20 % 20 %
1:3 50 % 16 %
The maximum frequency load is the basis of the following study for engineering
rules concerning HSN and MAIO. Indeed, as the frequency load is a limitation, the
aim of HSN and MAIO plans is to be as close as possible to this limitation, and to
have as less interference as possible (no adjacent frequency).
4.18.3 Maximum TRX configuration

With the previous results, it is possible to determine the maximum site configuration
according to the number of frequencies and the reuse pattern (considering a 4:12
reuse pattern for the BCCH), and taking into account the results of maximum
frequency load.
The following tables show the maximum site configuration according to the number
of frequencies and the reuse pattern (considering a 4:12 reuse pattern for the
BCCH), and taking into account the results of maximum frequency load.

Engineering issues
number of frequencies 96 84 72 60 54 48 47
1:3 fractional reuse pattern S888 S777
1:1 fractional reuse pattern S888
4 :12 reuse pattern S888 S777 S666 S555 S444
number of frequencies 42 37 36 32 30 27 24
1:3 fractional reuse pattern S666 S555 S444 S333
1:1 fractional reuse pattern S777 S666 S555 S444
4 :12 reuse pattern S333 S222
number of frequencies 22 18 17 12
1:3 fractional reuse pattern S222 S111
1:1 fractional reuse pattern S333 S222 S111
4 :12 reuse pattern S111
4.18.4 SFH parameter setting for 1:1 pattern: strategy 1

This strategy means the use of the same frequency group of TCH (Mobile
Allocation) for all cells in the network.
The values of maximum frequency load in a cell (function FreqLoadSite, 20 % for
1:1, 16 % for 1:3) indicated in chapter 4.18.2 show that for a given frequency band,
this strategy (1:1 pattern) leads to a capacity increase (more TRX per cell).
However, this maximum frequency load must be obtained without an increase of
interference. Then, the aim of the following study is to show what are the best HSN
and MAIO plans to reach the maximum frequency load without increasing the
interference.
HSN and MAIO general rules
In case of 1:1 fractional reuse pattern it is obviously forbidden to reuse the
same value of HSN and MAIO on two different cells of a same site. As they are
synchronised, it would systematically lead to frequency collision.
For a 1:1 reuse pattern, it is forbidden to use different HSN in cells of a same
site. It would lead to a frequency collision ratio of 1/n for all the TSs of the
communication.
Moreover, if some frequencies inside the group are adjacent (general case), the
use of two adjacent MAIO in a same site is also extremely inadvisable because it
would lead to interference (minimum frequency spacing of 400 kHz).

4119001036
Engineering issues
Assuming the following abbreviations, calculations can be made to show the

maximum frequency load associated to different engineering rules, according to the
MA content.
NbHopTRXSite: total number of hopping TRX (nonBCCH TRX) in the site.
NbHopTRXCell: total number of hopping TRX (nonBCCH TRX) in a cell.
Nhfsite: Number of Hopping Frequencies per site (MAIO step 2 leads to twice more
frequencies).
MAIO range: Number of Hopping Frequencies.
4.18.4.1 Strategy 1A: adjacent frequencies

Frequency band for hopping TRX: F1, F1+200, F1+400, F1+600,...
Rule:
The use of a unique HSN and different MAIO for each TRX within a site (with
a step of 2 for the MAIO because all frequencies inside the group are adjacent)
ensure the orthogonality and the nonadjacency of the frequencies.
Example: for a S444 with a MAIO step 2, there are 3 hopping TRX per cell, then
9 hopping TRX within the site.
HSN = 1
MAIO MAIO max = 16 then Nb hopping
0,6,12 frequencies in the site 17
HSN = 1 HSN = 1
MAIO 4,10,16 MAIO 2,8,14
In this example, to avoid any frequency adjacency, the minimum number of hopping
frequencies in the site must be 18 (17 + 1), as shown in the tables below.
With 17 frequencies, the adjacency appears when the frequency of the first TRX of
the first cell is not the first frequency of the band (F1).
Case a: No adjacent collision Case b: adjacent collision
Cell1 TRX1 F1 F5 = F1 + 800 kHz

MAIO = 0
Cell3 TRX3 F17 = F1 + 3200 kHz F4 = F1 + 600 kHz

MAIO = 16

Engineering issues
With one more frequency (18), the adjacency disappears
Case a: No adjacent collision Case b: No adjacent collision
Cell1 TRX1 F1 F5 = F1 + 800 kHz

MAIO = 0

MAIO = 16
Then, in this example: Nb hopping frequencies in the site 18 = 2*NbHopTRXsSite

For a trisectorial site with an homogeneous repartition of TRX in the cells, the
frequency load due to the previous constraints on HSN and MAIO is the
following (assuming an even number of frequencies in the group):
even number of frequencies in the group:
As there are 3 cells per site:
NbHopTRXSite = 3* NbHopTRXCell
And MAIO step 2 is used, then:
Nhfsite 2 * NbHopTRXSite
There are as many MAIO as TRX:
NbHopTRXSite = 3 * NbHopTRXCell

4119001036
Engineering issues
Then
Nhfsite
NbHopTRXCell p
6
NbHopTRXCell 1
FreqLoadSite = p
Nhfsite 6
thus:
FreqLoadSite p 16%
odd number of frequencies in the group:

NbHopTRXSite = 3* NbHopTRXCell
Nhfsite 2 * NbHopTRXSite + 1
There are as many MAIO as TRX:
NbHopTRXSite = NbHopTRXSite
Then:
Nhfsite 1
NbHopTRXCell p
6

Engineering issues
thus:
100
FreqLoadSite p 16% %
Nhfsite * 6
4.18.4.2 Strategy 1B: no adjacent frequency
Frequency band for hopping TRX: F1, F1+400, F1+800, F1+1200, ...
Frequency band for no hopping TRX: F1+200, F1+600, F1+1000, ... for instance
This strategy leads to permanent collisions between the BCCH and the TCH time
slots. Moreover, this strategy is not applicable at all when using PowerControl on
the TCH time slots.
Thus, in a 1:1 pattern, for a trisectorial site with an homogeneous repartition of TRX
in the cells, the engineering rules to follow are the following:
NbHopTRXcell/Nhfsite FreqLoadSit Adjacent HSN and

e max frequencies MAIO rule
in MA
Nhfsite 16 % yes Identical HSN

NbHopTRXcell MAIO step 2
6
Nhfsite 1 16 % yes Identical HSN
NbHopTRXcell MAIO step 2
6 (odd)
! Caution:
The only way to have a 20 % frequency load (maximum) with a 1:1 pattern is to use
an unique HSN with adjacent MAIO. However, this engineering rule is only
applicable if there are no adjacent frequencies in the MA (using MAIO step 2),
which is not generally the case. Otherwise it leads to an increase of interference and
it is not recommended to use MAIO step 1.
In the same way, the use of different HSN in each cell leads to an increase of
interference whatever the HSN and MAIO rules are.

4119001036
Engineering issues
4.18.5 SFH parameter setting for 1:3 pattern: Strategy 2

This strategy is studied here below in the case of a trisectorial site with an
homogeneous repartition of TRX in the cells.
4.18.5.1 Strategy 2A : 3 noncontinuous frequency bands
Cell1 : F1, F1+600, F1+1200,...

Cell2 : F1+200, F1+800, F1+1400,...
Cell3 : F1+400, F1+1000, F1+1600,...
If both HSN and MAIO are the same for each cell of a same site, there will be
systematical frequency adjacencies. Then, this configuration is not
recommended.
In order to systematically ensure a nonadjacency, the only way is to use a unique
HSN but different MAIO for consecutive cells within a site.
The MAIO can be adjacent within a cell, because two (2) consecutive
frequencies in a cell are not adjacent (noncontinuous frequency bands).
The use of different HSN and MAIO in each cell of a site is not recommended
because it would lead to frequency adjacencies, then to an increase of
interference.
Example: for a S444 with a MAIO step 1 in all cells, there are 3 hopping TRX per
cell, then 9 hopping TRX within the site.
Then, for:
MAI = 0
HSN = 1 MAIO max = 8 then Nb hopping

MAIO 0,1,2
frequencies in each cell 9
HSN = 1 HSN = 1
MAIO 6,7,8 MAIO 3,4,5
In this example, to avoid any frequency adjacency, the minimum number of hopping
frequencies in each cell must be 10, as shown in the tables below.
With 9 frequencies, the adjacency appears when the frequency of the first TRX of
the first cell is not the first frequency of the band (F1).

Engineering issues
Case a: No adjacent collision Case b: adjacent collision

Cell1 TRX1 F11 F15 = F11 + 2400 kHz
MAIO = 0
MAIO = 16
With one more frequency (16), the adjacency disappears
Case a: No adjacent collision Case b: No adjacent collision

Cell1 TRX1 F11 F15 = F11 + 2400 kHz
MAIO = 0
MAIO = 16
Then, in this example: Nb hopping frequencies in each cell 10

Then, for a trisectorial site with an homogeneous distribution of TRX in the cells,
the frequency load due to the previous constraints on HSN and MAIO is the
following:
The reuse pattern is 1:3, then:
Nhfsite
NbMAIOSite + 1 3
NbMAIOSite = 3 * NbMAIOCell
NbMAIOCell = NbHopTRXCell

4119001036
Engineering issues
Then:
Nhfsite 3
NbHopTRXCell
9
thus:
100
FreqLoadSite 11% %
Nhfsite * 3
Where:
NbHopTRXSite : the total number of nonBCCH TRX in the site.
NbHopTRXCell : the total number of nonBCCH TRX in a cell.
Nhfsite : Number of Hopping Frequencies per site
NbMAIOSite : number of MAIO in the site
NbMAIOCell : number of MAIO in the Cell
4.18.5.2 Strategy 2B: 3 continuous frequency bands
Disavantage:
This strategy minimizes the frequency diversity gain per cell.
Example with 4 frequencies per cell :
Cell1 : F1, F1+200, F1+400, F1+600
Cell2 : F1+800, F1+1000, F1+1200, F1+1400
Cell3 : F1+1600, F1+1800, F1+2000, F1+2200
Moreover, as in case A, the use of different HSN and MAIO within a site also
leads to adjacencies. Then, this configuration is not recommended.
In order to ensure a systematical nonadjacency, the only way is to use a unique
HSN but different MAIO in each cell of a same site.
The MAIO can not be adjacent within a cell, because two (2) consecutive
frequencies in a cell are adjacent in this case (continuous frequency bands).

Engineering issues
Example: for a S444 with a MAIO step 2 per cell, there are 3 hopping TRX per cell,
then 9 hopping TRX within the site.
HSN = 1
MAIO 0,2,4
MAIO max = 4 Nb hopping
frequencies in each cell 5
NbMAIOSite = 3
HSN = 1 HSN = 1
MAIO 0,2,4 MAIO 0,2,4
Note: Nortel recommend MAIO step 3 (0, 3, 6) to have more than 2 channels
separation within a cell.
However, in this example, in order to avoid frequency adjacencies, the number of

hopping frequencies in each cell must be greater than 6.
With 5 frequencies per cell:
Cell1 TRX1 F11

MAIO = 0
Cell1 TRX3 F15 = F11 + 800 kHz
MAIO = 4
Cell2 TRX1 F31 = F11 + 1000 kHz
MAIO = 0
With one more frequency (6), the adjacency disappears:
Cell1 TRX1 F11

MAIO = 0
Cell1 TRX3 F15 = F11 + 800 kHz
MAIO = 4
Cell3 TRX1 F31 = F11 + 1200 kHz
MAIO = 0
Then, in this example: Nb hopping frequencies in each cell 6

Remark:
The use of different MAIO in each cell would not lead to less interference,
because in the proposed solution, the nonadjacency is already ensured.
Then, for a trisectorial site with an homogeneous repartition of TRX in the cells,
the frequency load due to the previous constraints on HSN and MAIO is the
following :

4119001036
Engineering issues
MAIO step 2 is used:
Nhfcell 2 * NbMAIOCell
As the same MAIO plan is used in all cells:
NbMAIOSite = NbMAIOCell
The reuse pattern is 1:3:
Nhfsite = 3 * Nhfcell
Then:
Nhfsite
NbMAIOSite
2*3
As the same MAIO plan is used in all cells:
NbMAIOSite = NbMAIOCell
And:
NbMAIOCell = NbHopTRXCell
Then:
Nhfsite
NbHopTRXCell
6

Engineering issues
thus:
FreqLoadSite 16%
Where:
NbHopTRXSite : the total number of nonBCCH TRX in the site.
NbHopTRXCell : the total number of nonBCCH TRX in a cell.
Nhfsite : Number of Hopping Frequencies per site
NbMAIOSite : number of MAIO in the site
NbMAIOCell : number of MAIO in the Cell
Thus this solution leads to a non adjacency with a 16 % frequency load. As it
is the maximum frequency load determined in the limitation, it is the right
solution to choose when using continuous frequency bands.
It would be useless to have different HSN and MAIO, because the maximum
frequency load limitation is already reached. Then it would only lead to an increase
of interference without any frequency load benefit.
Then, in a 1:3 pattern, for a trisectorial site with an homogeneous distribution
of TRX in the cells, the engineering rules to follow are the following:
TRXcell/Nfcell FreqLoadSi Adjacent HSN and MAIO rule

te frequencies in
MA
Nhfsite 16 % (max) yes Identical HSN
NbTRXcell (3 continuous MAIO step 2 in a cell,
6 frequency bands) same MAIO in all cells

4119001036
Engineering issues
4.18.5.3 Sumup of the different strategy results
11% 16% 20%

FreqLoadSite
Max in 1/1 fractional reuse pattern
Strategy 1A (adj. freq)
Strategy 1B (no adj. freq)
Max in 1/3 fractional reuse pattern
Strategy 2A (no adj freq)
Strategy 2B (adj. Freq)
The recommended strategies for 1:3 reuse pattern systematically leads to a

nonadjacency of frequencies, and the maximum possible frequency load (50 %,
or 16 % with the defined frequency load in site). Furthermore, this results are
obtained in using either non continuous frequency band or continuous frequency
band (what is generally the case) in the MA.
For 1:1 pattern, the strategy to follow depends on the frequency bands constraints.
In the case of adjacent frequencies in the MA (general case), the maximum
frequency load is not reached without interference (16 % instead of 20 % at a
maximum).
However, if there is no adjacent frequency in the MA, it is possible to reach the
limitation in frequency load (20 %). But this case is rarely used by operators,
because it leads to some frequency adjacencies between TCH and BCCH.
Though both strategies generally lead to the same capacity (TRX number per
cell) for a given frequency band, the 1:1 pattern is recommended because the
frequency plan for TCH group is easier to do than for the 1:3 pattern. It is
particularly the case when adding cells, TRX or frequencies in a network,
because for a 1:1 pattern, the MA (TCH group) will be the same in all cells.
Then, the 1:1 reuse pattern with adjacent frequency group for the Mobile
Allocation is the strategy an operator must favour. It leads to a 16 % maximum
frequency load.

Engineering issues
4.19 BSC BOARDS MANAGEMENT
4.19.1 SICD boards management

To avoid overload on one SICD board due to high spot traffic, it is recommended:
1) to balance the distribution of the sites on the SICD boards in term of number of
Erlangs (from the design of the network)
2) to optimize the Location Areas ( = to avoid that 2 adjacent cells on 2 different
LAs at the frontier of the 2 LAs are on the same SICD board, cf. Following
figure).
It is therefore recommended to use the following rules for parenting:
Two neighbour cells must be on two different SICDs.
Two cells of a same site must be on two different SICDs (of course this condition
can only be applied if the two cells are mapped on two different LAPD channels).
One LAPD channel must be associated to one cell in urban zone. A site with less
than 8 TRX can easily be handled by a single LAPD channel. However
associating one LAPD channel per cell allows a finer balancing of the load on the
available SICD boards. This implies that additional DCC/DSC boards may be
required on the BTS and that additional timeslots on the Abis interface are also
necessary.
It is reminded that the paging has a very high weight in the SICD load (between 40
and 50%) because for 1 message coming from the MSC, there are N messages
broadcast on the network (with N=number of cells in the LA).

4119001036
Engineering issues
Assuming that BSC load is proportional to (number of subscribers * number of calls

relative to the BSC), we have the following example:
BSC load is proportional to (1000 * nb of calls)
BSC1 BSC2
BSC loadis proportional to ( 2*(1000/2) * nb of calls)

1000 subscribers 1000 subscribers BSC1
1000 subscribers 1000 subscribers

LAC1

LAC2

LAC1 LAC2
BSC2
The BSC load is the same in the 2 configurations but the second is better (if the aim
is the LAs frontier optimization) because we have several LAs in the same BSC.
Consequently, in order to modify the LA frontier, changing the LAC of some cells
can be sufficient and reparenting some sites on an other BSC is not necessary.
The capacity optimization on a gsm1800 network has been performed by Nortel
according to the previous rules (Lapd splitting/reparenting).
The picture below shows the inhomogeneous load on SICD boards before
optimisation and the homogeneous load after optimisation.

Engineering issues
45
Optimisation
40 Optimisation
sicd0
35 sicd1
sicd2
30
sicd3
25 sicd4
sicd5
20
sicd6
15 sicd7
sicd8
10
10 sicd9
5
5
0 time
These results demonstrate the capacity benefits induced by the engineering rules on
this specific contract.
Not using the engineering rules will lead to put some BSCs in the overload mode
in many various cases.
When the BSC triggers its SICD Overload management mechanism (see
Chapter 2), the following events are filtered:
RACH: this mechanism decreases the peak load but induces some repetitions
which are more and more stressful for the BSS,
PAGING: the same remark as above could be made.
These situations induce a lower Quality of Service which is directly perceived by
endusers.
To sum up, the purpose of SICD Overload management mechanism is to ensure
the BSS robustness only, and the purpose of the Engineering rules is to ensure the
overall network quality of service. In other words, the activation of this overload
mechanism does not prevent from applying proper engineering rules.

4119001036
Engineering issues
4.19.2 BSCB boards management

4.19.2.1 Principle
The BSCB concentrates LAPD channels coming from the BTS. The BSCB
concentrates 12 unconcentrated LAPD channels into 3 concentrated LAPD
channels (3*(4 unconcentrated into 1 concentrated Lapd)).
Although the BSCB option is available on the whole BSC 12000 product, the BSCB
is an option available for BSC 6000 types 4 and 5 only.
In a word, a BSCB board manages up to 3 concentrated SICD ports (LAPD
equipment).
4.19.2.2 Theoretical limitation
In fact, 1 BSCB board can manage up to 300 messages/s (only 150 messages/s in
V9 for BSC non retrofitted ) whereas 1 SICD8 board can manage up to 1600
messages/s therefore we have the following limitation:
max capacity of BSCB boards=11*300= 3300 messages/s
max capacity of SICD8 boards=5*1600= 8000 messages/s.
4.19.2.3 Engineering rule
That is the reason why the way BSCB boards have to be filled has changed: up to
V10 BSCB boards used to be filled one after the other, from V10 the sites have to
be affected one after the other to the BSCB board which has the smallest possible
number of TEIs (without forgetting that max number of TEI/SICD8 port=15
from V10).
Remark:
As a SICD4 board can manage up to 200 messages/s, there is no BSCB limitation
on the BSC 6000 product.
The design rules for the association of the LAPD channels to the SICD ports must
follow the rules hereafter.
Traffic concentration must be minimal on a BSC.
It is recommended to spread sites with heavy load on SICD ports not enabling
LAPD concentration.
Split LAPD Channels to concentrate on all available SICD ports.
4.19.2.4 BSC defense mechanism in case of one BSCB board failure
When overflowing during 1 second, all Lapd of this BSCB board are switched on
the redundant BSCB board (there is not any communication loss as the interruption
of service is very short), this first BSCB board is available again after less than 20
seconds and becomes the redundant board.
In case double failure, the related Lapd are in fault, there is no impact on the BSC
behaviour but there is a communication loss because of the reconfiguration.

Engineering issues
4.20 DUAL BAND NETWORKS

This chapter does not consider the new dualband cell feature (introduced in V12).
For this new feature, nevertheless, each of these new cells can be considered as
monoband at a selection / reselection point of view, the monoband type being
defined by the BCCH frequency.
Some information must be taken into account to define coverage and parameter
setting for Dual Band networks. To optimize network capacity, it is necessary to
evaluate balance load between the two bands and to avoid expensive procedures like
LAC optimization (leads to frequent location updates) or network topology (for
interBSS handovers). Furthermore, the percentage of dualband handsets and the
percentage of coverage of each band are also important to know.
Two different strategies can be used: adjacent coverage (one layer) or
superimposed coverage (at least, two layers). Parameter setting for a multilayer
network will be similar to microcell case. In both cases, intersites distance is also
a key parameter to design the network.
4.20.1 How to favour a frequency band?
4.20.1.1 Selection
To give a lower priority to band 1 cells, it is only necessary to set the parameter
cellBarQualify to true for these cells, and to false for band 2 (with cellBarred set
to not barred in both cases). A multiband MS (phase 2 MS) will choose a band 1 cell
only if no band 2 cells are found with a positive C1.
cellBarQualify cellBarred cell selection priority

false not barred normal
false barred no selection possible

true not barred low
true barred low
Cell access for phase 2 mobile stations

4119001036
Engineering issues
4.20.1.2 Reselection
Multiband mobile stations are phase 2 mobile stations. Cell reselection will involve
C2 computation (if cellReselInd= true). Here is the used formula:
C2 = C1 + cellReselectOffset temporaryOffset *H(x)

where: x=penaltyTime t
when: penaltyTime <> 640
C2 = C1 cellReselectOffset
when: penaltyTime = 640
Furthermore, as C1 is the criterion used to choose one cell, one band is favoured
when using advised parameter setting. Here is the formula used to compute C1:
C1 = RXLEV rxLevAccessMin Max (B,0)

with:
B = msTxPwrMaxCCH P
In both bands, usually Max(B,0) will be equal to 0. As the recommended value for
rxLevAccessMin is 101 to 100 dBm for GSM 900 and 99 to 98 dBm for
GSM 1800. It means that for an identical value of RXLEV, GSM 900 selection is
favoured (2dB) if recommended values are used for both types of cells.
However, cell reselect offset can be used in the computing of C2 criteria to
advantage one frequency band. Two different cellReselectOffset values can be
used according to the cell frequency band. With penaltyTime <> 640, the higher
the cellReselectOffset value, the higher the value of C2. Other parameters can be
set as follow if no special care needs to be taken for fast mobile stations:
penaltyTime <> 640, temporaryOffset = 0.
Then, cellReselectOffset can be set to 30 in the favoured frequency band between
4 and 10 in the otherone (some tests using 20 and 0 respectively provided good
results). The 2 dB difference for the C1 criteria between GSM900 and GSM1800
can be ignored in this case because the recommended parameter setting for
cellReselectOffset leads to a difference of more than 20 dB for the C2 criteria.
Another way of favouring one frequency band is to only declare reselection
neighbours belonging to the priority frequency band.

Engineering issues
4.20.1.3 Directed Retry
For distant mode, the eligible cell list is obtained from a level criteria directed retry
in the adjacentCellHO object. A way to have an underprivileged frequency band is
to choose two sets of value for directed retry, one for each band and to take the
higher value for neighbour cells belonging to the low priority frequency band.
However, it will impact the directed retry for monoband MS on this band (less
directed retry).
4.20.1.4 Handovers
If an offset was used to select (rather reselect) the cell, one must be aware that the
cell may not be the best one. To avoid going back to another band because it is the
best cell, this offset must be taken into account as well during handovers (ho
margin). Another way is also to inhibit power budget handovers from the priority
band towards the nonpriority one.
To penalize handovers towards band 1 cells, it is only necessary to modify the
different hoMargin for band 1 neighbouring cells, herein called
hoMargin_nei_cell_band1.
hoMargin_nei_cell_band1 > hoMargin_nei_cell_band2.
During interband handovers, care must be taken when GSM900 sites and GSM1800
sites are on different BSCs. This will awfully increase signaling because of
interBSS procedures. To avoid this case, interband HO on alarms must also be
limited (by modifying thresholds). Interband handovers can also be reduced by
limiting the number of outband neighbours for each cell. This will depend on
operator priorities.
4.20.1.5 Microcell algorithm
Microcell capture A algorithm can also be used to make mobile stations stay in
the same frequency band.
4.20.1.6 Sumup of the recommended parameter setting to favour one frequency band
High Priority band Low priority band Note
Multiband 2 3
reporting
cellBarQualify false true
cellReselectOff- cellReselectOffset = 30 cellReselectOffset =
set between 4 and 10

4119001036
Engineering issues
hoMar-
hoMar- hoMar- hoMar- gin_nei_cell_b
ginRxQual, gin_nei_cell_band1 for gin_nei_cell_band2 for and1
hoMarginRx- adjacentCellHO object adjacentCellHO object
Lev... hoMar-
gin_nei_cell_b
and2
directedRetry- rxLevMinCell + 3 dB rxLevMinCell + 3 dB
Algo
Note: See chapter 3 for recommended values
4.20.2 How not to favour a frequency band?
4.20.2.1 Selection
To give the same priority to both band cells, it is only necessary to set the parameters
cellBarQualify to false and cellBarred to not barred for all cells.
However, as GSM900 selection is favoured of 2 dB with the recommended values
for rxLevAccessMin for both bands, a balance can be found in setting
rxLevAccessMin to 100 to 99 dBm for all cells.
4.20.2.2 Reselection
No change may be done to the recommended parameter setting, then all cells may
have the same values for the parameters cellReselectOffset, temporaryOffset
and penaltyTime.
As in cell selection, the parameter rxLevAccessMin may be set to 100 to 99
dBm for all cells.
4.20.2.3 Other features

For all other features (Directed Retry or handover), the same parameter setting may
be kept for both band cells.
The remark about interband handovers (see above) is particularly crucial to take into
account in the case of no band is favoured. Indeed, a interband handover must be
reduced to the minimum (by modifying thresholds) and a particular neighbour plan
may be elaborated in order to avoid frequent interBSC handovers when GSM900
sites and GSM1800 sites are not on the same BSC.
4.20.2.4 Sumup of the recommended parameter setting for two equal frequency bands
GSM900 band GSM1800 band Note
Multiband the six strongest the six strongest

reporting cells cells

Engineering issues
cellBarQualify false false

cellReselectOffset between 4 and 10 between 4 and 10
rxLevAccessMin 100 to 99 dBm 100 to 99 dBm
hoMarginRxQual, Value900 for adja- Value1800 for Value900
hoMarginRxLev... centCellHO object adjacentCellHO =
object Value1800
directedRetry900
directedRetry directedRetry900 directedRetry1800 =
directedRetry1800

4119001036
Engineering issues
4.21 MICROCELL BENEFITS
4.21.1 Microcell benefits according to cell radius

The (theoretical) following result is obtained assuming that 1 O2 corresponds to 8.2
Erlangs and that 1 S333 represent 42 Erlangs (using a traffic model with 28%
dedicated signalling and with a blocking rate of 2%).
With a macro layer made up of S333, the maximum theoretical capacity gain is
almost 100% with 5 O2 below each S333 (considering that the initial network was
also made up of S333). However this benefit does not only depend on the cell radius
but also on other criterias:
existing network characteristics and parameters setting,
macro and micro layers characteristics,
users mobility,
microcells position (the micro cell coverage area must cover a sufficient number
of users)
4.21.2 Microcell benefits in terms of Quality Of Service (QOS) :

Coverage:
The addition of a microcell layer increases the coverage and especially the indoor
coverage (with a suitable sites density it is possible to obtain average deep
Indoor coverage rates around 90%). The gain depends obviously on the
engineering and on the building type.
Subjective Voice Quality:
The radio waves confinement of micro layer often provides a higher C/I level and
therefore a better voice quality (this quality enhancement is not canceled by the
number of handover increasing).

Engineering issues
4.22 SETUP PRINCIPLES OF A NEIGHBORING LIST AND A

BCC PLAN
4.22.1 Introduction
An optimum neighboring plan consists in having the best compromise between the
quality of service and the network load. Indeed, the higher the number of
neighboring cells in the neighboring list, the more loaded the traffic due to HO
procedures.
Moreover, an efficient neighboring plan ensures a better network reliability by
avoiding an excessive call drop rate resulting from HO failures.
Neighboring plan optimization is a trade off between:
many neighbors which can lead to excessive HO, and thus signaling overload.
Moreover, as measurements are performed on all neighbors in the list,
measurements on the more used neighbors are less often performed than with a
shorter list. Then the system is less reactive to perform hand over.
few neighbors which would lead to call drop and poor quality of service due to
HO failures.
Hereafter are the engineering rules to follow when initializing a neighboring plan,
depending on the type of pattern used for the frequency plan.
4.22.2 4/12 reuses pattern
4.22.2.1 Initialization of the neighbor list
The first step when initializing a neighbor list consists in choosing a cell as a
neighbor of the serving cell if they share a common border in the best server map.
The neighboring list will then define a geographical ring (first ring) around the
serving cell.

4119001036
Engineering issues
Example
1
2
8
5 Serving
cell
3
7 6
First ring neighbor list: 1 ; 2 ; 3 ; 4 ; 5

Each cell belonging to this first ring of the given cell will be automatically included
in the neighboring list without selection on geometrical or mean field level criteria.
However, using only the list of first ring neighbor cells can lead to dropped calls or
pingpong hand over, because the coverage of some first ring neighbor cells can be
thick between the serving cell and a second ring neighbor cell (see in the example
neighbor 4).
4.22.2.2 Establishing a list of cells on geometrical criteria
Some neighbors must be added to the previous list, in order to avoid the mentioned
troubles.
One solution could be to define another geographical ring (second ring) but this
solution would often lead to a very high number of neighbors in the neighbor list,
and consequently to an excessive number of hand over. Thus, the risk is to have
signaling overload.
In the previous example, the neighbor list with the second ring criteria would be:
1 ; 2 ; 3 ; 4 ; 5 ; 6 ; 7 ; 8.
Then, a good solution consists in defining a distance criteria, that must be fulfilled
by a cell for being considered as a neighbor.

Engineering issues
This distance is the one separating the server cell site location, and the other cells
contours. This method corresponds to the definition of a circle with a specified
diameter. Any cell coverage being totally included within this circle, or having a
part of the surface within the circle is added in the neighbor list.
This distance can be the same for all the cells of the network. But this method is more
efficient if the distance criteria is a multiple of the cell radius. The cell radius should
correspond to the maximum length separating the cell site location and any point
belonging to its coverage.
Example:
1
2
8
5 Serving
cell
3
7 6
Distance criteria neighbor list: 1 ; 2 ; 3 ; 4 ; 5 ; 6
Note: Height and roads are important aspects to keep in mind for neighboring
plan:
Indeed, two sites neighbor from a geometrical point of view but separated by a
high hill should not be declared as neighbor if no signal is expected to cross the
mountain.
Also as the channel effect is very important, especially in town, neighborhood
should take into account the main roads. Two cells not neighbor with statistical
prediction models, have high probability of being really neighbor if they are
located just on a large avenue not too far apart.

4119001036
Engineering issues
4.22.2.3 Resurgence problems
If the resurgence area is large and not too far from the serving cell, it can be
considered as a real cell. Consequently, this situation is equivalent to a normal cells
neighborhood assignment and all the cells surrounding the resurgence must be
added to the serving cell neighborhood. This situation is well handled by the
automatic tools.
However, there are several other situations where the resurgence should not be taken
into account:
The resurgence is reduced to a small area.
Then the resurgence coverage is not enough significant to be considered as a suitable
cell for the hand over or selection issue. Any HO operation performs on the cells
resurgence will lead to a pingpong hand over from the cell resurgence to the
surrounding cells.
The resurgence is located far from the serving cell (with several cells between the
resurgence and the serving cell).
This situation leads to a poor stability of the received signal. As the serving cell is
far away from the MS, the MS could easily lose the signal and thus almost
immediatly perform a hand over to another cell (signaling load).
That is why, all the cells assigned as neighbor of a serving cell because of this kind
of resurgence should then be removed from the neighbor list.
Then, such cells with resurgence which were first assigned as neighbor of a serving
cell (after distance criteria application) must be removed from the neighbor list.

Engineering issues
4.22.2.4 Conclusion
Initialization with the first ring
Current cell: Candidate cell:

Antenna azimuth, Eligibility criteria Antenna azimuth,
emission power, (distance criteria) geographical position
frequency, gain regarding to current cell
List of candidate cells
Taking into account

resurgency problems
List of neighbour cells
4.22.3 1:3 and 1:1 Fractional reuse pattern specific case.

When enabling frequency hopping on a network, a 1:3 or 1:1 pattern is generally
used for the TCH frequency plan (see chapters 5.9). Then, if the quality thresholds
for hand over are not changed, the number of hand over on quality criteria will
increase because the rxQual distribution is narrower (less bad rxQual samples but
also less good rxQual samples).
Thus using a distance criteria to create the neighbor list can lead to hand over on
TCH from a serving cell using the same TCH frequency group than the destination
(neighbor) cell. Now if the hand over is on quality criteria, the risk is high to arrive
on this cell with also a bad quality (and perhaps worst than before). Then a new hand
over will be triggered.
4.22.3.1 First ring neighbor list (1:3 reuse pattern)
In the case of a 1:3 reuse pattern, a way to avoid this kind of hand over is to declare
only the first crown of neighbors. In the following diagram, the cells in grey are not
declared neighbors to the serving cell S.

4119001036
Engineering issues
Example:
N1, T2
N2, T3 N6, T3
S, T1 N7, T1
N3, T2 N5, T2
N4, T3
N8, T1
In case of hot traffic spot, as this solution leads to a few number of cells in the
neighbor list, there is a risk of hand over failure due to channel unavailability. In
order to avoid this, two (2) channels in every cell must be reserved for hand over
(AllocPriorityThreshold = 2).
The only exceptions for this rule are the following :

Coverage hole,
Limited coverage due to shadowing effect.
However, this solution means a few number of neighbors in the list and then can lead
to call drop and hand over failures (see scheme with first ring neighbor list before).
4.22.3.2 Distance criteria neighbor list (1:3 and 1:1 patterns)
A good solution would be to put at a disadvantage hand over on quality criteria

toward neighbor cells using the same TCH group than the serving cell. It would be
done in setting the parameter hoMarginRxQual to 24 for these neighbors.
However, this solution could be a good solution for optimization but not for basic
neighbor plan, because it needs a study for each cell.

Engineering issues
A compromise is to increase the hand over quality thresholds (lRxQualDLH and

lRxQualULH) as it is recommended when enabling frequency hopping. Thus, the
global number of hand over will not increase and the risk of hand over on quality
criteria toward a cell using the same TCH group will be low.
Then the recommended solution in the case of fractional reuse pattern (1:3 or 1:1)
is the same than for a 4:12 pattern.
4.22.4 HandOver list versus Reselection list.
For all reuse patterns, the same cells should be declared in both hand over and
reselection list. Moreover, the serving cell should be declared in the reselection list.
In case of hole of coverage, this will allow the MS to reselect the best cell and not
a distant cell.
However, for 1:3 and 1:1 reuse pattern, if only the first ring is used for the neighbor
list, a higher number of reselection cells (first ring + second ring or distance criteria)
than hand over cells (only the first ring) must be declared.
4.22.5 Setup principles of a BSIC plan
Three (3) main procedures can be used to set easily the BCC parameter of each cell.
For all these methods, one should take into account a distance criteria in order to
minimize the probability of BSIC/BCCH conflict between nearby cells.
The first method is based on geographical BCC values gathering. It is done by
selecting the BCC value of a cell among the values already taken by its neighbor
cells. The chosen BCC is theone not leading to a BSIC / BCCH conflict.
The advantage of this solution is an homogeneous distribution of the BCC among
the network.
However, it is long and difficult to apply by hand and is generally used when
allocating BCC with automatic tools.
The second method consists in using as less BCC values as possible. Then, for
each cell, first BCC equal to 0 is tried. The tried value is increased by one (1) if it
leads to a BSIC / BCCH conflict. This operation is repeated until no conflict is
detected.
This method has the advantage to minimize the number of used BCC. Then when
adding new cells, generally a BCC for this cell can be found without creating BSIC
/ BCCH conflict and without modifying the BCC of existing cells.
However, it is long and difficult to apply by hand and is generally used when
allocating BCC with automatic tools.

4119001036
Engineering issues
The third method consists in allocating a specific BCC to each occurrence of the
BCCH reuse pattern. The occurrences having the same BCC must be as far as
possible from each other.
It is the most currently used method when BSIC plans are done by hand, because
it is easy and quick to apply.
However it means that a neighbor cell can not have the same BCCH than its
serving cell, what is restrictive.

Engineering issues
4.23 STREET CORNER ENIRONMENT
4.23.1 Description
Especially in microcellular network, where the antennas are under the roof, the
level received by the mobile can dramatically fluctuate. Ping pong handovers and
call drop were experienced in this type of environment, and led to bad quality of
service as well as a significant increase in signalling traffic. One of the toughest
issues to solve in a micro cellular network is street corner environment.
Two cases must be distinguished:

The first one deals with mobile moving straight the cross road. In the case, the
handover toward the cell A must be avoided.
Mobiles turning at the cross road is the second case. The handover from cell B to
A must be performed quickly before the field of the current cell dropped under a
critical value, leading a call drop.

4119001036
Engineering issues
4.23.2 Case A: Mobile moving straight

In the case of a mobile moving straight the cross road, a handover for PBGT may
be processed from cell B to cell A. Once the cross is passed, the mobile is handed
again over the cell B. This ping pong handover shall be avoided as useless handover
leads to voice quality degradation.
RxLev
rxLevDLPB
B
A
Time
The parameter rxLevDLPB allows to cope with that case. Actually, if the signal
received by the mobile from the serving cell exceeds this threshold, then the
handovers with powerbudget criteria are prevented.

Engineering issues
4.23.3 Case B: Mobile turning at the cross road

In a microcell environment, the size of cells is very small (40 to 400 meters). The
overlapping margin between cells is not very important. Moreover, a fast moving
mobile may cover a few hundred meters during the handover process (in the worst
configuration, the duration time of a handover can be more than 1.5 s). The
overlapping margin can be insufficient to prevent the field of the current cell from
dropping under a critical value before mobile locks on the next cell (with standard
parameters values). In such environment, reactivity is essential, handovers have to
be performed as quickly as possible.
RxLev cell A
cell B
Time

4119001036
Engineering issues
The problem is solved by the combination of the following features:

TF809 (Early Handover decision)
TF823 (protection against runHandOver = 1): In a microcell environment
reactivity is essential. This feature allows to set runHandOver to 1.
TF818 (max rxLev for PBGT): The problem of handover toward cell A when
mobile goes straight forward is solved by TF818, therefore a negative hoMargin
(for PBGT) can be set in order to help handover when mobile turns.
1/700 Hz
1/500 Hz

Engineering issues
4.24 BTS SENSITIVITY
4.24.1 Definition of Sensitivity

In this chapter, sensitivity figures are clarified, knowing that such notions as static,
dynamic, guaranteed and typical may often lead to confusion.
The sensitivity is completely defined in the GSM recommendation 05.05. 6.2., as
the input level for which all performances in terms of frame erasure, bit error or
residual error rates are met. A reference table specifies rates varying according to
the type of GSM channel (traffic, signaling) and the type of propagation channel
(static, urban, rural, hilly terrain).
Sensitivity is measured at antenna connector, and by definition this figure takes into
account all RF elements losses included in BTS cabinet, as shown on the following
figure:
Antenna
Common
cable Losses
Rx Sensitivity
Antenna Connector
Combiner losses
TxPa Output
Power
Rx Diversity Gain
Base Station
Duplexor
Combiner
Power Amplifier
Note: In case of BTS S2000H, antenna connector is located on the HP RF remote

unit, it is not on the BTS itself but on the remote RF module unit.

4119001036
Engineering issues
4.24.2 Static and Dynamic Sensitivity

Static sensitivity could be viewed as the level at which sensitivity performance is
met in the static channel mode. Yet, the static mode is only one of the propagation
models among others specified in the GSM Recs. reference table. The static mode
is the most favorable case (excepted a few cases of fully not correlated antennas and
2branchs diversity). In terms of radio, it can be understood that for a given signal
input, less communication errors are expected within a configuration where there
are no multipath effects at all.
4.24.3 Typical / Guaranteed Sensitivity

Typical sensitivity is 1dB better than the worstcase used, mainly due to the
variation in performance of the RF front end and not the variation in the DRX
module. The variation in performance of DRXs on a per cell basis is therefore very
tightly controlled.
Typical and guaranteed figures for the BTS S8000
These figures are given for specific cases where one does not wish to take the
typical figures recommended for linkbudgets by NORTEL. The cable loss
typical values are given from measurements on a few samples.
Modules Duplexer only whole H2D whole H4D
Bands 900 1800/1900 900 1800/1900 900 1800/1900
Typical losses 0.9 dB 1.1 dB 4.3 dB 4.5 dB 7.4 dB 7.6 dB
Guaranteed 1 dB 1.2 dB 5 dB 5 dB 8.5 dB 8.5 dB

losses
Cables PA to Combiner Combiner to Ant. conn
Bands 900 1800/1900 900 1800/1900
Indoor BTS Guaranteed losses 0.35 dB 0.5 dB 0.25 dB 0.35 dB
Outdoor Guaranteed 0.25 dB 0.4 dB 0.2 dB 0.3 dB

BTS losses

Engineering issues
4.24.4 Space diversity gains
4.24.4.1 Fading correlation

One major parameter to assess space diversity gain is the fading correlation, which
depends on many factors, such as radio environment (angular distribution of
reflectors), antenna configuration (spacing between antennas) and position of the
mobile respective to the BTS.
The sensitivity for fully correlated antennas and not correlated antennas
(correlation 0.2) can be viewed respectively as the worst case and quasibest case
situations. In reality, the correlation figure lies somewhere between both figures,
depending on the factors mentioned previously.
To assess correlation values applicable to engineering is not an easy task. Yet, it can
be observed that by taking 10 wavelengths of antenna separation (recommended
distance is 20 ), the correlation factor is as low as 0.2 for an angular spread of only
1 degree .These results give us enough confidence to interpolate the sensitivity at
values near the not correlated case, in such environments as builtup areas (urban,
suburban), as well as hilly terrain, which offer a multiplicity of reflectors. However,
this appears less obvious for open area environments, typically flat rural, for which
we will assume a more conservative correlation factor (see following paragraph).
4.24.4.2 Branch sensitivity

Diversity gains are calculated by doing the difference between with and without
2 antennas figures. Then diversity gains vary a lot with correlation and propagation
channels. Yet, it can be observed that after rounding figures, the overall sensitivity
+ diversity figure stays relatively constant, independently of the configuration. The
trend is a cumulated figure of 113 dBm for the S8000 without enhanced coverage
option, and 115 dBm for the S8000 with enhanced coverage option.
This observation partly justifies the uniformity of the diversity gain of 5 dB for the
S8000 (enhanced coverage option or not), which when added to the sensitivity
(108 or 110 dBm) gives the correct total. It must be stressed that this artifice is
only meant to provide separate figures for sensitivity and diversity gain, which are
still distinguished when discussing link budgets
4.24.5 Crosspolarization antenna use

The use of crosspolarization antenna has followed a growing trend, due to the
flexibility offered in terms of site installation (two antenna packaged into one,
offering diversity gain and coupling 2 TRXs on a single antenna without hybrid
coupling).
Cross polar antenna is characterized by:
2RF ports for one antenna
slant polarized transmission.

4119001036
Engineering issues
Hence use of cross polar antennas implies:

simplification of the coupling stage.
radio link performances modification.
diversity of polarization.
Simplification of coupling stages
It should be understood that with the same number of antennas as for spatial
diversity (i.e. one no space diversity or two space diversity) crosspolar antennas
provide 2 times more RF ports. This means that on one feeder, the number of
supported DRX is divided by two, and the size of the coupling stage too.
Radio link performances
Radio link performances are affected by the transmission over slanted polarization.
Measurement reports indicate performances of crosspolar antennas compared to
vertical antenna are lower:
in urban area of 1dB in 900 MHz and 2dB in 1800 MHz.
in flat rural area of 3dB in 900 MHz and 1800 MHz.
What should be highlighted is that performances of crosspolar antennas are strongly
dependent on environment, and mainly on reflectors and scatterers: the more they
are, the better the performances.
For link budget purposes, crosspolar antennas recommended typical losses are:
in all environment, 1.5dB in 900 MHz and 1800 MHz.
in flat open area, 3dB in 900 MHz and 1800 MHz.
Polarization diversity
Polarization diversity is obtained by processing the two signals coming from the
two branches of one crosspolar antenna. Polarization diversity is estimated after
measurements of signal decorrelation between the two diversity receiving branches
of one crosspolar.

Engineering issues
Link budget figures
As a summary, proposed link budget figures for crosspolar antenna use are
summarized in the table below:
all environments flat rural, flat open

900 MHz & 1800 MHz 900 MHz & 1800 MHz
radio link performances 1.5dB 3dB
(DL & UL)
diversity gain +4dB (5dB)* +4dB (5dB)*
(*) Crosspolar antennas offer as diversity solution:

polarization diversity (4dB gain) when 1 crosspolar antenna is used.
spatial diversity(5dB gain) with 2 crosspolar antennas.
Circular polarization and crosspolar antennas
This system, Nortel patented, combines two types of advantages:

the crosspolar antenna benefit of the 2 antennas connectors within one antenna
chassis.
the robustness of circular polarization against depolarization effect and mobile
positioning.

4119001036
Engineering issues
This system relies on a single 3dB90dephaserhybrid coupler located at the

bottom of the crosspolar antenna feeding the two ports of the crosspolar antenna
with exactly the same feeder length. The system scheme is shown below:
Crosspolar antenna
S+PI/2
S S+PI/2 S
3dB hybrid
dephaser
BTS with BTS with

polarisation space
diversity diversity
In term of radio figures, the benefits of the crosspolar antenna use combined with
the 3dBcoupler are:
the radio transmission is no more affected by the slanted polarization due to the
transmission of the whole signal over a circular polarized wave. Whatever the
position, the mobile receives all the power.
the combining stages are divided by 2.
the diversity gain is:
4dB with 1 crosspolar antenna the polarization diversity gain.
5dB with 2 crosspolar antenna the space diversity gain.
Recommended figures for this system are:
all environments 900 MHz & 1800 MHz

diversity gain polarization
diversity +4dB
space diversity +5dB
radio link performances 0dB
(UL and DL)

Engineering issues
4.25 SDCCH DIMENSIONING AND TDMA MODELS

The aim of this chapter is to define engineering rules associated to SDCCH
dimensioning, TDMA model and priority, and the PCM priority.
4.25.1 SDCCH Dimensioning

An SDCCH assignment is provided when one of the following Layer 3 message is
received:
SM Service Request
Paging Response
IMSI Detach
Location Update
So the number of these messages have to be taken into account in the dimensioning
of the SDCCH channels. Some rules are defined here below.
4.25.1.1 Parasite SDCCH allocation

The level of noise can provide a parasite SDCCH allocation, the BTS seems to
receive an RACH and allocates an SDCCH channel. In this case the SDCCH is
assigned for a short duration (free after T3101 (3 sec by default)). The parasite
SDCCH assignment depends of the BCCH TDMA model. Note that from V8B7 the
number of parasite SDCCH becomes negligible with new DRX.
So when the number of parasite SDCCH are not negligible it has to be taken into
account to determine the real traffic capacity of the signaling channels.
4.25.1.2 BTS geographical position in the LAC

In very loaded networks, a too high number of SDCCH (in comparison with the
number of TCH) would lead to a congestion of the signaling resources. Indeed, if
the offered SDCCH capacity is higher than the TCH capacity, in terms of Erlang,
a TCH congestion phase would lead to an SDCCH congestion phase. This situation
happens because when no TCH is allotted, the MS user often tries to connect itself
again, then uses a new SDCCH resource, leading also to an SDCCH congestion.
Then, in very loaded networks, for a given Erlang traffic capacity, the blocking rate
for SDCCH and TCH may follow:
SDCCH Blocking Rate > TCH Blocking Rate
However, the location update frequency must also be considered for the evaluation
of the blocking rate ratio for SDCCH. For BTS located at the border of a Location
Area, a lot of location updates are performed. Then, the signaling traffic is very
high. In this case (as for area with a high SMS traffic), the number of SDCCH
channels must be quite high. Therefore, the blocking rate ratio to consider for
SDCCH must be lower than theone for TCH.

4119001036
Engineering issues
Thus, a table can be established for the blocking rates to consider, depending on the
load of the network and the kind of signaling.
TCH
SDCCH Blocking rate
Blocking rate
Middle LAC LAC border
Normal load 2% 2 to 5 % 0.5 to 1 %
Very loaded 5% 5 to 10 % 1 to 3 %
4.25.1.3 Double SDCCH allocation
The double SDCCH allocation occurs when a second RACH is sent by the mobile
before the Immediate Assignment message of the first RACH is received.
The double allocation issue depends of the mobile phase (phase 1 or 2) and of the
TxInteger value.
4.25.1.4 Activation of SMSCB
The SMSCB is multiplexed with the SDCCH. So the activation of the SMSCB
reduces the number of SDCCH subchannels and so the signaling capacity of the
BTS. For example:
SDCCH/4 + SMSCB => 3 SDCCH available (combined case)
SDCCH/8 + SMSCB => 7 SDCCH available (not combined case)
TDMA Model Capacity (erlang)

SDCCH/4 0.235
SDCCH/3 0.087
SDCCH/7 1.422
SDCCH/8 1.054
So the activation of the SMSCB has a great impact on the signaling capacity of cell.
Note that in case of SMSCB, the SDCCH TS number has to be lower than 4 (< 4)
4.25.1.5 Subscribers mobilities

In a low mobility area (Indoor, pedestrian area) most of the RACH will father a
communication (> Assignement Request). In this case it is better to reduce the
number of SDCCH in order to favor the TCH signalling only which allocates a
TCH quicker (especially recommended when the Very Early Assignment feature
will be available).

Engineering issues
In a high mobility area (rural, highway) a none negligible number of the RACH
are requested for Location Updates. The total number of RACH is then higher
than in a low mobility area, it is then better to increase the number of SDCCH
channels.
In a very high mobility area (high speed train) the number of Location Area are
generally reduced in order to avoid a BSS signaling overload due to the LA
update. Moreover the TCH allocation has to be as fast as possible in order to
avoid dropped calls setup. So for the cells which are dedicated to the coverage
of very high mobility area only, (e.g. cells which cover only the high speed train
railways and not surrounding roads or villages) it is better to reduce the SDCCH
channels number. If the cell is at the boundary of a location area the SDCCH
channels have to be set according to the Location Area update load.
4.25.1.6 Number of networks

The SIM card can contain the Id of only 4 forbidden networks, i.e if there are more
than four (4) networks in a country a mobile can attempted a Location Update on
other networks (> Location Reject). So wherever there are more than four (4)
competitors in the same frequency band it is recommended to increase the number
of SDCCH channels.
4.25.1.7 Subscribers Call profile

In case of TCH blocking the subscriber behavior from one country to the other can
be very different. In some countries the number of subscribers attempts are
multiplied by 3 when there is a TCH blocking. So in case of TCH blocking it is
recommended to decrease the number of SDCCH channels. Note that this can be
done dynamically with the set channel state command, however in case of BSC
reboot the config is not saved.
4.25.2 SDCCH distribution

The following rules for the SDCCH distribution on TDMA Model must be applied:
No SDCCH on the first time slot (TS0) except for monoTRX cell where BCCH
combined (with SDCCH/4) can be used (some mobile brands do not support to
hop on TS0 in case of SDCCH/8). Then, the SDCCH must use TS1 (it is what is
recommended for reasons of uniformity and to enable the simultaneous
allocation of 2 SDCCHs for 2 different mobiles).
No SDCCH on the TDMA carrying BCCH channel (TDMA 0 in a general case)
when there is more than 2 TRXs ; the explanation is obvious for monoTRX ; for
a cell with 2 TDMAs, if SDCCH is on the second TDMA, in case of TRX
problem, only the first TDMA is kept so inducing no SDCCH in the cell. This
rule (No SDCCH on the TDMA carrying BCCH) is mandatory for Cell Tiering
and Data. A specific problem has also to be noticed : for sdcch8cbch, some
mobile brands do not accept a hopping CBCH (see Rec.9.94 5.3.1).

4119001036
Engineering issues
There shall be at most one SDCCH per DCU2 and per FPRX.
There shall be at most 2 SDCCH per TDMA for DCU4/DRX and in such cases,
they should be one on an odd TS and one on an even TS.
In case of SMSCB, the SDCCH TS number has to be lower than 4 (from 0 to 3).
It is recommended to give the same TS number to all SDCCH channels in order to
gather the Immediate Assignment messages by couple (possible if the mobile
allocations are identical) in order to reduce the global signaling messages
numbers.
SYSINFO message can not describe more than one sdcch8CBCH channel per
cell. It must be carried by the first TDMA carrying an SDCCH channel.
4.25.3 TDMA Model
According to the number of TRXs per cell, the following TDMA Mapping Model
and TDMA priorities are recommended.
The following abbreviations are used to define TDMA Mapping Models:
Abbreviation TS0 TS1 TS2 TS3 to TS7

Standard Cell
C mainBCCHcombined TCH TCH TCH
c bcchSdcch4CBCH TCH TCH TCH
B mainBCCH SDCCH TCH TCH
b1 mainBCCH sdcch8CBCH TCH TCH
b2 mainBCCH TCH TCH TCH
S TCH SDCCH TCH TCH
S1 TCH SDCCH SDCCH TCH
s TCH sdcch8CBCH TCH TCH
s1 TCH sdcch8CBCH SDCCH TCH
T TCH TCH TCH TCH
Extended Cell
C_ext mainBCCHcombined TCH
c_ext bcchSdcch4CBCH TCH
B_ext mainBCCH SDCCH
b1_ext mainBCCH sdcch8CBCH
b2_ext mainBCCH TCH
S_ext TCH SDCCH
s_ext TCH sdcch8CBCH
T_ext TCH TCH

Engineering issues
TRX / Cell SDCCH8/Cell TCH/Cell TDMA/Cell Priorities

Standard Cell
1 0 7 C 0
1 1 6 B 0
2 1 14 BT 0,1
3 2 21 b2SS 0,2,1
4 2 29 b2SST 0,2,1,3
5 3 36 b2SSST 0,2,4,1,3
6 3 44 b2SSSTT 0,2,4,1,3,5
7 4 51 b2SSSSTT 0,2,4,6,1,3,5
8 4 59 b2SSSSTTT 0,2,4,6,1,3,5,7
Extended Cell
(TDMA models with _ext)
1 0 3 C 0
2 1 6 CT 0,1
3 1 10 b2ST 0,1,2
4 1 14 b2STT 0,1,2,3
5 1 18 b2STTT 0,1,2,3,4
6 2 21 b2SSTTT 0,4,1,2,3,5
7 2 25 b2SSTTTT 0,4,1,2,3,5,6
8 2 29 b2SSTTTTT 0,4,1,2,3,5,6,7
For Cell Broadcast, the following permutations are allowed:
C <=> c
B <=> b1
S <=> s (for the first S only)
The TDMA mapping model can be continued up to 16 TRX, in adding either an S
TDMA or a T TDMA.
4.25.4 PCM Priority

The parameter trafficPCMAllocationPriority defines the priority level of a
TDMA frame on the Abis interface. It allows the setup of TDMA priority on the
Abis PCM for the reconfiguration process.
The engineering rule associated to this parameter will depend on the strategy the
operator wants to use for the corresponding site.
The default engineering rule is to give the highest priority (0) to the TDMA
supporting the BCCH, and the lowest priority (255) to all other TDMA.
However, one can privilege the traffic in one of the sectors. Then the highest
priorities will be set for the TDMA of the privileged cell.
An other possibility is to keep an equilibrate configuration, in order to provide a
service in all cells, though a PCM problem.

4119001036
Engineering issues
4.26 ENGINEERING GUIDELINES FOR EXCEPTIONAL EVENTS

This chapter is intended to provide guidelines on how to prepare Nortel GSM
networks for exceptional events from an engineering perspective. An exceptional
event as described in this chapter, is a temporary event which is known in advance
and which will generate an exceptional high traffic load on the network. Nortels
estimation is that it is economically not justifiable to dimension a GSM network for
these special events. Commonly a GSM network is dimensioned to carry the traffic
of the busy hour. The actions proposed in this chapter are intended to optimise the
behaviour of the network during an exceptional event. This chapter covers
recommended actions on the NSS and BSS. On the NSS, the subchapter describes
a set of recommended verifications that Nortel encourages the operator to do in
order to optimize the DMS behaviour. In addition a set of recommended office
parameter settings on the MSC is given with the aim of optimizing the behaviour
of the BSC. On the BSS side, the subchapter presents the list of strongly
recommended verifications and a parameter set to be applied for any wide area
special event. Nortel recommends that the normal parameter setting should be
reconfigured after the exceptional event.
This chapter covers the V10 & V11 BSS releases. The BSS NRP, referenced
throughout the chapter, is applicable to V10.4 and V11.3. On the NSS side the
chapter is applicable to GSM09. It is assumed that all required patches on NSS and
BSS are applied.
As signalling is the bottleneck during a high load situation on the BSS, the guiding
idea here is to reduce as much as possible unnecessary signalling during the
exceptional event. Nortels estimation is that this should improve the behaviour of
the BSC.
At the BSS level, the control of this situation is done by various verifications and
parameter modifications. The proposal is organised in 4 main levels:
Prerequisite,
Basic tuning of parameters
Overload configuration change,
Other parameter modification.
4.26.1 BSS: Prerequisite
4.26.1.1 Checks
These checks are also included in the BSS NRP preparation.

The syntax is:
name of the parameter = recommended value, [concerned object, class]

Engineering issues
Sanity checks
Should be done at least one month before the foreseen event.
Parameters:
Note: It is recommended that the following parameters are set as described

independently of the special event, and that they stay as defined after the
special event:
bssSccpConnEst = 5, [signallingPoint, 1]
processorLoadSupConf = 6 for BSC6000 & CPU66, [bsc, 3]
1 for BSC6000 & CPU120
1 for BSC12000 & CPU120
averagingPeriod = 20, [handoverControl, 2]
noOfBlocksForAccessGrant = 1 for not combined BCCH, [bts, 2]
0 if combined
noOfMultiframesBetweenPaging = 2 (in urban environment), [bts, 2]
numberOfSlotSpreadTrans = 32, [bts, 3]
if modeModifyMandatory = true or if interDirectedRetryFromCell = allowed then
chosenChannelAssComp = true, [signallingPoint, 1]
chosenChannelCompL3Info = true, [signallingPoint, 1]
chosenChannelHoPerf = true, [signallingPoint, 1]
chosenChannelHoReq = true, [signallingPoint, 1]
Network:
Each BSC is fully operational and a switchover should be done,

LapD loadsharing over SicDs,
LapD loadsharing over BSCBs,
Location Area (LA) sizing, (typically less than or equal to 1500 Erl),
TCH congestion (this is particularly important in case of concentric cell use),
Call Drop rate,
HandOver failure rate (and neighbouring reciprocity).

4119001036
Engineering issues
Checks correlated with the special event
The Nortel Recommendation is that these checks be done a few hours before the
special event.
Parameters:
abisSpy = not in progress, [bts, 3]

unknownCellWarning = disabled, [bts, 3]
4.26.1.2 Other prerequisites for the special event
The Operation, Administration and Maintenance shall be minimum. So:

All Call Traces and Call Path Traces shall be stopped/discarded.
All temporary observations shall be discarded.
The T2 of permanent observations shall be set to 30.
and the BSC shall be fully operational. So:
a switchover shall be done,
All of this should be done a few hours before the foreseen event.
Moreover, no modification of the network during the special event (such as
command files, OMC commands, ) shall be done.
4.26.2 BSS: Suggestions for parameters to be modified for the special

event
It is suggested that the following parameters be modified before the special event
and set back to the previous value after (when the amount of traffic is back to a
normal level):
These parameters are split into 3 categories.
The modification of parameters of the 1st category does not lead to any service
interruption. These modifications may be done very quickly and a few hours before
the event.
Parameters of the 2 nd category are only applied if there is any BSC6000 and can
be done without service interruption (refer to NRP).
Modification of parameters of the 3 rd category is optional and only applicable on
networks in which queuing is already activated. It requires a quite long
preparation and should be decided at least three months before the special event.
It does not lead to service interruption.

Engineering issues
4.26.2.1 Cat.1: Basic tuning of BSS parameters
Included in the BSS NRP. Should be set few hours before.

processorLoadSupConf = 9 for BSC6000 & CPU66, [bsc, 3]
3 for BSC6000 & CPU120
3 for BSC12000 & CPU120
interBscDirectedRetry = not allowed, [bsc, 3]
intraBscDirectedRetry = not allowed, [bsc, 3]
4.26.2.2 Cat.2: Overload configuration change
Included in the BSS NRP. Shall be applied few days before the event only if there
is any BSC6000.
The modified parameters are:
max nb of paging req sent by a BIFP to a SICD = 30,
threshold (%CPU) of SICD overload control = 70
4.26.2.3 Cat.3: Other parameters modification
Not included in the BSS NRP.

AllocPriorityTimers 30 [bts,3]
4.26.3 NSS level
4.26.3.1 DMS Preparation
The Chapters 7.31.3.1.2 and 7.31.3.1.4 are not applicable to a standalone HLR.
Note: The recommendations in this chapter should also be followed after the
exceptional event.
Computing Module (CM)
The Computing Module (CM) of the DMS is protected by a highly efficient

overload mechanism. This mechanism allows the DMS to stand a significant
overload.
In order to maintain the craftspersons capability to access the DMS in the expected
overload situation, it is suggested that verification is made to ensure that at least the
2 MAP terminals as well as the ETAS modems are declared as guaranteed
background task for the CPU. This is done by setting for these devices in table
TERMDEV the GUAR field to Y. A maximum of 5 devices can be declared in this
way. Refer to NTP 4113001451 Customer Service Data Schema Vol 3.

4119001036
Engineering issues
Link Peripheral Processor (LPP)

The behaviour of the LPP under heavy traffic conditions can be improved by
optimizing the allocation of BSSAP instances to LIU7s. It should be checked that
the following recommendations are followed.
Context:
Table GSMSSI defines the subsystem instances of the BSSAP local subsystem.
These instances reside on an LIU7 and serve SCCP Class 2 connections between
the BSS and the DMSMSC.
Table GSMSSI allows the customer to associate BSSAP instances with LIU7s.
BSSAP instances are used only for Ainterface messaging. They can be datafilled
on any LIU7 in the MSC. Also, there is no restriction that an Ainterface LIU7 must
have a BSSAP datafilled against it. However, datafilling the BSSAPs in a
nonoptimal manner can negatively impact the DMSMSCs performance under
heavy messaging conditions.
Further information about table GSMSSI and the BSSAP instances can be obtained
in The CCS7 Application Guide, NTP #4112231310. This document includes a
datafill example for GSMSSI.
Recommendations:
The recommendation is that all customers apply the following guidelines:
SSAP instances in table GSMSSI should only be defined against LIU7s which
have an inservice link to a BSC.
Each Ainterface linkset should at least have one BSSAP instance assigned to it.
The remaining instances (total of 32) should be spread out among the remaining
Ainterface LIU7s. Priority should be given to the highest traffic linksets.
SS7 Link
Underprovisioned SS7 links can result in link congestion, which potentially inhibit
mobile call processing. It is therefore recommended to audit the link provisioning
in the network before the special event. During the busy hour the mean link
occupancy should not exceed 40%. The expected subscriber growth in the network
has to be taken into account. This check should be done about 4 months before the
special event in order to allow potential HW extensions.
LAC Datafill
The Location Area Code (LAC) is a configurable parameter on the BSS and on the
NSS (table LAC). If the values are not the same, Mobile location updates on the
MSC will fail. This will result in all mobiles to repeat the locationupdate attempt.
The resulting high signaling load can decrease stability of the LPP due to the
increased signaling traffic. It is therefore highly recommended to verify that the
LAC values on BSS and NSS match up before the special event.

Engineering issues
4.26.3.2 BSC Protection
Reduction of the signaling load on the BSC optimizes its behavior in a high traffic
situation. This chapter proposes actions in the NSS, which will help to decrease the
signaling load on the BSC.
SMS Voicemail notification
Most of the GSM networks use voicemail notification via SMS. SMS traffic is
realtime cost intensive on the BSC processors. Furthermore, in a high traffic
situation with degraded QoS, the Voicemail traffic is expected to significantly
increase. The operator should consider to deactivate the notification of voicemails
via SMS. Under very high load the notified subscribers will not be able to consult
their voicemails anyway, due to the high blocking rate at the Air interface. The
deactivation should be done either on the VMS or on the SMSC.
Authentication
Authentication in GSM aims at ensuring that only mobiles with an official SIM card
can access the network. Reducing authentication reduces the signaling on the BSS.
The operator should consider to disable the optional authentication activities in the
network. This can be done by modifying parameter AUTH_CONTROL_PARM in
table OFCVAR. To configure to a minimum activity the parameter has to be set as
follows:
GSM09: AUTH_CONTROL_PARM = NORM_0 PER_0 ATT_0 MO_0 MT_0
Impact
It should be noted that even with this minimum setting the authentication procedure
will be executed at the first Attach or InterVLRlocationupdate of mobile at the
MSC. This implies that a reasonable degree of security is reached. The default value
of NORM_20 PER_20 ATT_20 MO_20 MT_20 configures that every 20th call,
locationupdate and attach will trigger the authentication procedure. The above
described minimum value results in only the first locationupdate (interVLR or
attach) to trigger authentication.
The parameter allows to individually set authentication rates for normal (NORM),
periodic (PER) location updates location, Attachs (ATT), mobile originated (MO)
and mobile terminated (MT) calls.

4119001036
Engineering issues
Page retry
The Paging message sent to the BSC is highly costly in terms of BSC CPU
processing. After a timer expires without a response from a mobile, the DMS sends
a second Paging message. Monitoring of live networks has shown that only an
insignificant portion of the second paging message is successfully responded by a
mobile. Due to this it is recommended to deactivate the paging retry. This is done
by setting the parameter GSM_PAGE_RETRY in table GSMVAR to 0.
Ciphering
Ciphering guarantees confidentiality of GSM communications on the radio

interface. Deactivating Ciphering reduces the signaling on the BSC. The operator
should consider whether the deactivation of ciphering is acceptable during the
special event. To deactivate, the officeparameter GMSC_CIPHERING in table
OFCENG of the MSC has to be set to OFF.

Engineering issues
4.27 ENGINEERING LIMITS WITH BSC OVERLOAD CONTROL

MECHANISM
The main objective of the BSC overload control mechanism (introduced in V12)
is to maintain BSC robustness during a traffic overload period.
The BSC controls achieve this by filtering of Mobile Originated calls, Mobile
Terminated calls, Location Updates, Handover or Random Access Channel
messages. This results in a Quality of Service degradation (through an increasing
Call Attempts reject rate) from a certain call attempt level on, as illustrated below.
Mean CPU occupancy

Offered traffic
100%
OAM & internal processes
CPU Call Processing limit (ex: 70%)
Carried traffic
CPU Engineering limit

(ex: 55%)
QoS decreases
BSC overload control

mechanism triggered
Mean Call Attempts
BSCs maximum throughput

with the highest QoS
Figure 412 MEAN CPU OCCUPANCY BEHAVIOUR FOR ANY GIVEN BOARD OF THE
BSC

4119001036
Engineering issues
4.27.1 What does the CPU Engineering limit mean ?
The CPU Engineering limit is defined as the limit of mean CPU occupancy (used
for Call Processing only) not to be exceeded in order to maintain the highest Quality
Of Service.
When exceeding this engineering limit, the probability that the Quality of Service
is degraded due to the triggering of the overload control mechanism cannot be
neglected.
The following set of CPU Engineering limits is based on lab performance reports
and validated in the field. Below these limits, no QoS degradation has been
observed.
Board CPU Engineering limits
MPU&BIFP 55%
SICD 60%
BSCB 60%
OMUSUPSWC 90%
This value does not refer to a CPU occupancy but to the OMUSUPSWC link
occupancy.
Table 41 CPU ENGINEERING LIMIT VALUES
Remark: Using higher values than those defined here above will potentially
have an impact on the Quality of Service
4.27.2 What does the CPU Call Processing limit mean ?
The CPU Call Processing limit is defined as the limit of mean CPU occupancy
(used for Call Processing only) not to be exceeded by the different boards,
regardless of Quality of Service. The overload control mechanism acts to keep the
mean Call Processing CPU occupancy due to the traffic below this limit.
The remaining x% is reserved for other processes required for OAM signaling and
internal processes.

Engineering issues
The following set of CPU Call Processing limit is based on field experience and
lab performance reports.
Board CPU Call Processing limit
MPU&BIFP 70%
SICD 70%
BSCB 70%
OMUSUPSWC 100%
This value does not refer to a CPU occupancy but to the OMUSUPSWC link
occupancy.
Table 42 CPU CALL PROCESSING LIMIT VALUES
Remark: It is not recommended to use higher threshold to make a BSC

dimensioning study!
Nortel Network Design teams computes BSC capacity through CT5100 tool based
on CPU Engineering limit to ensure the optimum Quality of Service for the
customer network.

4119001036
Engineering issues
Hereunder is an example of figures obtained for a BSC12000 (with CPU120) on

which is applied a typical standard (Nortel) traffic profile:
88% MOC
12% MTC
1,16 LU/call
CPU Real Load / Traffic increase 1,01HO/call
BSC12000/CPU120
Standard Profile
Load
70% 1200
65%
60%
1000
55%
50%
800
45%
Erlang
40%
35% 600
30%
25%
400
20%
15%
200
10%
%rejectRACH/TOTAL
5%
0% 0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25
%rejectRACH/TOTAL
SICD mean pr load (%)
BIFP mean pr load (%)
MPU mean pr load (%)
OMU mean pr load (%)
Requested traffic (Erl)
Realized traffic (Erl)

Engineering issues
4.28 POWER CONTROL COMPENSATION IN INTERZONE

HANDOVER
This chapter deals with the theoretical behaviour of the power control during
interzone handovers for the 3 concerned cell types (concentric cell, dualcoupling
cell, dualband cell) and for each Power Control algorithm (step by step, one shot).
For this study, 3 phases are defined:
Phase 1 : the MS is handled by a TDMA belonging to the band0/outerzone and
the TX power is stable
Phase 2 : the MS is handed over toward a TDMA belonging to the
band1/innerzone ; the power control is not running
Phase 3 : the power control is started and the power becomes stable.
4.28.1 Dualband cell
4.28.1.1 Step by step algorithm
In this example, we suppose that BS transceivers have the same maximum power
in each band. The studied case is the RxLev_DL but the RxLev_UL is similar.
There is no power compensation during the handover: the initial power after a
handover doesnt take into account the difference of radio propagation between the
two bands. So, there is a signal drop (approximately Bizone_power_offset).

4119001036
Engineering issues
However the condition on level for the Interzone handover ensures that the signal
drop has no effect.
The Step by step algorithm keeps the RxLev_DL in the interval L_RXLEV_DL_P,
U_RXLEV_DL_P. Thus the attenuation on BS power decreases in order to
compensate the signal drop.
Conclusion:
The Step by step algorithm compensates the signal drop.
Note: If the initial attenuation (in level) after the handover is less than
Bizone_power_offset, the definitive power compensation is reduced.
4.28.1.2 One shot algorithm
One shot applied to the BS power
The BS transceivers have the same maximum power in each band.
DL_TxPwr_BandX dB are attenuations resulting from the one shot algorithm.

Interzone handover toward Band1:
There is no power compensation on the Handover: the initial power after a

Engineering issues
Band1 after the Power control:

RxLev DL _Band1 = RxLev DL _Band0 Bizone_power_offset
+ KDL *Bizone_power_offset /VAL_PWRLEV_TO_DB
(with VAL_PWRLEV_TO_DB = 2)
Note: If the DL_TxPwr_Band0 (dB) is lower than KDL*Bizone_power_offset,
the power compensation is reduced.
Example:
Bizone_power_offset = 3 level (6 dB)
Bad quality without frequency hopping: KDL = 0.5
RxLev DL _Band1 RxLev DL _Band0 = 3 + 0.5*3/2 = 3 level (6 dB)
Good quality with frequency hopping: KDL = 0.9
RxLev DL _Band1 RxLev DL _Band0 = 3 + 0.9*3/2 = 1 level (2 dB)
One shot applied to the MS power
There is an MS transceiver maximum output power for each band:
Pm0 (max transmitting MS power in band0) depends on the MS_classmark in

Band0 and on the network parameter MS_TXPWR_MAX.

4119001036
Engineering issues
Pm1 (max transmitting MS power in band1) depends on the MS_classmark in

Band1 and on the network parameter MS_TXPWR_MAX_BAND1.
PMS = Pm0 Pm1.
UL_TxPwr_BandX dBm are absolute powers resulting from one shot algorithm.
Initialization after Interzone handover toward Band1:
There is no power compensation on the Handover: the initial power after a
Band1 after the Power control:
RxLev UL _Band1 = RxLev UL _Band0 Bizone_power_offset
+(KUL*Bizone_power_offset (1KUL)*PMS )/VAL_PWRLEV_TO_DB
Example:
Bizone_power_offset = 3 level (6 dB)
PMS = 3 dB
Bad quality without frequency hopping: KUL = 0.5
RxLev UL _Band1RxLev UL _Band0 = 3 + (0.5*3 0.5*3)/2 = 3 level (6 dB)
Good quality with frequency hopping: KUL = 0.9
RxLev UL _Band1 RxLev UL _Band0 = 3 + (0.9*3 0.1*3)/2 = 2 level (4 dB)
Conclusion on One shot
The definitive power compensation with the One shot algorithm is reduced
especially when the frequency hopping is not used. However the condition on level
for the Interzone handover ensures that the compensation is not indispensable.
In comparable conditions, the difference of level (resulting from the Power control)
between the two bands of a Dual Band cell always exist. It is not tied to the handover
example.

Engineering issues
4.28.2 Concentric cell
The BSC knows the BS maximum output TX power in each zone, so the
attenuation is compensated during an Interzone handover.
RxLev DL _Zone1 = RxLev DL _Zone0 (1K DL )*P BS )
/VAL_PWRLEV_TO_DB
RxLev UL _Zone1 = RxLev UL _Zone0
Example:
PBS = 15dB
RxLev DL _Zone1 RxLev DL _Zone0 = 0.5*15/2 = 3.7 level (6 dB)
RxLev DL _Zone1 RxLev DL _Zone0 = 0.1*15/2 = 0.7 level (0 dB)
4.28.3 Dualcoupling cell
The BS maximum output TX power is the same in each zone (P BS ), but the
difference comes from different coupling losses (downlink) which have the same
effect than a difference of radio propagation.
The power is not compensated during an Interzone handover.
The Power control result is nearly the same in the two zones.
RxLev DL _Zone1 = RxLev DL _Zone0 Bizone_power_offset
+ K DL * Bizone_power_offset / VAL_PWRLEV_TO_DB
RxLev UL _Zone1 = RxLev UL _Zone0
Example:
Coupling D (loss about1dB) and H2D (loss about 4dB)
Bizone_power_offset = 3dB = 1.5 level

4119001036
Engineering issues

RxLev DL _Zone1 RxLev DL _Zone0 = 1.5 + 0.5*1.5/2 = 1.1 level (2 dB)
RxLev DL _Zone1 RxLev DL _Zone0 = 1.5 + 0.9*1.5/2 = 0.8 level (0 dB)
The One shot associated with Dual coupling cells has a good behavior.

Engineering issues
4.29 CELL TIERING GAIN
4.29.1 Introduction
Today, the radio resource allocation is made randomly from Mobile Station point
of view: no discrimination is made between a Mobile Station at the cell edge in the
overlapping area, potentially interfered and a Mobile Station at the centre of cell
potentially not interfered.
The cell tiering aims at allocating resources taking into account a criterion
representing the potential interference that could be experienced by the call.
4.29.2 Simulations results

Simulations have been conducted in order to choose the best criterion. The criteria
candidates were:
RxLev : field strength reported in the measurement reports
Distance: derived from timing advance
Potential Worst C over I: calculated as the ratio between the signal received from
the current cell and the signal levels reported on the neighbour cells, weighted by
a factor depending on the relation between current and neighbour hopping
frequencies (cochannel, adjacent, non interfering)

4119001036
Engineering issues
Following are the simulation results, providing the cumulative probability of C/I
uplink and downlink for the different criteria:
0,1
no tiering (UL)
RxLev (UL)
0,01 distance (UL)
PWCI (UL)
0,001
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
0,1
no tiering (DL)
RxLev (DL)
distance (DL)
0,01
PWCI (DL)
0,001
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
On the uplink, RxLev is the best criterion whereas distance is the poorest.
Meanwhile on the downlink, PWCI is the best.

Engineering issues
RxLev provides 6 dB gain uplink and 2 dB downlink at 10% worst.

PWCI provides 3 dB gain uplink and 4 dB downlink at 10% worst
Distance is the poorest criterion and provides around 2dB uplink and downlink at
10% worst case.
The PWCI has been chosen as tiering criterion, providing the best downlink results
and comparable uplink gain.
4.29.3 Gain estimation based on terrain data

Some gain estimations have been processed based on PWCI terrainbased
distribution, by considering the following cases:
first allocation strategy: without tiering, uniform distribution of calls between
non hopping and hopping, considering that 1/N calls are randomly on BCCH and
the others on TCH, N being the ratio of non hopping timeslots. For example, for
S444 configuration with 1 nonhopping TRX, N=4.
Second allocation strategy: tiering on BCCH for the 1/N worst calls. N defined as
previously.
The two main parameters that have an impact on the cell tiering gain are:
The ratio of non hopping channels on which worst calls are transferred through
cell tiering
The estimated difference in terms of C/I between hopping TRXs and
nonhopping TRXs. The higher the difference, the higher the gain.
The graph below shows the estimated C/I distribution over a cell where the
difference of C/I between BCCH and TCH is 3 dB (for example BCCH 4*12, TCH
1*1 16% or BCCH 4*12, TCH 1*3 85%):
Note:
The C/I estimated on BCCH is derived from PWCI by taking into account the gain
due to higher distance reuse and the gain of Erlang law efficiency.
The C/I estimated on TCH is derived from PWCI by taking into account the gain
of GSM goodies such as DTX, power control and frequency hopping and the gain
due to Erlang law and fractional reuse (for example, using frequencies 50% of time
generates a gain of 3 dB).

4119001036
Engineering issues
BCCHTCH=3dB
120.00%
BCCH
BCCHTCH=3dB no tiering (19%nohop)
BCCHTCH=3dB tiering (19%nohop)
100.00%
80.00%
60.00%
40.00%
% of calls with C/I <= abscissa
20.00%
0.00%
7 3 1 5 9 13 17 21 25 29 33 37 41 45 49 53 57
11
estimated C/I
This curves show that the 19% tiering decreases the percentage of calls with low
and medium values of C/I (C/I < 16 dB). This enhancement in terms of C/I can be
translated in terms of capacity gain.
4.29.4 Capacity gain estimation

Some rough calculations have been performed to estimate the gain of cell tiering
in terms of capacity, considering a uniform traffic distribution.
The graph below shows the number of TRXs par cell in the following
configurations:
TRX12: 4*12 frequency plan
TRXF0.10: 1*1 10% frequency load without tiering

Engineering issues
TRXF0.15T19: 1*1 15% frequency load with 19% tiering which offers same
quality as 1*1 10% thanks to tiering
TRXF0.15: 1*1 15% frequency load without tiering
TRXF0.25T19: 1*1 25% frequency load with 19% tiering which offers same
quality as 1*1 15% thanks to tiering
Let us recall that:
FrequencyLoad = (Number of hopping TRX in a cell) / (Number of hopping
frequencies in a cell).
Please note that the irregularities in the curves are due to the division round off. The
remaining frequencies can be used to increase locally some sites capacity.
#TRX/cell versus spectrum

20,00 TRX12
18,00 TRXF0.15
16,00 TRXF0.25T19%
TRXF0.10
14,00
TRXF0.15T19%
12,00
10,00
8,00
TRX/cell
6,00
4,00
2,00
0,00
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
spectrum

4119001036
Engineering issues
Taking into account Erlang B law with 2% blocking rate, the following graph
provides, for the same configurations, the Erlang/cell for different spectrum:
Erlang at 2% GoS/cell versus

spectrum
118,00
ERG12
108,00
ERGF0.15
98,00
ERGF0.25T19%
88,00
ERGF0.10
78,00
ERGF0.15T19%
68,00
58,00
48,00
Erlang/cell
38,00
28,00
18,00
8,00
5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
spectrum
As can be seen on the graph, the capacity gain in terms of Erlang can be evaluated to:
Up to 70%(resp. 50%) gain compared to fractional reuse with the same quality,
for narrow (resp. large) spectrum
Up to 170% (resp. 150%) gain compared to 4*12 reuse plan for narrow (resp.
large) spectrum.
4.29.5 Conclusion
The gains assessed hereabove have been calculated based on a PWCI distribution
collected on a specific network and on simplistic assumptions of traffic distribution;
thus they have to be considered as indicative gains.
For a specific network, the capacity gain can be recalculated more precisely taking
into account the irregularities in traffic distribution and the specificities in terms of
PWCI distribution.
The gain brought by Automated cell Tiering (ACT) can be seen as a way:
to enhance quality experienced by enduser, for the same capacity offered
to push the capacity limits for overloaded network: put more TRXs per site with
the same spectrum
to save some frequency channels, which can be used for hot spots coverage

Engineering issues

4119001036
APPENDIX A: Main exchange procedures at BSC level
5 APPENDIX A: MAIN EXCHANGE PROCEDURES AT

BSC LEVEL
5.1 PROC_1: ESTABLISHMENT PROCEDURE
MS BTS BSC MSC
channel request
channel request
channel activate
TimmAck
channel activate Ack t3101
immediate assignment
Reset TimmAck
immediate assignment
SABME Reset t3101

Establishment Indication
UA
Connection request
Connection cnf
SABME: frame to set asynchronous balanced mode (initiate a link for numbered
information transfer).
UA: unnumbered aknowledge

5.2 PROC_2: CHANNEL MODE PROCEDURE
MS BTS BSC MSC
assign request
channel activate
TmodMs
TimmAck
channel activate /
mode modify Ack
Reset TmodMs
Reset TimmAck
channel mode modify TmodMs

channel mode
modify
mode channel
mode channel
modify Ack
modify Ack
assign complete
Reset TmodMs

4119001036
5.3 PROC_3: DEDICATED CHANNEL ASSIGNMENT
MS BTS BSC MSC
channel activate assign request
TimmAck
channel activate Ack
assign command Reset Timm Ack

t3107
assign command
SABME
establishment indication
UA
assign complete
Reset t3107
assign complete
Trf Ack
RF channel release
assign complete
RF channel release Ack
Reset Trf Ack

5.4 PROC_4: INTRACELL HANDOVER PROCEDURE
MS BTS BSC MSC
handover indication (TCH/SDCCH)
channel activate TimmAck
channel activate Ack
Reset Timm Ack

assign command t3107
assign command
SABME (new facch) establishment indication

(new facch)
UA (new facch)
assign complete
Reset t3107
assign complete
Trf Ack
RF channel release
handover performed
RF channel release Ack
Reset Trf Ack

4119001036
5.5 PROC_5: INTRABSS HANDOVER PROCEDURE
MS BTS 1 BTS 2 BSC MSC
>handover indication>
(TCH/SDCCH)
<channel activate<
TimmAck
>channel activate Ack>
Reset Timm Ack

<HO command<
<HO command< t3103
>H O access>
>HO detect>
<physical info<
>SABME (new dcch)>

>establishment indication
(new facch)> Reset t3103
<UA (new dcch)<
Trf Ack
>H O complete> <HO coplete> >handover performed>
<RF channel release<

Reset Trf Ack
<RF channel release
Ack>
From BTS 1 to BTS 2

5.6 PROC_6: INTERBSS HANDOVER PROCEDURE
MS BTS 1 BSC 1 MSCs BSC 2 BTS 2
>H O required> bssMap T7 <HO required>

<HO request<
TimmAck >channel
CC activate>
<channel
reset bssMap T7 <HO request Reset Timm Ack activate Ask<
t3103<bssMap T8 <H O command< Ack< ThnCom
<H O command<
<H O command<
>H O access>
<HO detect< <HO detect<
<physical info<
>HSABME <est connection
(new dcch)> (new dcch)<
<UA (new dcch)<
>H O complete>
Reset t3103, T8 >clear command< <HO complete< Reset <HO complete<

ThndCom
TrfAck
<RF channel
release<
<RF channel
release Ack< >clear complete>
Reset Trf Ack
BTS 1 (from BSC 1) to BTS 2 (from BSC 2)

4119001036
5.7 PROC_7: RESOURCE RELEASE PROCEDURE (EXAMPLE)
BTS BSC
Start t3111
Release Indication
RF Channel Release t3111 expires
RF Channel Release ACK

5.8 PROC_8: SACCH DEACTIVATION PROCEDURE
BTS BTS BSC

<DataReq (Channel Release)<
<Channel Release<
>Deactivate SACCH>
Start t3109
>Deactivate SACCH Ack>
>disc>
<UA<
>Release Indication> Stop t3109
Start t3111
<RF Channel Release<

t3111 expires
>RF Channel Release ACK>

4119001036
5.9 CASE OF MOBILE TERMINATING CALLS
BTS A BTS B
MS LAC 1 BSC LAC 1
Paging command Paging command
RR paging request Paging request
PCH PCH
RR channel request
RACH Channel required
Channel activation
Channel activation ACK

Immediate
RR immediate assignment command
assignment
AGCH
Switch to SDCCH
channel
SABM
(RR paging response)
SDCCH Establish indication
(RR paging response)
UA
(RR paging response) Toward MSC
SDCCH

5.10 CASE OF MOBILEINITIATING CALLS
MS BTS BSC MSC

RR channel request
RACH Channel required
Channel activation
Channel activation ACK

Immediate
RR immediate assignment command
assignment
AGCH
Switch to SDCCH
channel
SABM (MM CM_service

request) Establish indication
SDCCH (MM CM_service
request)
SCCP connection
UA (MM CM_service request (BSSMAP
request) complete L3 info (MM
SDCCH CM_service request)

4119001036
Erlang Table
6 ERLANG TABLE
Blocking 0,0001 0,001 0,005 0,01 0,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,2
rate
0,01% 0,10% 0,50% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 20%
Channels
1 0,000 0,001 0,005 0,010 0,020 0,030 0,040 0,050 0,060 0,070 0,080 0,090 0,100 0,200
2 0,014 0,046 0,105 0,151 0,219 0,273 0,320 0,362 0,401 0,438 0,472 0,505 0,536 0,800
3 0,087 0,194 0,347 0,451 0,590 0,694 0,780 0,854 0,922 0,983 1,040 1,093 1,144 1,544
4 0,235 0,439 0,698 0,861 1,070 1,221 1,343 1,448 1,541 1,625 1,702 1,774 1,841 2,356
5 0,452 0,761 1,126 1,347 1,624 1,819 1,975 2,108 2,224 2,328 2,424 2,511 2,593 3,208
6 0,728 1,145 1,126 1,890 2,230 2,467 2,654 2,812 2,950 3,073 3,185 3,288 3,383 4,087
7 1,054 1,577 2,147 2,476 2,877 3,152 3,369 3,551 3,709 3,849 3,976 4,092 4,199 4,984
8 1,422 2,049 2,716 3,096 3,554 3,867 4,112 4,316 4,493 4,649 4,790 4,919 5,038 5,895
9 1,825 2,555 3,316 3,745 4,258 4,606 4,876 5,102 5,296 5,468 5,622 5,763 5,892 6,818
10 2,260 3,089 3,941 4,417 4,982 5,364 5,660 5,905 6,116 6,302 6,469 6,621 6,759 7,748
11 2,721 3,648 4,587 5,108 5,725 6,138 6,458 6,723 6,949 7,149 7,328 7,490 7,638 8,686
12 3,207 4,227 5,253 5,817 6,483 6,927 7,270 7,553 7,795 8,008 8,198 8,369 8,527 9,629
13 3,713 4,826 5,934 6,541 7,254 7,728 8,093 8,393 8,650 8,875 9,076 9,257 9,423 10,578
14 4,238 5,441 6,630 7,278 8,036 8,539 8,926 9,243 9,514 9,751 9,962 10,153 10,326 11,530
15 4,781 6,071 7,339 8,027 8,829 9,361 9,768 10,101 10,385 10,634 10,855 11,054 11,235 12,486
16 5,338 6,715 8,059 8,786 9,632 10,190 10,617 10,966 11,264 11,523 11,754 11,961 12,150 13,446
17 5,910 7,371 8,790 9,555 10,443 11,027 11,474 11,838 12,148 12,418 12,658 12,874 13,069 14,408
18 6,495 8,038 9,530 10,333 11,261 11,871 12,336 12,716 13,038 13,318 13,567 13,790 13,993 15,373
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page 6.1

Erlang Table
Blocking 0,0001 0,001 0,005 0,01 0,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,2
rate
0,01% 0,10% 0,50% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 20%
Channels
19 7,092 8,715 10,279 11,118 12,086 12,721 13,205 13,599 13,933 14,223 14,481 14,711 14,921 16,339
20 7,700 9,402 11,036 11,910 12,918 13,578 14,079 14,487 14,832 15,132 15,398 15,636 15,852 17,308
21 8,318 10,098 11,801 12,709 13,755 14,439 14,958 15,379 15,736 16,045 16,319 16,564 16,786 18,279
22 8,945 10,801 12,572 13,515 14,598 15,305 15,841 16,276 16,643 16,962 17,243 17,495 17,723 19,251
23 9,582 11,513 13,349 14,326 15,446 16,175 16,728 17,176 17,554 17,881 18,171 18,429 18,663 20,224
24 10,226 12,231 14,133 15,142 16,298 17,050 17,618 18,079 18,468 18,804 19,101 19,366 19,605 21,199
25 10,879 12,956 14,922 15,963 17,154 17,928 18,513 18,986 19,385 19,729 20,033 20,305 20,550 22,176
26 11,539 13,687 15,716 16,789 18,015 18,810 19,411 19,896 20,304 20,658 20,969 21,246 21,496 23,153
27 12,206 14,424 16,515 17,619 18,879 19,696 20,311 20,809 21,227 21,588 21,906 22,189 22,445 24,131
28 12,879 15,167 17,319 18,454 19,748 20,584 21,215 21,724 22,152 22,521 22,845 23,135 23,396 25,111
29 13,559 15,914 18,127 19,292 20,619 21,476 22,121 22,642 23,079 23,456 23,787 24,082 24,348 26,091
30 14,244 16,667 18,939 20,134 21,493 22,370 23,030 23,562 24,008 24,393 24,730 25,031 25,301 27,072
31 14,936 17,425 19,756 20,981 22,369 23,267 23,942 24,483 24,939 25,331 25,675 25,981 26,256 28,053
32 15,631 18,186 20,575 21,828 23,250 24,167 24,856 25,408 25,872 26,272 26,622 26,933 27,214 29,036
33 16,333 18,953 21,397 22,681 24,133 25,069 25,769 26,333 26,808 27,214 27,569 27,886 28,172 30,019
34 17,039 19,722 22,225 23,533 25,019 25,972 26,689 27,264 27,744 28,158 28,519 28,842 29,131 31,003
35 17,750 20,497 23,053 24,392 25,906 26,881 27,608 28,192 28,683 29,103 29,469 29,797 30,092 31,989
36 18,467 21,275 23,886 25,253 26,797 27,789 28,531 29,125 29,622 30,050 30,422 30,756 31,053 32,972
37 19,186 22,056 24,722 26,114 27,689 28,697 29,453 30,058 30,564 30,997 31,378 31,714 32,014 33,958
38 19,908 22,842 25,561 26,981 28,583 29,611 30,378 30,992 31,506 31,947 32,331 32,672 32,978 34,944
Page 6.2 PE/DCL/DD/0036 Standard 12.01/EN January 2000

Erlang Table
Blocking 0,0001 0,001 0,005 0,01 0,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,2
rate
0,01% 0,10% 0,50% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 20%
Channels
39 20,636 23,628 26,400 27,847 29,478 30,525 31,303 31,928 32,450 32,897 33,286 33,633 33,944 35,931
40 21,369 24,419 27,244 28,717 30,378 31,439 32,231 32,867 33,394 33,847 34,244 34,594 34,908 36,917
41 22,103 25,214 28,092 29,589 31,278 32,356 33,161 33,806 34,342 34,800 35,203 35,558 35,875 37,906
42 22,842 26,011 28,939 30,464 32,181 33,275 34,092 34,744 35,289 35,756 36,161 36,519 36,842 38,892
43 23,583 26,811 29,789 31,339 33,083 34,194 35,025 35,686 36,239 36,711 37,122 37,486 37,811 39,881
44 24,331 27,614 30,642 32,217 33,989 35,117 35,958 36,628 37,189 37,667 38,083 38,450 38,778 40,869
45 25,078 28,419 31,497 33,097 34,894 36,042 36,892 37,572 38,139 38,622 39,044 39,417 39,747 41,858
46 25,831 29,225 32,356 33,978 35,803 36,964 37,828 38,517 39,092 39,581 40,006 40,383 40,719 42,847
47 26,583 30,036 33,214 34,861 36,714 37,892 38,767 39,464 40,044 40,539 40,969 41,350 41,689 43,836
48 27,342 30,847 34,075 35,747 37,625 38,817 39,703 40,411 40,997 41,497 41,933 42,317 42,661 44,825
49 28,100 31,664 34,936 36,633 38,536 39,744 40,642 41,358 41,950 42,458 42,897 43,286 43,633 45,817
50 28,864 32,481 35,803 37,522 39,450 40,675 41,583 42,306 42,906 43,419 43,864 44,256 44,606 46,806
51 29,628 33,297 36,667 38,411 40,364 41,606 42,525 43,256 43,864 44,381 44,831 45,225 45,581 47,797
52 30,397 34,119 37,536 39,303 41,281 42,536 43,467 44,206 44,819 45,342 45,797 46,197 46,553 48,789
53 31,167 34,942 38,406 40,197 42,200 43,469 44,408 45,158 45,778 46,306 46,764 47,167 47,528 49,778
54 31,939 35,767 39,275 41,089 43,117 44,403 45,353 46,108 46,736 47,269 47,731 48,139 48,503 50,769
55 32,714 36,594 40,150 41,986 44,036 45,336 46,297 47,061 47,694 48,233 48,700 49,111 49,478 51,761
56 33,492 37,422 41,022 42,881 44,958 46,272 47,244 48,017 48,656 49,197 49,669 50,083 50,453 52,753
57 34,269 38,253 41,897 43,781 45,881 47,208 48,192 48,969 49,617 50,164 50,639 51,058 51,431 53,744
58 35,050 39,086 42,775 44,678 46,803 48,144 49,139 49,925 50,578 51,131 51,608 52,031 52,406 54,736

Erlang Table
Blocking 0,0001 0,001 0,005 0,01 0,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,2
rate
0,01% 0,10% 0,50% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 20%
Channels
59 35,833 39,919 43,653 45,578 47,728 49,083 50,086 50,881 51,539 52,097 52,581 53,006 53,383 55,731
60 36,619 40,756 44,533 46,481 48,650 50,022 51,036 51,836 52,500 53,064 53,553 53,981 54,361 56,722
61 37,406 41,592 45,414 47,383 49,578 50,961 51,983 52,794 53,464 54,031 54,522 54,956 55,339 57,714
62 38,197 42,431 46,294 48,286 50,503 51,903 52,933 53,753 54,428 55,000 55,494 55,931 56,317 58,708
63 38,986 43,269 47,178 49,192 51,431 52,844 53,886 54,711 55,392 55,969 56,469 56,906 57,297 59,700
64 39,781 44,111 48,064 50,097 52,358 53,786 54,836 55,669 56,356 56,939 57,442 57,883 58,275 60,694
65 40,575 44,956 48,950 51,003 53,289 54,728 55,789 56,628 57,319 57,908 58,414 58,861 59,256 61,686
66 41,372 45,800 49,836 51,911 54,219 55,672 56,742 57,589 58,286 58,878 59,389 59,836 60,233 62,681
67 42,169 46,644 50,722 52,819 55,150 56,617 57,694 58,550 59,253 59,847 60,364 60,814 61,214 63,672
68 42,969 47,492 51,611 53,728 56,081 57,561 58,650 59,511 60,219 60,819 61,339 61,792 62,194 64,667
69 43,769 48,342 52,503 54,639 57,014 58,506 59,606 60,472 61,186 61,792 62,314 62,769 63,175 65,661
70 44,572 49,189 53,394 55,550 57,947 59,453 60,558 61,433 62,153 62,761 63,289 63,750 64,158 66,656
71 45,378 50,042 54,286 56,464 58,881 60,400 61,514 62,397 63,122 63,733 64,264 64,728 65,139 67,650
72 46,183 50,894 55,178 57,375 59,814 61,347 62,472 63,358 64,089 64,708 65,242 65,708 66,119 68,642
73 46,992 51,747 56,072 58,289 60,750 62,294 63,428 64,322 65,058 65,681 66,217 66,686 67,103 69,636
74 47,800 52,603 56,967 59,206 61,686 63,242 64,386 65,286 66,028 66,653 67,194 67,667 68,083 70,631
75 48,611 53,458 57,864 60,119 62,622 64,192 65,344 66,250 66,997 67,628 68,172 68,647 69,067 71,625
76 49,422 54,314 58,758 61,036 63,558 65,142 66,303 67,217 67,967 68,603 69,147 69,628 70,050 72,619
77 50,236 55,172 59,656 61,953 64,497 66,092 67,261 68,181 68,936 69,575 70,125 70,608 71,033 73,614
78 51,050 56,031 60,556 62,872 65,436 67,042 68,219 69,147 69,908 70,550 71,106 71,589 72,017 74,611

Erlang Table
Blocking 0,0001 0,001 0,005 0,01 0,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,2
rate
0,01% 0,10% 0,50% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 20%
Channels
79 51,864 56,892 61,456 63,789 66,375 67,994 69,178 70,111 70,878 71,525 72,083 72,569 73,000 75,606
80 52,681 57,753 62,356 64,708 67,314 68,944 70,139 71,078 71,850 72,500 73,061 73,550 73,983 76,600
81 53,500 58,614 63,256 65,628 68,256 69,897 71,100 72,044 72,822 73,478 74,039 74,533 74,967 77,594
82 54,319 59,478 64,156 66,550 69,194 70,850 72,061 73,014 73,794 74,453 75,019 75,514 75,950 78,589
83 55,142 60,342 65,058 67,472 70,136 71,803 73,022 73,981 74,767 75,428 76,000 76,497 76,936 79,586
84 55,961 61,208 65,961 68,392 71,078 72,756 73,983 74,947 75,739 76,406 76,978 77,478 77,919 80,581
85 56,786 62,072 66,867 69,317 72,019 73,711 74,947 75,917 76,711 77,383 77,958 78,461 78,906 81,575
86 57,608 62,942 67,769 70,239 72,964 74,664 75,908 76,886 77,686 78,358 78,939 79,444 79,889 82,572
87 58,433 63,808 68,675 71,161 73,906 75,619 76,872 77,856 78,658 79,336 79,919 80,428 80,875 83,567
88 59,261 64,678 69,583 72,086 74,850 76,575 77,836 78,822 79,633 80,314 80,900 81,411 81,861 84,561
89 60,089 65,547 70,489 73,011 75,794 77,531 78,797 79,794 80,608 81,292 81,881 82,394 82,847 85,558
90 60,917 66,417 71,397 73,936 76,739 78,486 79,764 80,764 81,581 82,269 82,861 83,378 83,831 86,553
91 61,747 67,289 72,306 74,864 77,686 79,444 80,728 81,733 82,556 83,250 83,844 84,361 84,817 87,550
92 62,578 68,161 73,214 75,792 78,631 80,400 81,692 82,703 83,531 84,228 84,825 85,344 85,803 88,544
93 63,408 69,033 74,122 76,717 79,578 81,358 82,656 83,675 84,506 85,206 85,808 86,331 86,789 89,542
94 64,242 69,908 75,033 77,644 80,525 82,317 83,622 84,644 85,483 86,186 86,789 87,314 87,778 90,539
95 65,075 70,783 75,944 78,575 81,469 83,275 84,589 85,617 86,458 87,164 87,772 88,300 88,764 91,533
96 65,911 71,658 76,856 79,503 82,419 84,233 85,553 86,589 87,433 88,144 88,753 89,283 89,750 92,531
97 66,744 72,533 77,767 80,433 83,367 85,192 86,519 87,561 88,411 89,125 89,736 90,269 90,736 93,525
98 67,583 73,411 78,678 81,361 84,314 86,150 87,486 88,533 89,386 90,106 90,719 91,253 91,725 94,522

Erlang Table
Blocking 0,0001 0,001 0,005 0,01 0,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09 0,1 0,2
rate
0,01% 0,10% 0,50% 1% 2% 3% 4% 5% 6% 7% 8% 9% 10% 20%
Channels
99 68,419 74,289 79,592 82,292 85,264 87,111 88,453 89,506 90,364 91,086 91,703 92,239 92,711 95,519
100 69,258 75,167 80,506 83,222 86,214 88,069 89,422 90,478 91,342 92,067 92,686 93,225 93,700 96,514
101 70,097 76,044 81,419 84,156 87,161 89,031 90,389 91,450 92,319 93,047 93,669 94,211 94,686 97,511
102 70,936 76,925 82,333 85,086 88,111 89,992 91,356 92,425 93,297 94,028 94,653 95,197 95,675 98,508
103 71,778 77,806 83,250 86,019 89,061 90,953 92,325 93,397 94,272 95,008 95,636 96,183 96,661 99,506
104 72,619 78,686 84,167 86,953 90,014 91,914 93,294 94,372 95,253 95,989 96,619 97,169 97,650 100,500
105 73,461 79,569 85,081 87,886 90,964 92,875 94,261 95,347 96,231 96,969 97,606 98,156 98,639 101,497
106 74,306 80,453 85,997 88,819 91,917 93,836 95,231 96,319 97,208 97,953 98,589 99,142 99,625 102,494
107 75,150 81,336 86,917 89,753 92,867 94,797 96,200 97,294 98,186 98,933 99,572 100,128 100,614 103,492
108 75,994 82,219 87,833 90,689 93,819 95,761 97,169 98,269 99,164 99,917 100,558 101,114 101,603 104,489
109 76,842 83,103 88,753 91,622 94,772 96,722 98,139 99,244 100,144 100,897 101,542 102,100 102,592 105,483
110 77,689 83,989 89,672 92,558 95,725 97,686 99,108 100,219 101,122 101,881 102,528 103,089 103,581 106,481
111 78,536 84,875 90,589 93,494 96,678 98,650 100,081 101,194 102,103 102,864 103,511 104,075 104,569 107,478
112 79,383 85,761 91,511 94,431 97,631 99,614 101,050 102,169 103,083 103,844 104,497 105,061 105,558 108,475

Abbreviations & definitions
7 ABBREVIATIONS & DEFINITIONS

7.1 ABBREVIATIONS
For other abbreviations, refer to [E3].
BCC Base station Colour Code
Last three bits of BSIC code. The BCC is used to identify one of the
cells sharing the same BCCH frequency. Neighouring cells may, or
may not, have different BCC.
BCCH Broadcast Control CHannel
Common mobile logical channel used for broadcasting system
information on the radio interface
BCF Base Common Function
BDA BSC application database
This database contains all the information objects describing the
BSS.
BDE OMCR operations database
This database contains all the information objects describing the
BSS under OMCR management control, and the objects required
to manage OMCR functionalities
BER Bit Error Rate
Method of measuring the quality of radio link transmission
A ratio of the number of digital errors received in a specified period
to the total number of bits received in the same period. Usually
expressed as a negative exponent, i.e:
106 means one bit error in 106 bits of transmission, or one in a
million
BIFP Base Interface Frontend Processor
Set of BSC functional units managing the interface with BTS
BSC Base Station Controller
BSCB BTS Signalling Concentration Board
Board which concentrates 12 LAPD signalling channels between
BSC and BTS into 3 channels
BSIC Base Station Identity Code
Code used to identify a base station which allows mobile stations to
distinguish the cells sharing the same BCCH frequency. A BSIC is
defined by an (NCC, BCC) combination
BSS Base Station Subsystem
Radio Cellular Network radio subsystem made up of Base Station
Controllers, one or more remote TransCoder Units and one or more
Base Transceiver Stations

BTS Base Transceiver Station
CA Cell Allocation
Radio frequency channel allocated to a cell
CBCH Cell Broadcast CHannel

Logical channel used inside a cell to broadcast short messages in
unacknowledged mode
CC Call Control
Sublevel of layer 3 on the radio interface charged with managing call
processing
CCCH Common Control CHannel

Common bidirectional mobile control channel, used for transmitting
signalling information on the radio interface
CCH Control CHannel

Common or dedicated control channel
CGI Cell Global Identifier

Global identifier of a mobile network cell. The CGI contains the
Location Area Code (LAC), Mobile Country Code (MCC), Mobile
Network Code (MNC) and the cell identifier in the location area
CPU Central Processing Unit

Slave BSC processing unit
CPUMPU/BIFP Central BSC processing unit handling MPU and BIFP functions
dB Decibel Unit of measure of relative power level defined as 10 log10

(P1/P2) where P1 and P2 are the power levels.
dBm Power in dB relative to 1 mW
DCCH Dedicated Control CHannel

Dedicated radio signalling channel with one SDCCH + one SACCH
DLNA Duplexer Low Noise Amplifier

Amplifier installed between BTS and the antenna
DRX Driver and Receiver Unit

Signal processing unit for radio transmission and reception.
DTX Discontinuous Transmission
EIRP Equivalent Isotropic Radiated Power
FACCH Fast Associated Control CHannel

Dedicated signalling channel (Um interface)

4119001036
FCCH Frequency Correction CHannel

Common frequency synchronization channel
FCH Frequency CHannel

Common frequency synchronization channel
FER Frame Erasure Rate
FH Frequency Hopping
FN Frame Number
FP Frame Processor
GSM Global System for Mobile Communications
GSM 900,
GSM 1800,
GSM 1900 Radio Cellular Network standard adapted for the 900 or 1800 or
1900 MHz frequency band.
HO HandOver.
Automatic call transfer implemented between the radio channels of
the same or different cells without interrupting transmission
HSN Hopping Sequence Number
L1M Processor functional unit handling BTS radio measurements
LAC Location Area Code

Code used to identify a location area in the GSM network
LAI Location Area Identity

Geographic identity of a group of cells used to locate a mobile station
LB Link Budget
LNA Low Noise Amplifier, part of DLNA system
MA Mobile Allocation
MAI Mobile Allocation Index
MAIO Mobile Allocation Index Offset
MCC Mobile Country Code
MTBF Minimum Time Between Failure
MEU Masthead Electronics Unit

Minimasthead electronics cabinet. Remote amplifier located
between BTS and the antenna
MHz MegaHertz

MMU Mass Memory Unit (BSC)
MPU Main Processor Unit (BSC)

Set of BSC functional units charged mainly with call processing
functions
MNC Mobile Network Code
Mp Measurement processing
MRC Maximum Radio Combiner
MS Mobile Station
MSC Mobile Services Switching Center
NCC Network Colour Code

First three bits of the BSIC code. Each country is assigned a list of
NCC.
MCL Minimum Coupling Loss
NMC Network Management Centre
NSS Network and Switching SubSystem

Radio Cellular Network subsystem including an MSC, main HLR,
VLR, EIR and AUC
OMC Operation and Maintenance Centre for the radio subsystem
OMCR Operation and Maintenance Centre Radio
OMCS Operation and Maintenance Centre Switching
OMU Central BSC Operation & Maintenance Unit
OSS Operation SubSystem

Radio Cellular Network operations subsystem including the OMCR
and OMCS
PA Power Amplifier
PC Power Control
PCH Paging CHannel

Common subscriber radio paging channel
PLMN Public Land Mobile Network
PSTN Public Switched Telephone Network
RACH Random Access CHannel

Common mobile logical channel, reserved for random access
requests transmitted by mobile stations on the radio interface.

4119001036
RF Radio Frequency
RLC Radio Link Counter
RX BTS receiver
SACCH Slow Associated Control CHannel

Slow logical control channel associated with a traffic channel during
a communication
SAM Smart Antenna Module
SCH Synchronization CHannel

Common time division synchronization channel
SCSI Small Computer System Interface

Interface between the MMU board containing the BSC hard disk and
its CPUOMU management unit
SDCCH Standalone Dedicated Control CHannel

Dedicated radio signalling channel temporarily allocated during call
set up. There are 2 types of SDCCH : SDCCH/8 and SDCCH/4, on
which the logical channels are grouped by 8 and by 4 respectively
and combined with CCH
SFH Slow Frequency Hopping
SICD Serial Interface Controller LAPD

BSC board controller for Abis and Ater Interface
SUP SUPervision unit

Functional BSC monitoring unit
SWC SWitching matrix Controller (BSC 6000)
TCH Traffic CHannel

Radio traffic channel
TCH/F Traffic CHannel/Full rate
TCH/H Traffic CHannel/Half rate
TDMA Time Division Multiple Access

Abbreviation used to designate a transmission frame on the radio
interface, divided into eight time slots (TS) or channels
TA Timing Advance
Alignment process designed to compensate propagation time
between a mobile and base station
TRX Transmission/reception subsystem of the BTS

TS Time Slot
TSCB Transcoder Signalling Concentration Board (BSC)

Board which concentrates LAPD signalling channels between BSC
and TCU into a single channel
TX BTS transmitter
7.2 DEFINITIONS
Erlang Unit of telecommunications traffic intensity
The number of erlangs represents the average number of resources
or circuits occupied during the peak traffic hour
Handover Automatic call transfer between two radio channels
MTBF It is a mathematical time expectancy between two successive parts

of equipment or unit failure
Radio interface Interface between the mobile station (MS) and the BTS
Timing Advance delay used to compensate propagation time between mobile and
base station
Uminterface See Radio interface

4119001036
Index of parameters
A
accessClassCongestion, 373
adjacent cell umbrella ref, 388
allocPriorityTable, 373
allocPriorityThreshold, 374
allocPriorityTimers, 375
allocWaitThreshold, 376
allOtherCasesPriority, 377
answerPagingPriority, 377
assignRequestPriority, 378
Attenuation, 361
averagingPeriod, 398
B
baseColourCode, bts, 3130
biZonePowerOffset
adjacentHandOver, 324
handOverControl, 325
bscHopReconfUse, 3118
bscMSAccessClassBarringFunction, 379
bscQueueingOption, 379
bsMsmtProcessingMode, 361
bsPowerControl, 362
bssMapT1, 3104
bssMapT12, 3104
bssMapT13, 3104
bssMapT19, 3105
bssMapT20, 3105
bssMapT4, 3106
bssMapT7, 3106
bssMapT8, 3106
bssMapTchoke, 3107
bssSccpConnEst, 3107
bsTxPwrMax, 362
bts time between HO configuration, 326
btsHopReconfRestart, 3118
btsIsHopping, 3119
btsMSAccessClassBarringFunction, 380
btsThresholdHopReconf, 3120
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page i

Index of parameters
C
callClearing, 356
callReestablishment, 39
callReestablishmentPriority, 380
cellAllocation, 3120
cellBarQualify, 381
cellBarred, 381
cellDeletionCount, 320
cellDtxDownLink, 3129
cellReselectHysteresis, 33
cellReselectOffset, 33
cellReselInd, 34
cellType
adjacentCellHandOver, 354
bts, 354
channelType, 381
concentAlgoExtMsRange, 393
concentAlgoExtRxLev, 393
concentAlgoIntMsRange, 394
concentAlgoIntRxLev, 395
concentric cell, 396
cpueNumber, 3130
D
delayBetweenRetrans, 3113
directedRetry, 388
directedRetryModeUsed, 389
directedRetryPrio, 389
distHreqt, 322
distWtsList, 322
dtxMode, 3129
E
early classmark sending, 3126
emergencyCallPriority, 382
enhancedTRAUFrameIndication, 3133
extended cell, 356
F
fhsRef, 3121
forced handover algo, 326
Page ii PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
Index of parameters
H
HandOver from signalling channel, 327
hoMargin, 327
hoMarginBeg, 328
hoMarginDist, 329
hoMarginRxLev, 329
hoMarginRxQual, 331
hoMarginTiering, 3136
hoMarginTrafficOffset, 331
HOPingpongCombination, 332
HOPingpongTimeRejection, 334
hoppingSequenceNumber, 3121
HOSecondBestCellConfiguration, 335
hoTraffic
bsc, 336
bts, 336
I
interBscDirectedRetry, 390
interBscDirectedRetryFromCell, 390
interCellHOExtPriority, 382
interCellHOIntPriority, 383
interferenceType, 3136
intraBscDirectedRetry, 391
intraBscDirectedRetryFromCell, 391
intraCell, 345
intraCellHOIntPriority, 384
intraCellQueueing, 384
intraCellSDCCH, 346
L
lapdTerminalNumber, 3124
lRxLevDLH, 349
lRxLevDLP, 363
lRxLevULH, 349
lRxLevULP, 364
lRxQualDLH, 350
lRxQualDLP, 364
lRxQualULH, 351
lRxQualULP, 365
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page iii

Index of parameters
M
maio, 3122
maxNumberRetransmission, 3113
measurementProcAlgorithm, 3130
microCellCaptureTimer, 355
microCellStability, adjacentCellHandOver, 355
minNbOfTDMA, 384
missDistWt, 323
missRxLevWt, 316
missRxQualWt, 313
mobileAllocation, 3122
modeModifyMandatory, 392
msBtsDistanceInterCell, 358
msRangeMax, 357
msTxPwrMax, 337
msTxPwrMax2ndBand, 366
msTxPwrMaxCCH, 34
msTxPwrMaxCell, 337
multi band reporting, 3126
N
nbLarge Reuse Data Channels, 3136
nbOfRepeat, 3114
new power control algorithm, 366
noOfBlocksForAccessGrant, 3114
noOfMultiframesBetweenPaging, 3115
notAllowedAccessClasses, 385
numberOfPwciSamples, 3137
numberOfSlotsSpreadTrans, 3116
numberOfTCHFreeBeforeCongestion, 385
numberOfTCHFreeToEndCongestion, 386
numberOfTCHQueuedBeforeCongestion, 386
numberOfTCHQueuedToEndCongestion, 386
O
offsetLoad, 338
offsetPriority, 339
otherServicesPriority, 387
Page iv PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
Index of parameters
P
pagingOnCell, 3116
pcmErrorCorrection, 3133
penaltyTime, 35
powerBudgetInterCell, 339
powerControlIndicator, 367
powerIncrStepSize, 367
powerRedStepSize, 368
preSynchroTimingAdvance, 359
priority, 387
processorLoadSupConf, 3124
pwciHreqave, 3137
R
radChanSelIntThreshold, 398
radioLinkTimeOut, 39
radResSupBusyTimer, 3102
radResSupervision, 3102
radResSupFreeTimer, 3103
retransDuration, 3116
rlf1, 311
rlf2, 312
rlf3, 312
rndAccTimAdvThreshold, 359
runCallClear, 360
runHandOver, 339
runPwrControl, 368
rxLevAccessMin, 36
rxLevDLIH, 346
rxLevDLPBGT, 353
rxLevHreqave, 316
rxLevHreqaveBeg, 317
rxLevHreqt, 318
rxLevMinCell, 340
rxLevNCellHreqaveBeg, 321
rxLevULIH, 347
rxLevWtsList, 318
rxNCellHreqave, 320
rxQualDLIH, 347
BSS PARAMETERS USER GUIDE GSM/BSS V12 Page v

Index of parameters
rxQualHreqave, 313
rxQualHreqt, 314
rxQualULIH, 348
rxQualWtsList, 315
S
selfTuningObs, 3138
siteGsmFctList, 3131
standard indicator AdjC
adjacentCellHandOver, 3127
adjacentCellReselection, 3128
synchronized, 343
T
t3101, 3108
t3103, 3108
t3107, 3109
t3109, 3110
t3111, 3111
t3122, 3111
temporaryOffset, 37
thresholdInterference, 3100
timeBetweenHOConfiguration, 343
timerPeriodicUpdateMS, 3112
traffic PCM allocation priority, 3123
U
uplinkMappingChannelNumber, 3134
uplinkMappingFreq, 3134
uplinkMappingMeasurementMode, 3135
uplinkMappingProcessingMode, 3135
uplinkPowerControl, 369
uRxLevDLP, 369
uRxLevULP, 370
uRxQualDLP, 370
uRxQualULP, 371
Z
zone Tx power max reduction, 397
Page vi PE/DCL/DD/0036 Standard 12.01/EN January 2000

4119001036
Nortel Networks Wireless Solutions
BSS PARAMETERS USER GUIDE
Copyright 19962000 Nortel Matra Cellular and Nortel Networks,

All Rights Reserved
NORTEL NETWORKS AND NORTEL MATRA CELLULAR

CONFIDENTIAL:
The information contained in this document is the property of Nortel

Networks and/or Nortel Matra Cellular. Except as specifically authorized
in writing by Nortel Networks and Nortel Matra Cellular, the holder of this
document shall keep the information contained herein confidential and
shall protect same in whole or in part from disclosure and dissemination For more information, please contact:
to third parties and use for evaluation, operation and maintenance
purposes only.
For all countries, except USA:
You may not reproduce, represent, or download through any means, the Documentation Department
information contained herein in any way or in any form without prior 1, Place des Frres Montgolfier
written consent of Nortel Networks and Nortel Matra Cellular. GUYANCOURT
The following are trademarks of Nortel Networks Corporation: NORTEL, 78928 YVELINES CEDEX 9
NORTEL NETWORKS, the NORTEL NETWORKS corporate logo, the FRANCE
NORTEL Globemark, HOW THE WORLD SHARES IDEAS. Email : gsmntp@nortelnetworks.com
All other brand and product names are trademarks or registred Fax : (33) (1) 39445029
trademarks of their respective holders.
In the USA:
Publication Reference
PE/DCL/DD/036 4119001036 2221 Lakeside Boulevard
12.01/EN Richardson TX 75082
January 2000 USA
Printed in France Tel: 18004 NORTEL
18004667838 or (972) 6845935
Internet Address:
http://www.nortelnetworks.com

BPUG Extv12

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BPUG Extv12

Загружено:

Авторское право:

Доступные форматы

Wireless Service Provider Solutions

BSS Parameters User Guide

Wireless Service Provider Solutions

NORTEL NETWORKS AND NORTEL MATRA CELLULAR CONFIDENTIAL:

SYSTEM RELEASE : GSM/BSS V12

SYSTEM RELEASE : GSM/BSS V11

SYSTEM RELEASE : GSM/BSS V10

SYSTEM RELEASE : GSM/BSS V09

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE GSM/BSS V12 Page iii

Confidential information may not be copied or disclosed without permission

Page iv PE/DCL/DD/0036 Standard 12.01/EN January 2000

ABOUT THIS DOCUMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

AUDIENCE FOR THIS MANUAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

RELATED DOCUMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

Applicable documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

DOCUMENT STRUCTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . XVII

1 CLASSIFICATION OF BSS PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.1 GROUPS OF BSS PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3 PARAMETERS INFORMATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4 PARAMETERS VERSUS BSS FEATURES AND PROCEDURES . . . . . . . . . . . . . . . . 19

2.2 CONVENTIONS & UNITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.2 Phase 2 BTS and MS maximum transmitting output powers . . . . . . . . . . . . . . . . . . . . . . 22

2.2.3 GSM Products sensitivity and power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.2.4 Conversion rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.5 Accuracy related to measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.6 Frequency band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.3 SELECTION, RESELECTION ALGORITHMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE GSM/BSS V12 Page v

2.3.3 C2 additional reselection criterion (for phase 2) (Sel_3) . . . . . . . . . . . . . . . . . . . . . . . . . . 211

2.4 MEASUREMENT PROCESSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

2.4.1 Mp_1: Measurement processing (run by the BTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214

2.4.3 Missing Downlink Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218

2.5 DIRECT TCH ALLOCATION & HANDOVER ALGORITHMS . . . . . . . . . . . . . . . . . . . . . 226

2.5.1 General formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226

2.5.2 Direct TCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227

2.5.3 Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228

2.5.4 HandOver decision priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229

2.5.5 Directed Retry Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231

2.5.6 Concentric/Dualcoupling/Dualband cell Handover (Ho_3) . . . . . . . . . . . . . . . . . . . . . . . . 232

2.5.7 Rescue Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235

2.5.8 Power Budget Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

2.5.9 Handover for traffic reasons (from V12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

2.5.11 Automatic cell tiering (from V12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

2.5.12 Microcellular Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

2.5.13 Forced Handover (Ho_10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

2.5.14 Early HandOver Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248

2.5.15 Maximum RxLev for Power Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

2.5.16 Presynchronized HO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

2.5.17 Radio channel allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252

Confidential information may not be copied or disclosed without permission

Page vi PE/DCL/DD/0036 Standard 12.01/EN January 2000

2.5.20 Protection against RunHO=1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

2.5.21 General protection against HO pingpong (from V12) . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

2.6 HANDOVER ALGORITHMS ON THE MOBILE SIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . 258

2.7 POWER CONTROL ALGORITHMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259

2.7.2 One shot power control (Pc_2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 260

2.7.3 Fast power control at TCH assignment (Pc_3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

2.7.4 Power control on mobile side (Pc_4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

2.8 TCH ALLOCATION MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264

2.8.1 TCH Allocation and Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264