BSS Parameter User's Guide V12

Wireless Service Provider Solutions
BSS Parameters User Guide

PE/IRC/APP/0037 05.02/EN Approved January 2000
< 37 >
: BSS Parameters User Guide
Wireless Service Provider Solutions
BSS Parameters User Guide

Document number: PE/IRC/APP/0037 Document status: Approved Document issue: 05.02/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 05.02/EN Modifications after Review December 1999 Issue 05.01/EN Modifications after Review

September 1999 Issue 04.03/EN Modifications after Review April 1999 Issue 04.02/EN Modifications after Review March 1999 Issue 04.01/EN Modifications after Review

June 1998 Issue 03.01/EN Modifications after Review
Confidential information may not be copied or disclosed without permission
BSS PARAMETERS USER GUIDE
GSM/BSS V12
Page iii
Publication History

March 1998 Issue 02.03/EN Modifications after Review January 1998 Issue 02.02/EN Modifications after Review August 1997 Issue 02.01/EN Modifications after ReviewSYSTEM release : gsm/bss V01 August 1997 Issue 01.03/EN Modifications after Review November 1996 Issue 01.02/EN Creation by Algorithm Working Group Former versions document obsolete BSS system versions. Therefore, the publication history is not applicable.
Page iv
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Table of contents
ABOUT THIS DOCUMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

PRESENTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AUDIENCE FOR THIS MANUAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PREREQUISITES FOR USE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applicable documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reference documents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DOCUMENT STRUCTURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
XVII
XVII XVII XVII xvii xvii XX
1
1.1 1.2 1.3 1.4
CLASSIFICATION OF BSS PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . .

GROUPS OF BSS PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROCESS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PARAMETERS INFORMATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PARAMETERS VERSUS BSS FEATURES AND PROCEDURES . . . . . . . . . . . . . . . .
11
11 12 13 19
2
2.1 2.2 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.3 2.3.1 2.3.2
ALGORITHMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CONVENTIONS & UNITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Phase 2 BTS and MS maximum transmitting output powers . . . . . . . . . . . . . . . . . . . . . . GSM Products sensitivity and power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conversion rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accuracy related to measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frequency band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SELECTION, RESELECTION ALGORITHMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selection or reselection between cells of current Location Area (Sel_1) . . . . . . . . . . . . Criteria for reselection towards a cell of a different Location Area (Sel_2) . . . . . . . . . . .
21
21 21 21 22 23 27 28 29 210 210 211
GSM/BSS V12
Page v
Table of contents
2.3.3 2.4 2.4.1 2.4.2 2.4.3 2.5 2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7 2.5.8 2.5.9 2.5.10 2.5.11 2.5.12 2.5.13 2.5.14 2.5.15 2.5.16 2.5.17 2.5.18 2.5.19
C2 additional reselection criterion (for phase 2) (Sel_3) . . . . . . . . . . . . . . . . . . . . . . . . . . MEASUREMENT PROCESSING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mp_1: Measurement processing (run by the BTS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mp_2: Measurement processing in dedicated mode (run by the MS) . . . . . . . . . . . . . . . Missing Downlink Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DIRECT TCH ALLOCATION & HANDOVER ALGORITHMS . . . . . . . . . . . . . . . . . . . . . General formulas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Direct TCH Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HandOver decision priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directed Retry Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concentric/Dualcoupling/Dualband cell Handover (Ho_3) . . . . . . . . . . . . . . . . . . . . . . . . Rescue Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power Budget Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handover for traffic reasons (from V12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Handover decision according to adjacent cell priorities and load (from V12) . . . . . . . . Automatic cell tiering (from V12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Microcellular Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forced Handover (Ho_10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Early HandOver Decision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maximum RxLev for Power Budget . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Presynchronized HO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio channel allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Define eligible neighbor cells for intercell handover (except directed retry) (Ho_11) . . Handover to 2nd best candidate when return to old channel (Ho_12) . . . . . . . . . . . . . .
211 214 214 218 218 226 226 227 228 229 231 232 235 237 237 240 241 244 248 249 252 252 253 254 255
Page vi
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Table of contents
2.5.20 2.5.21 2.6 2.7 2.7.1 2.7.2 2.7.3 2.7.4 2.8 2.8.1 2.8.2 2.8.3 2.8.4 2.8.5 2.8.6 2.8.7 2.8.8 2.8.9 2.9 2.9.1 2.9.2 2.9.3 2.9.4 2.10 2.10.1
Protection against RunHO=1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General protection against HO pingpong (from V12) . . . . . . . . . . . . . . . . . . . . . . . . . . . HANDOVER ALGORITHMS ON THE MOBILE SIDE . . . . . . . . . . . . . . . . . . . . . . . . . . . POWER CONTROL ALGORITHMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power control performed by the BTS (Step by step) (Pc_1) . . . . . . . . . . . . . . . . . . . . . . . One shot power control (Pc_2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fast power control at TCH assignment (Pc_3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power control on mobile side (Pc_4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCH ALLOCATION MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCH Allocation and Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Queueing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Barring of access class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio link failure process (run by the MS) (Rlfms) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio link failure process (run by the BTS) (Rlfbs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Call reestablishment procedure (Cr) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Call Clearing Process (run by BTS) (Cc) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Interference Management (BTS and BSC) (If) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DTX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PCH AND RACH CHANNEL CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paging command Process (Pag) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paging command repetition process (run by BTS) (Pag_rep) . . . . . . . . . . . . . . . . . . . . . Request access command process (RA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Request access command repetition process (RA_rep) . . . . . . . . . . . . . . . . . . . . . . . . . . FREQUENCY HOPPING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frequency hopping principles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
256 256 259 260 260 261 262 263 265 265 269 276 280 280 281 282 282 283 289 289 294 295 295 298 298
GSM/BSS V12
Page vii
Table of contents
2.10.2 2.10.3 2.10.4 2.11 2.11.1 2.11.2 2.12 2.12.1 2.12.2 2.12.3 2.13 2.13.1 2.13.2 2.14 2.15 2.15.1 2.15.2 2.16 2.16.1 2.16.2 2.16.3 2.17 2.17.1 2.17.2 2.17.3
Main benefits of frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Synthesised frequency hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Baseband Frequency Hopping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BSC OVERLOAD MANAGEMENT MECHANISMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mechanism up to V.11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mechanism defined from V12 on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CABINET OUTPUT POWER SETTING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cabinet power description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pr computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ps computation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DUAL BAND HANDLING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiband mobile station . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on existing procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INTERFERER CANCELLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPU/BIFP LOAD SHARING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feature principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer/service provider benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXTENDED CCCH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customer/service provider benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feature functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Counters used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PCM ERROR CORRECTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feature principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Feature benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Parameters and counters associated with this feature . . . . . . . . . . . . . . . . . . . . . . . . . . .
298 299 2100 2103 2103 2110 2116 2116 2117 2119 2122 2122 2123 2126 2128 2128 2128 2129 2129 2129 2130 2131 2131 2132 2132
Page viii
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Table of contents
2.18 2.18.1 2.18.2
UPLINK MAPPING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Main benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2133 2133 2136
3
3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20
ALGORITHM PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CELL SELECTION AND RESELECTION PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . RADIO LINK FAILURE PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIGNAL QUALITY AVERAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SIGNAL STRENGTH AVERAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . NEIGHBOR CELL AVERAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DISTANCE AVERAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HANDOVER (GLOBAL) PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INTRACELL HANDOVER PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INTERCELL HANDOVER THRESHOLDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HANDOVER FOR MICROCELLULAR NETWORK PARAMETERS . . . . . . . . . . . . . . . DISTANCE MANAGEMENT PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . POWER CONTROL PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCH ALLOCATION MANAGEMENT PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . DIRECTED RETRY HANDOVER PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CONCENTRIC CELLS PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INTERFERENCE LEVEL PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RADIO RESOURCES CONTROL AT CELL LEVEL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BSS TIMERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PAGING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
31 33 39 314 317 321 323 325 346 350 355 358 363 375 390 395 3100 3104 3106 3115
GSM/BSS V12
Page ix
Table of contents
3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29
FREQUENCY HOPPING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BSC LOAD MANAGEMENT PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DUAL BAND PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DTX PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MISCELLANEOUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . INTERFERER CANCELLATION PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PCM ERROR CORRECTION PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . UPLINK MAPPING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CELL TIERING PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3120 3126 3128 3131 3132 3135 3136 3138 3141
4
4.1 4.2 4.3 4.4 4.4.1 4.4.2 4.5 4.6 4.7 4.8 4.9 4.10 4.11 4.12
ENGINEERING ISSUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
HOW TO OPTIMIZE POWER CONTROL USE? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ONESHOT POWER CONTROL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MINIMUM TIME BETWEEN HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DIRECTED RETRY HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directed Retry and TCH reserved for Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Directed Retry benefit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CONCENTRIC CELLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IMPACT OF DTX ON AVERAGING . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BEST NEIGHBOR CELLS STABILITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TCH ALLOCATION GENERAL RULES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GENERAL RF RULES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DIFFERENCE BETWEEN UPLINK AND DOWNLINK LEVELS . . . . . . . . . . . . . . . . . . . EXPLANATION OF PEAK APPEARANCE IN RXLEV_UL DISTRIBUTION . . . . . . . .
41
41 42 44 49 49 411 416 426 427 428 429 430 431
EFFECTS OF NOOFMULTIFRAMESBETWEENPAGING ON MOBILE BATTERIES AND RESELECTION REACTIVITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435 EFFECTS OF SMSCB USE ON NOOFBLOCKSFOR ACCESSGRANT . . . . . . . . . IMPACT OF THE AVERAGING ON THE HANDOVERS . . . . . . . . . . . . . . . . . . . . . . . . . Global statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 438 441 441
4.13 4.14 4.14.1
Page x
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Table of contents
4.14.2 4.14.3 4.15 4.15.1 4.15.2 4.15.3 4.16 4.16.1 4.16.2 4.16.3 4.17 4.18 4.19 4.19.1 4.19.2 4.19.3 4.19.4 4.19.5 4.20 4.20.1 4.20.2 4.21 4.21.1 4.21.2 4.22 4.22.1
Study of reactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ping pong vs Reactivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IMPACT OF CALL REESTABLISMENT ON THE NETWORK . . . . . . . . . . . . . . . . . . . Impact on capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Impact on call drops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Call Reestablishment synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . FREQUENCY SPACING BETWEEN TWO TRXS OF THE SAME AREA . . . . . . . . . . No frequency hopping case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frequency hopping case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Summary for the frequency spacing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LINK BUDGET (LB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MINIMUM COUPLING LOSS (MCL) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GENERAL RULES FOR SYNTHESISED FREQUENCY HOPPING . . . . . . . . . . . . . . . Nortel choice between Baseband and Synthesised Frequency hopping . . . . . . . . . . . . Fractional frequency load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maximum TRX configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SFH parameter setting for 1:1 pattern: strategy 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SFH parameter setting for 1:3 pattern: Strategy 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BSC BOARDS MANAGEMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SICD boards management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BSCB boards management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DUAL BAND NETWORKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How to favour a frequency band? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How not to favour a frequency band? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MICROCELL BENEFITS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Microcell benefits according to cell radius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
443 445 446 446 446 448 450 450 451 451 452 456 458 458 461 462 463 468 478 478 481 482 482 485 487 487
GSM/BSS V12
Page xi
Table of contents
4.22.2 4.23 4.24 4.24.1 4.24.2 4.24.3 4.24.4 4.24.5 4.25 4.25.1 4.25.2 4.25.3 4.26 4.26.1 4.26.2 4.26.3 4.27 4.27.1 4.27.2 4.27.3 4.27.4 4.28 4.28.1 4.28.2 4.28.3
Microcell benefits in terms of Quality Of Service (QOS) : . . . . . . . . . . . . . . . . . . . . . . . . . INTERFERER CANCELLATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SETUP PRINCIPLES OF A NEIGHBORING LIST AND A BCC PLAN . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4/12 reuses pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1:3 and 1:1 Fractional reuse pattern specific case. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . HandOver list versus Reselection list. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setup principles of a BSIC plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SENSITIVITY CALCULATION FOR BTS USING DLNA EQUIPMENT . . . . . . . . . . . . . Configuration without a DLNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration with a DLNA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RxLev and RxQual measurements at BTS level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . STREET CORNER ENIRONMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Case A: Mobile moving straight . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Case B: Mobile turning at the cross road . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SYNCHRONIZED HO VERSUS NOT SYNCHRONIZED HO . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OMCR Parameter settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timing HO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BTS SENSITIVITY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Definition of Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Static and Dynamic Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Typical / Guaranteed Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
487 488 489 489 489 493 495 495 497 497 498 499 4101 4101 4102 4103 4105 4105 4105 4106 4112 4113 4113 4114 4114
Page xii
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Table of contents
4.28.4 4.28.5 4.29 4.29.1 4.29.2 4.29.3 4.29.4 4.30 4.30.1 4.30.2 4.30.3 4.30.4 4.31 4.31.1 4.31.2 4.31.3 4.32 4.32.1 4.32.2 4.33 4.33.1 4.33.2 4.33.3 4.34 4.34.1
Space diversity gains . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Crosspolarization antenna use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CIRCULAR POLARISED CROSSPOLAR ANTENNAS PERFORMANCES . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDCCH DIMENSIONING AND TDMA MODELS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDCCH Dimensioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SDCCH distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TDMA Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PCM Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ENGINEERING GUIDELINES FOR EXCEPTIONAL EVENTS . . . . . . . . . . . . . . . . . . . BSS: Prerequisite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BSS: Suggestions for parameters to be modified for the special event . . . . . . . . . . . . . NSS level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ENGINEERING LIMITS WITH BSC OVERLOAD CONTROL MECHANISM . . . . . . . . What does the CPU Engineering limit mean ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . What does the CPU Call Processing limit mean ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . POWER CONTROL COMPENSATION IN INTERZONE HANDOVER . . . . . . . . . . . . . Dualband cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Concentric cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dualcoupling cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CELL TIERING GAIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4115 4115 4119 4119 4119 4119 4121 4122 4122 4124 4125 4126 4127 4127 4129 4130 4134 4135 4135 4138 4138 4142 4142 4144 4144
GSM/BSS V12
Page xiii
Table of contents
4.34.2 4.34.3 4.34.4 4.34.5
Simulations results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gain estimation based on terrain data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Capacity gain estimation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4144 4146 4147 4149
5
5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10
APPENDIX A: MAIN EXCHANGE PROCEDURES AT BSC LEVEL . . . .

PROC_1: ESTABLISHMENT PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC_2: CHANNEL MODE PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC_3: DEDICATED CHANNEL ASSIGNMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC_4: INTRACELL HANDOVER PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC_5: INTRABSS HANDOVER PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC_6: INTERBSS HANDOVER PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROC_7: RESOURCE RELEASE PROCEDURE (EXAMPLE) . . . . . . . . . . . . . . . . . . . PROC_8: SACCH DEACTIVATION PROCEDURE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CASE OF MOBILE TERMINATING CALLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CASE OF MOBILEINITIATING CALLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
51 52 53 54 55 56 57 58 59 510
ERLANG TABLE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
7
7.1 7.2
ABBREVIATIONS & DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ABBREVIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
71 76
Page xiv
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
List of figures
FIGURE 21 FIGURE 22 FIGURE 23 FIGURE 24 FIGURE 25 FIGURE 41 FIGURE 42 FIGURE 43 FIGURE 44 FIGURE 45 FIGURE 46 FIGURE 47 FIGURE 48
MICROCELLULAR TYPE A HO ALGORITHM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CASE OF PHASE 1 MOBILES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CASE OF PHASE 2 MOBILES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BASE BAND FREQUENCY HOPPING MECHANISM . . . . . . . . . . . . . . . . . . . . . . POWER IN CABINET DESCRIPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MICROMICRO HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXAMPLE OF A CROSSROAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PROBLEM OF FIELD VARIATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MICROMACRO HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MACROMACRO HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OMNIDIRECTIONAL SITES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . TRISECTORIAL DIRECTIONAL SITES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . COLLISION BETWEEN PAGING AND SMSCB IF NOOFBLOCKSFORACCESSGRANT = 0. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . EXAMPLE OF AGCH AND CBCH COLLISION WITH NOOFBLOCKSFORACCESSGRANT = 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . REPARTITION OF THE HO FOR EACH SET OF PARAMETERS . . . . . . . . . . . . SIMULATION FOR A MS WITH A 1 KM/H SPEED CDF: CUMULATIVE DISTRIBUTION FUNCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MEAN CPU OCCUPANCY BEHAVIOUR FOR ANY GIVEN BOARD OF THE BSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
247 296 296 2101 2116 44 45 45 46 47 416 417
439
FIGURE 49
440 442
FIGURE 410 FIGURE 411
460
FIGURE 412
4134
GSM/BSS V12
Page xv
List of tables
TABLE 21 TABLE 22 TABLE 23 TABLE 24 TABLE 25 TABLE 41 TABLE 42
TIMER RANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PR VS BSTXPWRMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BSTXPWRMAX VS BTS TYPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S8000 OUTDOOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . S8000 INDOOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPU ENGINEERING LIMIT VALUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPU CALL PROCESSING LIMIT VALUES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
297 2117 2119 2121 2121 4135 4136
Page xvi
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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. For parameters related to Piconode or GPRS, refer to the specific BPUG addenda. PND/DCL/DD/0023 BSS Parameters User Guide for PicoNode V01.01/EN PE/IRC/APP/0119 BSS Parameters User Guide for GPRS V01.01/EN
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] [E2] [E3]
PE/SYS/DD/0065 Configuration parameters for BSS PE/DCL/DD/07 BSS Operating Principles Vol 7 Section #4 PE/DCL/DD/00 BSS Product Documentation Overview
Approved Internal NMC documents:
[I1]
PE/BTS/DD/0421 V2 SFS of BTS: Measurement Processing (V11)
GSM/BSS V12
Page xvii
About this document
[I4] [I5] [I6] [I7] [I8] [I9] [I10] [I11] [I12] [I13] [I14] [I15] [I16] [I17] [I18] [I19] [I20] [I21]
PE/SYS/DPL/0054 Feature list V11 written by P.Vincent PE/SYS/DJD/288 V1.02 NMC GSM/DCS/PCS systems performances by T.Billon Cellular
PE/IRC/APP/34 V1.1 NMC Link Budget V3.00 User guide by F.Miran PE/IRC/INF/0009 V1.1 InCar penetration written by M.Le Bozec PE/IRC/APP/30 V1.03. Engineering changes definition by M.Lionti (V8) PE/IRC/APP/48 V1.02. Engineering changes definition by L.Jullien (V9) IRC/97/12/38/EV Peaks in the RxLev_UL distribution each 3 dB by E. Van Haetsdaele MPC/SYS/DD/0013 Double Allocation Calculation V01.03 by G. duCrest MPC/IRC/INF/0012 J. T. Dollfus TXINTEGER impact V01.02 by
Memo IV.BSS/INT/DBR/97/322 Restrictions des fonctions TMG V9 by D. Bressanelli Memo IRC/97/06/012/PM, L1M simulations for Mandarin using the engg tool MASTER by P. Marty and F. Guitard NB/BSS/DJD/0007, Concentric Cell Feature test on the China UNICOM GSM 900 Network in NingBo by M. Jiang PE/IRC/INF/0007: Nortel Base Station Configurations and Link Budget Parameters Equipment
PE/IRC/INF/0010: Link Budget parameters for GSM DCS and PCS PE/IRC/APP/0015: BSC/TCU Engineering Information by B. Vanheeghe PE/BSC/INF/0083: Management of traffic overload at the BSC PE/IRC/INF/0013: SICD load engineering information by D. Meissonnier GDC/IRC/PENG/96/0104/PBO: M. de Langlade & P. Boulet SICD Overload by
Page xviii
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
About this document
[I22] [I23] [I24] [I25] [I26] [I27] [I28] [I29] [I30] [I31]
COP/IRC/98/03/00: Etude sur la charge BSCB by S. Colmano & A. de Lannoy GDC/BYT97/RP/F/1452: Feature FM691 Overload SICD by R. Pavkovic GDC/BYT97/KH/DIV/1701: BSC capacity by Kim Huynh PE/BSC/DJD/0142: BSS Performances Analyses PE/IRC/DD/0012: Engineering Rules For Frequency Hopping by S. Le Grat GDC/BYT97/KH/DIV/1333 IWG_answers_to_FX.NMC.LDM.DIV.055A970724 Mmo NMC/PENG/98/172/YM V1.02 : DLU Management for S8000 by Y. Maurin PE/BSS/INF/062: Management of BTS output power in BSS System by V. Cardoso PE/IRC/DD/0018: Circular polarised crosspolar antennas performances COP/IRC/NED/ES/1999010001/OL : Engineering Support Bulletin Proposal of a set of engg guidelines for exceptional events. Memo PVM/CD/98/VO/299/ME: C. Daoud Timing HOV11.0 by
[I32] [I33] [I34] [I35]
PE/IRC/APP/0078: V12 Feature Engineering Information by S. Luong PE/SYS/DJD/450: Optimisation fractionnaire by D. Vijcic des motifs charge
NMC/PENG/99/049/JCHM: Memo Description of the filter algorithm of the feature FM877 BSC Overload Management by JC. Monceau NMC/PENG/99/050/BVA: Memo CPU Engineering Limit versus CPU Call Processing limit BSC concept by B. Vanheeghe PE/SYS/DD/279: Functional Note: Automatic Cell Tiering by T. Rousseau PE/BTS/DD/1250: FF Dual band cell management in the BTS by D. Michenaud
[I36]
[I37] [I38]
GSM/BSS V12
Page xix
About this document
[I39]
PE/SYS/APP/230: Engineering exceptional events
recommendations
for
Documents of the Working Groups Algorithm & System Further information is available at: <http://136.147.68.68/ned/ND_AE/AE/index.html>) in the Working Group Deliverables
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. 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 xx
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Classification of BSS parameters
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: Concent_HO: Dist_ave: Dist_mgt: DRetry_HO: Dual_band: Freq_Hop: Global_HO: inter_HO: Interf_lev.: intra_HO: Lev_ave: micro_HO: Nei_ave: Pwr_Ctrl: Paging: Qual_ave: RR_Ctrl: Res_alloc: Rlink_fail: Selection: Cell_Tiering: Traffic_HO: Data_Trsf: parameters related to BSS timers parameters related to HO in Concentric cells parameters related to distance averaging parameters related to distance management parameters related to directed Retry HandOver parameters related to dual band parameters related to frequency hopping parameters related to HandOver (Global) parameters related to inter cell HandOver parameters related to Interference level parameters related to intra cell HandOver parameters related to signal strength averaging parameters related to HandOver for microcellular network parameters related to neighbor cell averaging parameters related to Power control parameters related to paging channels parameters related to signal quality averaging parameters related to radio resources control at cell level parameters related to resource allocation parameters related to Radio link failure parameters related to cell selection or reselection parameters related to Automated Cell Tiering parameters related to handover for traffic reasons parameters related to data transfer
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: Pc: Pag: Ho: Cc: Mp: If: Rlf: All: Selection process Power control process Paging process HO decision process Call clearing process Measurement process Interference level management process Radio link failure process Ressources allocation process
Furthermore, one process can be distributed among the different subsystems of the GSM system.
Page 12
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 name
accesClassCongestion adjacentCellUmbrellaRef allocPriorityTable allocPriorityThreshold allocPriorityTimers allocWaitThreshold allOtherCasesPriority answerPagingPriority assignRequestPriority Attenuation averagingPeriod baseColorCode biZonePowerOffset bscHopReconfUse
bscMSAccessClassBarringFunction
From version
V9 V9 V7 V7 V7 V7 V7 V7 V7 V9 V7 V7 V12 V8 V9 V7 V7 V7 V7 V7 V7 V7 V7 V7 V7 V7 V7 V7 V7 V9 + V12 V8 V7 V9 V8 bts bts bts bts bts bts bts bts bts
Object
Group
Res_alloc DRetry_HO Res_alloc Res_alloc Res_alloc Res_alloc Res_alloc Res_alloc Res_alloc Pwr_Hop Interf_lev
Process MS BSS MSC

Sel Ho All All All All All All All If
btsSiteManager handOverControl bts adjacentCellHandover, handOverControl bsc bsc signallingPoint bts powerControl signaling Point bsc bsc bsc bsc bsc bsc bsc bsc bsc powerControl bts bts bts bts bts
Frq_Hop Res_alloc Res_alloc Pwr_Ctrl Pwr_Ctrl BSS_timers BSS_timers BSS_timers BSS_timers BSS_timers BSS_timers BSS_timers BSS_timers Global_HO Pwr_Ctrl Global_HO Freq_Hop Freq_Hop Res_alloc Freq_Hop All Pc Ho Pc All All
bscQueueingOption bsMsmtProcessingMode bsPowerControl bssSccpConEst bssMapT1 bssMapT12 bssMapT13 bssMapT19 bssMapT20 bssMapT4 bssMapT7 bssMapT8 bssMapTchoke bsTxPwrMax
bts time between HO configuration
btsHopReconfRestart btslsHopping
btsMSAccessClassBarringFunction
btsTresholdHopReconf
GSM/BSS V12
Page 13
Parameters name
callClearing callReestablishment callReestablishmentPriority cellAllocation cellBarQualify cellBarred cellDeletionCount cellDtxDownLink cellReselInd cellReselectHysteresis cellReselectOffset cellType cellType channelType concentAlgoIntMsRange concentAlgoExtMsRange concentAlgoIntRxLev concentAlgoExtRxLev Concentric cell configRef CpueNumber data mode 14.4 kbit/s data non transparent mode data transparent mode delayBetweenRetrans directedRetryAlgo directedRetryModeUsed directedRetryPrio distHreqt distWtsList dtxMode early classmark sending emergencyCallPriority extendedCell forced handover algo fhsRef
HandOver from signalling channel HOSecondBestCellConfiguration
From version
V7 V7 V7 V7 V8 V7 V7 V7 V8 V7 V8 V7 V7 V7 V9 V9 V9 V9 V9 + V12 V8 V12 V11 V11 V11 V8 V9 V9 V12 V7 V7 V7 V10 V7 V9 V9 V7 V7 V9 V7 V11 bts bts bts bts bts bts bts bts bts bts bts bts
Object
Group MS
Selection Rlink_fail Res_alloc Freq_Hop Res_alloc Res_alloc Nei_ave Selection Selection Selection micro_HO micro _HO Res_alloc Concent_HO Concent_HO Concent_HO Concent_HO Concent_HO BSC_load_mgt Data_trf Data_trf Data_trf Paging DRetry_HO DRetry_HO DRetry_HO Dist_ave Dist_ave Sel Sel Sel Rlf
Process BSS
Cc Rlf All Rlf
MSC
Ho
Ho Ho Ho Ho Ho Ho
adjacentCellHandOver channel handOverControl handOverControl handOverControl handOverControl
bts
btsSiteManager btsSiteManager transcoder board signaling Point, bts signaling Point, bts bts adjacentCellHandOver bts bts handOverControl handOverControl bts bts bts bts adjacentCellHandOver channel handOverControl bsc adjacentCellHandOver bts
Pag Ho Ho Ho Mp Mp
Res_alloc Dist_mgt Global_HO Freq_Hop Global_HO Global_HO Global_HO Global_HO
All Ho Ho Ho Ho Ho
hoMargin hoMarginBeg
Page 14
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Parameters name
hoMarginTrafficOffset hoMarginDist hoMarginRxLev hoMarginRxQual hoMarginTiering hoPingpongCombination hoPingpongTimeRejection hoTraffic HoppingSequenceNumber incomingHandOver interBscDirectedRetry interBscDirectedRetryFromCell interCellHOExtPriority interCellHOIntPriority intraCellQueueing interferer cancel algo usage intraBscDirectedRetry interferenceType intraBscDirectedRetryFromCell intraCell intraCellHOIntPriority intraCellSDCCH lRxLevDLH lRxLevDLP lRxLevULH lRxLevULP lRxQualDLH lRxQualDLP lRxQualULH lRxQualULP LapdTerminalNumber maio maxNumberRetransmission measurementProcAlgo microCellCaptureTimer microCellStability microCellStability minNbOfTDMA missDistWt missRxLevWt
From version
V12 V8 V8 V8 V12 V12 V12 V12 V7 V7 V9 V9 V7 V7 V8 V10 V9 V12 V9 V7 + V12 V7 V8 V7 V7 V7 V7 V7 V7 V7 V7 V7 V7 V8 V12 V8 V8 V8 V7 V7 V7
Object
adjacentCellHandover adjacentCellHandOver adjacentCellHandOver adjacentCellHandOver handOverControl adjacentCellHandover adjacentCellHandover bts, bsc frequencyHoppingSystem handOverControl bsc bts bts bts bts bts bsc adjacentCellHandover bts handOverControl bts handOverControl handOverControl powerControl handOverControl powerControl handOverControl powerControl handOverControl powerControl lapdLink channel bts bts adjacentCellHandOver adjacentCellHandOver bts bts handOverControl handOverControl
Group MS
Traffic_HO Global_HO Global_HO Global_HO Cell_Tiering Global_HO Global_HO Traffic_HO Freq_Hop DRetry_HO DRetry_HO Res_alloc Res_alloc intra_HO DRetry_HO Cell_Tiering DRetry_HO intra_HO Res_alloc intra_HO inter_HO Pwr_Ctrl inter_HO Pwr_Ctrl Global_HO Pwr_Ctrl Global_HO Pwr_Ctrl BSC_load_mgt Freq_Hop Paging micro_HO micro_HO micro_HO Res_alloc Dist_ave Lev_ave
Process BSS
Ho Ho Ho Ho Ho Ho Ho
MSC
Ho Ho All All Ho Ho Ho Ho All Ho Ho Pc Ho Pc Ho Pc Ho Pc
Pag Ho Ho Ho Cc,Mp Ho,Mp
GSM/BSS V12
Page 15
Parameters name
missRxQualWt mobileAllocation modeModifyMandatory msBtsDistanceInterCell msRangeMax msTxPwrMax msTxPwrMaxCCH msTxPwrMax2ndBand msTxPwrMaxCell multi band reporting nbOfRepeat new power control algorithm noOfBlocksForAccessGrant
noOfMultiframesBetweenPaging
From version
V7 V7 V9 V7 V7 V7 V7 V12 V7 V10 V8 V9 + V12 V7 V7 V7 V7 V9 V9 V9 V9 V12 V12 V12 V7 V9 V8 V12 V7 V7 V7 V7 V7 V10 V7 V8 + V12 V12 V8 V7 V8 V8
Object
handOverControl frequencyHoppingSystem bsc handOverControl handOverControl bts bts bts adjacentCellHandOver bts bts powerControl bts bts bts bts bts bts bts bts handOverControl adjacentCellHandover adjacentCellHandover bts bts bts bts handOverControl powerControl bts powerControl powerControl
adjacentCellHandOver
Group MS
Qual_ave Freq_Hop DRetry_HO Global_HO Dist_mgt Global_HO Selection Pwr_ctrl Global_HO Dual_band Paging Pwr_Ctrl Paging Paging Res_alloc Paging Res_alloc Res_alloc Res_alloc Res_alloc Cell_Tiering Sel Sel Sel Sel Sel Sel
Process BSS
Ho,Mp Ho Ho Ho Ho Pc Ho Pag Pc Pag Pag Pag
MSC
notAllowedAccessClasses numberOfSlotsSpreadTrans
numberOfTCHFreeBeforeCongestion numberOfTCHFreeToEndCongestion
numberOfTCHQueuedBeforeCongestion numberOfTCHQueuedToEndCongestion
numberofPwciSamples offsetLoad offsetPriority otherServicesPriority pagingOnCell penaltyTime pcmErrorCorrection powerBudgetInterCell powerControl powerIControlIndicator powerIncrStepSize powerRedStepSize preSynchroTimingAdvance priority processorLoadSupConf pwciHreqave radChanSellIntThreshold radioLinkTimeOut radResSupBusyTimer radResSupervision
Res_alloc Paging Selection Global_HO Pwr_Ctrl Pwr_Ctrl Pwr_Ctrl Dist_mgt Res_alloc BSC_load_ngt Cell_Tiering Interf Rlink_fail RR_ctrl RR_ctrl Rlf Sel
All Pag
Ho Pc Pc Pc
transceiver bsc handOverControl handOverControl bts bsc bts
If
Page 16
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Parameters name
radResSupFreeTimer retransDuration rlf1 rlf2 rlf3
From version
V8 V8 V8 V8 V8 V8 V7 V7 V7 V7 V7 V11 V7 V11 V7 V7 V11 V7 V7 V7 V7 V7 V7 V12 V12 V7 V10 + V12 V10 + V12 V7 V8 V12 V9 V7 V9 V9 V9 V9 V9 V9 V8 bsc bts bts bts bts
Object
Group MS
RR_ctrl Paging Rlink_fail Rlink_fail Rlink_fail Dist_ngt Dist_mgt Global_HO Pwr_Ctrl Selection intra_HO Global_HO Lev_ave Nei_ave Lev_ave Global_HO Global_HO intra_HO Lev_ave Nei_ave Qual_ave Qual_ave Qual_ave Intra_HO Intra_HO Dual_band Dual_band Global_HO Cell_Tiering Res_alloc Timer Timer Timer Timer Timer Timer Selection Sel Sel
Process BSS
Pag Rlf Rlf Rlf Cc, Mp Ho, Mp Pc, Mp Ho Ho Mp Mp Mp Ho Ho Mp Mp Mp Mp Mp Ho Ho
MSC
rndAccTimAdvThreshold
runCallClear runHandOver runPwrControl rxLevAccessMin rxLevDLIH rxLevDLPBGT rxLevHreqave rxLevHreqaveBeg rxLevHreqt rxLevMinCell rxLevNCellHreqaveBeg rxLevULIH rxLevWtsList rxNCellHreqave rxQualHreqAve rxQualHreqt rxQualWtsList rxQualDLIH rxQualULIH SiteGsmFctList standardIndicator AdjC standardIndicator AdjC synchronized SpeechMode
bts
bts bts bts bts handOverControl adjacentCellHandOver handOverControl handOverControl handOverControl adjacentCellHandOver handOverControl handOverControl handOverControl handOverControl handOverControl handOverControl handOverControl handOverControl handOverControl btsSiteManager adjacentCellHandOver adjacentCellReselection adjacentCellHandhOver bts handOverControl handOverControl bts bts bts bts bts bts bts bts
selfTuningObs
smallToLargeZoneHOPriority smsCB t3101 t3103 t3107 t3109 t3111 t3122 temporaryOffset
Ho
GSM/BSS V12
Page 17
Parameters name
thresholdInterference timerPeriodicUpdateMS timeBetweenHOConfiguration uplinkMappingProcessingMode uplinkMappingChannelNumber uplinkMappingFreq uplinkMappingMeasurementMode uplinkPowerControl uRxLevDLP uRxLevULP uRxQualDLP uRxQualULP zoneTxPwrMaxReduction zone frequency hopping zone frequency threshold
From version
V7 V7 V9 + V12 V12 V12 V12 V12 V8 V7 V7 V7 V7 V9 V9 V9 bts bsc bsc bts bts bts
Object
handOverControl
Group MS
Interf_lev Timer Global_HO Um Um Um Um Pwr_Ctrl Pwr_Ctrl Pwr_Ctrl Pwr_Ctrl Pwr_Ctrl Concent_HO
Process BSS
If Ho Um Um Um Um Pc Pc Pc Pc Pc Ho
MSC
powerControl powerControl powerControl powerControl powerControl transceiverZone transceiverZone transceiverZone
Page 18
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
1.4
PARAMETERS VERSUS BSS FEATURES AND PROCEDURES

B.1.1 Level averaging Attribute rxLevHreqave rxLevHreqt rxLevWtsList missRxLevWt rxLevHreqaveBeg Object handOverControl handOverControl handOverControl handOverControl handOverControl
B.1.2
Quality averaging Attribute rxQualHreqave rxQualHreqt rxQualWtsList missRxQualWt Object handOverControl handOverControl handOverControl handOverControl
B.1.3
Distance averaging Attribute distHreqt distWtsList missDistWt Object handOverControl handOverControl handOverControl
B.1.4
Cell Eligibility Attribute rxLevMinCell rxNCellHreqave cellDeletionCount rxLevHreqave missRxLevWt msTxPwrMaxCell msTxPwrMax HOSecondBestCellConfiguration rxNCellHreqaveBeg Object adjacentCellHandOver handOverControl bts handOverControl handOverControl adjacentCellHandOver bts bsc handOverControl
GSM/BSS V12
Page 19
B.1.5
Radio Link Failure Attribute radioLinkTimeOut rlf1 rlf2 rlf3 t3111 t3109 Object bts bts bts bts bts bts
B.1.6
Interference management Attribute averagingPeriod thresholdInterference radChanSelIntThreshold Object handoverControl handoverControl handoverControl
B.1.7
PCH and RACH control parameters Attribute delayBetweenRetrans maxNumberRetransmission nbOfRepeat noOfBlocksForAccessGrant noOfMultiframesBetweenPaging numberOfSlotsSpreadTrans pagingOnCell retransDuration t3122 Object bts bts bts bts bts bts bts bts bts
B.2.1
Enhanced Full Rate encoding Attribute speechMode speechMode multipleVocoder version algorithmUsed Object signallingPoint bts bsc transcoder transcoderBoard
B.2.2
Concentric cell Attribute concentric cell Object bts
Page 110
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
concent AlgoExtMsRange concent AlgoExtRxLev concent AlgoIntMsRange concent AlgoIntRxLev zone Tx power max reduction transceiverEquipmentClass zone frequency hopping zone frequency threshold small to large zone HO Priority transceiver zone ref runHandover
handOverControl handOverControl handOverControl handOverControl transceiverZone transceiverEquipment transceiverZone transceiverZone handOverControl transceiver 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 extended cell rndAccTimAdvThreshold msRangeMax callClearing channelType Object bts bts handOverControl bts channel
B.2.4
Queueing and priority management Attribute allocPriorityTable allocPriorityTimers allocPriorityThreshold allocWaitThreshold allOtherCasesPriority answerPagingPriority assignRequestPriority bscQueueingOption callReestablishmentPriority emergencyCallPriority Object bts bts bts bts bts bts bts signallingPoint bts bts
GSM/BSS V12
Page 111
Attribute interCellHOExtPriority interCellHOIntPriority intraCellHOIntPriority otherServicesPriority small to large zone HO Priority directedRetryPriority intraCellQueuing B.2.5 SMSCB Attribute smsCB noOfBlocksForAccessGrant channelType B.2.6 Frequency Hopping Attribute btsIsHopping hoppingSequenceNumber maio siteGsmFctList cellAllocation mobileAllocation fhsRef configRef bscHopReconfUse btsHopReconfRestart btsThresholdHopReconf zone frequency hopping zone frequency threshold
Object bts bts bts bts handOverControl bts bts
Object bts bts channel
Object bts frequencyHoppingSystem channel btsSiteManager bts frequencyHoppingSystem channel btsSiteManager bsc bts bts transceiverZone transceiverZone
Page 112
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
B.2.7
Selection / Reselection (idle mode) Attribute cellBarQualify cellBarred rxLevAccessMin msTxPwrMaxCCH cellReselInd cellReselectHysteresis cellReselectOffset temporaryOffset penaltyTime rndAccTimAdvThreshold Object bts bts bts adjacentCellHandOver bts bts bts bts bts bts
B.2.8
Dynamic barring of access class Attribute bscMsAccessClassBarringFunction btsMsAccessClassBarringFunction accessClassCongestion numberOfTCHFreeBeforeCongestion numberOfTCHFreeToEndCongestion numberOfTCHQueuedBeforeCongestion numberOfTCHQueuedToEndCongestion notAllowedAccessClasses emergencyRestricted Object bsc bts bts bts bts bts bts bts bts
B.2.9
DTX Attribute dtxMode cellDtxDowlink Object bts bts Remark Uplink Downlink
GSM/BSS V12
Page 113
B.2.10
Uplink Power control
Attribute uplinkPowerControl new power control algorithm powerIncrStepSize powerRedStepSize runPowerControl lRxQualULP uRxQualULP lRxLevULP uRxLevULP msTxPwrMax msTxPwrMax2ndBand
Object powerControl bts powerControl powerControl bts powerControl powerControl powerControl powerControl bts bts
Remark flag step by step algorithm only step by step algorithm only
step by step algorithm only step by step algorithm only
RELATED FEATURES: B.1.1. : Level averaging parameters B.1.2. : Quality averaging parameters
B.2.11 Downlink Power control
Attribute bsPowerControl new power control algorithm powerIncrStepSize powerRedStepSize runPwrControl lRxQualDLP uRxQualDLP lRxLevDLP uRxLevDLP
Object powerControl bts powerControl powerControl bts powerControl powerControl powerControl powerControl
Remark flag step by step algorithm only step by step algorithm only
step by step algorithm only step by step algorithm only
Page 114
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
B.2.12 Directed retry handover Attribute interBscDirectedRetry intraBscDirectedRetry interBscDirectedRetryFromCell intraBscDirectedRetryFromCell modeModifyMandatory directedRetryModeUsed msTxPwrMaxCell msTxPwrMax directedRetryAlgo adjacent cell umbrella ref directedRetryPrio Object bsc bsc bts bts bsc bts adjacentCellHandOver bts adjacentCellHandOver bts bts bts mode bts mode bts mode bsc mode Remark
RELATED FEATURES: B.2.4. : Queueing parameters B.1.6.: Interference management

B.2.13 Uplink intracell handover Attribute intraCell intraCellSDCCH runHandOver rxLevULIH lrxQualULH (before V12) rxQualULIH (V12) Object handOverControl handOverControl bts handOverControl handOverControl handOverControl
GSM/BSS V12
Page 115
B.2.14 Downlink intracell handover Attribute intraCell intraCellSDCCH runHandOver rxLevDLIH lrxQualDLH (before V12) rxQualDLIH (V12) Object handOverControl handOverControl bts handOverControl handOverControl handOverControl
B.2.15 Intercell handover on bad uplink quality criterion Attribute HandOver from signalling channel runHandOver lrxQualULH hoMarginRxQual Object handOverControl bts handOverControl adjacentCellHandOver Threshold Eligibility Remark
RELATED FEATURES: B.1.2. : Quality averaging parameters B.1.4. : cell eligibility parameters B.1.6. : Interference management parameters
B.2.16 Intercell handover on bad downlink quality criterion Attribute HandOver from signalling channel runHandOver lrxQualDLH hoMarginRxQual Object handOverControl bts handOverControl adjacentCellHandOver Threshold Eligibility Remark
Page 116
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
RELATED FEATURES: B.1.2. : Quality averaging parameters B.1.4. : cell eligibility parameters B.1.6. : Interference management parameters
B.2.17 Intercell handover on bad uplink level criterion Attribute HandOver from signalling channel runHandOver lrxLevDLH hoMarginRxLev Object handOverControl bts handOverControl adjacentCellHandOver Threshold Eligibility Remark
RELATED FEATURES: B.1.1. : Level averaging parameters B.1.4. : cell eligibility parameters B.1.6. : Interference management parameters
B.2.18 Intercell handover on bad downlink level criterion Attribute HandOver from signalling channel runHandOver lrxLevULH hoMarginRxLev Object handOverControl bts handOverControl adjacentCellHandOver Threshold Eligibility Remark
RELATED FEATURES: B.1.1. : Level averaging parameters B.1.4. : cell eligibility parameters B.1.6. : Interference management parameters
B.2.19 Intercell handover on power budget criterion Attribute powerBudgetInterCell HandOver from signalling channel runHandOver hoMargin rxLevDLPBGT Object handOverControl handOverControl bts adjacentCellHandOver adjacentCellHandOver Remark flag
GSM/BSS V12
Page 117
RELATED FEATURES: B.1.4. : cell eligibility parameters B.1.6. : Interference management parameters
B.2.20 Microcellular algorithm Attribute HandOver from signalling channel runHandOver cellType cellType microCellCaptureTimer microCellStability rxNCellHreqave Object handOverControl bts bts adjacentCellHandOver adjacentCellHandOver adjacentCellHandOver handOverControl
RELATED FEATURES: B.1.6. : Interference management parameters

B.2.21 Intercell handover on distance criterion Attribute msBtsDistanceInterCell HandOver from signalling channel runHandOver hoMarginDist Object handOverControl handOverControl bts adjacentCellHandOver Remark flag
RELATED FEATURES: B.1.3. : Distance averaging parameters B.1.4. : cell eligibil.ity parameters B.1.6. : Interference management parameters
B.2.22 Handover for traffic reasons (V12) Attribute hoTraffic hoTraffic hoMarginTrafficOffset Object bsc bts adjacentCellHandover
Page 118
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
B.2.23
Handover decision according to adjacent cell (V12) Attribute offsetLoad offsetPriority Object adjacentCellHandover adjacentCellHandover
B.2.24
General protection against HO PingPong (V12) Attribute HOPingpongTimeRejection HOPingpongCombination timeBetweenHOConfiguration bts time Between HO Configuration Object adjacentCellHandover adjacentCellHandover bsc bts
B.2.25
Call clearing Attribute runCallClear callClearing Object bts bts
RELATED FEATURES: B.1.3. : Distance averaging parameters

B.2.26 Frequency Band favouring Attribute early classmark sending multiband reporting cellBarred cellBarQualify hoMargin hoMarginDist hoMarginRxQual hoMarginRxLev B.2.27 Object bts bts bts bts adjacentCellHandOver adjacentCellHandOver adjacentCellHandOver adjacentCellHandOver
Minimum Time between Handover (before V12) Attribute timeBetweenHOConfiguration bts time between HO configuration Object bsc bts
GSM/BSS V12
Page 119
B.2.28
Radio resource control at cell level Attribute radResSupervision radResSupBusyTimer radResSupFreeTimer Object bts bsc bsc
B.2.29
Presynchronised Handover Attribute synchronised preSynchroTimingAdvance Object adjacentCellHandOver adjacentCellHandOver
B.2.30
Interferer cancellation Attribute interferer cancel algo usage Object bts
B.2.31
Early HO decision Attribute HoMarginBeg RxLevHReqAveBeg RxLevNCellHReqAveBeg Object bts handOverControl handOverControl
B.2.32
Maximum RxLev for PBGT Attribute rxLevDLPBGT Object adjacentCellHandOver
B.2.33
Uplink Mapping (V12) Attribute uplinkMappingProcessingMode uplinkMappingMeasurementMode uplinkMappingFreq uplinkMappingChannelNumber Object bsc bts bts bts
Page 120
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
B.2.34
Cell Tiering (V12) Attribute interferferType intraCell measProcAlgorithm NbLargeReuseDataChannels hoMarginTiering pwciHreqave numberOfPwciSamples selfTuningObs Object adjacentCellHandover handoverControl bts handoverControl handoverControl handoverControl handoverControl handoverControl
GSM/BSS V12
Page 121
PAGE INTENTIONALLY LEFT BLANK
Page 122
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
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 RXQUAL_UL RXLEV_DL RXLEV_UL MS_BS_Dist RXLEV_NCELL(n) Weighted average for downlink (measurements made by the MS) signal quality
Weighted average for uplink signal quality (measurements made by the BTS) Weighted average for downlink (measurements made by the MS) Weighted average for uplink (measurements made by the BTS) signal signal strength strength
Weighted average of MS distance from BTS (timing advance used by the MS) 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.
GSM/BSS V12
Page 21
Algorithms
RXQUAL Value
Bit Error Rate From V9 Lower limit Upper limit Up to V8 Mean value 0.14% 0.28% 0.57% 1.13% 2.26% 4.53% 9.05% 18.10%
0 1 2 3 4 5 6 7
t 0.2 % w0.2% w0.4% w0.8% w1.6% w3.2% w6.4% w12.8% t0.4% t0.8% t1.6% t3.2% t6.4% t12.8 %
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:
GSM 900 CLASS 1: Phase 1 CLASS 2: CLASS 3: CLASS 4: CLASS 5: restricted MS 8W 5W 2W 39 dBm 37 dBm 33 dBm
GSM 1800 / GSM 1900 CLASS 1: CLASS 2: CLASS 3: 1W 30 dBm 24 dBm 36 dBm
Normal
Extreme
2 dB 2 dB 2 dB 2 dB 2 dB
2.5 dB 2.5 dB 2.5 dB 2.5 dB 2.5 dB
0.25W 4W
0.8W 29dBm
Page 22
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Tolerance for condition
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 2: [160 320[ W [52 55[ dBm CLASS 3: [80 160[ W CLASS 4: [40 80[W [49 52[ dBm CLASS 1: [20 40[ W [43 46[ dBm CLASS 2: [10 20[ W [40 43[ dBm CLASS 3: [5 10[ W [37 40[ dBm
2 dB 2 dB 2 dB 2 dB 2 dB 2 dB 2 dB 2 dB
2.5 dB 2.5 dB 2.5 dB 2.5 dB 2.5 dB 2.5 dB 2.5 dB 2.5 dB
[46 49[ dBm [43 46[dBm
CLASS 4: [2.5 5[ W [34 37[ dBm
CLASS 5: [20 40[ W CLASS 6: [10 20[ W CLASS 7: [5 10[ W
[40 43[ dBm [37 40[ dBm
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 104 dBm GSM 1800 102 dBm GSM 1900 102 dBm
Nevertheless, the MS seems to have usually better sensitivity than these figures.
GSM/BSS V12
Page 23
Algorithms
2.2.3.2
DRX based products sensitivity and power
GSM 900: DRX based products sensitivity and power

BTS Power amplifier S8000 Outdoor / Indoor 44.8 dBm (30 W) +/ 0.5 dB 1 dBm 5 dBm 8.5 dBm Not scheduled
108 dBm/110 dBm*
S2000 H 43.8 dBm (24 W) +/ 1 dB at antenna
S2000 L 35.6 dBm (3.6 W) +/ 1 dB at BTS feeder
Duplexor loss (guaranded) H2D loss (guaranded) H4D loss (guaranded) Cavity + Duplexor RX Sensitivity Expected space diversity gain at sensitivity level Global performances of the receiving system, including space diversity
109 dBm 5 dBm**
104 dBm 3 dBm with integrated antennas
5 dBm**
113 dBm/115 dBm
* with enhanced coverage option ** Crosspolar diversity gain is 1 dB less
Page 24
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms

BTS Power amplifier S8000 Outdoor / Indoor 44.8 dBm (30 W) +/ 0.5 dB 1.2 dBm 5 dBm 8.5 dBm Not scheduled
108 dBm/110 dBm*
S2000 H 43.8 dBm (24 W) +/ 1 dB at antenna
S2000 L 35.6 dBm (3.6 W) +/ 1 dB at BTS feeder
Duplexor loss H2D loss H4D loss Cavity + Duplexor RX Sensitivity Expected space diversity gain at sensitivity level Global performances of the receiving system, including space diversity
109.5 dBm 5 dBm**
104 dBm 3 dBm with integrated antennas
5 dBm**
113 dBm/115 dBm
* with enhanced coverage option ** Crosspolar diversity gain is 1 dB less 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.
GSM/BSS V12
Page 25
Algorithms

BTS Power amplifier S8000 Outdoor only S2000 H S2000 L 35.6 dBm (3.6 W) +/ 1 dB at BTS feeder
44.8 dBm (30 W) +/ 43.8 dBm (24 W) 0.5 dB +/ 1 dB at antenna 1.2 dB 5 dB 8.5 dB Not scheduled
108 dBm/110 dBm*
Duplexor loss H2D loss H4D loss Cavity + Duplexor RX Sensitivity Expected diversity gain Global performances
109 dBm 5 dB**
104 dBm 3 dB with integrated antennas
5 dB**
113 dBm/115 dBm
* with enhanced coverage option ** Crosspolar diversity gain is 1 dB less

2.2.3.3 TRX based products sensitivity and power
GSM 900: TRX based products sensitivity and power

BTS S4000 Indoor Stand (1 sect/cab) 44.8 dBm / 45.4 dBm hybrid /cavity 1 dB 5 dB 4.9 dB S4000 Indoor Compact (3 sec / 2 cab) 45.4 dBm 5 dB S4000 Outdoor 44 dBm 0/+3 dB 1 dB 5 dB S2000 E In/Out 44 dBm 0/+3 dB 1 dB
Power amplifier Duplexor loss H2D loss Cavity Master + Duplexor RX Sensitivity* Rx diversity gain
107 dBm 4 dB
107 dBm 4 dB
107 dBm 4 dB
107 dBm 4 dB
Page 26
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms

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

BTS Power amplifier Duplexor loss H2D RX Sensitivity* Rx diversity gain Antenna gain Balanced EIRP S4000 Outdoor only 43 dBm / 44.8 dBm hybrid /cavity 1.2 dB 5 dB 107 dBm 4 dB S4000 Outdoor 42 dBm +/1.5 dB 1.2 dB 5 dB 107 dBm 6.5 dB 18 dBi 59.5 dBm +/ 1.5 dB S2000 E In/Out 43 dBm 1.2 dB 107 dBm 4 dB
2.2.4
2.2.4.1
Conversion rules
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
GSM/BSS V12
Page 27
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 0 1 2 3 ... 63 [34 902..35456[ 0.4 % Distance (m) [0..554[ [554..1108[ [1108..1662[ [1662.. Recommendation accuracy 25 % 12.5 % 6.1 % 3.1 %
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.
.
2.2.5
The timing advance must be used carefully as a handover and call clearing criteria, especially in a microcellular configuration. 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 from 110 dBm to 48 dBm under normal conditions from 110 dBm to 48 dBm under extreme conditions
4dB 6 dB 6 dB
The overlap between the different ranges (see above normal condition cases) are specified in the recommendation.
Page 28
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 sensitivity + 14 dB> lower measured level > sensitivity + 1 dB sensitivity + 1 dB > lower measured level 2dB; + 2 dB 3dB; +2 dB 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 935960
880915 925960
876915 921960
17101785 18501910 18051880 19301990 2x75 MHz 95 MHz 374 2x60 MHz 80 MHz 299
downlink band (MHz)
bandwith (2*W simplex) duplex shift ( W duplex) number of carriers
2x25 MHz 2x35 MHz 2x39 MHz 45 MHz 124 45 MHz 174 45 MHz 194
GSM/BSS V12
Page 29
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 (see V8 feature ART264), 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.
Page 210
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 (see V8 feature AR264), 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.
GSM/BSS V12
Page 211
Algorithms
The timer (penaltyTime) ensures that the mobile will reselect a cell which has been received with a sufficient level for a sufficient time. Some microcellular handover algorithms given as an example in the GSM ETR 05.22 are based on this C2 reselection principle.
Cell B Cell A
.
C1 (A) C2 (A)
Trajectory
C1 (B) Slow MS C2 (B) Start of penalty time End of penalty time
C1 (A) C2 (A)
C1 (B) C2 (B) Start of penalty time End of penalty time
Fast MS
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.
Page 212
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
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). 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 barred barred not barred not barred cellBarQualify false true false true Priority no selection possible low normal 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 barred barred not barred not barred cellBarQualify false true false true Priority no reselection possible normal normal normal
Example of application: in a microcellular network, it is possible to give a priority of access to a microcell.
GSM/BSS V12
Page 213
Algorithms
2.4
2.4.1
MEASUREMENT PROCESSING
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 Compute Average Run Decision with
T = 480 ms on TCH T = 470 ms on SDCCH

SACCH blocks
Compute & Store Average
Compute & Store Average
L1M V2 In the new version of the L1M (V2), the process of averaging has been based on fully sliding windows.
Page 214
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
Time Run Decision with m1 Run Decision with m5 Run Decision with m9
DT
m1 m2 m3 m4 0
DT = 480 ms on TCH DT = 470 ms on SDCCH SACCH blocks mi Compute & Store Averages
m9
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).
GSM/BSS V12
Page 215
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
Run Decision with 2& 1 1
Run Decision with 3& 4
Run Decision with 5& 2 2
Page 216
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
L1M V2
Run Decision with m6 and m3
m1 m2 m3
m4 m5 m6
m7 m8 m9
m10 m11 m12
m13 m14
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.
GSM/BSS V12
Page 217
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
Page 218
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
L1MV1
received measurement report
missing measurement report
? r1 r2 r3 r4 r5 r6 r7 r8
m1
averaging
m2
averaging
time
r8 = m1 * missXXWt
L1M V2
? r1 r2 m1 m2 m3 m4 time r8 = m4 *missXXWt r3 r4 r5 r6 m5 r7 r8
GSM/BSS V12
Page 219
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
averaging
m2
averaging
time
r3 = r2 * missXXWt
Page 220
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
L1MV2
? r1 r2 m1 m2 m3 m4 time r3 = r2 * missXXWt r3 r4 r5 r6 m2 r7 r8
Rule 3: If no measurement value is available, the missing measurement is replaced by a default value. Example: xxHreqave = 4
GSM/BSS V12
Page 221
Algorithms
L1MV1
? r1 r2 r3 r4 r5 r6 r7 r8
m1
averaging
m2
averaging
time
r1 = default value
L1MV2
? r1 r2 m1 m2 m3 m4 time r1 = default value r3 r4 r5 r6 m2 r7 r8
Page 222
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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
averaging
m2
averaging
time
For neighboring measurement, 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.
GSM/BSS V12
Page 223
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)
Page 224
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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)
GSM/BSS V12
Page 225
Algorithms
2.5
2.5.1
DIRECT TCH ALLOCATION & HANDOVER ALGORITHMS

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)}
Page 226
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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
GSM/BSS V12
Page 227
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.
!
2.5.2.2
Caution: The BSC does not send the inquiry if the call is established on a signalling TCH.
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.
Page 228
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 229
Algorithms
The minimum number of periods before decision are:

Version PBGT HO rxQual HO rxLev HO intracell HO distance HO capture HO interzone HO (not dualband) interzone HO (dualband cell) traffic HO call clearing enhanced power control V12> V12> Minimum number of periods before decision Max(rxLevHreqaveBeg, rxNCellHreqaveBeg, runHO) Max(rxQualHreqave*rxQualHreqt, rxLevHreqave, rxNCellHreqave, runHO) Max(rxLevHreqave*rxLevHreqt, rxNCellHreqave, runHO) Max(rxQualHreqave*rxQualHreqt, rxLevHreqave*rxLevHreqt, runHO) Max(rxLevHreqave, distHreqt, rxNCellHreqave, runHO) Max(rxNCellHreqave, runHO) Max(rxLevHreqave*rxLevHreqt, distHreqt, runHO) Max(rxLevHreqave*rxLevHreqt, runHO)
V12>
Max(rxLevHreqave, rxNCellHreqave, runHO) Max(pwciHreqave, runHO) Max(distHreqt, runCallClear) Max(rxLevHreqaveBeg, runPC)
cell tiering HO V12>
Page 230
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
2.5.5
2.5.5.1
Directed Retry Handover

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.
GSM/BSS V12
Page 231
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 P = maximum RF output power of the MS 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)
. .
Page 232
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 233
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).
Page 234
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 As large zone cell As small zone cell Bs large zone Possible Possible cell Bs small zone Impossible Impossible a non concentric cell Possible Possible
2.5.7
2.5.7.1
Rescue Handover
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 Thresholds should be set in order to ensure good subjective voice quality (rxqual 5 with frequency hopping or rxqual 4 without hopping).
GSM/BSS V12
Page 235
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.
Page 236
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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
2.5.8.1
Power Budget Handover

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.
GSM/BSS V12
Page 237
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 S4000/S2000EDCU2/DCU4. for S4000/S2000EDCU2 or
This feature is applicable for all cases where PBGT handover is possible; so, handover for traffic reasons is not possible between microcell and macrocell.
Page 238
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 O1 x = 7 TCH O2 x = 14 TCH hoMargin reduction 1 dB 2 dB 1 dB 2 dB p = HO probability 0.125 0.24 0.125 0.24 traffic gain (Erlang) 0.875 1.68 1.75 3.36
GSM/BSS V12
Page 239
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.
Page 240
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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).
GSM/BSS V12
Page 241
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
(PWCI < x) cumulative probability Page 242 1 0.9 0.8 0.7 0.6 0.5 0.4 0.3 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
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 O2 (14 TCH) O4 (29 TCH) O8 (59 TCH) O16 (121 TCH) 20000 nbPwCISamples # 16 min # 8 min # 4 min # 2 min 60000 nbPwCISamples # 48 min # 24 min # 12 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.
GSM/BSS V12
Page 243
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.
Page 244
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
2.5.12.2
Ho__A: Microcellular Algo type A
This microcellular algorithm is activated in the static configuration of the OMCR. It was initially defined for France Tlcom (V6.4), and was used for the first time in the microcellular Network in the city of Nice. It could not be used in countries where France Tlcom is a competitor (unless a specific agreement is signed) until the end of 1997. It can be used from V9 release. 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 serving cell normal
normal signal quality UL, DL signal strength UL, DL distance power budget traffic directedRetry (BTS mode) forced handover signal quality signal strength distance power budget traffic directedRetry (BTS mode) forced handover signal quality signal strength distance power budget traffic directedRetry (BTS mode) forced handover
macrocell signal quality signal strength distance power budget traffic directedRetry (BTS mode) forced handover signal quality signal strength distance power budget traffic directedRetry (BTS mode) forced handover signal quality signal strength distance directedRetry (BTS mode) forced handover
microcell signal quality signal strength distance power budget traffic directedRetry (BTS mode) forced handover capture directedRetry (BTS mode) forced handover
macrocell
microcell
GSM/BSS V12

signal quality signal strength distance power budget traffic directedRetry (BTS mode) forced handover Page 245
Algorithms
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).
Page 246
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
IDLE
RUN_HANDOVER
Is capture confirmation running for microcell n ? (Y) Calculate average RXLEV_NCELL(n) RXLEV_NCELL(n) > RXLEV_MIN(n) ? (Y) Updating RXLEV_NCELL_MIN(n) RXLEV_NCELL_MAX(n)
(N)
(N)
Reset microCellCaptureTimer(n) and handover process on microcell: n
Normal handover procedure (Y) Handover decision ? (N) (Y)
RXLEV_NCELL_MAX(n) RXLEV_NCELL_MIN(n) < MicroCellStability(n) ? (Y) Has microCellCaptureTimer(n) expired ? (Y) Handover on CAPTURE criterion
(N)
Handover on NORMAL criterion (Y) Micro cell selected for capture confirmation ? (N) Microcell m found ?
(N)
RXLEV_NCELL(m) > RXLEV_MIN(m) ? (Y) Set timer microCellCaptureTimer(m)
(N)
IDLE
Figure 21
MICROCELLULAR TYPE A HO ALGORITHM
GSM/BSS V12
Page 247
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.
Page 248
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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
2.5.14.1
Early HandOver Decision

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
GSM/BSS V12
Page 249
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 Incoming handover from cell A Cell A C1/C2 algorithm execution
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.
Page 250
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
Risk of call drop
January 2000
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
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
Incoming handover
Decrease of the call drop risk zone
GSM/BSS V12
Page 251
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.
Page 252
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 253
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.
Page 254
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 Ho1 98 dBm 100 dBm IRxLevDLH Ho2
Cell B
92 dBm 95 dBm 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.
GSM/BSS V12
Page 255
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. This could cause SICD overload problems at the BSC. Although the BSC is protected against this, such a situation should be avoided as much as possible in order not to disturb cells not concerned by the congestion situation that could also be supported by the overloaded SICD. 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.
Page 256
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 257
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.
Page 258
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 259
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.
Page 260
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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: powerControl object: uplinkPowerControl = enabled and bsPowerControl = 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
GSM/BSS V12
Page 261
Algorithms
RXQUAL K with FH K without FH
0 0.9 0.7
1 0.8 0.6
5 0.7 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: powerControl object: uplinkPowerControl = enabled and bsPowerControl = 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.
Page 262
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 263
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 commands in L1 header of SACCH block
One SACCH reporting period 26*4 = 104 frames (480 ms)
BTS receives the Measurement Report
SA0
SA1
SA2
SA3
SA0
SA1
SA2
SA3
SA0
SA1
SA2
SA3
26 frames, SACCH sent on frame 12 MS has the SACCH block
MS starts applying new PC and TA MS builds a L1 header stating new values of PC and TA
MS starts transmitting SACCH concerning previous multiframe
Page 264
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
2.8
2.8.1
2.8.1.1
TCH ALLOCATION MANAGEMENT

TCH Allocation and Priority
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.
GSM/BSS V12
Page 265
Algorithms
Channel Request
SDCCH available ? yes no Internal Priority Evaluation number of free TCH u Allocpriority Threshold ? yes no internal priority = 0 ? yes number of free TCH 1 ? yes SDCCH allocation TCH allocation (signalling) no Request not allowed no
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
Page 266
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
TCH request with priority = 0 are acknowledged TCH request with priority 0 are acknowledged
1 allocPriorityThreshold = 2
Free TCH
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.
GSM/BSS V12
Page 267
Algorithms
14 external GSM priorities + 4 external priorities reserved for BSS internal use are converted on 8 internal priorities MAPPING TABLE Internal Priorities (07)
MSC External Priorities
MSC level (1 14) BSC level (0 13) Priorities 14 17 are reserved for BSS internal use O&M External Priorities ( 0 17 ) MAPPING TABLE Internal Priorities (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 OMCR Internal priorities table allocPriorityTable 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17
Procedures answerPaging assignRequest callReestablishment emergencyCall interCellHO inter BSC
External priority 02 10 14 15 00
Page 268
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
Procedures interCellHO intra BSC intraCellHO otherServices allOtherCases

small to large zone HO
External priority 00 08 07 07 08 08
directedRetry (new V12)
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.
GSM/BSS V12
Page 269
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.
Page 270
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
Caution: check which cause of assignRequest is allowed to be queued (at the MSC side).
TCH allocation request BSC side answerPaging assignRequest callReestablishment emergencyCall interCellHO inter BSC interCellHO intra BSC intraCellHO otherServices
small to large zone HO
Comment no queueing an internal priority is defined not significant (see Section 2.8.1.1 All_1) no queueing an internal priority is defined no queueing an internal priority is defined no queueing an internal priority is defined no queueing an internal priority is defined queueing is allowed an internal priority is defined no queueing an internal priority is defined queueing is allowed an internal priority is defined queueing is allowed an internal priority is defined
directedRetry
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.
GSM/BSS V12
Page 271
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.
TCH allocation request BSC side answerPaging Comment no queueing an internal priority is defined
Page 272

assignRequest queueing is allowed an internal priority is defined no queueing an internal priority is defined no queueing an internal priority is defined no queueing an internal priority is defined callReestablishment emergencyCall interCellHO inter BSC
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms

interCellHO intra BSC intraCellHO no queueing an internal priority is defined queueing is allowed an internal priority is defined no queueing an internal priority is defined otherServices small to large zone HO directedRetry queueing is allowed an internal priority is defined queueing is allowed an internal priority is defined
TCH allocation request BSC side
Comment
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 maximum waiting time.
GSM/BSS V12
Page 273
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 ? yes internal priority = 0 ? yes number of free TCH 1 ? yes no Queueing available ? no yes TCH allocation Queueing Queueing available ? yes no NOK TCH allocation no no internal priority = 0 ? no yes number of free TCH 1 ? yes no
Example of configuration (bscQueueingOption = forced)
for
Queueing
with
OMC
driven
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
Page 274
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 answerPaging assignRequest callReetablisment emergencyCall interCellHO inter BSC interCellHO intra BSC interCellHO allOtherCases otherServices small to large zone HO directedRetry No Yes No No No No Yes No No Yes Yes Queueing External priority 17 16 14 14 14 14 16 17 17 16 16 Internal priority 3 2 (queueing) 0 0 0 0 2 (queueing) 3 3 2 (queueing) 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 allocWaitTimer = = 0 0 8 0 0 0 0 0 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
GSM/BSS V12
Page 275
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 allocPriorityTable 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 2 3 Queue number 0 allocWaitThreshold 0 allocPriorityTimers allocPriorityThreshold allOtherCasesPriority answerPagingPriority assignRequestPriority callReestablishmentPriority 0 2 17 (for priority number = 3) 17 (for priority number = 3) 16 (for priority number = 2) 14 (for priority number = 0) 1 0 0 2 8 10 3 0 0 4 0 0 5 0 0 6 0 0 7 0 0
Comments
Priority 0
Queueing
emergencyCallPriority 14 (for priority number = 0) interCellHOExtPriority interCellHOIntPriority intraCelHOIntPriority otherServicesPriority small to large zone HO directedRetry 14 (for priority number = 0) 14 (for priority number = 0) 16 (for priority number = 2) 17 (for priority number = 3) 16 (for priority number = 2) 16 (for priority number = 2) Queueing Queueing 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.
Page 276
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 numberOfTCHFreeToEndCongestion. or The number of queued requests in the cell. The parameters are numberOfTCHQueuedBeforeCongestion numberOfTCHQueuedToEndCongestion. The feature is enabled at bscMSAccessClassBarringFunction. The feature is enabled at btsMSAccessClassBarringFunction. Principle: bsc bts level level by by the the and and
attribute attribute
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 accessClassCongestion is not allowed. mobile access classes in
GSM/BSS V12
Page 277
Algorithms
Congestion ? No Yes
notAllowedAccessClasses forbidden in the cell
accessClassCongestion 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.
Page 278
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
Example with a one TRX cell where one time slot is reserved for requests with an internal priority equal to 0:
bscMSAccessClassBarringFunction = enabled bscMSAccessClassBarringFunction = enabled
numberOfTCHFreeBeforeCongestion = 1 numberOfTCHFreeToEndCongestion = 3
Beginning of congestion
BCCH
Reserved TS (priority 0)
BCCH
numberOfTCHFreeToEndCongestion = 3 Congestion
End of congestion
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
GSM/BSS V12
Page 279
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.
Page 280
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 281
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.
Page 282
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 283
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).
Page 284
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
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.
12 bursts min. (over 104) + optional bursts
1) Measurements downlik (RxLev / RxQual Full and sub) 2) DTX uplink Status (used or not)
GSM/BSS V12
Page 285
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. 2.2.
2.2.1.
If Downlink DTX use field is unset, the DTX is activated If Downlink DTX use field appears: If transmitted data is non transparent, the DTX is activated without further consideration for the value of Downlink DTX use flag 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.
2.2.2.
Page 286
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
MSC
Assign Request 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
GSM/BSS V12
Page 287
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
Page 288
PE/IRC/APP/0037 4119001037
Uplink 1) DTX Uplink Status 2) Measurements downlink
L1M
Approved 05.02/EN
January 2000
Algorithms
2.9
2.9.1
PCH AND RACH CHANNEL CONTROL

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. (See Minutes of WGSys#15 for more details)
GSM/BSS V12
Page 289
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
FCCH SCH BCCH BCCH BCCH BCCH CCCH CCCH CCCH CCCH FCCH SCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH
50 FCCH SCH SDCCH/4(0) SDCCH/4(0) SDCCH/4(0) SDCCH/4(0) SDCCH/4(1) SDCCH/4(1) SDCCH/4(1) SDCCH/4(1) FCCH SCH SDCCH/4(2) SDCCH/4(2) SDCCH/4(2) SDCCH/4(2) SDCCH/4(3) SDCCH/4(3) SDCCH/4(3) SDCCH/4(3) FCCH SCH SACCH/4(0) SACCH/4(0) SACCH/4(0) SACCH/4(0) SACCH/4(1) SACCH/4(1) SACCH/4(1) SACCH/4(1) IDLE
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.
Page 290
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
BCCH not combined case:
FN 0
FCCH SCH BCCH BCCH BCCH BCCH CCCH CCCH CCCH CCCH FCCH SCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH 4 5 6 7
50
FCCH SCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH FCCH SCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH FCCH SCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH CCCH IDLE
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.
GSM/BSS V12
Page 291
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
Page 292
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.13). 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 A
51 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.
GSM/BSS V12
Page 293
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 A
51 A
Paging groups numbers: 0
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.12). 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.
Page 294
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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)
GSM/BSS V12
Page 295
Algorithms
V ariable delay f rom 0 to

(numberOfSlotsSpreadT rans1) 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
Page 296
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 (T) 3, 8, 14, 50 4, 9, 16 5, 10, 20 6, 11, 25 7, 12, 32 S (noncombined BCCH) 41 52 58 86 115 S (combined BCCH) 55 76 109 163 217
Table 21
TIMER RANGE
GSM/BSS V12
Page 297
Algorithms
2.10
2.10.1
FREQUENCY HOPPING
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.
Page 298
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
RXQUAL cdf versus SFH (1km/h, 104 dBm) cdf = cumulative distribution function 100 90 80 70 60 50 40 30 20 10 0 0 2 4 BER % 6 8 10 NO FH 4 freq 8 freq 16 freq
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).
GSM/BSS V12
Page 299
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 FP2
TX1
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. For more details see [I26]. 2.10.4
2.10.4.1
Baseband Frequency Hopping

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.
Page 2100
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 TDMA 0 TDMA 1 TDMA 2 TDMA 3 0 F1 MA0 MA0 MA0 1 F1 MA0 MA0 MA0 2 F1 MA0 MA0 MA0 3 F1 MA0 MA0 MA0 4 F1 MA0 MA0 MA0 5 F1 MA0 MA0 MA0 6 F1 MA0 MA0 MA0 7 F1 MA0 MA0 MA0 MAIO = 0 MAIO = 1 MAIO = 2 MAIO = 3
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
GSM/BSS V12
Page 2101
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.
Page 2102
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 2103
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) 6) Filtering of 50 % of Rach (at SICD level) 7) Filtering of 100 % 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.
Page 2104
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
Parameter value
S = 2K
% of the theoretical CPUBIFP mean load CPU120/C PU133 CPU66
0 1 2 3 4 5 6 7 8 9
10240 8960 7680 6400 5120 3660 3200 2740 2250 1830
20480 17920 15360 12800 10240 7320 6400 5480 4500 3660
8000 7000 6000 5000 4000 2850 2500 2150 1790 1430
80 70 60 50 40 29 25 21 18 14 80 70 60 49 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.
GSM/BSS V12
Page 2105
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.
Page 2106
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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...
GSM/BSS V12
Page 2107
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 and
Paging_Response)
screening2:Handover_Indication
(for handOver Handover_Request (for incoming handOver interBSC)
intraBSC)
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)
Page 2108
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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).
GSM/BSS V12
Page 2109
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.
Page 2110
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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
GSM/BSS V12
Page 2111
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 SICD boards handling this GSM object instance the overLoad level of each TCU, showing the highest overLoad level between SICD boards handling this GSM object instance
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.
Page 2112
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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,
GSM/BSS V12
Page 2113
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 processorLoadSupConf, settable by the operator.
by
one
parameter,
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).
Page 2114
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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
GSM/BSS V12
Page 2115
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 bsTxPwrMax S Pc Translation table Pr Coupling System
Antennae connector Ps
* 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.
Page 2116
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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
DLU attenuation or OMC attenuation BsTxPwrMax 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 0 22
Dp 1 Pr Nack Nack Nack Nack Nack Nack Nack Nack Pmax Pmax 2 Pmax 4 Pmax 6 Pmax 8 Pmax 10 Pmax 12 Nack Nack Nack Nack Nack Nack Nack Nack
TxF 1 Pr Nack Nack Nack Nack Nack Nack Nack Nack Pmax Pmax 2 Pmax 4
H2D 4 Pr Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Pmax Pmax 2
H4D 8 Pr Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Pmax Pmax 2 Pmax 4 Pmax 6 Pmax 8 Pmax 10 Pmax 12 Nack
Pmax 6 Pmax 4 Pmax 8 Pmax 6 Pmax 10 Pmax 8 Pmax 12 Pmax 10 Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Pmax 12
Table 22
PR VS BSTXPWRMAX
GSM/BSS V12
Page 2117
Algorithms
BTS (V9+) => S4000 smart Coupling system => DLU attenuation or OMC attenuation => bsTxPwrMax 51 50 49 48 47 46 45 44 43 42 41 40 39 38 37 36 35 34 33 32 31 30 29 28 27 26 25 24 23 0 > 22 Smart 0 Pr Nack Nack Nack Nack Nack Nack Nack Pmax Pmax Pmax2 Pmax2 Pmax4 Pmax4 Pmax6 Pmax6 Pmax8 Pmax8 Pmax10 Pmax10 Pmax12 Pmax12 Nack Nack Nack Nack Nack Nack Nack Nack Nack S2000E S4000Outdoor Dp Dp 1 Pr Nack Nack Nack Nack Nack Nack Nack Nack Pmax Pmax Pmax2 Pmax2 Pmax4 Pmax4 Pmax6 Pmax6 Pmax8 Pmax8 Pmax10 Pmax10 Pmax12 Pmax12 Nack Nack Nack Nack Nack Nack Nack Nack
S4000 (except 30W GSM 1800) S2000 (E) / S4000 smart S4000Indoor S4000Outdoor Cavity Dp 2 Pr Nack Nack Nack Nack Nack Nack Nack Nack Nack Pmax Pmax Pmax2 Pmax2 Pmax4 Pmax4 Pmax6 Pmax6 Pmax8 Pmax8 Pmax10 Pmax10 Pmax12 Pmax12 Nack Nack Nack Nack Nack Nack Nack S4000Indoor Cavity 3 Pr Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Pmax Pmax Pmax2 Pmax2 Pmax4 Pmax4 Pmax6 Pmax6 Pmax8 Pmax8 Pmax10 Pmax10 Pmax12 Pmax12 Nack Nack Nack Nack Nack Nack S4000Outdoor S4000Indoor (25W) H2D H2/H2D/Dp 4 Pr Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Pmax Pmax Pmax2 Pmax2 Pmax4 Pmax4 Pmax6 Pmax6 Pmax8 Pmax8 Pmax10 Pmax10 Pmax12 Pmax12 Nack Nack Nack Nack Nack S4000Indoor H4 7 Pr Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Nack Pmax Pmax Pmax2 Pmax2 Pmax4 Pmax4 Pmax6 Pmax6 Pmax8 Pmax8 Pmax10 Pmax10 Pmax12 Pmax12 Nack Nack
Table 52bisPR VS BSTXPWRMAX
Note: Codano 1067 The Tx has not acknowledged the power consign request.
Page 2118
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
In the previous table, we could see that Pmax is obtained for:

Bts Type S8000 Dp S8000 Tx Filter S8000 H2D S8000 H4D bsTxPwrMax 42 or 43 42 or 43 39 or40 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 Duplexeur (Dp) Tx FILTER (TxF) H2D H4D 1 1 5 8.5 GSM 1800 1.2 1 5 8.5 GSM 1900 1.2 1 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.
GSM/BSS V12
Page 2119
Algorithms
S8000 Example: Maximum insertion attenuation (guaranted): GSM 900: GSM1800&1900: Characteristic impedance: Total length: Maximum cable diameter: 0.2 dB Outdoor BTS, 0.25 dB Indoor BTS 0.3 dB Outdoor BTS, 0.35 Indoor BTS 50 290 mm 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: GSM 900 GSM1800&1900: Characteristic impedance: Maximum cable diameter: L 305 mm 0.25 dB Outdoor BTS, 0.35 dB Indoor BTS 0.40 dB Outdoor BTS, 0.5 dB Indoor BTS 50 5.5 mm
Page 2120
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
2.12.3.4
Ps Computation Losses coupling 900 1800&1900 1.2 1 5 8.5 0.2 0.2 0.2 0.2 Losses in the cables 900 0.25 0.25 0.25 0.25 = 0.45 = 0.45 = 0.45 = 0.45 1800&1900 0.3 0.3 0.3 0.3 0.4 0.4 0.4 0.4 = 0.7 = 0.7 = 0.7 = 0.7 Total losses 900 1.45 1.45 5.45 8.95 1800&1900 1.9 1.7 5.7 9.2
Diplexeur TxFilter H2D H4D
1 1 5 8.5
Table 24
S8000 OUTDOOR
Losses coupling 900 Diplexeur TxFilter H2D H4D 1 1 5 8.5 1800&1900 1.2 1 5 8.5 0.25 0.25 0.25 0.25
Losses in the cables 900 0.35 0.35 0.35 0.35 = 0.6 = 0.6 = 0.6 = 0.6 1800&1900 0.35 0.35 0.35 0.35 0.5 0.5 0.5 0.5 = 0.85 = 0.85 = 0.85 = 0.85
Total losses 900 1.6 1.6 5.6 9.1 1800&1900 2.05 1.85 5.85 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)
GSM/BSS V12
Page 2121
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. *: Number of measures before reporting the first measure of an other band neighbor cell.
Mobile Brand TEMS SH888 Motorola Bosch 738
Time (Number of measures) 10 to 18 measures * 1 to 5 measures * 4 to 13 measures *
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
Page 2122
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
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. 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).
GSM/BSS V12
Page 2123
Algorithms
Sys info 2 Sys info 5 GSM900 cell GSM 1800 cell GSM900 nei list GSM1800 nei list
Sys info 2bis Sys info 5bis GSM1800 nei list
Sys info 2ter Sys info 5ter 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.
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.
Page 2124
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
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). 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.
GSM/BSS V12
Page 2125
Algorithms
2.14
INTERFERER CANCELLATION
Interference cancellation is a very important feature in a mobile network, especially when capacity is a critical issue and aggressive frequency reuse schemes are applied to maximize it. Experience is not sufficient yet to know when capacity is limited by uplink interferers but preliminary studies indicate that it can typically happen in a 1/3 network. In general, even if capacity is not limited by uplink interferers, it is essential to mitigate their effect for quality improvement. A typical example is the case where a tight reuse pattern is applied with frequency hopping and fractional loading, like Nortels 1/3 scheme. Capacity will be limited by the occurrence of the same frequency in closely spaced cells i.e. by cochannel interferers. The studies indicate that in these situations it is most likely that the uplink interferers will be the limiting factors. More generally, strong interferers are likely to occur in any mobile network and they can strongly affect the call quality. A BTSbased interference cancellation algorithm is of great interest. Nortel has designed a proprietary signal processing scheme aimed at cancelling the interferers. It works on the Base Stations equipped with the socalled EGAL2 DRX (S8000 and S2000), with antenna diversity and after the V10 software version. The algorithm works as well with or without frequency hopping and it can remove any kind of interferer that has some spatial or temporal coherence (cochannel, adjacent channel, CDMA signal leaking in the PCS band, TV transmitter, etc..). It can be viewed as a digital beamforming technique in which a null of the radiation pattern is pointed towards the interferer. The algorithm is based on the use of the Maximum Ratio Combining diversity technique and the midamble in the GSM burst that is used to gain some indication of the channel characteristics, and hence an estimate of the noise present. This noise is approximately made up of interference and thermalnoise. The midamble is a known sequence of bits, which undergoes changes after propagation. This leads to an estimation of the impulse response of the channel. If there are no interferers it turns out that this noise estimate is not accurate for two reasons: the useful signal is only approximately reconstructed since the impulse response is only estimated it is biased by the limited number of available samples (22 out of 114 for the full burst). Thus it is better not to try to estimate the noise but to put as an a priori information that there is only white noise. However when there are interferers, it is necessary to estimate them and the algorithm can do it only on the 22 signal samples where the useful signal is known.
Page 2126
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
The r parameter is the interferer cancel algo usage parameter that can be set from the OMC. The r parameter is a compromise parameter that can tradeoff the pure noise performances against the dominant interferer case. The algorithm finds the maximum of the modified signaltonoise ratio:
, = max
(,)
U1 + U22 1 + 2
2
+ (1) 22.N0
U = useful signal N = estimate of noise and interference No = spectral power density of the white noise 1, 2 = index of the different antenna paths. r = 0 implies that we have a constant term at the denominator, the noise energy, and the processing finds the linear combination that maximizes the signal (under the constraint that |a| 2+|b| 2=1), i.e. it performs the maximal ratio combiner (MRC). r = 1 (100%) means that we remove the constant term i.e. the a priori information on the noise. When there is no interference an approximate MRC combiner is performed. other r values like e.g. .5 (50%) mean that a compromise is made between performances at high interference and at pure noise situations. MRC is Nortel equipments diversity combining technique which is known to be the linear combination of signals received on the two antennas, that maximises the S/N ratio when there is only thermal noise (for example it is 1.5dB better than selection combining). It suffers about 2dB loss when there are strong interferers. Simulations have been carried out to show how with the use of MRC, the required CarriertoInt+Noise ratio (C/(I+N)) to maintain a particular BER reduces, as the presence of synchronus/asynchronus interferers increases. Although following the same trend, ICA simulation showed the use of a lower C/(I+N) to maintain the same BER as opposed to only using MRC.
GSM/BSS V12
Page 2127
Algorithms
2.15
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.15.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.15.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.
Page 2128
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
2.16
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.16.1
Customer/service provider benefits This feature allows increasing the rate of paging and immediate assignment messages 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.16.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 0 = FCCH+SCH+BCCH+CCCH, TS 2 = BCCH+CCCH, CCCH_Conf = 4: TS 0 = FCCH+SCH+BCCH+CCCH, TS 2 = BCCH+CCCH, TS 4 = BCCH+CCCH, CCCH_Conf = 6: TS 0 = FCCH+SCH+BCCH+CCCH, 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.
GSM/BSS V12
Page 2129
Algorithms
2.16.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.
Page 2130
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
2.17
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.17.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
GSM/BSS V12
Page 2131
Algorithms
Caution:
This feature is only available at the OMCR if all TCB2 boards have V.12 software. 2.17.2 Feature benefits For users, the benefits of this feature are: Improvement of the voice quality, Better data transmissions. 2.17.3
2.17.3.1
Parameters and counters associated with this feature

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.17.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.
Page 2132
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
2.18
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.18.1
2.18.1.1
Functional description
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).
GSM/BSS V12
Page 2133
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 channel 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
Page 2134
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithms
Caution: BTSs equipped with DCU2 boards or with a mix of DCU2 and DCU4 boards do not support the Uplink Mapping feature.
2.18.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 T0 T1 = T0 + 1 s Tm = T0 + m s Position Pos(T0) Pos(T1) Pos(Tm) FN Frame Number(T0) Frame Number(T1) Frame Number(Tm) Cell Id LAC + CI (T0) LAC + CI (T1) LAC + CI (Tm)
After merging the above data, the data server provides uplink received levels correlated to location information: (c stand for cell and p for position)
Geographical Position Pos. 1 Pos. 2 Pos. M Cell 1 RxLevUL(c1, p1) RxLevUL(c1, p2) RxLevUL(c1, pM) Cell 2 RxLevUL(c2, p1) RxLevUL(c2, p2) RxLevUL(c2, pM) Cell N
RxLevUL(cN, p1) RxLevUL(cN, p2) RxLevUL(cN, pM)
GSM/BSS V12
Page 2135
Algorithms
2.18.2
2.18.2.1
Main benefits
Customer/Service provider benefits
The main benefit of this feature is to make available coverage maps and consequently interference matrixes based on field measurements. These interference matrixes are then used to compute a better BCCH frequency plan, which is a mandatory 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.18.2.2 Enduser/subscriber benefits
The improvement of the BCCH frequency plan provides a better quality in the network. So a better quality of service can be offered to the subscribers.
Page 2136
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Algorithm parameters
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) Note: The following types of parameters can be distinguished: Customer engineering parameters: Addressing: Design: relative to an object contract characteristic
Optimization: network tuning Operation: network operation
Manufacturer parameters: System: Product: DP: modifying such a parameter seriously impacts system behaviour parameters related to the current system release stands for permanent data
GSM/BSS V12
Page 31
OMCR class gives rules to be followed when modifying a parameter:

CLASS Class 0 Class 1 Rules Implies reconstruction of the BDA
Page 32

Put BSC out of service (i.e. BSC state set to locked), takes new parameters into account by resetting active chain and passive chains. Declares the object (or its parent) temporarily outofservice before modification Modification is dynamically taken into account Class 2 Class 3
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
3.2
CELL SELECTION AND RESELECTION PARAMETERS

cellReselectHysteresis Class 3C1 Description : Range value : Object : Default value : Type : Hysteresis to reselect towards cell with different Location Area [0 to 14, by steps of 2] dB bts 6 DP , Optimization
Recommended value : 4 dB (rural), 6 dB (urban) Used in : Engineering Rules : Sel_2 (Cf page 211). 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). (CPU load, LU) C1400C1193/1 CELL_RESELECT_HYSTERESIS , ETSI GSM 04.08 V8
Counters : GSM :
cellReselectOffset Class 3C2 Description : Range value : Object : Feature : Default value : Type :
Encouragement to reselect a cell (C2 criterion) for phase 2 MS [0 to 126, by steps of 2] dB bts AR 264 0 DP , Optimization
Recommended value : Between 4 and 10 Used in : Sel_3 (Cf page 211).
GSM/BSS V12
Page 33
Engineering Rules :
Otherwise, if there is no privileged layer, the recommended value remains the same for both sites, between 4 dB and 10 dB. CELL_RESELECT_OFFSET , ETSI GSM 05.08 DP , Optimization V8
GSM : Type :
cellReselInd Class 3 C3 Description : Range value : Object : Default value : Type :
Whether cell reselection criterion (C2) use is authorized [true / false] bts False DP , Optimization
Recommended value : True Used in : Engineering Rules : Sel_3 (Cf page 211). 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) bts Typical value of 33 dBm for GSM 900 handhelds, 30 dBm for GSM 1800 and 1900 DP , Optimization
Object : Default value : Type :
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).
Page 34
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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. MS_TXPWR_MAX_CCH , ETSI GSM 04.08 V8
GSM :
penaltyTime Class 3 P1 Description : Range value :
Timer used by an idle mobile before reselecting a cell (C2 criterion) [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). bts AR 264 20 DP , Optimization
Object : Feature : Default value : Type :
Recommended value : 20 Used in : Engineering Rules : Sel_3 (Cf page 211). 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. 640 None, because internal MS algorithm ETSI GSM 05.08
Default value : Counters : GSM :
GSM/BSS V12
Page 35
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 : Object : Default value : Type : [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm bts less than 110 dBm DP , Optimization
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)).
Page 36
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Example:
R1 R2
100 dBm
99 dBm
RxLevAccessMin 1 = 100 dBm RxLevAccessMin 2 = 99 dBm A rough calculation gives the following impact on the cell access surface: Engineering Rules : Access Zone 1 = Access Zone 2 x 1.2 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. 101 to 100 dBm (RACH, TCH, SDCCH) C1026C1027C1033, C1051/0C1051/1C1051/2, C1034C10351036C1193/2. RXLEV_ACCESS_MIN , ETSI GSM 04.08 V8
Default value : Counters :
GSM :
temporaryOffset Class 3T1 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.
Range value :
[0 to 70, by steps of 10] dB
GSM/BSS V12
Page 37
bts AR 264 70 DP , Optimization
Recommended value : 0 (microcell & macrocell in monolayer) 70 (macrocell in multilayers) Used in : Engineering Rules : Sel_3 (Cf page 211). 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). none, because internal MS algorithm ETSI GSM 05.08
Counters : GSM :
Page 38
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 : Object : Default value : Type : [allowed / not allowed] bts not allowed DP , Optimization
Recommended value : allowed (from GSM08 for DMSMSC) Used in : Engineering Rules : Counters : GSM : Rlfms (Cf page 280), Cr (Cf page 281). Enabling or not this feature is a MSC capability issue C1051C1193/2 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.
GSM/BSS V12
Page 39
0
radio link failure decoded expected but not decoded
Range value : Object : Default value : Type :
[4 to 64, by steps of 4] SACCH frames (1 unit = 480 ms on TCHs, 470 ms on SDCCHs) bts 20 SACCH DP , Design
Recommended value : 20 Used in : Engineering Rules : Rlfms (Cf page 280). 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
Counters : GSM :
anger and taxation increase before actual calls end or reestablishment. (Call drop on RLF) C1164/14 RADIO_LINK_TIMEOUT , ETSI GSM 05.08
Page 310
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
rlf1 Class 2 R2 Description :
V8 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 : Object : Feature : Default value : Type : [0 to 15] bts CM141 4 DP , Optimization
Recommended value : 4 Used in : Engineering Rules : Rlfbs (Cf page 280). 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. 4 (Call drop on RLF) C1164/14
GSM/BSS V12
Page 311
rlf2 Class 2 R3 Description :
V8 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 : Object : Feature : Default value : Type :
[1 to 4] SACCH frames bts CM141 2 DP , Optimization
Recommended value : 2 Used in : Engineering Rules : Rlfbs (Cf page 280). 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. 2 (Call drop on RLF) C1164/14 V8 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 : Object : Feature : Default value : Type : [1 to 4] SACCH frames bts CM141 1 DP , Optimization
Default value : Counters : rlf3 Class 2 R4 Description :
Page 312
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : 1 Used in : Engineering Rules : Rlfbs (Cf page 280). 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. 1 (Call drop on RLF) C1164/14
GSM/BSS V12
Page 313
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 : Object : Default value : Type : [100 to 200] % handOverControl 110 DP , Optimization
Recommended value : 110 Used in : Engineering Rules : Counters : GSM : Mp The higher the value is, the higher the missing measurement will be weighted. (Ho on Quality) C1138/2C1138/3C1138/8C1138/9 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 [1 to 10] number of measurement results handOverControl 8 DP , Optimization
Recommended value : 4 in urban environment ; > 8 in rural environment Used in : Mp
Page 314
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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. (Ho on Quality) C1138/2C1138/3C1138/8C1138/9 RXQUAL_HREQAVE
Counters : GSM :
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. [1 to 16] handOverControl 1 DP , Optimization
Recommended value : 1 Used in : Engineering Rules : Mp 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. 1 (Ho on Quality) C1138/2C1138/3C1138/8C1138/9 RXQUAL_HREQT
GSM/BSS V12
Page 315
rxQualWtsList Class 3 R7 Description : Range value : Object : Default value : Type : List of up to sixteen weights used to compute the average bit error rate on a radio link [0 to 100] % handOverControl 100 DP , Optimization
Recommended value : 100 Used in : Engineering Rules : Mp 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). 100 (Ho on Quality) C1138/2C1138/3C1138/8C1138/9 RXQUAL_WT
Page 316
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 measurements not favored. Range value : Object : Default value : Type : [0 to 100] % handOverControl 90 DP , Optimization
Recommended value : 90 Used in : Default value : Counters : GSM : Mp 90 (HO PBGT, HO Rxlev) C1138/5, C1138/0C1138/1 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 [1 to 10] number of measurement results handOverControl 8 DP , Optimization
Recommended value : 6 for small cells (Dintersite < 800m) between 8 and 10 for large cells (Dintersite > 1600m) Used in : Mp
GSM/BSS V12
Page 317
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. 8 (HO PBGT, HO Rxlev) C1138/5, C1138/0C1138/1 RXLEV_HREQAVE V11
rxLevHreqaveBeg Class3 R9 Description : Range value : Object : Feature : Default value : Type :
Number of measurement reports on current cell for signal strength arithmetic average for early handover mechanism [1 to 10] handOverControl TF809 2 DP , Optimization
Recommended 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.
Page 318
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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. [1 to 16] handOverControl 1 DP , Optimization
Recommended value : 1 Used in : Engineering Rules : Mp 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. (HO PBGT, HO Rxlev) C1138/5, C1138/0C1138/1 RXLEV_HREQT
Counters : GSM :
rxLevWtsList Class 3 R11 Description : Range value : Object : Default value : Type : Values of weights to be used for signal strength weighed average [0 to 100] % handOverControl 100 DP , Optimization
GSM/BSS V12
Page 319
Recommended value : 100 Used in : Engineering Rules : Counters : GSM : Mp Arithmetic law to be preferred, biggest weight for most recent reports (HO PBGT, HO Rxlev) C1138/5, C1138/0C1138/1 RXLEV_WT
Page 320
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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. Range value : Object : Default value : Type : [0 to 31] bts 5 in rural environment, 2 in microcell environment DP , Design
Recommended value : 5 in rural, 2 in urban environment cf. Section 4.7 about neighbor cells stability Used in : Engineering Rules : Mp 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. (HO) CELL_DELETE_COUNT
Counters : GSM :
rxNCellHreqave Class 3 R12 Description : Number of measurement results used in the PBGT algorithm to compute the average neighboring signal strength [1 to 10] number of measurement results handOverControl 8 DP , Optimization
GSM/BSS V12
Page 321
Recommended value : = rxLevHreqAve 6 for small cells (Dintersite < 800m) between 8 and 10 for large cells (Dintersite > 1600m) Used in : Engineering Rules : Mp 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. (Ho) from C1138/0 to C1138/9 NCELL_HREQAVE V11
Counters : GSM :
rxLevNCellHreqaveBeg Class 3 R13 Description :
Number of measurement results used in early handover algorithm to compute the average neighboring signal strength [1 to 10] handOverControl 2 TF809 DP , Optimization
Range value : Object : Default value : Feature : Type :
Recommended value : 2 Engineering Rules : rxNCellHreqaveBeg < rxLevNCellHreqave This parameter has to be coupled with hoMarginBeg and rxLevHreqaveBeg. This parameter is only available for DCU4 or DRX transceiver architecture. 2
Default value :
Page 322
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 [1 to 16] handOverControl 4 DP , Optimization
Recommended value : 4 Used in : Engineering Rules : Mp For distance handover and Call Clearing, a weighted average of the MSBS distance is computed from timingadvance results. (HO Dist) C1138/4 DIST_HREQT , ETSI GSM 05.08
Counters : GSM :
distWtsList Class 3 D2 Description : List of no more than sixteen weights, used to compute the average MS-to-BTS distance from distHreqt measurements [0 to 100] % handOverControl 40 30 20 10 DP , Optimization
Recommended value : 40 30 20 10 Used in : Engineering Rules : Mp 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. (HO Dist) C1138/4 DIST_WT , ETSI GSM 05.08
Counters : GSM :
GSM/BSS V12
Page 323
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 measurements not favored. Range value : Object : Default value : Type : Used in : Engineering Rules : Counters : GSM : [100 to 200] % handOverControl 110 DP , Optimization Mp The higher the value is, the higher the missing measurement will be weighted. (HO Dist) C1138/4 MISS_DIST_WT
Page 324
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
3.8
HANDOVER (GLOBAL) PARAMETERS

biZonePowerOffset Class 3 B1 Description : V12
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 : Object : Type : Feature : Default value : Note :
[63 to 63] dB adjacentCellHandOver DP , Optimization Dualband cell management (TF875 V12) 63 This parameter is only available for S8000 or ecell BTS DRX transceiver architecture.
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.
GSM/BSS V12
Page 325
biZonePowerOffset Class 3 B2 Description :
V12
Power offset between inner and outer TRXs of the handOverControl object of a dualband, dualcoupling, or concentric cell. [63 to 63] dB handOverControl 0 DP , Optimization Dualband cell management (TF875 V12)
Range value : Object : Default value : Type : Feature : Note :
This parameter is only available for S8000 or ecell BTS DRX transceiver architecture.
Recommended value :
concentric cell:
zoneTxPwrMaxReduction (inner zone)

dualcoupling:
D/H2D: H2D/H4D:
dualband:
max (0, bsTxPwrMax40) max (0, bsTxPwrMax36)
3dB + x (for gsmdcs) 3dB + x (for dcsgsm) where x = max (0, bsTxPwrMax40) for D/H2D max (0, bsTxPwrMax36) for H2D/H4D Engineering Rules : 0 otherwise 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.
Page 326
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
bts time between HO configuration Class 3 B3 Description : Range value :
V9
Whether the HOPingpongTimeRejection timer can be used at bts level when processing handovers [0 to 60] second for V9 to V11 [0 / 1] for V12
0: 1:
The timer is disabled. The timer is used. against pingpong handovers
bts General protection (TF821 V12) 0 DP , Optimization
Recommended value : 1 (or old value V9, if range [0 to 60]) Used in : Engineering Rules : Ho_11 (Cf page 254). 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
Counters :
Pingpong in chapter Algorithms. Tchoke, Tminho.
GSM/BSS V12
Page 327
forced handover algo Class 3 F1 Description :
V9
Minimum signal strength level received by the mobiles to be granted access to a neighbor cell in case of forced handover [less than 110, 110 to 109, ..., 49 to 48, more than 48] dBm handOverControl less than 110 DP , Optimization
Recommended value : = rxLevMinCell 1 HandOver from signalling channel Class 3 H1 Description : Range value : Object : Default value : Type : Authorization to perform intercell handovers on signalling channels (SDCCH or TCH in signalling mode) [enabled / disabled] handOverControl disabled DP , Design
Recommended value : disabled Used in : Engineering Rules : Counters : GSM : hoMargin Class 3 H2 Description : Range value : Object : Default value : Type : Margin to use for PBGT handovers to avoid subsequent handover, in PBGT formula [63 to 63] dB adjacentCellHandOver 4 DP , Optimization Ho It is recommended to enable this feature when queueing is activated. (HO on SDCCH) from C1139/0 to 1139/9 SDCCH_USED
Page 328
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : between 4 and 6 for small cells (4 in an 1:1 pattern, 5 or 6 otherwise), 5 for large cells. Used in : Engineering Rules : Ho_6 (Cf page 236). 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. (HO on PBGT) C1138/5 HO_MARGIN , ETSI GSM 05.08 V11
Counters : GSM :
hoMarginBeg Class 3 H3 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.
Range value : Object : Feature :
[63 to 63] dB bts TF809
GSM/BSS V12
Page 329
Default value : Type :
4 DP , Optimization
Recommended value : 4 dB Engineering Rules : This parameter is only available for DCU4 or DRX transceiver architecture. hoMarginDist Class 3 H4 Description : Range value : Object : Default value : Type : Feature : Margin to be used for Distance Handovers [63 to 63] dB adjacentCellHandOver 24 dB DP , Optimization TF 213 and 219 V8
Recommended value : 2 dB. Depends on the environment and on the value of the msRangeMax Threshold. Used in : Ho_6 (Cf page 236). 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. 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. (HO on Dist) C1338/4 HOMARGIN V8
Counters : GSM :
hoMarginRxLev Class 3 H5 Description : Range value : Object : Margin to be used for signal strength Handovers [63 to 63] dB adjacentCellHandOver
Page 330
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Feature : Default value : Type :
TF 213 and 219 24 dB DP , Optimization
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. Used in : Engineering Rules : Ho_6 (Cf page 236). 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. 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 : GSM : (Ho on Rxlev DL + UL) C1138/0C1138/1 HOMARGIN
GSM/BSS V12
Page 331
hoMarginRxQual Class 3 H6 Description : Range value : Object : Feature : Default value : Type : Margin to be used for Signal Quality Handovers [63 to 63] dB adjacentCellHandOver TF 213 and 219 24 dB DP , Optimization
V8
Recommended value : in [2; 0] without SFH in [1; (hoMargin2)] with SFH (# 2 or 3) Used in : Engineering Rules : Ho_6 (Cf page 236). 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. 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. C1138/2C1138/3 HOMARGIN V12
Counters : GSM :
hoMarginTrafficOffset Class 3 H7 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 [0 to 63] dB adjacentCellHandOver DP , Optimization
Range value : Object : Type :
Page 332
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Feature :
Handover for traffic reasons (TF132 V12)
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 Description :
V12
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.
GSM/BSS V12
Page 333
Range value : Object : Type : Feature :
[rxQual, rxLev, distance, powerBudget, capture, directedRetry, OaM, traffic, all, allCapture, allPowerBudget] adjacentCellHandOver DP , Optimization General protection (TF821V12) against pingpong handovers
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).
Page 334
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 btsTimeBetweenHOconfiguration shall be accordingly in order the feature to be activated. and set
HOPingpongTimeRejection Class 3 H9 Description :
V12
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 : Object : Feature :
[0 to 60] s adjacentCellHandOver General protection (TF821V12) against pingpong handovers
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).
GSM/BSS V12
Page 335
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 Description : V9
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).
[1 to 3] bsc 1 DP , Design
Recommended value : 3 Used in : Engineering Rules : Ho_10 (Cf page 248). 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. C1167 C1168 C1169 1170
Counters :
Page 336
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
hoTraffic Class 3 H11 Description : Range value : Object : Default value : Type : Feature :
V12
Whether handovers for traffic reasons at bsc level are allowed. [disabled / enabled] bsc disabled DP , Optimization Handover for traffic reasons (TF132 V12)
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. V12
hoTraffic Class 3 H12 Description : Range value : Object : Default value : Type : Feature :
Whether handovers for traffic reasons at bts level are allowed. [disabled / enabled] bts disabled DP , Optimization Handover for traffic reasons (TF132 V12)
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.
GSM/BSS V12
Page 337
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. [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) bts Typical value of 33 dBm for GSM 900 handhelds and 30 dBm for GSM 1800 and 1900 handhelds DP , Optimization
Range value :
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 260). 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). [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 network and GSM 1800 GSM 900) [0 to 33] dBm (GSM 1900 network) adjacentCellHandOver Typical value of 33 dBm for GSM 900 handhelds and 30 dBm for GSM 1800 and 1900 handhelds DP , Optimization
Range value :
Page 338
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : msTxPwrMaxCell = msTxPwrMaxCCCH of the current cell. Typical value of 33 dBm for GSM 900 handhelds and 30 dBm for GSM 1800 and 1900 handhelds Used in : Ho_5 (Cf page 236), 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 Description : Range value : Object : Type : Feature : V12 Load offset applied by the bsc to the cell selection process [0 to 63] dB adjacentCellHandOver DP , Optimization Handover decision according to adjacent cell priority and load (TF716 V12)
Recommended value : 3 dB 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.
GSM/BSS V12
Page 339
offsetPriority Class 3 O2 Description : Range value : Object : Type : Feature :
V12
Priority offset applied by the bsc to the cell selection process [1 to 5] adjacentCellHandOver DP , Optimization Handover decision according to adjacent cell priority and load (TF716 V12)
Recommended value : 1 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 : Range value : Object : Default value : Type : Authorization to perform intercell handovers for power budget [enabled / disabled] handOverControl enabled DP , Optimization
Recommended value : enabled Engineering Rules : Handover on PBGT should be enabled, because for an optimized network it ensures the best quality of service.
Page 340
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
runHandOver Class 3 R14 Description : Number of Measurement Results messages that must be received before the handover algorithm in a cell is triggered. [1 to 31] SACCH frames (1 unit = 480 ms on TCHs, 470 ms on SDCCHs) bts 1 DP , System !
Recommended value : 1 (from V11), 2 (until V10) Used in : Engineering Rules : Ho 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. (HO, CPU load) from C1038/0 to C1038/9 C1400 RUN_HANDOVER
Counters : GSM :
rxLevMinCell Class 3 R15 Description : Range value : Object : Default value : Type : Minimum signal strength level received by MS for being granted access to a neighbor cell [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm adjacentCellHandOver 95 to 94 dBm (GSM 900), 93 to 92 (GSM 1800) DP , Optimization
GSM/BSS V12
Page 341
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. Used in : Engineering Rules : Ho_5 (Cf page 236). 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
For a dual Band Network where one frequency band is 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.
Page 342
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
t 50 km/h
margin with FH margin without FH 2 dB 5 dB
u 50 km/h t 80 km/h 2 dB 4 dB 2 dB
u 80 km/h
2 dB 2 dB
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 margin with FH margin without FH 2 dB 5 dB
C/I= 20 3 dB 6 dB
C/I= 15 4 dB 10 dB
Counters : GSM :
(HO, CD) from C1138/0 to C1138/9C1164/14 RXLEV_MIN(n) , ETSI GSM 05.08
GSM/BSS V12
Page 343
synchronized Class 3 S1S2 Description : Range value : Whether the neighbor cell and the associated serving cell are synchronous, that is attached to the same BTS [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
Object : Type : Engineering Rules :
timing advance is used in the presynchronized handover procedure between the serving cell and the neighbor cell. Refer to preSynchroTimingAdvance parameter. adjacentCellHandOver DP , Optimization 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.
Caution:
It is recommended to use the not synchronized cells value for this parameter even for synchronized cells. This is due to the higher number of HO failure noticed in a site using synchronized cells compared to the same site using not synchronized cells .
Page 344
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
timeBetweenHOConfiguration Class 3 T2 Description :
V9
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 : Object : Feature : Default value : Type :
[used / not used] bsc General protection (TF821 V12) used DP , Design against pingpong handovers
Recommended value : used Used in : Engineering Rules : Ho_11 (Cf page 254). See engineering rules for btstimeBetweenHOConfiguration the parameter
GSM/BSS V12
Page 345
3.9
INTRACELL HANDOVER PARAMETERS

intraCell Class 3 I1 Description : Range value : Whether intra-bts handovers on TCH are allowed in a cell for interference reasons or CellTiering reasons [cellTieringHandover handoverNotAllowed] / intraCellHandover /
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 handOverControl Automatic Cell Tiering (TF995V12) disabled DP , Design
Recommended value : handoverNotAllowed or cellTieringHandover Used in : Engineering Rules : Ho_1 (Cf page 231). 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. (Ho on quality) C1138/8C1138/9C1081C1082C1083C1134 INTRACELL_USED , ETSI GSM 05.08
Counters : GSM :
Page 346
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
intraCellSDCCH Class 3 I2 Description : Range value : Object : Feature : Default value : Type :
V8
Whether intra-bts handovers on SDCCH are authorized in a cell for interference reasons [enabled / disabled] handOverControl CM 143 disabled DP , Optimization
Recommended value : disabled Used in : Ho_1 (Cf page 231). Engineering Rules : None except system ability. Note that, some mobiles have been reported to drop the call when that feature is performed. Default value : disabled Counters : (SDCCH intracell Ho) C1154C1155C1156C1157C1139/8C1139/9 ETSI GSM 05.08 GSM : rxLevDLIH Class 3 R16 Description : Range value : Object : Default value : Type : Maximum interference level in BTS-to-MS direction, beyond which an intra cell handover may be triggered [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm handOverControl 85 to 84 dBm DP , Optimization
Recommended value : 85 to 84 dBm Used in : Ho_1 (Cf page 231). Engineering Rules : lrxlevDLH < rxLevDLIH <= lRxLevDLP
Caution: Path balance must be considered for this threshold parameter setting. C1081C1082C1083C1134C1138/9 RXLEV_DL_IH , ETSI GSM 05.08
Counters : GSM :
GSM/BSS V12
Page 347
rxLevULIH Class 3 R17 Description : Range value : Object : Default value : Type : Maximum interference level in MS-to-BTS direction, beyond which an intra cell handover may be triggered [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm handOverControl 85 to 84 dBm DP , Optimization
Recommended value : 85 to 84 dBm Used in : Engineering Rules : Ho_1 (Cf page 231). lrxlevULH < rxLevULIH <= lRxLevULP
Caution: Path balance must be considered for this threshold parameter setting. C1081C1082C1083C1134C1138/8 RXLEV_UL_IH , ETSI GSM 05.08 V12
Counters : GSM :
rxQualDLIH Class 3 R18 Description :
Bit error rate threshold in BTStoMS direction for intracell handover, above which a handover may be triggered. [less than 0.2, 0.2 to 0.4, 0.4 to 0.8, ... , 6.4 to 12.8, more than 12.8] % handOverControl DP , Optimization Intracell handover enhancements (TF819 V12)
Recommended value : rxQualDLIH lRxQualDLH
Page 348
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 Description :
V12
Bit error rate threshold in MStoBTS direction for intracell handover, above which a handover may be triggered. [less than 0.2, 0.2 to 0.4, 0.4 to 0.8, ... , 6.4 to 12.8, more than 12.8] % handOverControl DP , Optimization Intracell handover enhancements (TF819 V12)
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.
GSM/BSS V12
Page 349
3.10
INTERCELL HANDOVER THRESHOLDS

lRxLevDLH Class 3 L1 Description : Range value : Object : Default value : Type : Signal strength threshold in BTS-to-MS direction, below which a handover may be triggered [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm handOverControl 101 to 100 dBm (GSM 900) 99 to 98 dBm (GSM1800/1900) DP , Optimization
Recommended value : 95 to 94 dBm in urban environment (900 MHz) 101 to 100 dBm in rural environment (900 MHz) Used in : Engineering Rules : Ho_3 (Cf page 232). 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. C1138/1C1139/1 L_RXLEV_DL_H , ETSI GSM 05.08
Counters : GSM :
lRxLevULH Class 3 L2 Description : Range value : Object : Default value : Type : Signal strength threshold in MS-to-BTS direction, below which a handover may be triggered [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm handOverControl 101 to 100 dBm (GSM 900) 99 to 98 dBm (GSM 1800/1900) DP , Optimization
Page 350
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : 95 to 94 dBm in urban environment (900 MHz) 101 to 100 dBm in rural environment (900 MHz) Used in : Engineering Rules : Ho_3 (Cf page 232). 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 C1138/0C1139/0 L_RXLEV_UL_H , ETSI GSM 05.08
Counters : GSM :
lRxQualDLH Class 3 L3 Description : Range value : Object : Default value : Type : Bit error rate threshold in BTS-to-MS direction, above which an inter cell handover may be triggered [less than 0.2, 0.2 to 0.4, 0.4 to 0.8, ... , 6.4 to 12.8, more than 12.8] % handOverControl 1.6 to 3.2 % DP , Optimization
Recommended value : 1.6 to 3.2 % (4 in rxqual GSM unit) without frequency hopping. See Engineering Rules in case of frequency hopping. Used in : Ho_1 (Cf page 231), Ho_2 (Cf page 231).
GSM/BSS V12
Page 351
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 %). When using both frequency hopping and DTX, it is highly recommended to disable handovers on quality criteria. Then, in the case, maximum value (7) must be assigned to rxQual thresholds or set hoMarginRxQual to 63 dB for the concerned neighbour cells.
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 : GSM :
C1138/2C1138/3C1139/2C1139/3 L_RXQUAL_DL_H, ETSI GSM 05.08
Page 352
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
lRxQualULH Class 3 L4 Description : Range value : Object : Default value : Type : Bit error rate threshold in MS-to-BTS direction, above which an inter cell handover may be triggered [less than 0.2, 0.2 to 0.4, 0.4 to 0.8, ... , 6.4 to 12.8, more than 12.8] % handOverControl 1.6 to 3.2 % DP , Optimization
Recommended value : 1.6 to 3.2 % (4 rxqual GSM unit)without frequency hopping. See Engineering Rules in case of frequency hopping. Used in : Engineering Rules : Ho_1 (Cf page 231) and Ho_2 (Cf page 231). 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 %). When using both frequency hopping and DTX, it is highly recommended to disable handovers on quality criteria. Then, in the case, maximum value (7) must be assigned to rxQual thresholds or set hoMarginRxQual to 63 dB for the concerned neighbour cells.
GSM/BSS V12
Page 353
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. C1138/2C1138/3C1139/2C1139/3 L_RXQUAL_UL_H, ETSI GSM 05.08 V11
Counters : GSM :
rxLevDLPBGT Class 3 R20 Description : Range value : Object : Feature : Default value : Type : Engineering Rules :
Downlink signal strength threshold above which handover for power budget are inhibited [less than 110, 110 to 109,..., 49 to 48, more than 48] dBm adjacentCellHandOver TF818 less than 110 DP , Optimization 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). This parameter is only available for DCU4 or DRX transceiver architecture. It shall be disabled for DCU2 architecture.
Page 354
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 : Range value : Object : Default value : Type : Type of the adjacent cell [normalType / umbrellaType / microType] adjacentCellHandOver normalType DP , Design
Recommended value : normalType Used in : Engineering Rules : Ho__A (Cf page 245). 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 : Range value : Object : Default value : Type : Type of the serving cell [normalType / umbrellaType / microType] bts normalType DP , Design
GSM/BSS V12
Page 355
Recommended value : normalType Used in : Engineering Rules : Ho__A (Cf page 245). 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 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. V8
microCellCaptureTimer Class 3 M7 Description : Range value : Object : Feature : Default value : Condition : Type :
Time used to confirm a capture (signal strength stability) when using microcell Algorithm type A [0 to 255] multiple of <runHandOver> adjacentCellHandOver AR 108 0 To define if A handover algorithm is activated DP , Design
Recommended value : 8s, whatever runHandOver value (8 if runHandOver = 2, 16 if runHandOver = 1) Used in : Engineering Rules : Counters : Ho__A (Cf page 245). Experiments done in urban areas show that a timer of 8 seconds to 10 seconds allows a better use of the capture. C1138/6
microCellStability class 3 M8 Description : Range value : Object : Default value : Condition : Type : Strength Level Algorithm A Stability Criterion for Capture
[0 to 255] dB adjacentCellHandOver 10 To define if A handover algorithm is activated DP , Design
Page 356
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : 63 dB Used in : Engineering Rules : Ho__A (Cf page 245). 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. C1138/6
Counters :
GSM/BSS V12
Page 357
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. [2 to 35] km (nonextended mode) [2 to 120] km (extended mode) bts 35 in nonextended mode , 90 in extended mode 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 : Engineering Rules :
Cc (Cf page 282). 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 (CD on Dist) C1164/12 MS_RANGE_MAX_CLEAR V9
Counters : GSM :
extended cell Class 2 E1 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
Page 358
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
concentAlgoExtMsRange
and concentAlgoIntMsRange attributes of the associated handOverControl object if the bts object describes a concentric cell
Range value : Object : Default value : Type : Engineering Rules :
[true (extended) / false (normal)] bts False DP , Optimization 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 [1 to 34] km (nonextended mode) [1 to 120] km (extended mode) handOverControl 34 in nonextended mode, 89 in extended mode DP , Optimization
Recommended value : = callClearing 1 km Used in : Ho_4 (Cf page 235).
GSM/BSS V12
Page 359
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 : GSM :
C1138/4 MS_RANGE_MAX_HAND
msBtsDistanceInterCell Class 3 M10 Description : Range value : Object : Default value : Type : Whether inter-bts handovers are allowed in a cell for distance reasons [enabled / disabled] handOverControl enabled DP , Optimization
Recommended value : enabled Used in : Engineering Rules : Ho_4 (Cf page 235). 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. C1138/4 MS_BS_DIST_USED
Counters : GSM :
Page 360
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
preSynchroTimingAdvance Class 3 P3 Description :
V10
Predefined timing advance used in a presynchronized handover procedure between the serving cell and this neighbor cell. [1 to 35] (km) adjacentCellHandOver, adjacentCellReselection 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 Description : Range value : Object : Default value : Type :
V8
MS-to-BTS distance beyond which mobile access requests to a cell are refused. [2 to 35] km (nonextended mode) [2 to 120] km (extended mode) bts 35 (nonextended cell), 90 (extended cell) DP , Optimization
Recommended value : msRangeMax (= call clearing 1km = 1.5* cell diameter + 2 km 1 km)
GSM/BSS V12
Page 361
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. For example, for small cells, if the value is 35 km, almost 30% of the RACHs are parasite. If the value is modified to 2, almost no parasite RACH are detected. 1185/0, 1702
Counters :
runCallClear Class 3 R22 Description : Number of Measurement Results messages that must be received before the call clearing algorithm in a cell is triggered [1 to 31] SACCH frames (1 unit = 480 ms on TCHs, 470 ms on SDCCHs) bts 16 DP , System !
Recommended value : 16 Used in : Engineering Rules : Cc (Cf page 282). 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. (CD on Dist) C1164/12 RUN_CALL_CLEAR
Counters : GSM :
Page 362
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 Description : V9
Attenuation due to coupling system losses. This value depends on the BTS configuration and should not be modified by the operator. [0 to 14] dB btsSiteManager Depends on the equipment DP , Optimization
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 : Range value : Object : Default value : Type : Whether radio measurements collected by the mobiles for a cell are processed by the BTS or the BSC [preProcessedMeasurementReporting (BTS) / basicMeasurementReporting (BSC)] bts preProcessedMeasurementReporting DP , Product
Recommended value : preProcessedMeasurementReporting Engineering Rules : Since radio measurements are always preprocessed by the BTS, changing this attribute has no meaning.
GSM/BSS V12
Page 363
bsPowerControl Class 3 B5 Description : Range value : Object : Feature : Default value : Type : Whether BTS transmission power control is allowed at cell level [enabled / disabled] powerControl V8 CM145 disabled DP , Optimization
Recommended value : enabled Used in : Engineering Rules : Pc_2 (Cf page 261). 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. V8 CM145 (HO on Quality UL) C1138/2C1138/8C1138/5 BTS_PWR_USED
Feature : Counters : GSM :
bsTxPwrMax Class 3 B6 Description : Range value : Object : Default value : Type : Maximum theoretical level of BTS transmission power in a cell [2 to 51] dBm powerControl 43 DP , Optimization
Recommended value : Depends on the equipment
Page 364
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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. Pc_2 (Cf page 261). BS_TXPWR_MAX C1400C1164/14
Used in : GSM : Counters :
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. [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm powerControl 95 to 94 dBm DP , Optimization
Recommended value : 95 to 94 dBm (step by step) 85 to 84 dBm (one shot) Used in : Engineering Rules : Pc_2 (Cf page 261). 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 : GSM : (Ho on Rxlev DL, Call drop on RLF) C1138/1,C1164/14 L_RXLEV_DL_P , ETSI GSM 05.08
GSM/BSS V12
Page 365
lRxLevULP Class 3 L6 Description : Signal strength threshold in MS-to-BTS direction, below which the power control function increases power. It is lower than uRxLevULP. [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm powerControl 95 to 94 dBm DP , Optimization
Recommended value : 95 to 94 dBm (step by step) 85 to 84 dBm (one shot) Used in : Engineering Rules : Pc_2 (Cf page 261). 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). (Ho on Rxlev UL, Call drop on RLF) C1138/0,C1164/14 L_RXLEV_UL_P , ETSI GSM 05.08
Counters : GSM :
lRxQualDLP Class 3 L7 Description : Bit error rate threshold in BTS-to-MS direction, above which the power control function increases power. It is greater than or equal to uRxQualDLP. [less than 0.2, 0.2 to 0.4, 0.4 to 0.8, ... , 6.4 to 12.8, more than 12.8] % powerControl 0.4 to 0.8 DP , Optimization
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
Page 366
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering Rules :
This value must be lower than lRxQualDLH in order to maintain priority between power control and handover.
Caution: From V9 the comparison is made with the upper or the 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. (Ho on Quality) C1138/3C1138/2C1138/8C1138/9 L_RXQUAL_DL_P , ETSI GSM 05.08
Counters : GSM :
lRxQualULP Class 3 L8 Description : Bit error rate threshold in MS-to-BTS direction, above which the power control function increases power. It is greater than or equal to uRxQualULP. [less than 0.2, 0.2 to 0.4, 0.4 to 0.8, ... , 6.4 to 12.8, more than 12.8] % powerControl 0.4 to 0.8 DP , Optimization
Recommended value : 0.8 to 1.6 % (RxQual = 3 in GSM unit) without SFH 1.6 to 3.2 % (RxQual = 4 in GSM unit) with SFH Used in : Engineering Rules : Pc_2 (Cf page 261). This value must be lower than lRxQualULH in order to maintain priority between power control and handover.
Caution: From V9 the comparison is made with the upper or the lower limit of the BER range. So a same value of lRxQualULP between V8 (or previous releases) and V9 release will not trigger a power control at the same moment. (Ho on Quality, CD on RLF) C1138/3C1138/2C1138/8C1138/9,C1164/14 L_RXQUAL_UL_P, ETSI GSM 05.08
Counters : GSM :
GSM/BSS V12
Page 367
msTxPwrMax2ndBand Class 2 M11 Description :
V12
Maximum MS transmisssion power in the band 1 of the dualband cell depending on the network type (BCCH is only defined in band 0) [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) bts DP , Optimization Dualband cell management (TF875 V12)
Range value :
Object : Type : Feature :
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 Description : Range value :
V9
Algorithm used by the BTS to control power in a cell [step by step / one shot / enhanced one shot] As a result, the amount of mobiles emitting at Pmax is reduced. bts Fast power control at TCH assignment (TF975 V12) stepbystep DP , Optimization
Page 368
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : one shot (if DCU2 boards) or enhanced one shot (otherwise) Used in : Pc 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 : Range value : Whether MS signal strength measurements include measurements on BCCH [include BCCH measurements / do not include BCCH measurements] This parameter should only be used with cavity coupling. bts include BCCH measurements DP , Optimization
Recommended value : See Engineering Rules 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 : Range value : Object : Default value : Type : Step for increasing MS or BTS txpwr when using step by step algorithm [2, 4, 6] dB powerControl 4 dB DP , Optimization
GSM/BSS V12
Page 369
Recommended value : 6 dB Used in : Pc_1 (Cf page 260), Pc_2 (Cf page 261). 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 : Range value : Object : Default value : Type : Step for reducing MS or BTS txpwr when using step by step algorithm [2, 4] dB powerControl 2 dB DP , Optimization
Recommended value : 2 dB Used in : Pc_1 (Cf page 260), Pc_2 (Cf page 261). 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 Description : Number of Measurement Results messages that must be received before the power control algorithm in a cell is triggered. [1 to 31] SACCH frames (1 unit = 480 ms on TCHs, 470 ms on SDCCHs) bts 4 DP , System !
Page 370
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : 2 Used in : Pc_2 (Cf page 261). Engineering Rules : The lowest is the parameter value, the best will be the reactivity ; nevertheless, it is better to wait for the effect of MS power decrease on the uplink quality. Counters : (CPU load) C1400, C1601, C8052, C1198, C8050, C1602, C8053, C1199, C8051 GSM : RUN_POWER_CONTROL uplinkPowerControl Class 3U1 Description : Range value : Object : Default value : Type : V8
Whether power control in the MS-to-BTS direction is authorized at cell level [enabled / disabled] powerControl enabled DP , Optimization
Recommended value : enabled uRxLevDLP Class 3 U2 Description : Upper strength threshold for BTS txpwr decrease for step by step algorithm It is greater than lRxLevDLP. [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm powerControl 85 to 84 dBm DP , Optimization
Recommended value : = lRxLevDLP + Max (powerIncrStepSize, powerRedStepSize) typically Used in : Pc_2 (Cf page 261). Engineering Rules : Difference between the lower and upper thresholds must be greater or equal to the maximum power step size. Counters : GSM : Not used in one shot power control. (Ho on Rxlev DL, Call drop on RLF) C1138/1,C1164/14 U_RXLEV_DL_P , ETSI GSM 05.08
GSM/BSS V12
Page 371
uRxLevULP Class 3 U3 Description : Upper strength threshold for MS txpwr decrease for step by step algorithm It is greater than lRxLevULP. Range value : Object : Default value : Type : [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm powerControl 85 to 84 dBm DP , Optimization (powerIncrStepSize,
Recommended value : lRxLevULP + Max powerRedStepSize) typically Used in : Engineering Rules : Pc_2 (Cf page 261).
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. (Ho on Rxlev UL, Call drop on RLF) C1138/0,C1164/14 U_RXLEV_UL_P , ETSI GSM 05.08
Counters : GSM :
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. Range value : Object : Default value : Type : [less than 0.2, 0.2 to 0.4, 0.4 to 0.8, ... , 6.4 to 12.8, more than 12.8] % powerControl 0.2 to 0.4 DP , Optimization
Page 372
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 Used in : Engineering Rules : Pc_2 (Cf page 261). This value must be lower than lRxQualDLH in order to maintain priority between power control and handover. Not used with one shot power control.
Caution: From V9 the comparison is made with the upper or the lower limit of the BER range. So a same value of lRxQualDLP between V8 (or previous releases) and V9 release will not trigger a power control at the same moment. (Ho on Quality, CD on RLF) C1138/3C1138/2C1138/8C1138/9,C1164/14 U_RXQUAL_DL_P , ETSI GSM 05.08
Counters : GSM :
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. Range value : Object : Default value : Type : [less than 0.2, 0.2 to 0.4, 0.4 to 0.8, ... , 6.4 to 12.8, more than 12.8] % powerControl 0.2 to 0.4 DP , Optimization
Recommended value : 0.8 to 1.6 % (RxQual = 3 in GSM unit) without SFH 1.6 to 3.2 % (RxQual = 4 in GSM unit) wtih SFH Engineering Rules : This value must be lower than lRxQualULH in order to maintain priority between power control and handover. There is no reason why this value should differ from uRxQualDLP. Not used with one shot power control.
GSM/BSS V12
Page 373
Caution: From V9 the comparison is made with the upper or the lower limit of the BER range. So a same value of lRxQualDLP between V8 (or previous releases) and V9 release will not trigger a power control at the same moment. Pc_2 (Cf page 261). (Ho on Quality) C1138/3C1138/2C1138/8C1138/9 U_RXQUAL_UL_P, ETSI GSM 05.08
Used in : Counters : GSM :
Page 374
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
3.14
TCH ALLOCATION MANAGEMENT PARAMETERS

accessClassCongestion Class 3 A1 Description : Range value : Object : Default value : Type : V9
List of access classes that are not authorized in a cell during TCH congestion phase (class 10 not included) [0 to 9] User classes [11 to 15] Operator classes bts 0123456789 DP , Design
Recommended value : See Engineering Rules Used in : Engineering Rules : All_4 (Cf page 277). 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 : Object : Default value : Type : [0 to 7]. 0 defines the highest priority. bts 000000000000000000 DP , System !
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 265), All_2 (Cf page 270), All_3 (Cf page 272).
GSM/BSS V12
Page 375
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 TCH = 0 TCH request of priority 0 TCH request of priority > 0 queueing if defined or reject queueing if defined or reject
1 Number of free TCH allocPriorityThreshold TCH allocated
Number of free TCH > allocPriorityThreshold TCH allocated
queueing if defined or reject
TCH allocated
[0 to 2147483646] bts 0 DP , Design
Recommended value : n, with n TRX Used in : All_1 (Cf page 265).
Page 376
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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, allocPriorityThreshold = 0 capacity for incoming calls = 2,88 Erlang 1 TRX, 7 TCH, 2 % blocking rate, allocPriorityThreshold = 1 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 [0 to 2147483646] seconds bts 00000000 DP , System !
Recommended value : 0 0 3 0 0 0 0 0 Used in : All_2 (Cf page 270), All_3 (Cf page 272). 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),
GSM/BSS V12
Page 377
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 Assign Request queueing Maximum Waiting Time
MSC start tnt2
Assign Command Start t3107 Assign Complete
Counters :
A high value of timer is not realistic, since a subscriber will not wait unless the last TCH is available quickly. 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 : Object : Default value : Type : [0 to 2147483646] bts 00000000 DP , System !
Page 378
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : 0 0 n 0 0 0 0 0 , for 2n SDCCH subchannels Used in : Engineering Rules : All_2 (Cf page 270), All_3 (Cf page 272). 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. C1039, C1058
Counters :
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. Range value : Object : Default value : Type : [0 to 17] bts 0 DP , System !
Recommended value : 16 Used in : Engineering Rules : All_1 (Cf page 265). 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 Description : Index in the allocPriorityTable that defines the processing priority of TCH allocation requests with cause reply to paging This priority is used in signaling mode on TCH only. Range value : Object : [0 to 17] bts
GSM/BSS V12
Page 379
Default value : Type :
17 DP , System !
Recommended value : 16 Used in : Engineering Rules : All_1 (Cf page 265). 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 Description : Index in the allocPriorityTable that defines the processing 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). Range value : Object : Default value : Type : [0 to 17] bts 17 DP , System !
Recommended value : 17 Used in : Engineering Rules : All_1 (Cf page 265), All_3 (Cf page 272). 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.
Page 380
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
bscMSAccessClassBarringFunction Class 3 B7 Description : Range value : Object : Default value : Type :
V9
Enable or disable dynamic barring of access class at the bsc level [enabled / disabled] bsc disabled DP , Design
Recommended value : enabled, see Engineering Rules Used in : All_4 (Cf page 277). 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 277). 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. [allowed (MSC driven) / forced (O&M driven) / not allowed] signallingPoint not allowed DP , Design
Recommended value : forced (O&M driven) allowed (MSC driven), if MSC is able to manage queueing. Used in : All_2 (Cf page 270), All_3 (Cf page 272).
GSM/BSS V12
Page 381
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 Description : Range value : Object : Default value : Type :
V9
Enable or disable dynamic barring of access class at the bts level [enabled / disabled] bts disabled DP , Design
Recommended value : see Engineering Rules Used in : Engineering Rules : All_4 (Cf page 277). 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 Description : Index in the allocPriorityTable that defines the processing priority of TCH allocation requests with cause call reestablishment [0 to 17] bts 17 DP , System !
Page 382
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : 16 Used in : All_1 (Cf page 265). Engineering Rules : The value that must be given should correspond to a priority 0. cellBarQualify Class 3 C10 Description : V8
Cell selection priority used in the C2 algorithm in Phase II The information is broadcast to the mobiles at regular intervals on the cell BCCH. [true (low priority) / false (normal priority)] bts False DP , Optimization
Recommended value : False Engineering Rules : To be defined (Cf page 211). cellBarred Class 3 C11 Description : Whether direct cell access are barred to mobiles The information is broadcast to the mobiles at regular intervals on the cell BCCH. [barred / not barred] bts not barred DP , Optimization
Recommended value : not barred Engineering Rules : See Chapter 2.3.3. channelType Class 2 C12 Description : Range value : Type of logical channel supported by a radio time slot [tCHFull (traffic) / sDCCH (traffic) / mainBCCH / mainBCCHCombined (with SDCCH) / bcchSdcch4CBCH / sdcch8CBCH / cCH (V12)] channel
Object :
GSM/BSS V12
Page 383
Feature : Type :
Extended CCCH (TF184 V12) DP , Optimization
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 : Range value : Object : Default value : Type : Index in the table allocPriorityTable for a TCH allocation request whose cause is emergency call [0 to 17] bts 17 DP , System !
Recommended value : 15 Used in : Engineering Rules : All_1 (Cf page 265). 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 Description : Index in the allocPriorityTable that defines the processing 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).
Page 384
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
[0 to 17] bts 17 DP , System !
Recommended value : 15 Used in : Engineering Rules : All_1 (Cf page 265). The internal priority associated is 0. A TCH allocation 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 Description : Index in the allocPriorityTable that defines the processing 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. Range value : Object : Default value : Type : [0 to 17] bts 17 DP , System !
Recommended value : 15 Used in : All_1 (Cf page 265), All_2 (Cf page 270), All_3 (Cf page 272). The internal priority associated is 0. A TCH allocation 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.
Engineering Rules :
GSM/BSS V12
Page 385
intraCellHOIntPriority Class 3 I5 Description : Range value : Object : Default value : Type : Index in the allocPriorityTable that defines the processing priority of an intra-bts handover in a cell [0 to 17] bts 17 DP , System !
Recommended value : 17 Used in : All_1 (Cf page 265), All_2 (Cf page 270), All_3 (Cf page 272). 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.
Engineering Rules :
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. [enabled / disabled] bts disabled DP , Optimization
Recommended value : Enabled Used in : All_2 (Cf page 270), All_3 (Cf page 272).
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.
Page 386
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
[1 to 16] bts 1 DP , Optimization
Recommended value : 1 notAllowedAccessClasses Class 3 N2 Description : Range value : List of mobile access classes that are forbidden in the cell, except case of congestion. List of mobile access class: [0 to 9]: user classes [11 to 15]: operator classes bts DP , Operation
Object : Type :
Recommended value : null (empty list) Used in : All_4 (Cf page 277). 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 Description : V9
Minimum number of free TCHs which triggers the beginning of the TCH congestion phase and the beginning of the traffic overload condition [0 to infinite] bts 0 DP , Design
Recommended value : 1 for cells with 12 TRXs 2 or 3 for cells with more than 3 TRXs Used in : All_4 (Cf page 277). 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.
GSM/BSS V12
Page 387
numberOfTCHFreeToEndCongestion Class 3 N4 Description :
V9
Threshold that gives the number of free TCHs, which triggers the end of TCH congestion phase and the end of the traffic overload condition. [0 to infinite] bts 0 DP , Design
Recommended value : 2 for cells with 12 TRXs 3 or 4 cells with more than 3 TRXs Used in : All_4 (Cf page 277). Engineering Rules : numberOfTCHFreeToEndCongestion > numberOfTCHFreeBeforeCongestion Note, this inequality is not checked at the OMC. numberOfTCHQueuedBeforeCongestion Class 3 N5 Description : V9
Maximum number of TCH allocation requests queued which triggers the beginning of the TCH congestion phase and the beginning of the traffic overload condition [0 to infinite] bts 0 DP , Design All_4 (Cf page 277). V9
Range value : Object : Default value : Type : Used in :
numberOfTCHQueuedToEndCongestion Class 3 N6 Description :
Maximum number of TCH allocation requests queued which triggers the end of TCH congestion phase and the end of the traffic overload condition [0 to infinite] bts 0 DP , Design All_4 (Cf page 277).
Range value : Object : Default value : Type : Used in :
Page 388
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
otherServicesPriority Class 3 O3 Description : Index in the table allocPriorityTable for a TCH allocation request (in signaling mode) whose cause is other services [0 to 17] bts 17 DP , System !
Recommended value : 16 Used in : Engineering Rules : All_1 (Cf page 265). The internal priority associated is 0. A TCH allocation request (in signaling mode) whose cause is other services is acknowledged when at least allocPriorityThreshold + 1 channels are free.
priority Class 2 P7 Description : Range value : Object : Type : Engineering Rules : Priority level of a TDMA frame. [0 to 255] transceiver DP , Optimization 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.
GSM/BSS V12
Page 389
Algorithms parameters
3.15
DIRECTED RETRY HANDOVER PARAMETERS

adjacent cell umbrella ref Class 3 A9 Description : V9
Identifier of the adjacentCelHandOver object that describes the neighbor cell towards which a directed retry will be triggered in BSC mode [0 to 31] bts 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 Description : V9
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 [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm adjacentCellHandOver >48 dBm DP , Optimization
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.2 for an example of parameter setting.
Page 390
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Caution: Directed retry is not allowed between 2 zones of a concentric cell. For a dual Band Network where one frequency band is 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 Description :
V9
Specify how directed retry handovers are processed in a cell either directly by the BSC (microcells only) or by querying the BTS first [bsc / bts] bts bts DP , Design Ho_8 (Cf page 237), Ho_9 (Cf page 237). In V9, bsc mode can only be applied from a micro cell towards a macrocell (system rule). 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.
Range value : Object : Default value : Type : Used in : Engineering Rules : Note :
directedRetryPrio D5 Description : Range value : Object :
V12 Defines the number priority for directed retry handovers [0 to 17] bts
GSM/BSS V12
Page 391
Feature : Type : Engineering Rules :
General protection (TF821 V12) DP , Optimization
against
pingpong
handovers
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. V9
interBscDirectedRetry Class 3 I7 Description : Range value : Object : Default value : Type :
Whether inter-bss directed retry handovers are allowed in a BSS [allowed / not allowed] bsc allowed DP , Design
Recommended value : allowed Used in : Engineering Rules : Ho_8 (Cf page 237), Ho_9 (Cf page 237). 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. Directed retry is not allowed between 2 zones of a concentric cell. interBscDirectedRetryFromCell Class 3 I8 Description : Range value : Object : Default value : Type : V9
Whether inter-bss directed retry handovers are allowed in a cell [allowed / not allowed] bts not allowed DP , Optimization
Page 392
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Recommended value : allowed Used in : Engineering Rules : Ho_8 (Cf page 237), Ho_9 (Cf page 237). If the value is allowed then the interBscDirectedRetry must be allowed. Queueing must also be activated at BSC level. Directed retry is not allowed between 2 zones of a concentric cell. intraBscDirectedRetry Class 3 I9 Description : Range value : Object : Default value : Type : V9 value of
Whether intra-bss directed retry handovers are allowed in a BSS [allowed / not allowed] bsc allowed DP , Design
Recommended value : allowed Used in : Engineering Rules : Ho_8 (Cf page 237), Ho_9 (Cf page 237). 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 Description : Range value : Object : Default value : Type : V9
Whether intra-bss directed retry handovers are allowed in a cell [allowed / not allowed] bts not allowed DP , Optimization
GSM/BSS V12
Page 393
Recommended value : allowed Used in : Engineering Rules : Ho_8 (Cf page 237), Ho_9 (Cf page 237). If the value is allowed then the intraBscDirectedRetry must be allowed. Queueing must be activated at BSC level. Directed retry is not allowed between 2 zones of a concentric cell. modeModifyMandatory Class 3 M13 Description : V9 value of
Whether a CHANNEL MODE MODIFY message should be sent to the mobile after a directed retry handover in the BSS [used (yes) / not used (no)] bsc not used DP , Optimization
Recommended value : used Engineering Rules : This message is only useful for mobiles belonging to special brands that are not able to switch directly from signaling 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).
Page 394
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
3.16
CONCENTRIC CELLS PARAMETERS

concentAlgoExtMsRange Class 3 C13 Description : V9
MS to BTS distance below which a handover is requested from the large zone to the small zone if the level criteria is verified [1 to 34] km (nonextended mode) [1 to 120] km (extended mode) handOverControl 1 To define if the associated bts object describes a concentric cell. DP , Design
Range value : Object : Default value : Condition : Type :
Recommended value : 34 (urban) Used in : Engineering Rules : Ho_3 (Cf page 237). See previous parameter. A good solution is to apply:
concentAlgoExtMsRange = concentAlgoIntMsRange 1 km
Constraints: concentAlgoExtMsRange < concentAlgointMsRange concentAlgoExtMsRange < msRangeMax concentAlgoExtRxLev Class 3 C14 Description : Range value : Object : Default value : Condition : Type : V9
The level of the MS signal strength from below which a handover is requested from the large zone to the small zone [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm handOverControl 95 to 94 To define if the associated bts object describes a concentric / dualband / dualcoupling cell DP , Design
GSM/BSS V12
Page 395
Recommended value : RxLevLimitInt + zoneTxpowerMaxReduction where:

RxLevLimitInt = RxLevLimitExt + Q Q is the RxLevAccessMin difference between the two
areas Ho_3 (Cf page 237). 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 Description : Range value : Object : Default value : Condition : Type :
V9
MS to BTS distance from which a handover from the small zone to the large zone will be requested [1 to 34] km (nonextended mode) [1 to 120] km (extended mode) handOverControl 2 To define if the associated bts object describes a concentric / dualband / dualcoupling cell. 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) Used in : Ho_7 (Cf page 237). 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.
Page 396
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 Description : Range value : Object : Default value : Condition : Type : V9
Level of the MS signal strength below which a handover is requested from the small zone to the large zone [less than 110, 110 to 109, ... , 49 to 48, more than 48] dBm handOverControl less than 110 To define if the associated bts object describes a concentric/dualband/dualcoupling cell DP , Design
Recommended value : concentAlgoExtRxLev Hysteresis Margin Used in : Engineering Rules : Ho_3 (Cf page 237). 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 margin is 5 dB. (See 4.5). The following rule must be fulfilled concentAlgoExtRxLev concentAlgoIntRxLev.
GSM/BSS V12
Page 397
concentric cell Class 2 C17 Description : Range value : Object : Feature : Default value : Type :
V9
Whether the cell is monozone, concentric, dualband or dualcoupling [true / false] for V9 to V11 [monozone / concentric / dualband / dualcoupling] for V12 bts Dualband cell management (TF875 V12) monozone DP , Optimization
Recommended value : See Engineering Rules 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
Page 398
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
zone Tx power max reduction Class 2 Z1 Description : Range value : Object : Default value : Type : Reminder :
V9
Attenuation vs bsTxPowerMax that defines the maximum TRX/DRX transmission power in the zone large zone = [0] dB, small zone = [1 to 55] dB transceiverZone 0 DP , Design 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 Ho_3 (Cf page 237). 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.
GSM/BSS V12
Page 399
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 : Object : Default value : Type : [0 to 255] SACCH frame (1 unit = 480 ms on TCH, 470 ms on SDCCH) handOverControl 20 DP , System !
Recommended value : 20 Used in : Engineering Rules : If (Cf page 282). 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. (CPU load) C1400 V8
Counters :
radChanSelIntThreshold Class 3 R24 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.
Page 3100
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 Range value : Object : Feature : Default value : Type : [0 to 4] handOverControl TF131 1 DP , Optimization
Recommended value : 3, 1 (for 1:1 & 1:3) Used in : Engineering Rules : If (Cf page 282). A high value for this parameter means a tolerant interference 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.
GSM/BSS V12
Page 3101
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. Feature : TF131
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.
Page 3102
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
128
dBm
th. 1 Level 0
th. 2 Level 1
th. 3 Level 2
th.4 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 : Object : Default value : Type : [128 to 0] dBm handOverControl 100 90 80 70 DP , Optimization
Recommended value : 114, 112, 108, 100 Used in : Engineering Rules : If (Cf page 282). 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. (CPU load) C1400
Counters :
GSM/BSS V12
Page 3103
3.18
RADIO RESOURCES CONTROL AT CELL LEVEL

radResSupBusyTimer Class 3 R25 Description : Range value : Object : Default value : Type : V8
Maximum time that SDCCH or TCH can be continuously occupied without generating an alarm [1 to 18] hours bsc 3 DP , System !
Recommended value : 10 or 3 (see below) Engineering Rules : Useful, for example, to see problems of resource deallocation. 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). V8
radResSupervision Class 3 R26 Description : Range value : Object : Default value : Type :
Indicates whether radio resources are controlled at the cell level (both busy resources and free resources) [true / false] bts true DP , System !
Recommended value : True Engineering Rules : Note : It is recommended to use this control mainly after a frequency plan update, to regularly supervise the network. 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 overloaded at a rate of radResSupBusyTimer or radResSupFreeTimer.
Page 3104
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
radResSupFreeTimer Class 3 R27 Description : Range value : Object : Default value : Type :
V8
Maximum time an SDCCH or TCH can be continuously free without generating an alarm [1 to 18] hours bsc 18 DP , System !
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).
GSM/BSS V12
Page 3105
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. [2 to 300] seconds bsc 5 DP , System !
Recommended value : 5, 60 (if using DMS switch) bssMapT12 Class 1 B11 Description : A interface timer triggered by the BSC in the BSSMAP 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. [2 to 300] seconds bsc 5 DP , System !
Recommended value : 5, 60 (if using DMS switch) bssMapT13 Class 1 B12 Description : A interface timer triggered by the BSC in the BSSMAP management procedure. It is started on receipt of RESET sent by the MSC. On elapse, the BSC sends RESET ACKNOWLEDGE to the MSC.
Page 3106
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Range value : Default value : Object : Type :
[2 to 300] seconds 32 bsc DP , System !
Recommended value : 32 bssMapT19 Class 1 B13 Description : V8
A interface timer triggered by the BSC in the BSSMAP 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 ACKNOWLEDGE sent by the MSC. [2 to 300] seconds bsc 60 DP , System !
Recommended value : 32 bssMapT20 Class 1 B14 Description : V8
A interface timer triggered by the BSC in the BSSMAP 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 ACKNOWLEDGE sent by the MSC. [2 to 300] seconds bsc 60 DP , System !
Recommended value : 32
GSM/BSS V12
Page 3107
bssMapT4 Class 1 B15 Description : A interface timer triggered by the BSC in the BSSMAP management procedure It is started on transmission of RESET and canceled on receipt of RESET ACKNOWLEDGE sent by the MSC. On elapse, the BSC sends RESET. Range value : Object : Default value : Type : [5 to 600] seconds bsc 60 DP , System !
Recommended value : 60 bssMapT7 Class 1 B16 Description : A interface timer triggered by the BSC in the BSSMAP management procedure It is started on transmission of HANDOVER REQUIRED and canceled on receipt of HANDOVER COMMAND, RESET, RESET CIRCUIT, CLEAR COMMAND or HANDOVER REQUIRED REJECT. Range value : Object : Default value : Type : [2 to 120] seconds bsc 7 DP , Optimization
Recommended value : 7 bssMapT8 Class 1 B17 Description : A interface timer triggered by the BSC in the BSSMAP 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.
Page 3108
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
[0 to 255] seconds bsc 15 DP , Optimization
Recommended 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 management procedure 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. Range value : Object : Default value : Type : [1 to 255] seconds bsc 4 DP , System !
Recommended 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 management procedure It is set on transmission of CONNECTION REQUEST and canceled on receipt of CONNECTION CONFIRM or CONNECTION REFUSED. Range value : Object : Default value : Type : [5 to 360, by steps of 5] seconds signallingPoint 5 DP , System !
GSM/BSS V12
Page 3109
Recommended 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. Range value : Object : Default value : Type : [2 to 255] seconds bts 3 DP , System !
Recommended 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. C1163/5
Counters : 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
Page 3110
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 : Object : Default value : Type : [2 to 255] seconds (t3103 < bssMapT8) bts 5 seconds DP , Optimization
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 procedure. Use the suggested system value. 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. Range value : Object : Default value : Type : [2 to 255] seconds bts 10 seconds DP , Optimization
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.
GSM/BSS V12
Page 3111
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. C1163/6
Counters : 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.
[2 to 255] seconds (t3109 radioLinkTimeout) bts 12 seconds DP , Optimization
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
Page 3112
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 procedure. Use the suggested system value. It is set on receipt of RELEASE INDICATION sent by the BTS. On elapse, the BSC sends RF CHANNEL RELEASE. Range value : Object : Default value : Type : [1 to 255] seconds bts 2 seconds DP , System !
Recommended value : 2 seconds 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 [0 to 255] seconds
Range value :
GSM/BSS V12
Page 3113
bts 10 seconds DP , Optimization
Recommended value : 10 seconds 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 : Range value : Object : Default value : Type : Time between two location update requests [0 to 255] 1/10th of hour. 0 means that no periodic location update is requested. bts 60 DP , Optimization
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.
Page 3114
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
3.20
PAGING PARAMETERS
delayBetweenRetrans Class 2 D6 Description : Range value : Object : Default value : Type : V8
Number of occurences of a paging sub-group that separates two transmissions of the same paging message. [0 to 22] bts 0 DP , Optimization
Recommended value : 0 Engineering Rules : The recommended value is 0 because the time between two paging commands broadcast must not be too long, otherwise 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. Furthermore, 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 The information is broadcast to the mobiles at regular 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 : Object : Default value : Type : [one / two / four / seven] bts two DP , Optimization
Recommended value : two in noninterfered areas four in interfered areas
GSM/BSS V12
Page 3115
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 Description :
V8
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):
[0 to 22] bts 3 DP , Optimization
Recommended 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 repetitions 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 : Range value : Number of CCCH blocks not used for paging [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.
Page 3116
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
bts 0 DP , System !
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 : Range value : Object : Default value : Type : Number of occurences of a paging sub-group [2 to 9] multi-frame of fifty-one frames bts 2 DP , Optimization
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, frequency of measurements performed on idle neighbours thanks to the formula: mesurements done every Max (5 seconds, ((5*nb of idle neighbors + 6) DIV 7) * noOfMultiframesBetweenPaging /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.
GSM/BSS V12
Page 3117
numberOfSlotsSpreadTrans Class 3 N10 Description : Number of radio time slots over which RACH transmission access are spread in a random way to avoid collisions [3 to 12, 14, 16, 20, 25, 32, 50] time slots bts 32 DP , Optimization
Recommended 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 Description : Range value : Object : Default value : Type : Enable or disable paging requests in a cell [enabled / disabled] bts enabled DP , Optimization V9
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 Description : V8
Maximum number of occurrences of a same paging sub-group that separates the first and the last transmissions of the same paging message. [0 to 22]
Range value :
Page 3118
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
bts 10 DP , Optimization
Recommended 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 nbOfRepeat and retransDuration. Furthermore, the following inequality, that is not checked by the system, must be true:
GSM/BSS V12
Page 3119
3.21
FREQUENCY HOPPING PARAMETERS

bscHopReconfUse Class 1 B20 Description : Range value : Object : Default value : Type : V8
Whether frequency hopping reconfiguration is authorized in BTSs that use cavity coupling [true / false] bsc True 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 Description : Range value : Object : Default value : Type : V8
Whether hopping frequency reconfiguration is authorized on TX restart in a cell [true / false] bts true DP , Optimization
Recommended value : True (for cavity coupling), False (mandatory for hybrid coupling)
Page 3120
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 : Range value : Object : Default value : Type : Whether frequency hopping is allowed in a cell [hopping / noHopping / hoppingWithCarrierFilling (V8) / noHoppingWithCarrierFilling (V8)] bts noHopping 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. When using both frequency hopping and DTX, it is highly recommended to disable handovers on quality criteria. The reason comes from the few number of rxQual measurements when using DTX. Then, when the MS is really in DTX mode and if there are radio interference at the same time, rxQual samples will be considered as bad measurements though they could be good measurement without DTX activation.
GSM/BSS V12
Page 3121
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. Tests on NOKIA mobiles provide following results: A gap of 30 dB leads to a dead time between 4 to 7 s. Except this particular case (cavity coupler + FH + PWC) there is no restriction in combining Frequency hopping with Power Control.
btsThresholdHopReconf Class 2 B23 Description : Range value : Object : Default value : Type :
V8
Minimum number of frequencies that must be working in a cell to allow frequency hopping reconfiguration [1 to 64] bts 1 DP , Optimization
Recommended 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.
Page 3122
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
cellAllocation Class 2 C18 Description : Range value : List of no more than sixty-four frequencies allotted to a cell in the network frequency band [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) bts DP , Optimization
Object : Type :
Recommended value : See Engineering Rules 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. fhsRef Class 2 F2 Description : Identifier of the frequencyHoppingSystem object that defines the frequency hopping management parameters for the radio time slot [0 to 63] channel To define if the time slot hops in frequencies. DP , Optimization
Range value : Object : Condition : Type :
Recommended value : See Engineering Rules 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.
GSM/BSS V12
Page 3123
[0 to 63] frequencyHoppingSystem DP , Optimization
Recommended value : See Engineering Rules and Chapter 4.19 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 : Object : Type : [0 to N1] N is the number of frequencies ( 64) allotted to the time slot. channel DP , Optimization
Recommended value : See Engineering Rules and Chapter 4.19 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 Allocation 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.
Page 3124
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 [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) frequencyHoppingSystem DP , Optimization
Range value :
Object : Type :
Recommended value : see Engineering Rules 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 frequency). V9
traffic PCM allocation priority Class 2 T11 Description : Range value : Object : Feature : Type :
Allocation priority of a TDMA frame on the covering site PCMs [0 to 255] transceiver FM844 DP , Optimization
Recommended value : 0 for the TDMA supporting the BCCH, 255 for the others Feature : FM844
GSM/BSS V12
Page 3125
3.22
BSC LOAD MANAGEMENT PARAMETERS

lapdTerminalNumber Class 0 L9 Description : Range value : BSC SICD port assigned to the LAPD link [0 to 7] (BSC type 1) [0 to 15] (BSC type 2) [0 to 23] (BSC type 3) [0 to 31] (BSC type 4) [0 to 39] (BSC type 5) lapdLink DP , Optimization
Object : Type : 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 Description : V8
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 0 1
OMU (level 1, 2, 3) 8090100 8090100
Other boards 8090100 90100100
Comments nominal value permissive value
Page 3126
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
value 2 3 4 5 6 7 8 9
OMU (level 1, 2, 3) 8090100 100100100 8090100 8090100 8090100 8090100 8090100 8090100
Other boards 758595 100100100 8090100 90100100 758595 506070 8090100 90100100
Comments restrictive value simplex mode (see Note 1) nominal value (see Note 2) permissive value (see Note 2) restrictive value (see Note 2) exceptional value (see Note 3) reserved value (see Note 4) 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. Range value : Object : Feature : Default value : Type : [0 to 9] bsc BSC overload management (FM877 V12) 1 DP , Optimization
Recommended value : 0 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).
GSM/BSS V12
Page 3127
3.23
DUAL BAND PARAMETERS

early classmark sending Class 3 E3 Description : Range value : Object : Default value : Type : V10
Whether Early classmark sending procedure initiated by a multiband MS is allowed. [Not Allowed, Allowed] bts Not Allowed DP , Design
Recommended value : Allowed (for dual band network) Engineering Rules : When this parameter 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 enables interband handover procedures (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 Description : Range value : V10
Minimum number of cells that multiband MSs must report in their radio measurements in each frequency band [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 bts the six strongest cells DP , Optimization
Recommended value : The two strongest cells out band (case of privileged band), the six strongest cells (case of no privileged band)
Page 3128
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering Rules :
For values indicating the one (1), two (2) or three (3) strongest 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 Description : Range value : Object : Feature : Default value : Type :
V10
Type of network in which this neighbor cell is working [gsm / extended gsm / dcs1800 / pcs1900 / R gsm / gsmdcs (V12) / dcsgsm (V12)] adjacentCellHandover Dualband cell management (TF875 V12) gsm DP , Optimization
GSM/BSS V12
Page 3129
Recommended value : see Engineering Rules Engineering Rules : The indicated standard indicator must have the same value in adjacentCellHandover or adjacentCellReselection objects and in the associated neighbour bts object. V10
standard indicator AdjC Class 2S4 Description : Range value : Object : Default value : Type : Feature :
Type of network in which this neighbor cell is working [gsm / extended gsm / dcs1800 / pcs1900 / R gsm / gsmdcs (V12) / dcsgsm (V12)] adjacentCellReselection gsm DP , Optimization Dualband cell management (TF875 V12)
Recommended value : see Engineering Rules Engineering Rules : The indicated standard indicator must have the same value in adjacentCellHandover or adjacentCellReselection objects and in the associated neighbour bts object.
Page 3130
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
3.24
DTX PARAMETERS
cellDtxDownLink Class 3 C19 Description : Range value : Object : Default value : Type : Whether the use of discontinuous transmission in BTS-to-MS direction is allowed in a cell [enabled / disabled] bts enabled DP , Optimization
Recommended value : See Engineering Rules 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 : Range value : Object : Default value : Type : MS control of the discontinuous transmission mechanism in a cell [msMayUseDtx / msShallUseDtx / msShallNotUseDtx] bts msShallNotUseDtx DP , Optimization
Recommended value : msShallUseDtx
GSM/BSS V12
Page 3131
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. [0 to 7] bts DP , Optimization
cpueNumber Class 0 C20 Description :
V12
Number of the CPU/BIFP board chosen for managing the radio site and its related equipment.
BSC BSC 12000/6000 types 3, 4, 5 CPUE 0 BIFP0 CPUE 1 BIFP 1
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
Object : Type : Feature : Engineering Rules :
btsSiteManager DP , Optimization CPU/BIFP load sharing (AR874 V12) 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.
Page 3132
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
measurementProcAlgorithm Class 2 Description : Range value : Whether the new L1M interface is used [L1MV1, L1MV2]
L1MV1: the older L1M is used L1MV2: the newer L1M is used
V12
Object : Feature : Type :
bts L1M evolutions (TF1089V12) DP , Optimization for advanced features support
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 : Range value : List of up to fourteen elements that identify the GSM functions configured in a site BCF [entityMgt / download / siteMgt / abisSig / abisTraf / rfTrans / rfRecep / cellMgt / fhMgt / tdmaMgt / tsMgt / gsmTime / car0Fil / freqMgt] btsSiteManager [entityMgt / download / siteMgt / abisSig / abisTraf / rfTrans / rfRecep / cellMgt / fhMgt / tdmaMgt / tsMgt / gsmTime / car0Fill / freqMgt]
Object : Default value :
GSM/BSS V12
Page 3133
Type :
DP , Optimization
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.
Page 3134
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
3.26
INTERFERER CANCELLATION PARAMETERS

interferer cancel algo usage Class 2 I11 Description : V10
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. [0 to 100] % bts 0 DP , Design
Recommended value : see Engineering Rules Engineering Rules : Three values are necessary and sufficient to cover the clients needs according to the sold options (it is quite unlikely that a more refined finetuning will bring anything more):
0%: Maximum Ratio Combining (best pure thermal
noise sensitivity). No interference cancellation. Minimum speed correction.

50%: MRC when no interferers (same pure thermal
noise sensitivity as 0%). Interference cancellation. Medium speed correction.

100%: Approximate MRC when no interferers.
Interference cancellation. Best speed correction. To set a specific value to this parameter, the gsm Protocol (in the omcconfigure.cfg of the OMC) shall be set to JTC.
GSM/BSS V12
Page 3135
3.27
PCM ERROR CORRECTION PARAMETERS

enhancedTRAUFrameIndication E4 Description : Range value : Object : Type : Feature : 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 Description : V12 V12
Whether the BTS uses the Enhanced TRAU Frame (ETF) for TCU [notAvailable / available / active] bsc DI , Optimization PCM error correction (FM660 V12)
Whether the bts uses the new ETF (Enhanced TRAU Frame) frame (set to 1) or the ETSI Rec 08.60 frame (set to 0). [0 / 1] bts 0 DP , Optimization PCM error correction (FM660 V12)
Range value : Object : Default value : Type : Feature :
Page 3136
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Note :
This parameter is only available for BTSs equipped with non mixed DCU4 or DRX transceiver architecture.
Recommended value : 1 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.
GSM/BSS V12
Page 3137
3.28
UPLINK MAPPING PARAMETERS

uplinkMappingChannelNumber Class 2 U6 Description : Range value : Object : Default value : Type : Feature : V12
Channel number used for uplink mapping as the monitored TS [1 to 7] bts 7 DP , Optimization Uplink mapping (TF816 V12)
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.18 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 Description : Range value : Object : Default value : Type : Feature : Frequency (f0) used for uplink mapping [0 to 1023] bts 0 DP , Optimization Uplink mapping (TF816 V12)
V12
Page 3138
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.18 Uplink mapping in the Algorithms part.
uplinkMappingMeasurementMode Class 2 U8 Description : Range value : Object : Default value : Type : Feature :
V12
Whether uplink mapping is active on the BTS or not [disabled / enabled] bts enabled DP , Optimization Uplink mapping (TF816 V12)
Recommended value : disabled Engineering Rules : See also subchapter 2.18 Uplink mapping in the Algorithms part.
uplinkMappingProcessingMode Class 3 U9 Description : Range value : Object : Default value : Type :
V12
Whether uplink mapping is active on the BSC or not [disabled / enabled] bsc disabled DP , Optimization
GSM/BSS V12
Page 3139
Feature :
Uplink mapping (TF816 V12)
Recommended value : disabled Engineering Rules : See also subchapter 2.18 Uplink mapping in the Algorithms part.
Page 3140
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
3.29
CELL TIERING PARAMETERS

hoMarginTiering Class 3 Description : V12
Hysteresis between the uPwCIDLH and lPwCIDLH tiering thresholds to avoid pingpong handovers (expressed in dB) [0 to 63] dB handOverControl 4 dB DP , Optimization Automatic Cell Tiering (TF995V12) 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.
Range value : Object : Default value : Type : Feature : Engineering Rules :
interferenceType Class 3 Description : Range value : Object : Default value : Feature : Type : Engineering Rules : Type of interference created by neighbour cell [not applicable / adjacent / coChannel] adjacent CellHandOver 0 Automatic Cell Tiering (TF995V12) DP , Optimization
V12
See subchapter 2.5.11 Automatic cell tiering in the 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 Description :
V12
Mean number of logical channels belonging to the large frequency reuse pattern and used at the same time for data communications [16 to +16]
Range value :
GSM/BSS V12
Page 3141
Object : Default value : Feature : Type : Engineering Rules :
bts 0 Automatic Cell Tiering (TF995V12) DP , Optimization See subchapter 2.5.11 Automatic cell tiering in the 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 Description :
V12
Minimum number of PwCI samples required to reach a reliable distribution (representative of the real distribution in the whole cell) * 1000 [0 to 60] handOverControl 20 Automatic Cell Tiering (TF995V12) DP , Optimization See subchapter 2.5.11 Automatic cell tiering in the 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.
Range value : Object : Default value : Feature : Type : Engineering Rules :
pwciHreqave Class 3 Description : Range value : Object : Default value : Feature : Type : Averaging window size for PwCI [0 to 16] handOverControl 8 Automatic Cell Tiering (TF995V12) DP , Optimization
V12
Page 3142
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering Rules :
See subchapter 2.5.11 Automatic cell tiering in the Algorithms part. It defines the number of measurement reports for PWCI arithmetic averaging.
selfTuningObs Class 3 Description : Range value :
V12
Parameter indicating that the BTS is in charge of sending pwCi distribution on Abis interface [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
Object : Default value : Feature : Type : Note :
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 handOverControl 0 Automatic Cell Tiering (TF995V12) DP , Optimization pwCi distribution may be gathered and sent onto Abis interface independantly of tiering activation See subchapter 2.5.11 Automatic cell tiering in the Algorithms part.
Engineering Rules :
GSM/BSS V12
Page 3143
Page 3144
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
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 (4) lRxQualxxP uRxQualxxP (3) Power Power Zone 1 RXLEV Zone 1 RXLEV lRxLevxxH (100 dBm) lRxLevxxP uRxLevxxP (88 dBm) Power Power
lRxQualxxH (4) lRxQualxxP (3) uRxQualxxP (2)
lRxLevxxH lRxLevxxP uRxLevxxP (100 dBm) (88 dBm) (82 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.
GSM/BSS V12
Page 41
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: 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.
Page 42
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
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. However, these results come from a study over few days and in a specific configuration. It is difficult to say that the one shot power control algorithm is simply better than the stepbystep one. The quality is not degrataded and it seems to lead to more power attenuation but nothing allows to conclude surely that this algorithm is the one to use in all cases.
GSM/BSS V12
Page 43
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.
Page 44
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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).
GSM/BSS V12
Page 45
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.
Page 46
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 47
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
Page 48
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.4
4.4.1
DIRECTED RETRY HANDOVER

Directed Retry and TCH reserved for Handover Special care must be taken for the following case: Two adjacent cells have 2 TCH reserved for incoming handover which have the highest priority for TCH assignment. If cell A is saturated (all the TCH minus the 2 TCH reserved for incoming handover are occupied), the TCH assignment will be directed toward cell B (using the Directed Retry feature). If the 8 TCHs of cell B are not occupied, the assignment will be taken into account because cell B will understand this assignment with the cause incoming handover. If there is only one TCH free, it is a TCH reserved for this kind of assignment. The handover with cause Directed Retry is computed because it has the same priority as the handover with other causes. Conclusion of this problem: a call request is accepted by the network, when, due to the engineering design (reserved TCH for incoming handover), it should be rejected. A consequence is the deletion of incoming handover priority. Calls are going to be propagated, and this is the opposite of what the network design should provide.
cell B 2 TCH reserved for incoming handover
cell A (saturated = 6 TCH occupied) directed retry handover TCH assigment
2 TCH reserved for incoming handover
GSM/BSS V12
Page 49
Engineering issues
In this case the only solution is to not use the Directed Retry feature for both cells. Moreover, if cell B is also saturated (6 TCHs occupied) the TCH assignment will be directed to cell A. The consequence is that many mobiles will be managed by a BTS which is far from them. That will lead to an increase of the interference, Because the emitted power of the mobile and the BTS will be high. (See figure below).
cell B (satutared = 6 TCHs occupied) 2 TCH reserved for incoming handover TCH assigment
cell A
(satutared = 6 TCHs occupied) directed retry handover directed retry handover TCH assigment
2 TCH reserved for incoming handover
Note: The problem is the same if the number of TCH reserved is not 2.
Page 410
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.4.2
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
Directed Retry
Duration of congestion (time)
Network is underdimensioned !
normal situation
short duration small surface
Call Queueing
Surface of congestion (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 Without Directed Retry: The carried capacity is: 9 cells * 9 TCH + 3 * 76% * 26= 140 Erlang the highest blocking rate is over 24%
GSM/BSS V12
Page 411
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. With Directed Retry: When the Macrocell begins to be full (the blocking rate will become low (from 2% to 3%)) then no more calls are redirected from the cell to the macro. Capacity of cell + macrocell: we aim to satisfy the 10 + 9 requests (i.e. 19 Erl needed): n cell * X% * 10 + 1 macro * 9 The macro cell is able to carry: 14.9 Erlang 9 requests from the Macrocell 5.9 requests from the cells Then, the mcells keep: X% * ((n mcell * 10) 5.9)
Page 412
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
With Directed Retry: 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 With Directed Retry: Gain 30% on ONE cell and the highest blocking rate is over 12.4% (instead of 48%). With Directed Retry: 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 (%) = Erl carried DR(dis) X(n) * (10n 5.9) (5,2n + 9) Gain (%) = 5,2n + 9
Gain (%) = (number of cells under one umbrella) 35% 30% 25% 20% 15% 10% 5% 0% 1 2 3 4 5 6 7 8 9 10 Gain (%) Blocking Rate 50.0% 45.0% 40.0% 35.0% 30.0% 25.0% 20.0% 15.0% 10.0% 5.0% 0.0%
GSM/BSS V12
Page 413
Engineering issues
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). 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
Page 414
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
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 At neighbor cell level: directedRetry = rxLevMinCell + 3 dB At cell level for neighbor cells: btsTimeBetweenHOconfiguration = 30 allocPriorityThreshold = 3
GSM/BSS V12
Page 415
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.
Page 416
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 f3 f1 f2 f3 f2 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. Notice that 70% of the large zone cell range has been obtained for the small zone cell range in experimental results.
GSM/BSS V12
Page 417
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.
Page 418
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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
GSM/BSS V12
Page 419
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
n 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.
Page 420
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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. Caution: the parameters based on distance were set to high values in order to disable the test on distance. 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.
GSM/BSS V12
Page 421
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. It shows also less power attenuation and light deterioration of downlink quality after the concentric cell implement. The number of samples with a downlink quality > 4 increases when the concentric cell configurations are introduced in the network (to more than 2 % in some configurations, though there were 1 % of the samples with a downlink quality > 4 without concentric cell configuration).
Page 422
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
BS Pwr Att. RxQual UL > 4 MS Pwr Att. RxQual DL > 4 20 18 16 14 12 10 8 6 4 2 0
Meas 1 : non concetric cell Meas 2 ...8 : concentric cell
2,5% 2,0% 1,5% 1,0% 0,5% 0,0%
Meas 1
Meas 2
Meas 3
Meas 4
Meas 5
Meas 6
Meas 7
Meas 8
SML Zone TCH/BCCH TCH/sDCCH RxQual UpLink RxQual DownLink RxLev UpLink RxLev DownLink Avg BS Power Att Avg MS Power Att Call Drop > > > > + + +
LGE Zone
Cell +
> > > > >
> > > > + > >
+: 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). However, with concentric cells, the BSC is more loaded because more TCH resources are used. Some remarks can be given after these tests.
GSM/BSS V12
Page 423
Engineering issues
TCH allocation The concentric cell implementation induces an increase of the TCH allocations (because of intracell handover increase). This increase has been observed up to 1 to 1.6 times the normal TCH allocation due to ConcentAlgoExtRxlev and ConcentAlgoIntRxlev definition (and could be accented up to 2 times when ConcentAlgoExtRxlev and ConcentAlgoIntRxlev did not follow the rule ConcentAlgoExtRxlev ConcentAlgoIntRxlev = zoneTxPwrMax). This increase may induce a BSC overload, if the concentric cell feature is extended over the whole network. Call Start 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). The same set of parameters did not provide the same results on all sectors. The congestion may be easily induced sectors with only 2 TDMA. RESULTS ON THE CONCENTRIC CELLS TRIALS IN NINGBO Traffic distribution analysis It appears clearly that after activation of concentric cells feature, with a 12 dB power reduction on the small zone, the TCH blocking rate increased sharply. A simple calculation can show the route cause of the problem:
TRX 0
Page 424
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
On TRX 0, 1 TS is reserved for BCCH, 1 TS for SDCCH and 6 will be available to carry the outgoing and incoming calls, as well as incoming handovers from external cells and from the small zone. According to Erlang B law, with 6 channels, we can carry 2.28 Eralngs @2% blocking rate. In order to keep the blocking rate below 2%, the traffic on the TRX0 must not exceed 2.28 Erlang. Since statistically, we cannot handoff more than half of the traffic to the small zone (Mobiles geographical distribution between the 2 zones with 12 dB reduction), the rule to design the concentric cells will be (for originating cells with only 2 TRXs):
If the traffic on the cell is > 4.5 Erl, 2 TRX are needed on the large zone to maintain Blocking rate < 2%, and secure incoming handovers
Impact on system / engineering
100% increase of handovers 25 to 40% increase in the number of TCH allocations inside the cell. Sharp increase of N5 of HO / call. In some cases, this leads to saturation of the billing server memory. Loss of capacity in Erlang for concentric cells. Time consuming. The geographical distribution between large zone and small zone differs from one cell to the other. The shape of the zones depends on the antenna pattern and propagation conditions. There is a gap between theoretical calculations and what is observed on field.
GSM/BSS V12
Page 425
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 meanvalue of (rxlev_fullrxlev_sub) (dB) standard deviation (dB) 1 2 3 4 8
0.15 2.12
0.15 1.48
0.15 1.19
0.15 1.03
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. 8 to 10 for neighbor; standard deviation on RXLEV_SUB can be extended to RXLEV(i). 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.
Page 426
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000

0.15 0.72
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:
absent_time (s) 0.66 1.32 1.98 2.64 3.3 % 1.18 1.89 4.01 5.42 1.89 4.01 4.48 1.65 1.42 8.02 66.04 % cumulate 1.18 3.07 7.08 12.5

14.39 18.4 22.88 24.53 25.94 33.96 100 3.96 4.62 5.28 5.94 6>11 >11
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.
GSM/BSS V12
Page 427
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 allocPriorityThreshold + 1 free TCHs if there is at least
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 No TCH
Queueing Free TCH No TCH
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.
Page 428
PE/IRC/APP/0037 4119001037

Call in the queue Approved 05.02/EN
Call failure
Handover successful
Call successful Handover failure
January 2000
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.
GSM/BSS V12
Page 429
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.
Page 430
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.11
EXPLANATION OF PEAK APPEARANCE IN RXLEV_UL DISTRIBUTION

Normally, uplink RxLev measurements should lead to a distribution of the RxLev_UL representing a regular gaussian graph. However, some Nortel BTS measurements show an irregular gaussian graph with some peaks each 3 dB always at the same value: 21, 24, 27, 30, 33 in GSM unit (from 0 up to 63 which means from 110 dBm up to 48 dBm). Several reasons can be considered, the most likely is the specific postprocessing used by NMC, which leads to the most accurate measurements as possible. Nortel BTS measures the received field level in Watts. Every 104 measurements, an arithmetic average in Watts is done to calculate the measurements which will beconsidered by the L1M. Before sending this value to the L1M, it is translated into dBm according to the GSM Recommendation, thanks to a specific algorithm, which translate the Watt value in binary notation before being translated in GSM unit thanks to an equivalence table [I8]. The particularity of the Nortel BTS to measure all received field level in Watt and to calculate an arithmetic average in Watts every 104 samples gives a more accurate value than BTSs from others providers where the arithmetic average is computed directly in dBm. Simulations have been performed show the peak appearance and to demonstrate that the error due to these peaks is weak. A pulling of 12 000 samples following the normal law with an average value of 28 dBm and a standard deviation of 6 dB has been used for the simulations:
GSM/BSS V12
Page 431
Engineering issues
Normal law (28;6) 12000 samples
ENT (nb+0,5) Cumulative input
Samples 1000 900 800 700 600 500 400 300 200 100 0 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 46 6 8
% 100 90 80 70 60 50 40 30 20 10 0 48 % 100 90 80 70 60 50 40 30 20 10 0 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 48 6 8
After a perfect translation of these GSM unit values in Watt values, the use of NMC algorithm to translate again the Watt values in GSM unit values provides the following result:
Algo result 12000 samples
Result Cumulative result
Samples 1000 900 800 700 600 500 400 300 200 100 0
The previous drawing shows the appearance of peaks in the RxLev_UL distribution.
Page 432
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
The simulation results show [I8] the variation due to NMC algorithm is always included in the interval [0.4 dB;0.9 dB]. The variation of the algorithm result has been tested for small and very high values. The average variation is 0.28 dB and its standard deviation is 0,30 dB. The algorithm provides a result which is below the correct value most of the time. This is a quite good result. In order to simulate a mobile communication with an average RxLev_UL of 28 GSM unit, a pulling of 1000 samples following the normal law with 28 as average and 8 as standard deviation is used. The aim is to evaluate the error provided by the algorithm in several averaging windows (2,4 or 8 measurements) depending on the calculation of (HReqAve * Hreqt). The results are summedup in the following table.
Averaging window Average variation Standard deviation 1 measurements 2 measurements 4 measurements 8 measurements 0.28 dB 0.30 0.28 dB 0.21 0.28 dB 0.15 0.28 dB 0.10
When the Watt value is translated in dBm, the average dubiousness becomes 0.28 dB with a standard deviation included in [0.10; 0.30] and a range of [0.4 dB; 0.9 dB]. In order to show that some mobiles are using the same algorithm than Nortel BTS, the same simulations than for uplink RxLev has been done for downlink RxLev measurements. The graph below show the result of these simulations.
GSM/BSS V12
Page 433
Engineering issues
0.05
0.04
0.03
0.02
0.01
0 110 105 100 95 90 85 80 75 70 65 60 55 50
This graph shows an irregular gaussian wiht some peaks, but at irregular steps. If all Mobiles were using a Watt to dBm translation, the peak appearance would be regular each 3 dB. Then the irregularity of peaks appearance shows that some Mobile convert the RxLev from Watts to dBm, and others are calculating the arithmetic average directly in dBm. The conclusion of this study is that one may not take into account the 2.5 dB difference between the arithmetic average calculated in dBm and directly in Watts. As many mobiles are using the same translation from Watts to dBm than Nortel BTS, the parameter setting of the uplilnk and downlink RxLev thresholds is not influenced by this translation.
Page 434
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.12
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. This formula, confirmed by tests performed on Mandarin network by J. Pandion, shows that increasing the parameter NoOfMultiframesBetweenPaging slows down the cell reselection mechanism (see R1 for further details). 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.
GSM/BSS V12
Page 435
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 Number of BCCH to monitor 20 11
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:
Numbers of BCCH in reselection list NoOfMultiframesBetweenPaging that doesnt slow down the reselection mechanism 6 4 2
Page 436

4 6 13
from 13 to 32 none
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
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.
GSM/BSS V12
Page 437
Engineering issues
4.13
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 FN 0
CCCH CCCH CCCH CCCH CCCH CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
CCCH
BCCH
BCCH
BCCH
BCCH
FCCH
FCCH
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.
Page 438
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
SCH
TDMA carrying the BCCH
January 2000
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.
GSM/BSS V12
Page 439
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.
Page 440
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.14
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 (I14). The simulations were performed from real RF measurements and network field configuration. Four Simulations have been performed with the following sets of parameters:
runHandOver 1 2 3 4 2 2 1 1
Hreqt 2 1 2 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.14.1 Global statistics The Figure 410 shows the amount of HO during the whole simulation for each set of parameters.
GSM/BSS V12
Page 441
Engineering issues
90
70
Number of HO
50 40 30 20 10 0
Lev_DL
Capture
PBGT
Qual_DL
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.
Page 442
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
60
runHO=2 runHO=2 runHO=1 runHO=1
HreqT=2 HreqT=1 HreqT=2 HreqT=1
Impact of runHO & HreqT Amount of HO per cause
Total
January 2000
80
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 Study of reactivity 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 Hreqt No change: same cause at the same moment reference 2 2 reference reference 2 1 85% 15% 1 2 100% 0% 1 1 85% 15%
4.14.2
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 Hreqt Average advance (sec) Std deviation (sec) 2 1 1,6 0,6 1 1 1,5 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.
GSM/BSS V12
Page 443
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 average hreqave=4
stored average
10
11
12
13
14
15
16
sliding average t=5: super average on 5 measures t=16: super average on 8 measures
sliding average
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
Page 444
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.14.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.
GSM/BSS V12
Page 445
Engineering issues
4.15
4.15.1
IMPACT OF CALL REESTABLISMENT ON THE NETWORK

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. On the other hand, on Sunday network, tests have been performed showing that, after the Call Reestablishment activation, nearly no trunk erlangs have been noticed by Mandarin Radio Engineers.
4.15.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.
Page 446
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 down to a call drop
The call is reestablished 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.
GSM/BSS V12
Page 447
Engineering issues
4.15.3
Call Reestablishment synchronization The 2 following drawings represent cases of success and failure of call reestablishment. Case 1:
t3109
20s
Call Rees given up In the represented case, the BTS has detected the radio link failure before the MS, so the MSC has started t3109, and is waiting for a channel request from the MS.
Up link t MSC is waiting for RACH
In the worse case, the MS will take 10s to detects after the MSC the radio link failure, and takes at most 5 seconds (max authorised) to select a destination cell for call reestablishment. With T3109 = 20s, the system has 5s left to reestablish the call. (20 10 5) Caution: for smaller values of t3109, the MS may not have the time to process selection and send the RACH.
Down link Channel Request t MS has time to send the channel request
Page 448
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
Case 2: Nortel DMS
t3109
20s In that second case, the MS has detected the radio link failure before the MSC, and sends a channel request before the MSC has started t3109. So the DMS does not acknowkedge the request, and the call re restablishment cant be performed.
Rlf1
Up link Channel Request t MSC NACK
RLT
Down link t Ms sends RACH too early
Unfortunately, this second case is the most usual.
GSM/BSS V12
Page 449
Engineering issues
4.16
4.16.1
FREQUENCY SPACING BETWEEN TWO TRXS OF THE SAME AREA

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) (b) for a given site, the beacon frequency carriers of the cells are, at least, spaced of 600 kHz for a given cell, the carriers are spaced, at least, of 600 kHz a cell with two TRXs (TX1 and TX2) emitting respectively at frequencies f1 and f2. Those two mobiles communicate respectively with Tx1 and Tx2.
Example:
TX1
TX2
D1 MS1 MS2
D2
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.
Page 450
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.16.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.16.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.
For more information on this subject, look at the Engineering Rules for Frequency hopping document [I26].
GSM/BSS V12
Page 451
Engineering issues
4.17
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.
Page 452
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 453
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 : If > 0 : If < 0 : the link budget is balanced, so take either DL_budget or UL_budget as path loss, the link budget is uplink limited, take the UL_budget as path loss, the link budget is downlink limited, take the DL_budget as path loss.
Page 454
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
Example of a link budget calculation with Nortel values for the S8000 Outdoor BTS using duplexor, in GSM1800:
Downlink BTS BTS_pwr BTS_ant_gain BTS_feeder_loss EIRP 43.3 dBm 17 dBi 2 dB 58 dBm MS MS_sen MS_ant_gain Body_loss 102 dBm 2 dBi 3 dB BTS_sen BTS_ant_gain BTS_div_gain BTS_feeder_loss DL_budget Link Budget 155.3 MS_pwr, incl. TX_loss MS_ant_gain Body_loss EIRP Uplink MS 30 dBm 2 dBi 3 dB 28 BTS 110 dBm 17 dBi 5 dB 2 dB UL_budget 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 Budget 125 dBm 129 dBm 130 dBm 131 dBm 135 dBm Coverage Range 72 % 93 % 100 % 107 % 132 % Coverage Area 52 % 88 % 100 % 114 % 190 % Number of sites 190 % 114 % 100 % 88 % 52 %
GSM/BSS V12
Page 455
Engineering issues
4.18
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 Transmitter Max Power Output Noise Level Margin Max Output Noise Level Receiver Sensitivity Input Noise Level Margin Max Input Noise Level Noise Decoupling Value A (dBm) B (dB) C (dBm) = A B D (dBm) E (dB) F (dBm) G (dB) = C F 30 60
UPLINK
DOWNLINK 33 60 27 101 9 110 83
30 104 9 113 83
As we can notice in the results of the upper table, the values are the same for uplink and downlink.
Page 456
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 Transmitter Max Power A (dBm) 30
UPLINK
DOWNLINK 33 44 77
Max Received Signal Strength B (dB) Decoupling Value C (dB) = A B
35 65
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.
GSM/BSS V12
Page 457
Engineering issues
4.19
GENERAL RULES FOR SYNTHESISED FREQUENCY HOPPING

For more information see [I26].
4.19.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
Page 458
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
TS TDMA 0 TDMA 1 TDMA 2 TDMA 3
0 F1 MA0 MA0 MA0
1 MA1 MA1 MA1 MA1
2 MA1 MA1 MA1 MA1
3 MA1 MA1 MA1 MA1
4 MA1 MA1 MA1 MA1
5 MA1 MA1 MA1 MA1
6 MA1 MA1 MA1 MA1
7 MA1 MA1 MA1 MA1 MAIO = 0 MAIO = 1 MAIO = 2 MAIO = 3
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).
GSM/BSS V12
Page 459
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.
Page 460
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.19.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:
FreqLoadSite
NbHopTRXCell Nhfsite
With: NbHopTRXCell: number of hopping TRX in a cell Nhfsite: number of hopping frequencies in a site
GSM/BSS V12
Page 461
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 = 3 * FreqLoadSite
FrequencyLoad
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 1:1 1:3 FrequencyLoad max 20 % 50 % FreqLoadSite max 20 % 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.19.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.
Page 462
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
number of frequencies 1:3 fractional reuse pattern 1:1 fractional reuse pattern 4 :12 reuse pattern
96
84
72
60
54 S888
48 S777
47
S888 S888 S777 S666 S555 S444
42 S666 S777
37
36 S555
32
30 S444
27
24 S333
S666 S333
S555
S444 S222
22
18 S222
17
12 S111
S333
S222
S111 S111
4.19.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.19.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).
GSM/BSS V12
Page 463
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.19.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 0,6,12
MAIO max = 16 then Nb hopping frequencies in the site 17
HSN = 1 MAIO 4,10,16
HSN = 1 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 Cell1 TRX1 MAIO = 0 Cell3 TRX3 MAIO = 16 F1 F17 = F1 + 3200 kHz
Case b: adjacent collision F5 = F1 + 800 kHz F4 = F1 + 600 kHz
Page 464
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
With one more frequency (18), the adjacency disappears
Case b: No adjacent collision F5 = F1 + 800 kHz F3 = F1 + 400 kHz
Then, in this example: Nb hopping frequencies in the site 18 = 2*NbHopTRXsSite Remark: In the above example, another solution for the MAIO rule would have been to give MAIO 0, 2, 4 to TRX in the first cell, MAIO 6, 8, 10 to TRX in the second cell and MAIO 12, 14, 16 to TRX in the third cell. However, the disadvantage of this solution appears when adding new TRX in a cell. For instance, a new TRX in the first cell would have MAIO 18 assigned, then the logic aspect of the MAIO assignment is lost.
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
GSM/BSS V12
Page 465
Engineering issues
Then Nhfsite 6
NbHopTRXCell
NbHopTRXCell FreqLoadSite = Nhfsite
1 6
thus: FreqLoadSite p 16% odd 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 + 1 There are as many MAIO as TRX: NbHopTRXSite = NbHopTRXSite Then: Nhfsite 1 6
NbHopTRXCell p
Page 466
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
thus:
FreqLoadSite p 16%
100 % Nhfsite * 6
4.19.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 e max 16 % Adjacent frequencies in MA yes HSN and MAIO rule Identical HSN MAIO step 2 Identical HSN MAIO step 2
NbHopTRXcell NbHopTRXcell
Nhfsite 6 Nhfsite 1 6 (odd)
16 %
yes
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.
GSM/BSS V12
Page 467
Engineering issues
4.19.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.19.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,... HSN and MAIO general rules 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 0,1,2
MAIO max = 8 then Nb hopping frequencies in each cell 9
HSN = 1 MAIO 6,7,8
HSN = 1 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).
Page 468
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
Case b: adjacent collision F15 = F11 + 2400 kHz F34 = F11 + 2200 kHz
With one more frequency (16), the adjacency disappears
Case b: No adjacent collision F15 = F11 + 2400 kHz F33 = F11 + 1600 kHz
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:
NbMAIOSite + 1
Nhfsite 3
As there are 3 cells per site:
NbMAIOSite = 3 * NbMAIOCell
And MAIO step 1 is used, then:
NbMAIOCell
= NbHopTRXCell
GSM/BSS V12
Page 469
Engineering issues
Then:
NbHopTRXCell
Nhfsite 3 9
thus:
FreqLoadSite
11%
100 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 The maximum value for FreqLoadSite was defined at 16 %, then this strategy is not optimised. Keeping three (3) non continuous frequency bands, a better MAIO plan can be chosen, in order to reach the maximum defined frequency load (FreqLoadSite = 16 %). An indexed frequency Fi in the MA of the first cell is not adjacent with an indexed frequency Fi in the MA of the third cell frequency (spacing of 400 kHz). However, an indexed frequency Fi+1 in the MA of the first cell frequency is adjacent with an indexed frequency Fi in the MA of the third cell frequency. Thus, using the same MAIO step 2 rule for both first and third cells will not lead to frequency adjacencies between these cells. Moreover, using different MAIO with a step 2 rule for the second cell will also ensure a non frequency adjacency with this cell.
Page 470
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
Example: for a S444 with a MAIO step 2 in all cells, same MAIO in first and third cells, there are 3 hopping TRX per cell, then 9 hopping TRX within the site.
HSN = 1 MAIO 0,2,4
MAIO max = 5 then Nb hopping frequencies in each cell 6 NbMAIOSite = 6
HSN = 1 MAIO 0,2,4
HSN = 1 MAIO 1,3,5
Then the following frequency groups can be defined:

Cell1 Cell2 Cell3 F1 F1+200 kHz F1+400 kHz F1+600 kHz F1+800 kHz F1+1200 kHz F1+1800 kHz F1+2400 kHz F1+3000 kHz F1+1400 kHz F1+2000 kHz F1+2600 kHz F1+3200 kHz
F1+1000 kHz F1+1600 kHz F1+2200 kHz F1+2800 kHz F1+3400 kHz
According to the MAI, the following frequencies will be allocated to each TRX. Then, for: MAI = 0
TRX 1 Cell 1 (MAIO: 0, 2, 4) Cell 2 (MAIO: 1, 3, 5) Cell 3 (MAIO: 0, 2, 4) F1 F1 + 800 kHz F1 + 400 kHz TRX 2 F1 + 1200 kHz F1 + 2000 kHz F1 + 1600 kHz TRX 3 F1 + 2400 kHz F1 + 3200 kHz F1 + 2800 kHz
For MAI = 1
TRX 1 Cell 1 (MAIO: 0, 2, 4) Cell 2 (MAIO: 1, 3, 5) Cell 3 (MAIO: 0, 2, 4) F1+ 600 kHz F1 + 1400 kHz F1 + 1000 kHz TRX 2 F1 + 1800 kHz F1 + 2600 kHz F1 + 2200 kHz TRX 3 F1 + 3000 kHz F1 + 200 kHz F1 + 3400 kHz
Whatever the MAI is, all frequencies are spaced of at least 400 kHz, then there is no frequency adjacencies. 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:
GSM/BSS V12
Page 471
Engineering issues
The reuse pattern is 1:3, then:
NbMAIOSite
Nhfsite 3
As there are 3 cells but 2 with same MAIO:
NbMAIOSite = 2 * NbMAIOCell
And:
NbMAIOCell
= NbHopTRXCell
Then:
NbHopTRXCell
Nhfsite 6
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
Page 472
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
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 non continuous frequency bands.
Caution: An other way to reach the maximum frequency load is to use different HSN and different MAIO for each cell. This configuration leads to a 16 % frequency load (ideal case) but it also leads to frequency adjacencies, then to interference increase.
4.19.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 HSN and MAIO general rules 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). 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 MAIO 0,2,4
HSN = 1 MAIO 0,2,4
GSM/BSS V12
Page 473
Engineering issues
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 MAIO = 0 Cell1 TRX3 MAIO = 4 Cell2 TRX1 MAIO = 0 F11 F15 = F11 + 800 kHz F31 = F11 + 1000 kHz
With one more frequency (6), the adjacency disappears:

Cell1 TRX1 MAIO = 0 Cell1 TRX3 MAIO = 4 Cell3 TRX1 MAIO = 0 F11 F15 = F11 + 800 kHz F31 = F11 + 1200 kHz
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 : MAIO step 2 is used: Nhfcell 2 * NbMAIOCell
As the same MAIO plan is used in all cells:
NbMAIOSite = NbMAIOCell
Page 474
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
The reuse pattern is 1:3:
Nhfsite = 3 * Nhfcell
Then:
NbMAIOSite
Nhfsite 2*3
As the same MAIO plan is used in all cells:
NbMAIOSite = NbMAIOCell
And:
NbMAIOCell
= NbHopTRXCell
Then:
NbHopTRXCell
Nhfsite 6
thus:
FreqLoadSite
16%
GSM/BSS V12
Page 475
Engineering issues
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 te 16 % (max) Adjacent frequencies in MA HSN and MAIO rule
Nhfsite NbTRXcell 6
NbTRXcell
Nhfsite 6
16 % (max)
no Identical HSN (3 non continuous Same MAIO step 2 in frequency bands) two cells Other MAIO step 2 in the third cell yes Identical HSN (3 continuous MAIO step 2 in a cell, frequency bands) same MAIO in all cells
Page 476
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.19.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.
GSM/BSS V12
Page 477
Engineering issues
4.20
4.20.1
BSC BOARDS MANAGEMENT

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).
Page 478
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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
LAC1
LAC2
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.

LAC1 BSC2
1000 subscribers
1000 subscribers
BSC1
1000 subscribers
LAC2
GSM/BSS V12
Page 479
Engineering issues
45 40 35 30 25 20 15 10 10 5 0 5
Optimisation Optimisation
sicd0 sicd1 sicd2 sicd3 sicd4 sicd5 sicd6 sicd7 sicd8 sicd9
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.
Page 480
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.20.2
4.20.2.1
BSCB boards management

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.20.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.20.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.20.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.
GSM/BSS V12
Page 481
Engineering issues
4.21
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.21.1
4.21.1.1
How to favour a frequency band?

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 false false true true cellBarred not barred barred not barred barred cell selection priority normal no selection possible low low
Cell access for phase 2 mobile stations
Page 482
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.21.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 P = maximum RF output power of the MS
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.
GSM/BSS V12
Page 483
Engineering issues
4.21.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.21.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.21.1.5 Microcell algorithm
Microcell capture A algorithm can also be used to make mobile stations stay in the same frequency band.
4.21.1.6 Sumup of the recommended parameter setting to favour one frequency band
High Priority band Multiband reporting cellBarQualify cellReselectOffset 2 false cellReselectOffset = 30
Low priority band 3 true cellReselectOffset = between 4 and 10
Note
Page 484
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
hoMarginRxQual, hoMarginRxLev...
hoMargin_nei_cell_band1 for adjacentCellHO object
hoMargin_nei_cell_band2 for adjacentCellHO object
hoMargin_nei_cell_b and1 hoMargin_nei_cell_b and2
directedRetryAlgo
rxLevMinCell + 3 dB
rxLevMinCell + 3 dB
Note: See chapter 3 for recommended values 4.21.2

4.21.2.1
How not to favour a frequency band?

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.21.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.21.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.21.2.4 Sumup of the recommended parameter setting for two equal frequency bands
GSM900 band Multiband reporting the six strongest cells
GSM1800 band the six strongest cells
Note
GSM/BSS V12
Page 485
Engineering issues
cellBarQualify cellReselectOffset rxLevAccessMin hoMarginRxQual, hoMarginRxLev...
false between 4 and 10 100 to 99 dBm Value900 for adjacentCellHO object
false between 4 and 10 100 to 99 dBm Value1800 for adjacentCellHO object directedRetry1800 Value900 = Value1800 directedRetry900 = directedRetry1800
directedRetry
directedRetry900
Page 486
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.22
4.22.1
MICROCELL BENEFITS
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.22.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).
GSM/BSS V12
Page 487
Engineering issues
4.23
INTERFERER CANCELLATION All the results so far lead to the following conclusion: 50% for interferer cancellation algo usage is a very good compromise between interference cancellation and pure thermal noise sensitivity: it does not degrade the sensitivity and gives almost the same interference cancellation performance as 100% with .5dB cancellation loss in the range I/N=0 to 20dB. For instance, it will be very useful in a medium traffic area, where the isolated interferers will be very well removed with no coverage degradation. When pure thermal noise sensitivity is not an issue (not coverage but interference limited situation), 100% achieves the best interference cancellation. In an actual network, some particular synchronization patterns may exhibit a performance loss when interference cancellation is applied although there are many interferers. However, on the overall network a typical net gain of about 1dB will be obtained with 50% (remember that 1dB is 26% increased capacity if the network capacity is limited by the uplink interferers). The following guidelines should be applied: when the interference cancellation is available, 50% is an excellent compromise between coverage and interference cancellation. When speed is the main problem (high speed train coverage) 100% is the best value.
Page 488
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.24
SETUP PRINCIPLES OF A NEIGHBORING LIST AND A BCC PLAN

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.24.1
4.24.2
4.24.2.1
4/12 reuses pattern

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.
GSM/BSS V12
Page 489
Engineering issues
Example
1 8 5 Serving cell 3 6 4
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.24.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.
Page 490
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 8 5 Serving cell 3 6 4
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.
GSM/BSS V12
Page 491
Engineering issues
4.24.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.
Page 492
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.24.2.4
Conclusion
Initialization with the first ring
Current cell: Antenna azimuth, emission power, frequency, gain
Eligibility criteria (distance criteria)
Candidate cell: Antenna azimuth, geographical position regarding to current cell
List of candidate cells
Taking into account resurgency problems
List of neighbour cells
4.24.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.24.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.
GSM/BSS V12
Page 493
Engineering issues
Example:
N1, T2 N2, T3 S, T1 N3, T2 N4, T3

N8, T1
N6, T3
N7, T1
N5, T2
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.24.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.
Page 494
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.24.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.24.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.
GSM/BSS V12
Page 495
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.
Page 496
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.25
SENSITIVITY CALCULATION FOR BTS USING DLNA EQUIPMENT

The sensitivity of a digital radio equipment is directly linked to the noise figure of the equipment, the signal processing capabilities and the radio propagation phenomenon (multipath) in the environment in which it operates. The difference in the noise figure gives the uplink gain of the system when using a DLNA compared to when not using a DLNA. The cases studied hereafter suppose that DLNA is implemented at full gain without compensating at the BTS RxSplitter.
4.25.1
Configuration without a DLNA The sensitivity S of the BTS is defined at the input connector of the BTS. The noise figure of the equipment at this point is NF1.
In a configuration without DLNA, the antenna is connected to the BTS through a feeder line. The feeder line is a passive element introducing a loss Lc. Therefore the Global Noise Figure NFg at the antenna connector can be easily calculated when expressed in dB (logarithmic scale): NFg = NF1 + Lc and the sensitivity at the antenna connector is: Santenna = S + (NFg NF1) logarithmic scale
Application with S4000:
BTS sensitivity: 107 dBm BTS Noise Figure: NF1: 6 dB
GSM/BSS V12
Page 497
Engineering issues
Cable Losses: Lc = 2.8 dB Upper Jumper Losses: Lu = 0.2 dB Global Noise Figure: NFg = 9 dB Sensitivity at antenna connector: Santenna = 104 dBm 4.25.2 Configuration with a DLNA
A DLNA is an active element and therefore its contribution to the global noise figure of the system takes into account its gain and own noise figure.
Noise Figure calculation rule:
For two pieces of equipment connected together, the Noise Figure at the input of equipment 2 (NFglobal) is a function of the Noise Figure of equipment 1 (NF1) and of the Noise Figure (NF2) and gain (G2) of equipment 2. Using linear values: NFglobal = NF2 + (NF1 1) / G2 linear scale For active elements, the Gain and Noise Figure are not directly related. For passive elements, the Gain is the inverse value of the Noise value (or opposite on a logarithmic scale).
For example:
Standard DLNAs have a gain around 12 dB and a Noise Figure aroung 2.4 dB. Feeder lines have a loss of X dB per 100 feet and a gain of X dB per 100 feet.
Page 498
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
Using the same figures as the case without DLNA for feeder losses and BTS Noise Figure and Sensitivity and taking into account the following figures: Extra Jumper Losses: 0.2 dB DLNA NF: 2.4 dB DLNA gain: 12 dB
dB Upper Jumper NF Upper Jumper Gain DLNA NF DLNA Gain Extra Jumper NF Extra Jumper Gain Cable NF Cable Gain BTS NF 0.2 0.2 2.4 12 0.2 0.2 2.8 2.8 6 Linear 1.05 0.95 1.74 15.85 1.05 0.95 1.91 0.52 3.98 NF at Cable Connector 8.80 7.59 NF at Jumper Connector 9.00 7.94 NF at DLNA Input 3.38 2.18 NF at Antenna Connector dB 3.58 Linear 2.28
Noise figure calculation when using a DLNA The Uplink gain between the two configurations is the difference between the Noise Figure without a DLNA and the Noise Figure with a DLNA. Uplink gain = NFg(DLNA) NFg(No DLNA) = 5.4 dB 4.25.3 RxLev and RxQual measurements at BTS level The RxLev measurements at BTS level are calibrated to measure the energy level at the input of the BTS. Adding a DLNA offering 12 dB gain will increase the energy level at the input of the BTS by 12 dB. However, as seen previously, this does not mean that the system sensitivity is improved by 12 dB.
GSM/BSS V12
Page 499
Engineering issues
Observing RxQual/RxLev distribution plots with and without DLNA, one can see that the relation between RxQual and Rxlev changes between the two plots. This is easily understandable by remembering that with a DLNA: the sensitivity level is improved by 5.4 dB the energy level is increased by 12 dB Therefore a 6.6 dB shift can be observed in the RxLev/RxQual distribution. For example, if a mean RxQual level of 5 was observed at a RxLev level of 107 dBm without a DLNA, the same mean RxQual level of 5 will be observed for a RxLev level of 100.4 dBm with a DLNA. This does not mean that the system sensitivity is worse with a DLNA, but only that the sensitivity reference point has changed and is now at the antenna connector.
Page 4100
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.26
4.26.1
STREET CORNER ENIRONMENT

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.
GSM/BSS V12
Page 4101
Engineering issues
4.26.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.
Page 4102
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.26.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
GSM/BSS V12
Page 4103
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.
Page 4104
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.27
4.27.1
SYNCHRONIZED HO VERSUS NOT SYNCHRONIZED HO

Introduction Some tests have been carried in order to compare the timing HO of the three kinds of handovers. No interBSC handovers were performed as synchronized handovers are only available for intraBSC HO. The test plan was the following: Intra BSC / Intra BTS HO Not synchronized HO from Cell A to Cell B (UL & DL) Synchronized HO from Cell A to Cell B (UL & DL) Presynchronized HO from Cell A to Cell B (UL & DL) with different values of the PresynchTimingAdvance parameter. Intra BSC / Inter BTS HO Not synchronized HO from Cell A to Cell B (UL & DL) Presynchronized HO from Cell A to Cell B (UL & DL) with different values of the PresynchTimingAdvance parameter. Cell A and Cell B are sectors of a S8000 BTS.
4.27.2
4.27.2.1
OMCR Parameter settings

Intra BSC / Intra BTS HO (UL)
It has to be noted that ECU was enabled on both Cell A and Cell B. ECU may have an influence on UL measurements.
Synchronized HO Parameters adjacentCellHO object CellId Synchronized hoMargin Not Synchronized HO Parameters adjacentCellHO object CellId Synchronized hoMargin Cell B Id Not Synchronized 24 Cell A Id Not Synchronized 24 Cell A Cell B Cell B Id Synchronized 24 Cell A Id Synchronized 24 Cell A Cell B
GSM/BSS V12
Page 4105
Engineering issues
Presynchronized HO
Parameters
Cell A
Cell B
AdjacentCellHO object
CellId Synchronized PreSynchroTA Cell B Id Pre sync HO with timing advance 0 1 1 2 3 4 5 6 30 24 Cell A Id Pre sync HO with timing advance 0 1 1 2 3 4 5 6 30 24
hoMargin
Note: The value 1 for the PreSynchroTA parameter stands for a TA value equal to 1 (554 m).
4.27.3
4.27.3.1
Timing HO Procedure The test procedure was based on tone recordings. A specific tone is sent for UL (resp. DL) from the MS (resp. the land line). The tone is a pattern of a 3 second 500 Hz signal and a 3 second 700 Hz signal. The use of 2 contiguous signal is needed because problems of no signal emission occurred when a one frequency tone signal is used.
Page 4106
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
1/700 Hz
1/500 Hz
The tone was sent for a minute. An HO occurred approximately every 5,7 seconds. Each record has a serial of about 10 HOs. All the averages shown in that study are calculated from these 10 values.
4.27.3.2 Synchronized HO Results Collected data HO # 1 2 3 4 5 6 7 8 9 10 11 Muting (ms) 26 14 21 31 14 26 70 66 43 49 29 Silence (ms) 55 60 57 61 52 50 26 28 25 10 18 Demuting (ms) 28 21 15 14 15 19 19 26 46 38 36 Total (ms) 109 95 93 106 81 95 115 120 114 97 83
The (1,2,3,4,5,6) HO # are HOs which occurred in the 500 Hz frequency part of the tone. The (7,8,9,10,11) HO # are HOs which occurred in the 700 Hz frequency part of the tone.
GSM/BSS V12
Page 4107
Engineering issues
Statistics & Comments
HOs in 500 Hz frequency tone part

Muting (ms) 22 14 31 7 Silence (ms) 56 50 61 4 Demuting (ms) 19 14 28 5 Total (ms) 97 78 120 16
HOs in 700 Hz frequency tone part

Muting (ms) 51 29 70 17 Silence (ms) 21 10 28 7 Demuting (ms) 33 19 46 11 Total (ms) 106 58 144 35
Comments: For both frequencies, the average timing HO of a synchronized HO is the same, around 100 ms. The interesting part is that the time repartition between the muting, silence and demuting phases are not the same. The muting and demuting phases appear to be dependent on the frequency. However, the muting and demuting algorithms at the TCB are not dependent on the frequency. Actually, the ECU activation on both cells may be responsible of this dependence. It seems that the ECU algorithm at the BTS makes the muting and demuting dependent on frequency. When ECU is enabled, it seems that the muting and demuting slopes are correlated to the frequency.
Page 4108
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.27.3.3
Not Synchronized HO Results Collected Data HO # 1 2 3 4 5 6 7 8 9 Muting (ms) 25 47 40 20 24 48 18 38 25 Silence (ms) 133 113 114 137 131 93 123 143 109 Demuting (ms) 4 84 43 47 43 33 46 38 44 Total (ms) 162 244 197 204 198 174 187 219 178
The (1,2,3,4,5,6,7,8,9) HO # are HOs which occurred in the 500 Hz tone part of the signal. A typical representation of a not synchronized HO is as follows:
Statistics & Comments Muting (ms) 32 18 48 12 Silence (ms) 122 93 143 16 Demuting (ms) 42 4 84 20 Total (ms) 196 162 244 25
The Not Synchronized Timing HO is around 200 ms. Unfortunately, the high standard deviation value does not allow any conclusion on this specific duration. Note: Not synchronized HO procedure Here is a brief example of the L3 radio protocol of such a HO: DL: HANDOVER COMMAND UL: HANDOVER ACCESS DL: PHYSICAL INFO DL: PHYSICAL INFO DL: PHYSICAL INFO UL: HANDOVER COMPLETE
GSM/BSS V12
Page 4109
Engineering issues
The TA is indicated from the target BTS to the MS in the PHYSICAL INFO. We can make the statement that the not synchronized HO is twice slower than the synchronous one. It is mainly due to the PHYSICAL INFO expectation of the MS.
4.27.3.4
Presynchronized HO Results
How does it work ?
The presynchronized handover procedure is exactly the same than the synchronized handover procedure. After the Handover Access bursts which shall be sent with a TA value of 0 the MS shall use a TA as specified in the HO Command by the old BTS, or a default value of 1, if the old BTS did not provide a TA value. The BSC indicates in the HO Command message that the handover will be presynchronized and, if needed, the predefined Timing Advance to be used by the MS in the new cell (preSynchroTimingAdvance parameter at the OMCR).
Collected data
The real TA of both cells is 0 (but fluctuant sometimes to a TA value of 1). The aim of these tests is to evaluate the voice quality loss and/or gain of a presynchronized HO versus the PreSynchroTimingAdvance value set at the OMCR.
Statistics & Comments PreSynchroTA (kms) Average (ms) Minimum Maximum Standard Deviation 0 120 108 129 8 1 122 94 144 18 1 89 65 126 17 2 105 89 105 13 3 436 79 958 334 4 739 524 971 172 5 756 606 970 133 6 684 532 947 132 30 705 533 945 133
Total Timing HO This statistic table is graphically shown hereafter. The blue vertical bars represent the range [min , max] of the Timing HO for a specific preSynchroTA value.
Page 4110
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
1000
900
800
Average
700
739
756 705 684
600
500 436 400
Time (ms)
300
200
100
120
122 89
105
Presynchronized Timing HO versus preSynchroTA First, it has to be known that for the S8000, the estimation of the impulse response is made: On 7 different temporal positions in LS (108 dBm): 3 0+3 On 3 different temporal positions in MAP (110 dBm): 1 0 +1 It means that the S8000 BTS is able to handle a wrong TA up to 3 steps (108 dBm) or 1 steps (110 dBm). Note: For those tests, for the S8000, the estimation of the impulse response has been made on 7 different temporal positions. We were in LS (according to the results).
GSM/BSS V12
Page 4111
Engineering issues
Whats going on for a wrong value of TA ?
It has to be understood that the presynchronized handover has been implemented in order to fasten the handover procedure in a dense (size <2kms) environment or in a railway/highway optimization. As the setting of the preSynchroTimingAdvance parameter is not that easy (onfield measurements and TA distributions after HO per pair of cells), the behavior of the MS for a wrong (2 or 3 steps of TA) and a very wrong (greater than 3 steps of TA) TA value is very interesting for the network optimization. Actually, regarding the timing HO results versus different preSynchroTimingAdvance values, it seems that the MS is able to resynchronize with the BTS. The drawback is that the speech cut duration and the handover procedure are highly increased (up to 1 second). 4.27.4 Conclusion Regarding the results of that study, it clearly appears that the synchronized handover is the faster type of handover but only available for intraBTS or intracell handovers. However, the presynchronized handover has shown very good results (almost the same performance than the synchronized one) if the TA after HO is previously known. Therefore, presynchronized HO is a good solution to fasten handover and to decrease (up to 80 ms) the speech cut duration. The fields of appliance should be dense (cell size < 2kms), railway or highway environment to ensure that the distance after handover is known. Not synchronized handover still remains the only setting for InterBSC handovers. Anyway, the UL results of that memo show that the speech cut duration is less than 250 ms. This value allows to keep a pretty good voice quality during handovers.
Page 4112
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.28
4.28.1
BTS SENSITIVITY
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.
GSM/BSS V12
Page 4113
Engineering issues
4.28.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.28.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 Bands Typical losses Guaranteed losses Duplexer only 900 0.9 dB 1 dB 1800/1900 1.1 dB 1.2 dB whole H2D 900 4.3 dB 5 dB 1800/1900 4.5 dB 5 dB whole H4D 900 7.4 dB 8.5 dB 1800/1900 7.6 dB 8.5 dB
Cables Bands Indoor BTS Outdoor BTS Guaranteed losses Guaranteed losses
PA to Combiner 900 0.35 dB 0.25 dB 1800/1900 0.5 dB 0.4 dB
Combiner to Ant. conn 900 0.25 dB 0.2 dB 1800/1900 0.35 dB 0.3 dB
Page 4114
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.28.4
4.28.4.1
Space diversity gains

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.28.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.28.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.
GSM/BSS V12
Page 4115
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.
Page 4116
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
Link budget figures
As a summary, proposed link budget figures for crosspolar antenna use are summarized in the table below:
all environments 900 MHz & 1800 MHz radio link performances (DL & UL) diversity gain 1.5dB +4dB (5dB)*
flat rural, flat open 900 MHz & 1800 MHz 3dB +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.
GSM/BSS V12
Page 4117
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+PI/2
3dB hybrid dephaser
BTS with polarisation diversity
BTS with space 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 space diversity radio link performances (UL and DL) +4dB +5dB 0dB
Page 4118
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.29
CIRCULAR POLARISED CROSSPOLAR ANTENNAS PERFORMANCES

Introduction Here the aim is to present the characteristics of crosspolar antennas used in circular polarised configuration. The principle is the following: just before the crosspolar antenna connectors, an hybrid coupler is connected, for signal dephasing. Instead of using only one branch (that is one pole) of the antenna, the two branches are simultaneously used for transmission. The maximum number of TRXs that can be directly connected to the system is 2, as it is for traditional crosspolar antennas.
4.29.1
4.29.2
Performances Downlink performances of circular polarised crosspolar antennas are very similar to traditional vertical polarised antennas. Unlike classical crosspolar antennas, no additive losses are induced in the link budget. Furthermore, and like traditional crosspolar antennas, the tested system offers a double capacity in terms of TRXs that can be connected. Consequently, the present tests reveal that circular polarised antennas manage to overcome the disadvantage of standard crosspolar antennas but while keeping their main advantages in capacity.
4.29.3
4.29.3.1
Configuration Used
Reference Antenna
The reference configuration of antenna is given by the use of two vertically polarised antennas, in space diversity. The EIRP during the measurement was as following: PA output power 39.5 dBm Antenna gain 14 dBi Cable losses 4 dB EIRP 49.5 dBm
GSM/BSS V12
Page 4119
Engineering issues
4.29.3.2
Crosspolar Antenna
For the tests purposes, crosspolar antenna is preceded by a splitterdephaser and connected to the transmitter as following: The EIRP during the measurement was as following: PA output power 37.8 dBm Antenna gain 14.5 dBi Cable losses 4 dB Dephaser losses 3 dB Jumper losses 0.5 dB EIRP 45.5 dBm As can be seen, this type of configuration suffer of 3.5 dB additive losses. For the analysis purpose, only the EIRP will be taken into account and different antennas configuration will be compared at same EIRP. Circular polarised antenna seems to bring an advantage when the field is lower. Furthermore, the magnitude of the variations of the circular transmitted signal seems to be less important. At equivalent EIRP, crosspolar antennas in circular configuration offer an interesting gain, whatever the environment is. When removing from the EIRP the 3.5 dB losses of the dephaser, this kind of antenna still has correct performances, with a very limited loss compared to the traditional configuration. Whatever the conditions of propagation are, circular polarised antenna offer always better performances. If the 3.5 dB due to dephaser losses are taken into account, circular antenna still has interesting performances, plus 2 to 4 dB comparing to the use of one simple crosspolar antenna. Furthermore, circular polarised signal varies as the best linear polarised signal varies. Actually, the worst linear polarised signal always suffer of stronger and more frequent attenuation. This is mainly due to the diversity effect of the changes of the polarisation of the transmitted signal. Signal does not stay, from the polarisation point of view, in a bad situation very long time. Since direction of polarisation changes, bad configurations of orientation have no effects anymore.
Page 4120
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.29.4
Conclusion Comparing with traditional antennas, circular polarised antennas have similar performances since, at same PA output power and same antenna gain and same cable losses, circular polarised antenna induce a loss lower than 0.4 dB (worst case). As reference, simple crosspolar antennas induce losses of around 2 dB. Furthermore, performances of circular polarised antenna for carkit or handset are equivalent, which is not the case of crosspolar antennas. These latters actually can induce huge losses depending on the direction of the mobile antenna. Circular polarised signal is more stable. At same PA, antenna gain and cable losses, circular polarised antenna induces a gain of around 3 dB, in comparison with the use of only one branch of a crosspolar antenna.
GSM/BSS V12
Page 4121
Engineering issues
4.30
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.30.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.30.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.30.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.
Page 4122
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 Blocking rate Normal load Very loaded 2% 5%
SDCCH Blocking rate Middle LAC 2 to 5 % 5 to 10 % LAC border 0.5 to 1 % 1 to 3 %
4.30.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.30.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 SDCCH/4 SDCCH/3 SDCCH/7 SDCCH/8 Capacity (erlang) 0.235 0.087 1.422 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.30.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).
GSM/BSS V12
Page 4123
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.30.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.30.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.30.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).
Page 4124
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.30.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 C c B b1 b2 S S1 s s1 T C_ext c_ext B_ext b1_ext b2_ext S_ext s_ext T_ext TS1 Standard Cell mainBCCHcombined TCH bcchSdcch4CBCH TCH mainBCCH SDCCH mainBCCH sdcch8CBCH mainBCCH TCH TCH SDCCH TCH SDCCH TCH sdcch8CBCH TCH sdcch8CBCH TCH TCH Extended Cell mainBCCHcombined bcchSdcch4CBCH mainBCCH mainBCCH mainBCCH TCH TCH TCH TS0 TS2 TCH TCH TCH TCH TCH TCH SDCCH TCH SDCCH TCH TCH TCH SDCCH sdcch8CBCH TCH SDCCH sdcch8CBCH TCH TS3 to TS7 TCH TCH TCH TCH TCH TCH TCH TCH TCH TCH
GSM/BSS V12
Page 4125
Engineering issues
TRX / Cell
SDCCH8/Cell
TCH/Cell Standard Cell
TDMA/Cell
Priorities
1 1 2 3 4 5 6 7 8
0 1 1 2 2 3 3 4 4
1 2 3 4 5 6 7 8
0 1 1 1 1 2 2 2
7 C 6 B 14 BT 21 b2SS 29 b2SST 36 b2SSST 44 b2SSSTT 51 b2SSSSTT 59 b2SSSSTTT Extended Cell (TDMA models with _ext) 3 C 6 CT 10 b2ST 14 b2STT 18 b2STTT 21 b2SSTTT 25 b2SSTTTT 29 b2SSTTTTT
0 0 0,1 0,2,1 0,2,1,3 0,2,4,1,3 0,2,4,1,3,5 0,2,4,6,1,3,5 0,2,4,6,1,3,5,7
0 0,1 0,1,2 0,1,2,3 0,1,2,3,4 0,4,1,2,3,5 0,4,1,2,3,5,6 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.30.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.
Page 4126
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.31
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.31.1
4.31.1.1
BSS: Prerequisite
Checks
These checks are also included in the BSS NRP preparation. The syntax is: name of the parameter = recommended value, [concerned object, class]
GSM/BSS V12
Page 4127
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).
Page 4128
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.31.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.31.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.
GSM/BSS V12
Page 4129
Engineering issues
4.31.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.31.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.31.2.3 Cat.3: Other parameters modification
Not included in the BSS NRP. AllocPriorityTimers 30 [bts,3] 4.31.3

4.31.3.1
NSS level
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.
Page 4130
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 4131
Engineering issues
4.31.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.
Page 4132
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 4133
Engineering issues
4.32
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 100% OAM & internal processes CPU Call Processing limit (ex: 70%)
Offered traffic
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
Page 4134
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
4.32.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 MPU&BIFP SICD BSCB OMUSUPSWC CPU Engineering limits 55% 60% 60% 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.32.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.
GSM/BSS V12
Page 4135
Engineering issues
The following set of CPU Call Processing limit is based on field experience and lab performance reports.
Board MPU&BIFP SICD BSCB OMUSUPSWC CPU Call Processing limit 70% 70% 70% 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.
Page 4136
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
Hereunder is an example of figures obtained for a BSC12000 (with CPU120) on which is applied a typical standard (Nortel) traffic profile:
Load 70% 65% 60% 55% 50% 45% 40% 35% 30% 25% 20% 15% 10% 5% 0% 1 2 3 4 5 6 7 8
CPU Real Load / Traffic increase BSC12000/CPU120 Standard Profile
88% MOC 12% MTC 1,16 LU/call 1,01HO/call
1200
1000
800 Erlang 600
400
200 %rejectRACH/TOTAL 0 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)
GSM/BSS V12
Page 4137
Engineering issues
4.33
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.33.1
4.33.1.1
Dualband cell
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).
Page 4138
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.33.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 handover doesnt take into account the difference of radio propagation between the two bands. So, there is a signal drop (approximately Bizone_power_offset).
GSM/BSS V12
Page 4139
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.
Page 4140
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 handover doesnt take into account the difference of radio propagation between the two bands. So, there is a signal drop (approximately Bizone_power_offset). Band1 after the Power control: RxLev UL _Band1 = RxLev UL _Band0 Bizone_power_offset +(KUL*Bizone_power_offset (1KUL)*PMS )/VAL_PWRLEV_TO_DB (with VAL_PWRLEV_TO_DB = 2) 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.
GSM/BSS V12
Page 4141
Engineering issues
4.33.2
4.33.2.1
Concentric cell
One shot algorithm
The BSC knows the BS maximum output TX power in each zone, so the attenuation is compensated during an Interzone handover. RxLev DL _Zone1 = /VAL_PWRLEV_TO_DB RxLev
DL
_Zone0
(1K
DL
)*P
BS )
RxLev UL _Zone1 = RxLev UL _Zone0 (with VAL_PWRLEV_TO_DB = 2) Example: PBS = 15dB Bad quality without frequency hopping: KDL = 0.5 RxLev DL _Zone1 RxLev DL _Zone0 = 0.5*15/2 = 3.7 level (6 dB) Good quality with frequency hopping: KDL = 0.9 RxLev DL _Zone1 RxLev DL _Zone0 = 0.1*15/2 = 0.7 level (0 dB) 4.33.3
4.33.3.1
Dualcoupling cell
One shot algorithm
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 (with VAL_PWRLEV_TO_DB = 2) Example: Coupling D (loss about1dB) and H2D (loss about 4dB) Bizone_power_offset = 3dB = 1.5 level
Page 4142
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
Bad quality without frequency hopping: KDL = 0.5 RxLev DL _Zone1 RxLev DL _Zone0 = 1.5 + 0.5*1.5/2 = 1.1 level (2 dB) Good quality with frequency hopping: KDL = 0.9 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.
GSM/BSS V12
Page 4143
Engineering issues
4.34
4.34.1
CELL TIERING GAIN

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.34.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)
Page 4144
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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.
GSM/BSS V12
Page 4145
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.34.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).
Page 4146
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Engineering issues
BCCHTCH=3dB
120.00% BCCH BCCHTCH=3dB no tiering (19%nohop) 100.00% BCCHTCH=3dB tiering (19%nohop) BCCHTCH=3dB no tiering (25%nohop) BCCHTCH=3dB tiering (25%nohop) BCCHTCH=3dB no tiering (33%nohop) 80.00% BCCHTCH=3dB tiering (33%nohop)
60.00%
40.00% % of calls with C/I <= abscissa
20.00%
0.00% 11 7 3 1 5 9 13 17 21 25 29 33 37 41 45 49 53 57
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.34.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
GSM/BSS V12
Page 4147
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 18,00 16,00 14,00 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
TRX12 TRXF0.15 TRXF0.25T19% TRXF0.10 TRXF0.15T19%
Page 4148
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 108,00 98,00 88,00 78,00 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 ERG12 ERGF0.15 ERGF0.25T19% ERGF0.10 ERGF0.15T19%
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.34.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
GSM/BSS V12
Page 4149
Engineering issues
Page 4150
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
APPENDIX A: Main exchange procedures at BSC level
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
Establishment Indication
Reset t3101
UA
Connection request
Connection cnf
SABME: frame to set asynchronous balanced mode (initiate a link for numbered information transfer). UA: unnumbered aknowledge
GSM/BSS V12
Page 51
5.2
PROC_2: CHANNEL MODE PROCEDURE
MS
BTS
BSC
MSC
channel activate TmodMs TimmAck
assign request
channel activate / mode modify Ack Reset TmodMs Reset TimmAck channel mode modify channel mode modify TmodMs
mode channel modify Ack
mode channel modify Ack assign complete Reset TmodMs
Page 52
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
5.3
PROC_3: DEDICATED CHANNEL ASSIGNMENT
MS
BTS
BSC
MSC
channel activate TimmAck channel activate Ack
assign request
assign command
Reset Timm Ack t3107
assign command SABME UA assign complete assign complete RF channel release assign complete Reset Trf Ack Reset t3107 Trf Ack
establishment indication
RF channel release Ack
GSM/BSS V12
Page 53
5.4
PROC_4: INTRACELL HANDOVER PROCEDURE
MS
BTS
handover indication channel activate
BSC
(TCH/SDCCH)
MSC
TimmAck
channel activate Ack assign command Reset Timm Ack t3107
assign command SABME (new facch) UA (new facch) assign complete assign complete RF channel release handover performed RF channel release Ack Reset Trf Ack Reset t3107 Trf Ack establishment indication (new facch)
Page 54
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
5.5
PROC_5: INTRABSS HANDOVER PROCEDURE
MS
BTS 1
BTS 2
>handover indication>
BSC
(TCH/SDCCH) <channel activate< TimmAck
MSC
>channel activate Ack> <HO command< <HO command< >H O access> >HO detect> <physical info< >SABME (new dcch)> <UA (new dcch)< >H O complete> Reset Timm Ack t3103
>establishment indication (new facch)>
Reset t3103 Trf Ack
<HO coplete> <RF channel release< <RF channel release Ack> Reset Trf Ack
>handover performed>
From BTS 1 to BTS 2
GSM/BSS V12
Page 55
5.6
PROC_6: INTERBSS HANDOVER PROCEDURE
MS
BTS 1
BSC 1
MSCs
<HO required> <HO request<
BSC 2
BTS 2
>H O required>
bssMap T7
TimmAck CC
>channel activate> <channel activate Ask<
<H O command< >H O access>
<H O command<
reset bssMap T7 t3103<bssMap T8 <H O command<
<HO request Ack<
Reset Timm Ack ThnCom
<HO detect< >HSABME (new dcch)>
<HO detect< <physical info< <est connection (new dcch)<
<UA (new dcch)< >H O complete>
Reset t3103, T8 >clear command< <HO complete< <RF channel release< <RF channel release Ack< TrfAck
Reset ThndCom
<HO complete<
Reset Trf Ack
>clear complete>
BTS 1 (from BSC 1) to BTS 2 (from BSC 2)
Page 56
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
5.7
PROC_7: RESOURCE RELEASE PROCEDURE (EXAMPLE)
BTS
BSC
Start t3111
Release Indication
RF Channel Release RF Channel Release ACK
t3111 expires
GSM/BSS V12
Page 57
5.8
PROC_8: SACCH DEACTIVATION PROCEDURE
BTS
BTS
<DataReq (Channel Release)< <Channel Release< >Deactivate SACCH>
BSC
>Deactivate SACCH Ack> >disc> <UA< >Release Indication>
Start t3109
Stop t3109 Start t3111
<RF Channel Release<
t3111 expires
>RF Channel Release ACK>
Page 58
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
5.9
CASE OF MOBILE TERMINATING CALLS
MS RR paging request
BTS A LAC 1 Paging command PCH RR channel request RACH Channel required Channel activation
BSC Paging command
BTS B LAC 1 Paging request PCH
Channel activation ACK RR immediate assignment AGCH Switch to SDCCH channel SABM (RR paging response) SDCCH UA (RR paging response) SDCCH Establish indication (RR paging response) Toward MSC Immediate assignment command
GSM/BSS V12
Page 59
5.10
CASE OF MOBILEINITIATING CALLS
MS RR channel request RACH
BTS Channel required Channel activation
BSC
MSC
Channel activation ACK RR immediate assignment AGCH Switch to SDCCH channel SABM (MM CM_service request) SDCCH UA (MM CM_service request) SDCCH Immediate assignment command
Establish indication (MM CM_service request)
SCCP connection request (BSSMAP complete L3 info (MM CM_service request)
Page 510
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Erlang Table
ERLANG TABLE
Blocking rate Channels 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 0,000 0,014 0,087 0,235 0,452 0,728 1,054 1,422 1,825 2,260 2,721 3,207 3,713 4,238 4,781 5,338 5,910 6,495 0,001 0,046 0,194 0,439 0,761 1,145 1,577 2,049 2,555 3,089 3,648 4,227 4,826 5,441 6,071 6,715 7,371 8,038 0,005 0,105 0,347 0,698 1,126 1,126 2,147 2,716 3,316 3,941 4,587 5,253 5,934 6,630 7,339 8,059 8,790 9,530 0,010 0,151 0,451 0,861 1,347 1,890 2,476 3,096 3,745 4,417 5,108 5,817 6,541 7,278 8,027 8,786 9,555 10,333 0,020 0,219 0,590 1,070 1,624 2,230 2,877 3,554 4,258 4,982 5,725 6,483 7,254 8,036 8,829 9,632 10,443 11,261 0,030 0,273 0,694 1,221 1,819 2,467 3,152 3,867 4,606 5,364 6,138 6,927 7,728 8,539 9,361 10,190 11,027 11,871 0,040 0,320 0,780 1,343 1,975 2,654 3,369 4,112 4,876 5,660 6,458 7,270 8,093 8,926 9,768 10,617 11,474 12,336 0,050 0,362 0,854 1,448 2,108 2,812 3,551 4,316 5,102 5,905 6,723 7,553 8,393 9,243 10,101 10,966 11,838 12,716 0,060 0,401 0,922 1,541 2,224 2,950 3,709 4,493 5,296 6,116 6,949 7,795 8,650 9,514 10,385 11,264 12,148 13,038 0,070 0,438 0,983 1,625 2,328 3,073 3,849 4,649 5,468 6,302 7,149 8,008 8,875 9,751 10,634 11,523 12,418 13,318 0,080 0,472 1,040 1,702 2,424 3,185 3,976 4,790 5,622 6,469 7,328 8,198 9,076 9,962 10,855 11,754 12,658 13,567 0,090 0,505 1,093 1,774 2,511 3,288 4,092 4,919 5,763 6,621 7,490 8,369 9,257 10,153 11,054 11,961 12,874 13,790 0,100 0,536 1,144 1,841 2,593 3,383 4,199 5,038 5,892 6,759 7,638 8,527 9,423 10,326 11,235 12,150 13,069 13,993 0,200 0,800 1,544 2,356 3,208 4,087 4,984 5,895 6,818 7,748 8,686 9,629 10,578 11,530 12,486 13,446 14,408 15,373 0,0001 0,01% 0,001 0,10% 0,005 0,50% 0,01 1% 0,02 2% 0,03 3% 0,04 4% 0,05 5% 0,06 6% 0,07 7% 0,08 8% 0,09 9% 0,1 10% 0,2 20%
GSM/BSS V12
Page 6.1
Erlang Table
Blocking rate Channels 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
0,0001 0,01% 7,092 7,700 8,318 8,945 9,582 10,226 10,879 11,539 12,206 12,879 13,559 14,244 14,936 15,631 16,333 17,039 17,750 18,467 19,186 19,908
0,001 0,10% 8,715 9,402 10,098 10,801 11,513 12,231 12,956 13,687 14,424 15,167 15,914 16,667 17,425 18,186 18,953 19,722 20,497 21,275 22,056 22,842
0,005 0,50% 10,279 11,036 11,801 12,572 13,349 14,133 14,922 15,716 16,515 17,319 18,127 18,939 19,756 20,575 21,397 22,225 23,053 23,886 24,722 25,561
0,01 1% 11,118 11,910 12,709 13,515 14,326 15,142 15,963 16,789 17,619 18,454 19,292 20,134 20,981 21,828 22,681 23,533 24,392 25,253 26,114 26,981
0,02 2% 12,086 12,918 13,755 14,598 15,446 16,298 17,154 18,015 18,879 19,748 20,619 21,493 22,369 23,250 24,133 25,019 25,906 26,797 27,689 28,583
0,03 3% 12,721 13,578 14,439 15,305 16,175 17,050 17,928 18,810 19,696 20,584 21,476 22,370 23,267 24,167 25,069 25,972 26,881 27,789 28,697 29,611
0,04 4% 13,205 14,079 14,958 15,841 16,728 17,618 18,513 19,411 20,311 21,215 22,121 23,030 23,942 24,856 25,769 26,689 27,608 28,531 29,453 30,378
0,05 5% 13,599 14,487 15,379 16,276 17,176 18,079 18,986 19,896 20,809 21,724 22,642 23,562 24,483 25,408 26,333 27,264 28,192 29,125 30,058 30,992
0,06 6% 13,933 14,832 15,736 16,643 17,554 18,468 19,385 20,304 21,227 22,152 23,079 24,008 24,939 25,872 26,808 27,744 28,683 29,622 30,564 31,506
0,07 7% 14,223 15,132 16,045 16,962 17,881 18,804 19,729 20,658 21,588 22,521 23,456 24,393 25,331 26,272 27,214 28,158 29,103 30,050 30,997 31,947
0,08 8% 14,481 15,398 16,319 17,243 18,171 19,101 20,033 20,969 21,906 22,845 23,787 24,730 25,675 26,622 27,569 28,519 29,469 30,422 31,378 32,331
0,09 9% 14,711 15,636 16,564 17,495 18,429 19,366 20,305 21,246 22,189 23,135 24,082 25,031 25,981 26,933 27,886 28,842 29,797 30,756 31,714 32,672
0,1 10% 14,921 15,852 16,786 17,723 18,663 19,605 20,550 21,496 22,445 23,396 24,348 25,301 26,256 27,214 28,172 29,131 30,092 31,053 32,014 32,978
0,2 20% 16,339 17,308 18,279 19,251 20,224 21,199 22,176 23,153 24,131 25,111 26,091 27,072 28,053 29,036 30,019 31,003 31,989 32,972 33,958 34,944
Page 6.2
PE/IRC/APP/0037
Standard 05.02/EN
January 2000
Erlang Table
0,0001 0,01% 20,636 21,369 22,103 22,842 23,583 24,331 25,078 25,831 26,583 27,342 28,100 28,864 29,628 30,397 31,167 31,939 32,714 33,492 34,269 35,050
0,001 0,10% 23,628 24,419 25,214 26,011 26,811 27,614 28,419 29,225 30,036 30,847 31,664 32,481 33,297 34,119 34,942 35,767 36,594 37,422 38,253 39,086
0,005 0,50% 26,400 27,244 28,092 28,939 29,789 30,642 31,497 32,356 33,214 34,075 34,936 35,803 36,667 37,536 38,406 39,275 40,150 41,022 41,897 42,775
0,01 1% 27,847 28,717 29,589 30,464 31,339 32,217 33,097 33,978 34,861 35,747 36,633 37,522 38,411 39,303 40,197 41,089 41,986 42,881 43,781 44,678
0,02 2% 29,478 30,378 31,278 32,181 33,083 33,989 34,894 35,803 36,714 37,625 38,536 39,450 40,364 41,281 42,200 43,117 44,036 44,958 45,881 46,803
0,03 3% 30,525 31,439 32,356 33,275 34,194 35,117 36,042 36,964 37,892 38,817 39,744 40,675 41,606 42,536 43,469 44,403 45,336 46,272 47,208 48,144
0,04 4% 31,303 32,231 33,161 34,092 35,025 35,958 36,892 37,828 38,767 39,703 40,642 41,583 42,525 43,467 44,408 45,353 46,297 47,244 48,192 49,139
0,05 5% 31,928 32,867 33,806 34,744 35,686 36,628 37,572 38,517 39,464 40,411 41,358 42,306 43,256 44,206 45,158 46,108 47,061 48,017 48,969 49,925
0,06 6% 32,450 33,394 34,342 35,289 36,239 37,189 38,139 39,092 40,044 40,997 41,950 42,906 43,864 44,819 45,778 46,736 47,694 48,656 49,617 50,578
0,07 7% 32,897 33,847 34,800 35,756 36,711 37,667 38,622 39,581 40,539 41,497 42,458 43,419 44,381 45,342 46,306 47,269 48,233 49,197 50,164 51,131
0,08 8% 33,286 34,244 35,203 36,161 37,122 38,083 39,044 40,006 40,969 41,933 42,897 43,864 44,831 45,797 46,764 47,731 48,700 49,669 50,639 51,608
0,09 9% 33,633 34,594 35,558 36,519 37,486 38,450 39,417 40,383 41,350 42,317 43,286 44,256 45,225 46,197 47,167 48,139 49,111 50,083 51,058 52,031
0,1 10% 33,944 34,908 35,875 36,842 37,811 38,778 39,747 40,719 41,689 42,661 43,633 44,606 45,581 46,553 47,528 48,503 49,478 50,453 51,431 52,406
0,2 20% 35,931 36,917 37,906 38,892 39,881 40,869 41,858 42,847 43,836 44,825 45,817 46,806 47,797 48,789 49,778 50,769 51,761 52,753 53,744 54,736
GSM/BSS V12
Page 6.3
Erlang Table
0,0001 0,01% 35,833 36,619 37,406 38,197 38,986 39,781 40,575 41,372 42,169 42,969 43,769 44,572 45,378 46,183 46,992 47,800 48,611 49,422 50,236 51,050
0,001 0,10% 39,919 40,756 41,592 42,431 43,269 44,111 44,956 45,800 46,644 47,492 48,342 49,189 50,042 50,894 51,747 52,603 53,458 54,314 55,172 56,031
0,005 0,50% 43,653 44,533 45,414 46,294 47,178 48,064 48,950 49,836 50,722 51,611 52,503 53,394 54,286 55,178 56,072 56,967 57,864 58,758 59,656 60,556
0,01 1% 45,578 46,481 47,383 48,286 49,192 50,097 51,003 51,911 52,819 53,728 54,639 55,550 56,464 57,375 58,289 59,206 60,119 61,036 61,953 62,872
0,02 2% 47,728 48,650 49,578 50,503 51,431 52,358 53,289 54,219 55,150 56,081 57,014 57,947 58,881 59,814 60,750 61,686 62,622 63,558 64,497 65,436
0,03 3% 49,083 50,022 50,961 51,903 52,844 53,786 54,728 55,672 56,617 57,561 58,506 59,453 60,400 61,347 62,294 63,242 64,192 65,142 66,092 67,042
0,04 4% 50,086 51,036 51,983 52,933 53,886 54,836 55,789 56,742 57,694 58,650 59,606 60,558 61,514 62,472 63,428 64,386 65,344 66,303 67,261 68,219
0,05 5% 50,881 51,836 52,794 53,753 54,711 55,669 56,628 57,589 58,550 59,511 60,472 61,433 62,397 63,358 64,322 65,286 66,250 67,217 68,181 69,147
0,06 6% 51,539 52,500 53,464 54,428 55,392 56,356 57,319 58,286 59,253 60,219 61,186 62,153 63,122 64,089 65,058 66,028 66,997 67,967 68,936 69,908
0,07 7% 52,097 53,064 54,031 55,000 55,969 56,939 57,908 58,878 59,847 60,819 61,792 62,761 63,733 64,708 65,681 66,653 67,628 68,603 69,575 70,550
0,08 8% 52,581 53,553 54,522 55,494 56,469 57,442 58,414 59,389 60,364 61,339 62,314 63,289 64,264 65,242 66,217 67,194 68,172 69,147 70,125 71,106
0,09 9% 53,006 53,981 54,956 55,931 56,906 57,883 58,861 59,836 60,814 61,792 62,769 63,750 64,728 65,708 66,686 67,667 68,647 69,628 70,608 71,589
0,1 10% 53,383 54,361 55,339 56,317 57,297 58,275 59,256 60,233 61,214 62,194 63,175 64,158 65,139 66,119 67,103 68,083 69,067 70,050 71,033 72,017
0,2 20% 55,731 56,722 57,714 58,708 59,700 60,694 61,686 62,681 63,672 64,667 65,661 66,656 67,650 68,642 69,636 70,631 71,625 72,619 73,614 74,611
Page 6.4
PE/IRC/APP/0037
Standard 05.02/EN
January 2000
Erlang Table
0,0001 0,01% 51,864 52,681 53,500 54,319 55,142 55,961 56,786 57,608 58,433 59,261 60,089 60,917 61,747 62,578 63,408 64,242 65,075 65,911 66,744 67,583
0,001 0,10% 56,892 57,753 58,614 59,478 60,342 61,208 62,072 62,942 63,808 64,678 65,547 66,417 67,289 68,161 69,033 69,908 70,783 71,658 72,533 73,411
0,005 0,50% 61,456 62,356 63,256 64,156 65,058 65,961 66,867 67,769 68,675 69,583 70,489 71,397 72,306 73,214 74,122 75,033 75,944 76,856 77,767 78,678
0,01 1% 63,789 64,708 65,628 66,550 67,472 68,392 69,317 70,239 71,161 72,086 73,011 73,936 74,864 75,792 76,717 77,644 78,575 79,503 80,433 81,361
0,02 2% 66,375 67,314 68,256 69,194 70,136 71,078 72,019 72,964 73,906 74,850 75,794 76,739 77,686 78,631 79,578 80,525 81,469 82,419 83,367 84,314
0,03 3% 67,994 68,944 69,897 70,850 71,803 72,756 73,711 74,664 75,619 76,575 77,531 78,486 79,444 80,400 81,358 82,317 83,275 84,233 85,192 86,150
0,04 4% 69,178 70,139 71,100 72,061 73,022 73,983 74,947 75,908 76,872 77,836 78,797 79,764 80,728 81,692 82,656 83,622 84,589 85,553 86,519 87,486
0,05 5% 70,111 71,078 72,044 73,014 73,981 74,947 75,917 76,886 77,856 78,822 79,794 80,764 81,733 82,703 83,675 84,644 85,617 86,589 87,561 88,533
0,06 6% 70,878 71,850 72,822 73,794 74,767 75,739 76,711 77,686 78,658 79,633 80,608 81,581 82,556 83,531 84,506 85,483 86,458 87,433 88,411 89,386
0,07 7% 71,525 72,500 73,478 74,453 75,428 76,406 77,383 78,358 79,336 80,314 81,292 82,269 83,250 84,228 85,206 86,186 87,164 88,144 89,125 90,106
0,08 8% 72,083 73,061 74,039 75,019 76,000 76,978 77,958 78,939 79,919 80,900 81,881 82,861 83,844 84,825 85,808 86,789 87,772 88,753 89,736 90,719
0,09 9% 72,569 73,550 74,533 75,514 76,497 77,478 78,461 79,444 80,428 81,411 82,394 83,378 84,361 85,344 86,331 87,314 88,300 89,283 90,269 91,253
0,1 10% 73,000 73,983 74,967 75,950 76,936 77,919 78,906 79,889 80,875 81,861 82,847 83,831 84,817 85,803 86,789 87,778 88,764 89,750 90,736 91,725
0,2 20% 75,606 76,600 77,594 78,589 79,586 80,581 81,575 82,572 83,567 84,561 85,558 86,553 87,550 88,544 89,542 90,539 91,533 92,531 93,525 94,522
GSM/BSS V12
Page 6.5
Erlang Table
Blocking rate Channels 99 100 101 102 103 104 105 106 107 108 109 110 111 112
0,0001 0,01% 68,419 69,258 70,097 70,936 71,778 72,619 73,461 74,306 75,150 75,994 76,842 77,689 78,536 79,383
0,001 0,10% 74,289 75,167 76,044 76,925 77,806 78,686 79,569 80,453 81,336 82,219 83,103 83,989 84,875 85,761
0,005 0,50% 79,592 80,506 81,419 82,333 83,250 84,167 85,081 85,997 86,917 87,833 88,753 89,672 90,589 91,511
0,01 1% 82,292 83,222 84,156 85,086 86,019 86,953 87,886 88,819 89,753 90,689 91,622 92,558 93,494 94,431
0,02 2% 85,264 86,214 87,161 88,111 89,061 90,014 90,964 91,917 92,867 93,819 94,772 95,725 96,678 97,631
0,03 3% 87,111 88,069 89,031 89,992 90,953 91,914 92,875 93,836 94,797 95,761 96,722 97,686 98,650 99,614
0,04 4% 88,453 89,422 90,389 91,356 92,325 93,294 94,261 95,231 96,200 97,169 98,139 99,108 100,081 101,050
0,05 5% 89,506 90,478 91,450 92,425 93,397 94,372 95,347 96,319 97,294 98,269 99,244 100,219 101,194 102,169
0,06 6% 90,364 91,342 92,319 93,297 94,272 95,253 96,231 97,208 98,186 99,164 100,144 101,122 102,103 103,083
0,07 7% 91,086 92,067 93,047 94,028 95,008 95,989 96,969 97,953 98,933 99,917 100,897 101,881 102,864 103,844
0,08 8% 91,703 92,686 93,669 94,653 95,636 96,619 97,606 98,589 99,572 100,558 101,542 102,528 103,511 104,497
0,09 9% 92,239 93,225 94,211 95,197 96,183 97,169 98,156 99,142 100,128 101,114 102,100 103,089 104,075 105,061
0,1 10% 92,711 93,700 94,686 95,675 96,661 97,650 98,639 99,625 100,614 101,603 102,592 103,581 104,569 105,558
0,2 20% 95,519 96,514 97,511 98,508 99,506 100,500 101,497 102,494 103,492 104,489 105,483 106,481 107,478 108,475
Page 6.6
PE/IRC/APP/0037
Standard 05.02/EN
January 2000
Abbreviations & definitions
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 BDA Base Common Function 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 BSCB Base Station Controller 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
GSM/BSS V12
Page 71
BTS CA
Base Transceiver Station 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 dB dBm DCCH
Central BSC processing unit handling MPU and BIFP functions Decibel Unit of measure of relative power level defined as 10 log10 (P1/P2) where P1 and P2 are the power levels. Power in dB relative to 1 mW 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 EIRP FACCH
Discontinuous Transmission Equivalent Isotropic Radiated Power Fast Associated Control CHannel Dedicated signalling channel (Um interface)
Page 72
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
FCCH
Frequency Correction CHannel Common frequency synchronization channel
FCH
Frequency CHannel Common frequency synchronization channel
FER FH FN FP GSM GSM 900, GSM 1800, GSM 1900 HO
Frame Erasure Rate Frequency Hopping Frame Number Frame Processor Global System for Mobile Communications
Radio Cellular Network standard adapted for the 900 or 1800 or 1900 MHz frequency band. HandOver. Automatic call transfer implemented between the radio channels of the same or different cells without interrupting transmission
HSN L1M LAC
Hopping Sequence Number Processor functional unit handling BTS radio measurements 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 LNA MA MAI MAIO MCC MTBF MEU
Link Budget Low Noise Amplifier, part of DLNA system Mobile Allocation Mobile Allocation Index Mobile Allocation Index Offset Mobile Country Code Minimum Time Between Failure Masthead Electronics Unit Minimasthead electronics cabinet. Remote amplifier located between BTS and the antenna
MHz
MegaHertz
GSM/BSS V12
Page 73
MMU MPU
Mass Memory Unit (BSC) Main Processor Unit (BSC) Set of BSC functional units charged mainly with call processing functions
MNC Mp MRC MS MSC NCC
Mobile Network Code Measurement processing Maximum Radio Combiner Mobile Station Mobile Services Switching Center Network Colour Code First three bits of the BSIC code. Each country is assigned a list of NCC.
MCL NMC NSS
Minimum Coupling Loss Network Management Centre Network and Switching SubSystem Radio Cellular Network subsystem including an MSC, main HLR, VLR, EIR and AUC
OMC OMCR OMCS OMU OSS
Operation and Maintenance Centre for the radio subsystem Operation and Maintenance Centre Radio Operation and Maintenance Centre Switching Central BSC Operation & Maintenance Unit Operation SubSystem Radio Cellular Network operations subsystem including the OMCR and OMCS
PA PC PCH
Power Amplifier Power Control Paging CHannel Common subscriber radio paging channel
PLMN PSTN RACH
Public Land Mobile Network Public Switched Telephone Network Random Access CHannel Common mobile logical channel, reserved for random access requests transmitted by mobile stations on the radio interface.
Page 74
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
RF RLC RX SACCH
Radio Frequency Radio Link Counter BTS receiver Slow Associated Control CHannel Slow logical control channel associated with a traffic channel during a communication
SAM SCH
Smart Antenna Module 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 SICD
Slow Frequency Hopping Serial Interface Controller LAPD BSC board controller for Abis and Ater Interface
SUP
SUPervision unit Functional BSC monitoring unit
SWC TCH
SWitching matrix Controller (BSC 6000) Traffic CHannel Radio traffic channel
TCH/F TCH/H TDMA
Traffic CHannel/Full rate Traffic CHannel/Half rate 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
GSM/BSS V12
Page 75
TS TSCB
Time Slot 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 MTBF Radio interface Timing Advance Uminterface Automatic call transfer between two radio channels It is a mathematical time expectancy between two successive parts of equipment or unit failure Interface between the mobile station (MS) and the BTS delay used to compensate propagation time between mobile and base station See Radio interface
Page 76
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Index of parameters
A
accessClassCongestion, 375 adjacent cell umbrella ref, 390 allocPriorityTable, 375 allocPriorityThreshold, 376 allocPriorityTimers, 377 allocWaitThreshold, 378 allOtherCasesPriority, 379 answerPagingPriority, 379 assignRequestPriority, 380 Attenuation, 363 averagingPeriod, 3100
B
baseColourCode, bts, 3132 biZonePowerOffset
adjacentHandOver, 325 handOverControl, 326
bscHopReconfUse, 3120 bscMSAccessClassBarringFunction, 381 bscQueueingOption, 381 bsMsmtProcessingMode, 363 bsPowerControl, 364 bssMapT1, 3106 bssMapT12, 3106 bssMapT13, 3106 bssMapT19, 3107 bssMapT20, 3107 bssMapT4, 3108 bssMapT7, 3108 bssMapT8, 3108 bssMapTchoke, 3109 bssSccpConnEst, 3109 bsTxPwrMax, 364 bts time between HO configuration, 327 btsHopReconfRestart, 3120 btsIsHopping, 3121 btsMSAccessClassBarringFunction, 382 btsThresholdHopReconf, 3122
GSM/BSS V12
Page i
Index of parameters
C
callClearing, 358 callReestablishment, 39 callReestablishmentPriority, 382 cellAllocation, 3123 cellBarQualify, 383 cellBarred, 383 cellDeletionCount, 321 cellDtxDownLink, 3131 cellReselectHysteresis, 33 cellReselectOffset, 33 cellReselInd, 34 cellType
adjacentCellHandOver, 355 bts, 355
channelType, 383 concentAlgoExtMsRange, 395 concentAlgoExtRxLev, 395 concentAlgoIntMsRange, 396 concentAlgoIntRxLev, 397 concentric cell, 398 cpueNumber, 3132
D
delayBetweenRetrans, 3115 directedRetry, 390 directedRetryModeUsed, 391 directedRetryPrio, 391 distHreqt, 323 distWtsList, 323 dtxMode, 3131
E
early classmark sending, 3128 emergencyCallPriority, 384 enhancedTRAUFrameIndication, 3136 extended cell, 358
F
fhsRef, 3123 forced handover algo, 328
Page ii
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Index of parameters
H
HandOver from signalling channel, 328 hoMargin, 328 hoMarginBeg, 329 hoMarginDist, 330 hoMarginRxLev, 330 hoMarginRxQual, 332 hoMarginTiering, 3141 hoMarginTrafficOffset, 332 HOPingpongCombination, 333 HOPingpongTimeRejection, 335 hoppingSequenceNumber, 3123 HOSecondBestCellConfiguration, 336 hoTraffic
bsc, 337 bts, 337
I
interBscDirectedRetry, 392 interBscDirectedRetryFromCell, 392 interCellHOExtPriority, 384 interCellHOIntPriority, 385 interferenceType, 3141 interferer cancel algo usage, 3135 intraBscDirectedRetry, 393 intraBscDirectedRetryFromCell, 393 intraCell, 346 intraCellHOIntPriority, 386 intraCellQueueing, 386 intraCellSDCCH, 347
L
lapdTerminalNumber, 3126 lRxLevDLH, 350 lRxLevDLP, 365 lRxLevULH, 350 lRxLevULP, 366 lRxQualDLH, 351 lRxQualDLP, 366 lRxQualULH, 353 lRxQualULP, 367
GSM/BSS V12
Page iii
Index of parameters
M
maio, 3124 maxNumberRetransmission, 3115 measurementProcAlgorithm, 3133 microCellCaptureTimer, 356 microCellStability, adjacentCellHandOver, 356 minNbOfTDMA, 386 missDistWt, 324 missRxLevWt, 317 missRxQualWt, 314 mobileAllocation, 3125 modeModifyMandatory, 394 msBtsDistanceInterCell, 360 msRangeMax, 359 msTxPwrMax, 338 msTxPwrMax2ndBand, 368 msTxPwrMaxCCH, 34 msTxPwrMaxCell, 338 multi band reporting, 3128
N
nbLarge Reuse Data Channels, 3141 nbOfRepeat, 3116 new power control algorithm, 368 noOfBlocksForAccessGrant, 3116 noOfMultiframesBetweenPaging, 3117 notAllowedAccessClasses, 387 numberOfPwciSamples, 3142 numberOfSlotsSpreadTrans, 3118 numberOfTCHFreeBeforeCongestion, 387 numberOfTCHFreeToEndCongestion, 388 numberOfTCHQueuedBeforeCongestion, 388 numberOfTCHQueuedToEndCongestion, 388
O
offsetLoad, 339 offsetPriority, 340 otherServicesPriority, 389
Page iv
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
Index of parameters
P
pagingOnCell, 3118 pcmErrorCorrection, 3136 penaltyTime, 35 powerBudgetInterCell, 340 powerControlIndicator, 369 powerIncrStepSize, 369 powerRedStepSize, 370 preSynchroTimingAdvance, 361 priority, 389 processorLoadSupConf, 3126 pwciHreqave, 3142
R
radChanSelIntThreshold, 3100 radioLinkTimeOut, 39 radResSupBusyTimer, 3104 radResSupervision, 3104 radResSupFreeTimer, 3105 retransDuration, 3118 rlf1, 311 rlf2, 312 rlf3, 312 rndAccTimAdvThreshold, 361 runCallClear, 362 runHandOver, 341 runPwrControl, 370 rxLevAccessMin, 36 rxLevDLIH, 347 rxLevDLPBGT, 354 rxLevHreqave, 317 rxLevHreqaveBeg, 318 rxLevHreqt, 319 rxLevMinCell, 341 rxLevNCellHreqaveBeg, 322 rxLevULIH, 348 rxLevWtsList, 319 rxNCellHreqave, 321 rxQualDLIH, 348
GSM/BSS V12
Page v
Index of parameters
rxQualHreqave, 314 rxQualHreqt, 315 rxQualULIH, 349 rxQualWtsList, 316
S
selfTuningObs, 3143 siteGsmFctList, 3133 standard indicator AdjC
adjacentCellHandOver, 3129 adjacentCellReselection, 3130
synchronized, 344
T
t3101, 3110 t3103, 3110 t3107, 3111 t3109, 3112 t3111, 3113 t3122, 3113 temporaryOffset, 37 thresholdInterference, 3102 timeBetweenHOConfiguration, 345 timerPeriodicUpdateMS, 3114 traffic PCM allocation priority, 3125
U
uplinkMappingChannelNumber, 3138 uplinkMappingFreq, 3138 uplinkMappingMeasurementMode, 3139 uplinkMappingProcessingMode, 3139 uplinkPowerControl, 371 uRxLevDLP, 371 uRxLevULP, 372 uRxQualDLP, 372 uRxQualULP, 373
Z
zone Tx power max reduction, 399
Page vi
PE/IRC/APP/0037 4119001037
Approved 05.02/EN
January 2000
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 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 Reference PE/IRC/APP/037 4119001037 05.02/EN January 2000 Printed in France
For more information, please contact: For all countries, except USA: Documentation Department 1, Place des Frres Montgolfier GUYANCOURT 78928 YVELINES CEDEX 9 FRANCE Email : gsmntp@nortelnetworks.com Fax : (33) (1) 39445029 In the USA: 2221 Lakeside Boulevard Richardson TX 75082 USA Tel: 18004 NORTEL 18004667838 or (972) 6845935
Internet Address: http://www.nortelnetworks.com

BSS Parameter User&#39;s Guide V12

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

BSS Parameter User&#39;s Guide V12

Transféré par

Droits d'auteur :

Formats disponibles

Wireless Service Provider Solutions

BSS Parameters User Guide

: BSS Parameters User Guide

Wireless Service Provider Solutions

BSS Parameters User Guide

SYSTEM RELEASE : GSM/BSS V11

SYSTEM RELEASE : GSM/BSS V10

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE

SYSTEM RELEASE : GSM/BSS V09

Confidential information may not be copied or disclosed without permission

ABOUT THIS DOCUMENT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

CLASSIFICATION OF BSS PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . .

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE

Confidential information may not be copied or disclosed without permission

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE

Confidential information may not be copied or disclosed without permission

2.18 2.18.1 2.18.2

2133 2133 2136

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE

3.21 3.22 3.23 3.24 3.25 3.26 3.27 3.28 3.29

3120 3126 3128 3131 3132 3135 3136 3138 3141

4.13 4.14 4.14.1

Confidential information may not be copied or disclosed without permission

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE

Confidential information may not be copied or disclosed without permission

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE

4.34.2 4.34.3 4.34.4 4.34.5

4144 4146 4147 4149

APPENDIX A: MAIN EXCHANGE PROCEDURES AT BSC LEVEL . . . .

ABBREVIATIONS & DEFINITIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Confidential information may not be copied or disclosed without permission

247 296 296 2101 2116 44 45 45 46 47 416 417

FIGURE 410 FIGURE 411

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE

TABLE 21 TABLE 22 TABLE 23 TABLE 24 TABLE 25 TABLE 41 TABLE 42

297 2117 2119 2121 2121 4135 4136

Confidential information may not be copied or disclosed without permission

About this document

ABOUT THIS DOCUMENT

AUDIENCE FOR THIS MANUAL

[E1] [E2] [E3]

Approved Internal NMC documents:

PE/BTS/DD/0421 V2 SFS of BTS: Measurement Processing (V11)

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE

About this document

Confidential information may not be copied or disclosed without permission

About this document

[I32] [I33] [I34] [I35]

Confidential information may not be copied or disclosed without permission

BSS PARAMETERS USER GUIDE

About this document

PE/SYS/APP/230: Engineering exceptional events

Confidential information may not be copied or disclosed without permission

Classification of BSS parameters

CLASSIFICATION OF BSS PARAMETERS

BSS Parameter User's Guide V12

BSS Parameter User's Guide V12