WKS04 HDPC2 GSR8 PDF

CHAPTER 1 CHAPTER 2 CHAPTER 3 CHAPTER 4 CHAPTER 5
TRAINING MANUAL
HANDOVER DETECTION AND POWER CONTROL
WORKSHOPS 2
VERSION 1 REV 1
GSM SOFTWARE RELEASE 8
WKS 04
FOR TRAINING PURPOSES ONLY –

THIS MANUAL WILL NOT BE UPDATED
PURPOSES ONLY
WKS 04
TRAINING MANUAL
FOR TRAINING
THIS MANUAL
WILL NOT BE
UPDATED
HANDOVER DETECTION AND POWER CONTROL WORKSHOPS 2
–
VERSION 1 REV 1
GSM SOFTWARE RELEASE 8
GSM
Software Release GSR8
wks 04
Handover detection and power
control workshops 2
E Motorola 2002
All Rights Reserved
Printed in the UK.
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 i

Version 1 Rev 1
Copyrights, notices and trademarks
Copyrights
The Motorola products described in this document may include copyrighted Motorola computer
programs stored in semiconductor memories or other media. Laws in the United States and other
countries preserve for Motorola certain exclusive rights for copyright computer programs, including the
exclusive right to copy or reproduce in any form the copyright computer program. Accordingly, any
copyright Motorola computer programs contained in the Motorola products described in this document
may not be copied or reproduced in any manner without the express written permission of Motorola.
Furthermore, the purchase of Motorola products shall not be deemed to grant either directly or by
implication, estoppel or otherwise, any license under the copyrights, patents or patent applications of
Motorola, except for the rights that arise by operation of law in the sale of a product.
Restrictions
The software described in this document is the property of Motorola. It is furnished under a license
agreement and may be used and/or disclosed only in accordance with the terms of the agreement.
Software and documentation are copyright materials. Making unauthorized copies is prohibited by
law. No part of the software or documentation may be reproduced, transmitted, transcribed, stored
in a retrieval system, or translated into any language or computer language, in any form or by any
means, without prior written permission of Motorola.
Accuracy
While reasonable efforts have been made to assure the accuracy of this document, Motorola
assumes no liability resulting from any inaccuracies or omissions in this document, or from the use
of the information obtained herein. Motorola reserves the right to make changes to any products
described herein to improve reliability, function, or design, and reserves the right to revise this
document and to make changes from time to time in content hereof with no obligation to notify any
person of revisions or changes. Motorola does not assume any liability arising out of the application
or use of any product or circuit described herein; neither does it convey license under its patent
rights of others.
Trademarks
and MOTOROLA are registered trademarks of Motorola Inc.

Intelligence Everywhere, M-Cell and Taskfinder are trademarks of Motorola Inc.
All other brands and corporate names are trademarks of their respective owners.
.
.
.
ii wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1
Contents
General information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Reporting safety issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Warnings and cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
General warnings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
General cautions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Devices sensitive to static . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Chapter 1
Congestion Relief Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Congestion Relief Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
Directed Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
Congestion relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
Congestion Handover Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
Enabling Directed Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Emergency and EGSM calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Microcellular purchasable option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
TCH flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Directed Retry and External Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
Congestion relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Congestion Relief – Standard Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
Congestion Relief – Type 2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–14
Associated Congestion Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16
Chapter 2
Microcellular Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Microcellular Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
Microcellular Handover Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Macro%Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Macro%Micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Micro%Micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Micro%Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
The Seven Motorola Microcellular Handover Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 2–4
Type 1 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
PBGT algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–6
Criteria 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–8
Criteria 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–10
Type 1 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–12
Type 2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–14
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 iii

Version 1 Rev 1
Type 3 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16

GSR5 Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16
Type 4 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–18
Type 5 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–20
Algorithm Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–20
Optimisation of type 5 handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–22
Type 6 Algorithm (Delay PBGT using Dynamic ho_margin) . . . . . . . . . . . . . . . . . . . . . . . 2–24
Description of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–24
Algorithm Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–24
Handover Scenario for Adjacent Channels (Both BCCH Carriers) . . . . . . . . . . . . . . . . . . 2–26
Type 7 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–28
Interference Avoidance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–32
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–32
Setting of Candidate List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–34
Micro – Micro Quality Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–36
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–36
Chapter 3
Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Multiband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
Power Based Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Handover to Inner Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Power Based Concentric Cells – HO to Inner Zone Power Level . . . . . . . . . . . . . . . . . . 3–6
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Handover to Inner Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Handover to Outer Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–8
Interference Based Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Power Budget Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12
Mobile Power Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12
Interference Based Algorithm – Handover to Inner Zone . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Direct Inner Zone Threshold and Neighbour Report Timer . . . . . . . . . . . . . . . . . . . . . . . . 3–16
Interference Based Algorithm – Handover to Outer Zone . . . . . . . . . . . . . . . . . . . . . . . . . 3–18
Power Control When Using Interference Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–20
Concentric Cells – Channel Allocation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
outer_zone usage_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
intra_cell_handover_allowed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
Emergency call pre–emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
Immediate Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
iv wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1
Chapter 4
Multiband Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Multiband Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
Multiband Inter–cell Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–2
Multiband Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
Enhanced SDCCH to TCH (preferred band) Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 4–8
Multiband Neighbour Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10
MSC Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
ALM for EGSM Carriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
EGSM Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
Database parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
Neighbour Re–ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
ALM for EGSM Carriers Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Coincident Multiband Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Feature objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Cell Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Configuring Coincident Multiband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Coincident Multiband External Neighbour Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Single BCCH for Dual Band Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
Feature Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
Feature Overview (Continued) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–28
Frequency Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Primary Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Secondary band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Dependancies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Modification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
inner_zone_alg <value>cell=<cell_desc> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Equipping DRI and RTF groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Outer zone usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Dual band Inner Zone use Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34
Propagation Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34
Power losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34
Dual Band Inner Zone Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–36
Dual Band Inner Zone Use Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–38
Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–38
BTS Power Control on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
BTS Power Control off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
MS Power Control on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
MS Power Control off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
Handovers to n/bours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 v

Version 1 Rev 1
Enabling the Dual Band Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42

Multiband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
Handover and Power Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–44
Power Budget Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Power Budget Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Handover Power Level Inner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Transmit Power Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Dependancies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
EGSM Layer Management Within a Dualband Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–48
Ping–Pong Handover Prevention Between Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–50
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–50
Causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–50
Controlling the Behaviour of Ping–Pongs Between Zones . . . . . . . . . . . . . . . . . . . . . . . . 4–52
Intelligent Multilayer Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–54
Description of the reasons to introduce this feature . . . . . . . . . . . . . . . . . . . . . . . . 4–54
Description of IMRM functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–56
Intelligent Multilayer Resource Management – PCPB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–58
Per Call Preferred Band (PCPB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–58
When PCPB is set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–58
IMRM – Forced Recalculation of PCPB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–60
General Call Handling for an IMRM Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–62
Building the Handover Candidate List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–62
Intelligent Multilayer Resource Management – 2G to 3G Handover . . . . . . . . . . . . . . . . 4–64
2G – 3G Handover Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–64
Interactions with SERVICE HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–64
Interactions with UMTS band preferred flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–64
IMRM – Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–66
IMRM – Database Parameters Continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–68
Chapter 5
Adaptive Multi–Rate and Half–Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Adaptive Multi–Rate and Half Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Half Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
Adaptive Multi–Rate (AMR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
AMR Full – Rate Channel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
Full Rate Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
AMR Half – Rate Channel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
Half Rate Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
Active Codec Set Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
AMR Half–Rate Further Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6
Enabling Half Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
RTF Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Channel Allocation for AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
vi wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1
Force Half–Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12

Reconfiguration of Existing Full–Rate Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Reservation of Half–Rate Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–14
AMR Full – Rate Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
AMR Half – Rate Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–18
Enabling/Disabling Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–20
AMR FR/HR Commands to Specify ACS and Associated Parameters . . . . . . . . . . . . . . 5–22
AMR FR/HR Commands to Specify ACS and Associated Parameters–Cont’d . . . . . . . 5–24
Downlink Adaptation Change Minimum Time Period . . . . . . . . . . . . . . . . . . . . . . . 5–26
MS Monitor Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
Downlink Adaptation MS Monitor Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
(AMR) Half Rate Handover and Power Control Parameters . . . . . . . . . . . . . . . . . . . . . . . 5–30
AMR or GSM Half–Rate Intracell Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–32
AMR or GSM Half Rate Intra–cell Handover Hop Count . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34
Chapter 6
Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Lab Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Lab Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
Creating CTP Traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–3
CTP Traces using MMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
Using TEMS Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–9
Using MDTT Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–10
Lab Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–11
Lab Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–12
Exercise 1 – Directed Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–13
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–13
Initial Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–13
Student Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–13
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–13
Further Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–14
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–14
Exercise 2 – Congestion Relief Type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–15
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–15
Student Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–15
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–16
Final Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–16
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 vii

Version 1 Rev 1
Exercise 3 – Congestion Relief Type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–17

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–17
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–18
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–19
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–19
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–20
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–21
Exercise 4 – PBGT Algorithm Type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–23
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–24
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–25
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–26
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–27
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
viii wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–29
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–29
Exercise 9 – PBGT Algorithm Type 6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–31
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–31
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–31
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–32
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–32
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–33
Exercise 11 – Adjacent Channel Interference Avoidance Test . . . . . . . . . . . . . . . . . . . . . 6–34
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–34
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–34
Exercise 12 – Micro – Micro Quality Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–35
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–35
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–35
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–36
Exercise 13 – Power Based Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–37
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–37
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–37
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–38
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 ix

Version 1 Rev 1
Exercise 14 – Interference Based Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–39

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–39
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–39
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–40
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–41
Exercise 15 – Multiband Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–42
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–42
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–42
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–43
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–44
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–45
Exercise 16 – Single BCCH (SBCCH) Multiband Handover . . . . . . . . . . . . . . . . . . . . . . . 6–46
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–46
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–47
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–48
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–48
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–49
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–50
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–50
x wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1
Exercise 17 – Intelligent Multilayer Resource Management . . . . . . . . . . . . . . . . . . . . . . . 6–51

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–51
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–52
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–52
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–53
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–53
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–54
Exercise 18 – Coincident Multiband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–55
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–55
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–55
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–56
Exercise 18 – GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–57
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–57
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–58
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–58
Glossary of technical terms and abbreviations . . . . . . . . . . . . . . . . . . . . . . G−1
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 xi

Version 1 Rev 1
xii wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1 General information
General information
Important notice
If this manual was obtained when attending a Motorola training course, it will not be
updated or amended by Motorola. It is intended for TRAINING PURPOSES ONLY. If it
was supplied under normal operational circumstances, to support a major software
release, then corrections will be supplied automatically by Motorola in the form of
General Manual Revisions (GMRs).
Purpose
Motorola cellular communications manuals are intended to instruct and assist personnel
in the operation, installation and maintenance of the Motorola cellular infrastructure
equipment and ancillary devices. It is recommended that all personnel engaged in such
activities be properly trained by Motorola.
WARNING Failure to comply with Motorola’s operation, installation and

maintenance instructions may, in exceptional circumstances,
lead to serious injury or death.
These manuals are not intended to replace the system and equipment training offered by
Motorola, although they can be used to supplement and enhance the knowledge gained
through such training.
ETSI standards
The standards in the table below able are protected by copyright and are the property of
the European Telecommunications Standards Institue (ETSI).
ETSI specification number

GSM 02.60 GSM 04.10 GSM 08.08
GSM 03.60 GSM 04.11 GSM 08.16
GSM 03.64 GSM 04.12 GSM 08.18
GSM 04.01 GSM 04.13 GSM 08.51
GSM 04.02 GSM 04.60 GSM 08.52
GSM 04.03 GSM 04.64 GSM 08.54
GSM 04.04 GSM 04.65 GSM 08.56
GSM 04.05 GSM 08.01 GSM 08.58
GSM 04.06 GSM 08.02 GSM 09.18
GSM 04.07 GSM 08.04 GSM 09.60
GSM 04.08 GSM 08.06
Figures from the above cited technical specifications standards are used, in this training
manual, with the permission of ETSI. Further use, modification, or redistribution is strictly
prohibited. ETSI standards are available from http://pda.etsi.org/pda/ and
http://etsi.org/eds/
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 1

General information Version 1 Rev 1
Data encryption
In order to avoid electronic eavesdropping, data passing between certain elements in the
GSM and GPRS network is encrypted. In order to comply with the export and import
requirements of particular countries, this encryption occurs at different levels as
individually standardised, or may not be present at all in some parts of the network in
which it is normally implemented. The manual set, of which this manual is a part, covers
encryption as if fully implemented. Because the rules differ in individual countries,
limitations on the encryption included in the particular software being delivered, are
covered in the Release Notes that accompany the individual software release.
Cross references
Throughout this manual, cross references are made to the chapter numbers and section
names. The section name cross references are printed bold in text.
This manual is divided into uniquely identified and numbered chapters that, in turn, are
divided into sections. Sections are not numbered, but are individually named at the top of
each page, and are listed in the table of contents.
Text conventions
The following conventions are used in the Motorola cellular infrastructure manuals to
represent keyboard input text, screen output text and special key sequences.
Input
Characters typed in at the keyboard are shown like this.
Output
Messages, prompts, file listings, directories, utilities, and
environmental variables that appear on the screen are shown like
this.
Special key sequences

Special key sequences are represented as follows:
CTRL–c Press the Control and c keys at the same time.

ALT–f Press the Alt and f keys at the same time.
| Press the pipe symbol key.
CR or RETURN Press the Return key.
2 wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1 Reporting safety issues
Reporting safety issues
Introduction
Whenever a safety issue arises, carry out the following procedure in all instances.
Ensure that all site personnel are familiar with this procedure.
Procedure
Whenever a safety issue arises:
1. Make the equipment concerned safe, for example by removing power.
2. Make no further attempt to adjust or rectify the equipment.
3. Report the problem directly to the Customer Network Resolution Centre, Swindon
+44 (0)1793 565444 or China +86 10 68437733 (telephone) and follow up with a
written report by fax, Swindon +44 (0)1793 430987 or China +86 10
68423633 (fax).
4. Collect evidence from the equipment under the guidance of the Customer Network
Resolution Centre.

Warnings and cautions Version 1 Rev 1
Warnings and cautions
Introduction
The following describes how warnings and cautions are used in this manual and in all
manuals of this Motorola manual set.
Warnings
Definition of Warning
A warning is used to alert the reader to possible hazards that could cause loss of life,
physical injury, or ill health. This includes hazards introduced during maintenance, for
example, the use of adhesives and solvents, as well as those inherent in the equipment.
Example and format

WARNING Do not look directly into fibre optic cables or data in/out
connectors. Laser radiation can come from either the data in/out
connectors or unterminated fibre optic cables connected to data
in/out connectors.
Failure to comply with warnings

Observe all warnings during all phases of operation, installation and maintenance of the
equipment described in the Motorola manuals. Failure to comply with these warnings,
or with specific warnings elsewhere in the Motorola manuals, or on the equipment
itself, violates safety standards of design, manufacture and intended use of the
equipment. Motorola assumes no liability for the customer’s failure to comply
with these requirements.
Cautions
Definition of Caution
A caution means that there is a possibility of damage to systems, software or individual
items of equipment within a system. However, this presents no danger to personnel.
Example and format

CAUTION Do not use test equipment that is beyond its due calibration date;
arrange for calibration to be carried out.

Version 1 Rev 1 General warnings
General warnings
Introduction
Observe the following specific warnings during all phases of operation, installation and
maintenance of the equipment described in the Motorola manuals:
S Potentially hazardous voltage
S Electric shock
S RF radiation
S Laser radiation
S Heavy equipment
S Parts substitution
S Battery supplies
S Lithium batteries
Failure to comply with these warnings, or with specific warnings elsewhere in the
Motorola manuals, violates safety standards of design, manufacture and intended use of
the equipment. Motorola assumes no liability for the customer’s failure to comply with
these requirements.
Warning labels
Warnings particularly applicable to the equipment are positioned on the equipment.
Personnel working with or operating Motorola equipment must comply with any warning
labels fitted to the equipment. Warning labels must not be removed, painted over or
obscured in any way.

General warnings Version 1 Rev 1
Specific warnings
Specific warnings used throughout the GSM manual set are shown below, and will be
incorporated into procedures as applicable.
These must be observed by all personnel at all times when working with the equipment,
as must any other warnings given in text, in the illustrations and on the equipment.
Potentially hazardous voltage

WARNING This equipment operates from a hazardous voltage of 230 V
ac single phase or 415 V ac three phase supply. To achieve
isolation of the equipment from the ac supply, the ac input
isolator must be set to off and locked.
When working with electrical equipment, reference must be made to the Electricity at
Work Regulations 1989 (UK), or to the relevant electricity at work legislation for the
country in which the equipment is used.
NOTE Motorola GSM equipment does not utilise high voltages.
Electric shock
WARNING Do not touch the victim with your bare hands until the
electric circuit is broken.
Switch off. If this is not possible, protect yourself with dry
insulating material and pull or push the victim clear of the
conductor.
ALWAYS send for trained first aid or medical assistance
IMMEDIATELY.
In cases of low voltage electric shock (including public supply voltages), serious injuries
and even death, may result. Direct electrical contact can stun a casualty causing
breathing, and even the heart, to stop. It can also cause skin burns at the points of entry
and exit of the current.
In the event of an electric shock it may be necessary to carry out artificial respiration.
ALWAYS send for trained first aid or medical assistance IMMEDIATELY.
If the casualty is also suffering from burns, flood the affected area with cold water to cool,
until trained first aid or medical assistance arrives.
RF radiation
WARNING High RF potentials and electromagnetic fields are present in
this equipment when in operation. Ensure that all
transmitters are switched off when any antenna connections
have to be changed. Do not key transmitters connected to
unterminated cavities or feeders.
Relevant standards (USA and EC), to which regard should be paid when working with RF
equipment are:
S ANSI IEEE C95.1-1991, IEEE Standard for Safety Levels with Respect to Human
Exposure to Radio Frequency Electromagnetic Fields, 3 kHz to 300 GHz.
S CENELEC 95 ENV 50166-2, Human Exposure to Electromagnetic Fields High
Frequency (10 kHz to 300 GHz).

Version 1 Rev 1 General warnings
Laser radiation
WARNING Do not look directly into fibre optic cables or optical data
in/out connectors. Laser radiation can come from either the
data in/out connectors or unterminated fibre optic cables
connected to data in/out connectors.
Lifting equipment
WARNING When dismantling heavy assemblies, or removing or
replacing equipment, a competent responsible person must
ensure that adequate lifting facilities are available. Where
provided, lifting frames must be used for these operations.
When dismantling heavy assemblies, or removing or replacing equipment, the competent

responsible person must ensure that adequate lifting facilities are available. Where
provided, lifting frames must be used for these operations. When equipments have to be
manhandled, reference must be made to the Manual Handling of Loads Regulations
1992 (UK) or to the relevant manual handling of loads legislation for the country in which
the equipment is used.
Parts substitution
WARNING Do not install substitute parts or perform any unauthorized
modification of equipment, because of the danger of
introducing additional hazards. Contact Motorola if in doubt
to ensure that safety features are maintained.
Battery supplies
WARNING Do not wear earth straps when working with standby battery
supplies.
Lithium batteries
WARNING Lithium batteries, if subjected to mistreatment, may burst
and ignite. Defective lithium batteries must not be removed
or replaced. Any boards containing defective lithium
batteries must be returned to Motorola for repair.
Contact your local Motorola office for how to return defective lithium batteries.

General cautions Version 1 Rev 1
General cautions
Introduction
Observe the following cautions during operation, installation and maintenance of the
equipment described in the Motorola manuals. Failure to comply with these cautions or
with specific cautions elsewhere in the Motorola manuals may result in damage to the
equipment. Motorola assumes no liability for the customer’s failure to comply with these
requirements.
Caution labels
Personnel working with or operating Motorola equipment must comply with any caution
labels fitted to the equipment. Caution labels must not be removed, painted over or
obscured in any way.
Specific cautions
Cautions particularly applicable to the equipment are positioned within the text of this
manual. These must be observed by all personnel at all times when working with the
equipment, as must any other cautions given in text, on the illustrations and on the
equipment.
Fibre optics
CAUTION Fibre optic cables must not be bent in a radius of less than
30 mm.
Static discharge
CAUTION Motorola equipment contains CMOS devices. These metal
oxide semiconductor (MOS) devices are susceptible to
damage from electrostatic charge. See the section Devices
sensitive to static in the preface of this manual for further
information.

Version 1 Rev 1 Devices sensitive to static
Devices sensitive to static
Introduction
Certain metal oxide semiconductor (MOS) devices embody in their design a thin layer of
insulation that is susceptible to damage from electrostatic charge. Such a charge applied
to the leads of the device could cause irreparable damage.
These charges can be built up on nylon overalls, by friction, by pushing the hands into
high insulation packing material or by use of unearthed soldering irons.
MOS devices are normally despatched from the manufacturers with the leads shorted
together, for example, by metal foil eyelets, wire strapping, or by inserting the leads into
conductive plastic foam. Provided the leads are shorted it is safe to handle the device.
Special handling techniques

In the event of one of these devices having to be replaced, observe the following
precautions when handling the replacement:
S Always wear an earth strap which must be connected to the electrostatic point
(ESP) on the equipment.
S Leave the short circuit on the leads until the last moment. It may be necessary to
replace the conductive foam by a piece of wire to enable the device to be fitted.
S Do not wear outer clothing made of nylon or similar man made material. A cotton
overall is preferable.
S If possible work on an earthed metal surface or anti-static mat. Wipe insulated
plastic work surfaces with an anti-static cloth before starting the operation.
S All metal tools should be used and when not in use they should be placed on an
earthed surface.
S Take care when removing components connected to electrostatic sensitive
devices. These components may be providing protection to the device.
When mounted onto printed circuit boards (PCBs), MOS devices are normally less
susceptible to electrostatic damage. However PCBs should be handled with care,
preferably by their edges and not by their tracks and pins, they should be transferred
directly from their packing to the equipment (or the other way around) and never left
exposed on the workbench.

Chapter 1
Congestion Relief Mechanisms

Version 1 Rev 1

Version 1 Rev 1
Chapter 1
Congestion Relief Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Congestion Relief Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–1
Directed Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
Congestion relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–2
Congestion Handover Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–4
Enabling Directed Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Emergency and EGSM calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Microcellular purchasable option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
TCH flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–6
Directed Retry and External Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–8
Congestion relief . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–10
Congestion Relief – Standard Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–12
Congestion Relief – Type 2 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–14
Associated Congestion Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1–16

Version 1 Rev 1

Version 1 Rev 1 Congestion Relief Mechanisms
Congestion Relief Mechanisms
Objectives
On completion of this chapter the student will be able to:
S Discuss the use and implementation of directed retry
S Discuss the use and implementation of congestion relief type 1
S Discuss the use and implementation of congestion relief type 2
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 1–1

Directed Retry Version 1 Rev 1
Directed Retry
The GSM implementation of standard directed retry allows the simultaneous handling of
call setup assignment and handover procedures, by allowing a handover from an SDCCH
to a TFC. Essentially this feature allows a MS to be handed from an SDCCH in one cell
that has no TFC channel capacity available at call setup (for that MS) to a TFC channel
in another cell. This feature will not be activated unless the Assignment Request (for that
MS) is queued awaiting resource (i.e. All TFC resources in the cell are utilized).
It is possible to enable this feature such that it will only allow movement of an MS to cells
internal to the BSS. This implementation has no impact on the A–interface signalling and
for this reason can be used with an existing MSC configuration. If this feature is
implemented to allow the MS to be handed to an external cell, then it requires the
Handover Required message to carry a cause of directed retry.
To instruct the mobile to move the Handover Command carrying the channel mode
element is sent to the mobile. The channel mode element indicates to the mobile that
the target channel supports, either speech, signalling or data. Of course a directed retry
handover will not be initiated unless the MS has reported a strong enough neighbour that
meets a congestion relief criteria.
If directed retry is enabled and the BSS receives an Assignment Request and no TFC
channels are available then the Assignment Request is queued regardless of queuing
being enabled in add_cell. If a TFC becomes available whilst the neighbours are being
processed then the queuing procedure is followed and the directed retry procedure is
aborted.
If queuing is disabled in the BSS, the BSS will perform an internal queuing procedure, to
a maximum of 25 calls. If queuing is enabled normal queuing shall be performed. If the
BSS is using internal queuing, it will not send a Queuing Indication message. If all
attempts at directed retry fail or no valid neighbours are reported then the TFC request
will remain queued for the remainder of the relevant queuing timer.
Congestion relief
This feature consists of two congestion relief procedures (they are mutually exclusive)
that can be enabled independently or in conjunction with Directed Retry. If the MS
requiring a TFC channel has not had the opportunity to report a neighbour that is good
enough to hand to, then the BSS may force another MS to handover from the congested
cell to free up a TFC channel. Of course this MS that is in an established call is only
forced to handover if it has a neighbour that meets the congestion handover criteria. If
no calls meet the congestion handover criteria, no handovers shall be initiated. The
following options are available:
1. The maximum number of handovers initiated by this method is the number of
queued requests in the congested cell.
2. The maximum number of handovers initiated by this method is the number of calls
meeting the congestion handover criteria in the congested cell.
1–2 wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1 Directed Retry
Directed Retry
Serving Cell Neighbour Cell
MS is on SDCCH, but wants TCH – non available

MS queued regardless of whether queuing enabled or not
If there is a qualified neighbour, MS hands over
SYS12_Ch05_01

Congestion Handover Criteria Version 1 Rev 1
Congestion Handover Criteria

The handover criteria is specified on a per cell basis. A handover margin is prompted in
add_neigbor, this is called the congest_ho_margin. If the latest rxlev_dl average of
any of the neighbour’s (for any MSs established in a call on the congested cell) meet
criteria 1 then they are further processed through a modified criteria 2:
pbgt– congest_ho_margin > 0
If any neighbours qualify using directed retry they can be used to handover the call to the
best neighbour.
To make it easier to handover to this neighbour in the case of congestion, this parameter
value should be less that the value of the handover margin(s) for handovers for radio
reasons.
To disable congestion handovers to this neighbour, set the congestion handover margin
to the maximum value +63.
In addition as the congest_ho_margin is usually set to negative values or 0 to facilitate
DR handovers to neighbours with free resources. A positive congest_ho_margin would
mean that the chances of finding a suitable neighbour would be minimal and the
congestion situation on the serving cell couldn’t be resolved effectively.
congest_ho_margin is a per neighbour parameter.
Valid Range: –63dB to 63dB
Default Value: None

Version 1 Rev 1 Congestion Handover Criteria
Congestion Handover Criteria
N1
N2 N6
Server
N3 N5
N4
S All neighbours assessed to see if they meet criteria 1
S Then ordered by pbgt – congest_ho_margin > 0
S congest_ho_margin – 63 to +63 Default None

SYS12_Ch05_03

Enabling Directed Retry Version 1 Rev 1
Enabling Directed Retry

dr_preference
This is a chg_element command and is entered at the BSC, it is used to enable the
feature and to determine if the MSC is to be involved in the procedure as necessary. By
entering this command it determines if handovers can be forced to either internal
neighbours or internal and external neighbours.
dr_standard_congest
This is a chg_element command that can only be entered on a per cell basis if the
dr_preference is enabled at the BSC. This element enables or disables the standard
directed retry feature on a per cell basis. If this is command is enabled within the BSS
then the timer that that awaits an Assignment Complete message may require
modification (i.e. increasing) in the MSC
dr_ho_during_assign
The BSS has the ability to enable and disable handovers triggered during an assignment
procedure. These handovers would be from SDCCH to TFC in target cell. This feature
does not effect the existing SDCCH to SDCCH handovers enabled in add_cell. If an
intra–cell handover is needed during an assignment procedure and the assignment
request is queued, the BSS will perform the intra–cell handover. If an inter–cell handover
is needed during the assignment procedure and the Assignment Command has not been
sent to the MS, an inter–cell handover is initiated. No Handover Performed message
shall be sent to the MSC as the Assignment Complete from the new cell contains all the
necessary information. If the Assignment Command has been sent to the MS, the BSS
shall wait for either the Assignment Complete or Failure message from the MS before
initiating the handover.
Emergency and EGSM calls

If the emergency call pre–emption feature is enabled, emergency calls will not be handed
over for congestion reasons unless all the calls in the cell are emergency calls. In the
case of all emergency calls in a cell, pre–emption cannot occur so a handover shall be
attempted to service the incoming emergency call.
An MS on an EGSM channel shall not be handover from an EGSM frequency due to
congestion unless an EGSM capable MS is queued.
Microcellular purchasable option

When directed retry and or congestion relief are allowed, if a neighbour qualifies for a
congestion handover prior to satisfying the microcellular algorithm selected for that cell, a
handover will be attempted (cause directed retry). A way of avoiding this would be to
give the microcell neighbours a high congest_ho_margin.
TCH flow control

It is advisable, if the maximum benefit of directed retry or congestion relief is to be had
the tch_flow_control should be disabled.

Version 1 Rev 1 Enabling Directed Retry
Enabling Directed Retry
chg_element dr_preference <*> <bsc or 0> 0 = DR Disabled (def)
1 = DR Enabled
Entered at BSC
BSC
Chg_element dr_standard_congest <*><site id><cell id>

0 = Disabled
1 = DR enable
BTS BTS BTS Entered per Cell
Handover during assignment for radio reasons
chg_element dr_ho_during_assign <*><site id> cell_number = <cell id> 0 = Ignore the need for handover
1 = Handover on queue
SYS12_Ch05_04

Directed Retry and External Handovers Version 1 Rev 1
Directed Retry and External Handovers

msc_preference (Default 0)
This element is used to set the message flow sequence used on the A–interface for
external handovers during the assignment procedure. This element must align with the
MSC expectations. The MSC implementation may depend on whether queuing is
enabled in the cell. The cause value sent to the MSC can be set according to whether
directed retry is supported by the MSC. This parameter requires the directed retry or
multiband operation to be enabled.
chg_element dr_chan_mode_modify <value> 0 or bsc (Default 0)

This element is entered at the BSC and determines the need for a channel mode modify
procedure after a successful handover in which the channel mode changed ( GSM 04:08
sect 7.3.7 ). The BSS shall read this database parameter only in the case of a
successful handover in which the channel mode changed, the MS is phase 1, and the
new channel mode is full rate speech. Typically changing the channel mode during a
handover occurs only during a directed retry handover that has successfully completed to
this BSS during directed retry procedure. This is required as some MSs cannot interpret
the channel_mode element of the handover_command.
Valid Range 0 = disabled, 1 = Enabled
chg_element handover_required_curr_ch <value> 0 or bsc(Default 0)

This parameter must align with the settings of the MSC regarding the contents of the
Handover Required message from the BSS. This parameter is set on a per BSS basis, it
determines if the current channel information element is included in the Handover
Required message.
This element is found in GSM08:08.
The target BSS on receipt of a Handover Required message composes the requested
channel type with the current_channel_element and if they are different it will include
the channel_mode_element in the handover_command. This is done so that the MSs
can determine whether that are moving to a speech, data or signalling channel.
Valid Range 0 = Not included, 1 = Included
modify_neighbor <source cell><neighbor cell> dr_allowed 1
Allows a directed retry to an external neighbour during the assignment procedure. An
external handover may only be initiated if either the dr_standard_congest or
dr_ho_during_assign parameter is enabled. This attribute is only valid for SACCH
neighbours.

Version 1 Rev 1 Directed Retry and External Handovers
Directed Retry and External Handovers
chg_element msc_preference <*> <site id> cell_number = <cell id>

MSC 0 = Directed Retry is supported in the BSS but not across the
A–Interface
1 = Directed Retry is supported within the BSS. The only A–
interface impact is the Assignment Complete message,
which contains the optional Cell ID if the Cell ID changes
during the assignment.
Assignment 2 = The BSS sends the Handover Required message with
Complete the cause ”directed retry” to the MSC.
3 = The BSS sends the Handover Required message with
the cause of the handover to the MSC (for example,
BetterCell).
4 = The BSS sends an Assignment Failure message with
the cause ”directed retry” and then sends a Handover
BSS BSS Required message with cause ”directed retry” to the
MSC.
5 = The BSS sends an Assignment Failure message with the
cause ”directed retry” and then sends a Handover Required
message with the cause of the handover to theMSC (for
example, Better Cell).
6 = The BSS sends a Handover Required message with cause
”directed retry” and then sends an Assignment Failure
message with cause ”directed retry” to the MSC.
7 = The BSS sends a Handover Required message with the
cause of the handover (for example, Better Cell) and then
sends an Assignment Failure message with cause ”directed
retry” to the MSC.
SYS12_Ch05_05

Congestion relief Version 1 Rev 1
Congestion relief
Congestion relief is an optional feature which is available as an alternative to Directed
retry for the case of a congested cell. This feature differs in that it chooses the best
candidate from all existing calls in the cell to be moved to the alternate cell thus freeing
TCH’s in the congested cell. This can result in better overall system quality compared to
Directed Retry because the best handover candidate is chosen instead of the candidate
requesting a TCH.
It consists of two congestion relief procedures (they are mutually exclusive) that can be
enabled independently or in conjunction with Directed Retry. If the MS requiring a TFC
channel has not had the opportunity to report a neighbour that is good enough to hand to,
then the BSS may force another MS to handover from the congested cell to free up a
TFC channel. Of course this MS that is in an established call is only forced to handover
if it has a neighbour that meets the congestion handover criteria. If no calls meet the
congestion handover criteria, no handovers shall be initiated. The following options are
available:
1. The maximum number of handovers initiated by this method is the number of
queued requests in the congested cell.
2. The maximum number of handovers initiated by this method is the number of calls
meeting the congestion handover criteria in the congested cell.

Version 1 Rev 1 Congestion relief
Congestion Relief
Type 1

Another MS that is best qualified, hands over
chg_element ho_exist_congest 1 <site> cell_number = <cell id>
Type 2

All the MSs that qualify, handover
chg_element ho_exist_congest 2 <site> cell_number = <cell id>
SYS12_Ch05_06

Congestion Relief – Standard Parameters Version 1 Rev 1
Congestion Relief – Standard Parameters

The main O&M impacts of this feature are to the BSS database with several BSS, Cell
and Neighbour parameters, some of which are shared with the Directed Retry feature.
Database Parameters
ho_exist_congest
This parameter determines if attempts to handover existing calls on a TCH will be
initiated in the case of an MS needing a TCH when there are none available in that cell.
This parameter indicates either to attempt to handover as many calls as the number of
queued assignment requests (if set to 1) or attempt to handover as many calls as meet
the congestion handover criteria (if set to 2). It concerns a cell.
Valid Range: 0,1 or 2
Default Value: 0
If set to 0, the functionality is disabled.
congest_ho_margin
This parameter is used in the case of a congestion handover. To make it easier to
handover to this neighbour in the case of congestion in the current cell, this parameter
value should be less that the value of the handover margin(s).
To disable congestion handovers to this neighbour, set the congestion handover margin
to the maximum value.
Valid Range: –63dB to 63dB
Default Value: None
tch_congest_prevent_thres
This per cell parameter specifies the level of overall TCH utilisation by any MS in a given
Cell, at which the Congestion Relief procedure is initiated. The parameter is expressed
as a percentage.
Valid Range: 1 to 101
Default Value: 100
If set to 100 it means congestion relief will be triggered when attempting to use the last
resource. If set to 101 it means congestion relief can only will be triggered when there is
no resources left.
mb_tch_congest_thres
Used to control the percentage point at which Multiband Mobile Stations will start to be
redirected to the preferred band. The BSS does not allow an incoming band preference
handover should the servicing of that handover cause this percentage to be exceeded.
Default Value: 100
Timers
valid_candidate_ period
The BTS (RRSM) timer valid_candidate_period specifies the duration for which
candidate channels for handover due to congestion are kept, before querying again for
new ones.
Default Value: 4000 milliseconds

Version 1 Rev 1 Congestion Relief – Standard Parameters
Congestion Relief – Standard Parameters
Mobile
attempts to
set up call
in cell

congest_ho_margin = –5 Pbgt(n) = –2
ho_exist_congest = 1
tch_congest_prevent_thres = 90
Neighbour cell must pass criteria 1 to be used as target
pbgt(n) – congest_ho_margin > 0
valid_candidate_period = 4000
SYS12_Ch05_07

Congestion Relief – Additional type 1 & 2 Parameters Version 1 Rev 1
Congestion Relief – Additional type 1 & 2 Parameters

Advanced Congestion Relief defines new handover procedures to select active calls to
be handed over to relieve congestion in the cell.
These new procedures take the form of expanding the decision process for handover to
include the state of congestion at the target cell and incorporate the added dimension of
time over which the decision is to be implemented. For example, target cells will not
accept a congestion relief handover that puts itself into a congested state, resulting in
further congestion procedures being invoked. Excessive handovers are therefore
eliminated.
congest_at_source
Used to control how a given cell behaves should it be unable to force a given imperative
handover
Valid Range: 0,1 Default Value: 1
If set to 0: The system takes no actions if a given candidate rejects a handover.
If set to 1: if an imperative handover is needed, the source Cell retries candidates which
were previously unable to serve the handover request.
congest_at_target
Used to control how a given cell behaves should it reject a handover request (either an
imperative or congestion relief attempt).
Valid Range: 0,1 Default Value: 1
If set to 0: The system will take no action if the Cell reject a congestion handover
request.
If set to 1: The system will invoke Congestion Relief procedures if this cell rejects a
congestion handover request.
enhanced_relief
This database parameter was introduced at GSR5 and when enabled removes rejection
of non–imperative handovers when congest_at_target is set to 1.
Valid Range: 0,1 Default: 0
If set to 0: The two parameters congest_at_target and congest_at_source have no
meaning if enhanced relief is set to 0. Also the target cell will accept incoming congestion
handovers even if they trigger congestion relief in that cell.
If set to 1: The target cell will not accept incoming congestion handovers and will also
behave in the way chosen by congest_at_target and congest_at_source.
ext_rtry_cand_prd timer
Used to control the time between successive attempts to handover to a particular
inter–BSS target cell which had previously rejected a handover attempt (either an
Valid Range: 0 to 1000000 Default Value: 4000 milliseconds
rtry_cand_prd timer
Used to control the time between successive attempts to handover to a particular
intra–BSS target cell which had previously rejected a handover attempt (either an
Valid Range: 0 to 1000000 Default Value: 4000 milliseconds

Version 1 Rev 1 Congestion Relief – Additional type 1 & 2 Parameters
Congestion Relief – Type 2 Parameters
BSC BSC
Neighbour Cell
Serving Cell
Neighbour Cell Neighbour Cell
chg_element ho_exist_congest 1 or 2
If enhanced_relief = 1, the target cell will not accept incoming congestion
handovers and enables congest_at_target, congest_at_source parameters
If congest_at_target =1, then initiate congestion relief procedures in
that cell, when it rejects a congestion handover attempt
congest_at_source = 1....Retries for imperative handover attempts after
rtry_cand_period (4000 def)
For external neighbours ext_rtry_cand_period (4000 def)
SYS12_Ch05_08

Associated Congestion Parameters Version 1 Rev 1
Associated Congestion Parameters

When performing a handover to a new cell, due to congestion problems in the serving
cell, it is possible that the serving cells rxlev could be much better than the target cells
rxlev. Thus, after arriving in the target cell, the mobile could immediately hand over back
to the original server due to PBGT or rxlev, followed very quickly by another congestion
handover and so on. This condition is known as ping–pong or bouncing.
To cure this problem, an extra handover margin bounce_protect_margin can be added
to the ho_margin(n) for a defined period of time bounce_protect_cong_tmr in the
target cell after a channel is activated in that cell. This makes it more difficult for the
mobile to hand over back to the original cell after a congestion handover.
The functionality of the bounce_protect_margin is shared with bounce protect margins
applied for rxqual reasons (covered in SYS03).
chg_element bounce_protect_margin <*><cell_desc>

<*> = 0 to 127 dB (default = 0)
chg_element bounce_protect_cong_tmr <*><cell_desc>

<*> = 0 to 255 (default = 0)

Version 1 Rev 1 Associated Congestion Parameters
Associated Congestion Parameters
10dB added to ho_margin(n)

for 20 SACCH
chg_element bounce_protect_margin 10 <cell_desc>
sys12_ch6_08a
chg_element bounce_protect_cong_tmr 20 <cell_desc>

Associated Congestion Parameters Version 1 Rev 1

Chapter 2
Microcellular Database

Version 1 Rev 1

Version 1 Rev 1
Chapter 2
Microcellular Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Microcellular Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–1
Microcellular Handover Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Macro%Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Macro%Micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Micro%Micro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Micro%Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–2
Current Motorola Handover Decision Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–4
The Seven Motorola Microcellular Handover Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 2–5
Type 1 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–7
PBGT algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–7
Criteria 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–9
Criteria 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–11
Type 1 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–13
Uses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–13
Type 2 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–15
Type 3 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–17
GSR5 Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–17
Type 4 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–19
Type 5 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–21
Algorithm Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–21
Optimisation of type 5 handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–23
Type 6 Algorithm (Delay PBGT using Dynamic ho_margin) . . . . . . . . . . . . . . . . . . . . . . . 2–25
Description of variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–25
Handover Scenario for Adjacent Channels (Both BCCH Carriers) . . . . . . . . . . . . . . . . . . 2–27
Type 7 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–29
Interference Avoidance Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–33
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–33
Setting of Candidate List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–35
Micro – Micro Quality Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–37
Ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–37

Version 1 Rev 1

Version 1 Rev 1 Microcellular Database
Microcellular Database
Objectives
On completion of this chapter the student will have:
S Reviewed the principles of handovers in multilayer systems
S Discussed the seven Motorola microcellular handover algorithms
S Discussed the use of micro to micro rxqual handovers

Microcellular Handover Criteria Version 1 Rev 1
Microcellular Handover Criteria

When planning a microcellular handover strategy, there are some basic criteria that
should be employed. These criteria detail a strategy for handovers between:
Macro⇒Macro
This is the standard power budget or imperative type of handover.
Macro⇒Micro
When the environmental conditions are well known, to ensure that the micro cell is going
to provide a good service to a particular mobile, its level will be measured and when it
exceeds a certain value (rxlev_min) for a given period (delay time), and power budget
conditions are met, this mobile will be allowed to be passed between the macro and the
micro.
This period must be long enough to ensure that this mobile is not a fast mobile.
Micro⇒Micro
Line of sight – Algorithm incorporates a delay timer to limit the handover rate
(ping–pong handovers) and to force fast moving mobiles to hand up to the macro layer
before quality of service is degraded. This is because microcells have a small radius and
as the mobile travels towards the edge of the cell it will suffer interference, also the
number of handovers generated would cause and unacceptable loading on the system
processors.
Around the corner – In this configuration, the signal level is monitored and handovers
will be prevented to the neighbour microcell unless the server level goes below a
threshold. This is extremely useful when the topology of the streets can create problems
such as rapid drop in signal level when turning a corner.
Micro⇒Macro
It is necessary to keep the call as long as possible in the micro layer, this effectively
disables the use of power budget considerations to trigger the handover to the macro
layers. However power budget is still calculated for candidate ordering purposes for
imperative handovers such as Rxqual and Rxlev.
System behaviour is dependant on mobile speed. If the speed is low enough the
microcellular system will take the call, but if the speed increases the call will be handed
up to the macrocellular layer. For example a car may stop at traffic lights and be located
in a micro. When the vehicle starts to move faster, the timer of the serving micro cell will
prevent handover to further micro and this mobile will be forced to hand up to a macro.
Another reason to hand calls up to the macrocell is when the microcell capacity is
exceeded and directed retry or congestion relief is being used. The macrocell cell could
then be used to take the congested calls.
The main design target can thus be stated as:

“Keep the mobiles on the microcells except when their speed is high enough to
degrade their service quality, in which case they are to be served by the
macrocells. If their speed reduces such that they can be adequately served by the
microcells, then hand them back to the microcells”.
Motorola defines a number of handover procedures each tailored to a particular scenario,
these procedures can be selected on a per–neighbour basis.

Version 1 Rev 1 Microcellular Handover Criteria
Microcellular Handover Criteria
Pbgt or Imperative
handovers
Macro Macro
Fast moving MS
Micro Micro
Acceptable rxlev
Delay time
Slow moving MS Pbgt
Imperative handovers
MS speed
Combat adj chan int Line of sight (micro or
Congestion Relief macro)
Round the corner
sys12_ch05_01

The Seven Motorola Microcellular Handover Procedures Version 1 Rev 1
The Seven Motorola Microcellular Handover Procedures

When the microcellular feature is enabled and the need for a power budget handover is
detected, the handover process checks the CM database to see if there are any further
power budget restrictions, these are set in the neighbour cells description
(pbgt_alg_type) and have a valid range from 1 to 7. These algorithms are described
briefly on this page, but in greater detail later. Another important point is candidate
ordering which is a key component of the algorithms used. Once again these are
described later.
Algorithm Title pbgt_alg_type
Conventional GSM PBGT 1
Restricted PBGT for macro 2

cells
PBGT with RXLEV as qualifier 3
PBGT with time in cell as 4

qualifier
PBGT with delay since 5

neighbour level exceeds
threshold as qualifier
Delayed power budget using 6

dynamic handover margin
PBGT algorithm to avoid 7

adjacent channel interference

Version 1 Rev 1 The Seven Motorola Microcellular Handover Procedures
The Seven Motorola Microcellular Handover Procedures
S Specified on a per neighbour basis by pbgt_alg_type

S Each neighbour cell is classified by an algorithm
ranging from 1 to 7

Type 1 Algorithm Version 1 Rev 1
Type 1 Algorithm
PBGT algorithm
Algorithm 1 is simply the standard GSM power budget algorithm. The difference from the previous
implementation is that the averaging period (hreqave) can be set on a per–neighbour basis,
The power budget formula can be considered in two parts, the left handside the serving cell and the
right handside the neighbour cell. The power budget calculation is carried out every 480ms (SACCH
multiframe). For each reported neighbour of all mobiles engaged in traffic the aim of the formula is to
afford the mobile the lowest uplink pathloss (not subject to N & P voting).
PBGT(n)= (min(ms_txpwr_max,P) – rxlev_dl – PWR_C_D)

SERVER
– (min(ms_txpwr_max,P) – rxlev_dl)
NEIGHBOUR
For handover to take place it is usual for:

PBGT(n)>ho_margin
SYS12_Ch4_08

Version 1 Rev 1 Type 1 Algorithm
Type 1 – Power Budget Assessment
All values in dBm
Serving neighbour
Min(ms_txpwr_max,P) – rxlev_dl – PWR_C_D Min(ms_txpwr_max,P) – rxlev_dl
PBGT(n) = [Min(ms_txpwr_max,P) – rxlev_dl – PWR_C_D] – [Min(ms_txpwr_max,P) – rxlev_dl]
PBGT(n) > ho_margin

SYS12_Ch4_09

Criteria 1 Version 1 Rev 1
Criteria 1
Criteria 1 ensures that the mobile is perceiving each neighbours Rxlev at a power level
good enough for the downlink path to support a ‘good call’, criteria 1 is as follows:
rxlev_ncell > rxlev_min(n) + Max (0, Pa)

rxlev_ncell is the latest averaged average processed for that neighbour. rxlev_min (n)
is the database parameter set in the add_neighbor command. For internal cells
rxlev_min_cell is optional and if not specified then rxlev_min_def in the add_cell
command of the server is used.
The last part of this calculation tempers the perceived downlink rxlev average with the
potential uplink path.
Max (0, Pa) where

Pa = ms_txpwr_max(n) – P
P = max power of ms
If the MS is suited for the PLMN in question Pa will always equal either zero or a
negative value and will therefore not be considered.
The value of ms_txpwr_max (n), can be set by ms_txpwr_max_def in add_cell for
undefined adjacent cells and ms_txpwr_max_cell in add_neighbor.
If the MS is not suited to that neighbour, ie its maximum power can not support that
required by that cell then the averaged rxlev_ncell would have to become a greater
value to overcome this handicap. Criteria 1 would therefore prevent such a handover
until the MS was deeper into that neighbour.
Any neighbour failing Criteria 1 is not further considered in any handover decision
process.
The software bin and hence averages used for criteria 1 are created in the averaging
mechanism “chg_cell_element surround cell” for per cell averaging or from
add_neighbor per neighbour surround_cell hreqave which in both cases is pointed to
by “decision_1_ncell_av_h_calc” in “add_cell”.
In the example shown opposite the neighbour receive level minimum has been set to
–80dBm and the actual receive level is –70dBm. Even after the mobile power has been
taken into consideration criteria 1 allows the neighbour to be taken into consideration for
further processing by criteria 2.

Version 1 Rev 1 Criteria 1
First Criteria
– 80dBm
–70dBm
Serving
Neighbour
rxlev_min_cell = 30
ms_txpwr_max = 39
MS Power
Class 4 (P)
rxlev_ncell > rxlev_min(n) + max (0,Pa) Pa = ms_txpwr_max – P
– 70 > – 80 + 6 6 = 39 – 33
– 70 > – 74
sys12_ch05_17

Criteria 2 Version 1 Rev 1
Criteria 2
Each neighbour, for that mobile, that satisfies criteria 1 is then subjected to criteria 2.
criteria 2 specifies that:
PBGT(n) – ho_margin
ho_margin for both external and internal cells can be specified in the add_neighbor
command. For internal cells this parameter is optional and if not specified then the
ho_margin_def in the add_cell of the neighbour is used.
Criteria 2 will produce a result for each neighbour, which has got to be greater than zero
for consideration by the specific handover procedure to follow.
For microcellular the neighbours are then ranked by algorithm type.
The neighbour software bin and hence the averages used in criteria 2 are set in
chg_cell_element surround_cell which is pointed to by
decision_1_ncell_rxlev_av_h_calc in add_cell.
The server averages used in criteria 2 are again set in chg_cell_element rxlev_dl_ho
which in this case is pointed to by decision_1_p_bgt_rxlev_av_h in add_cell.
In the example shown the power budget calculates to 2dB. The ho_margin is set to 6dB,
once criteria 2 is applied, it gives a value of – 4dB.

Version 1 Rev 1 Criteria 2
Second Criteria
– 80dBm
– 70dBm
Serving
35dBm Neighbour
rxlev_min_cell = 30 43dBm
ms_txpwr_max = 33 ms_txpwr_max = 33
max_tx_bts = 0 ho_margin = 6
max_tx_ms = 33
MS Power
Class 4 (P)
<server> <neighbour>
PBGT(n) = [Min(ms_txpwr_max,P) –rxlev_dl – PWR_C_D] – [Min(ms_txpwr_max,P) – rxlev_dl]
2 = [33 + 80 – (43 – 35)] – [33 + 70]
Criteria 2 specifies PBGT(n) – ho_margin 2 – 6 = – 4dB
sys12_ch05_18

Type 1 Algorithm
Uses
This is an extension of an existing algorithm to a per neighbour basis. As this is the case, it will
still mainly be used in its traditional role, that of macro to macro handovers.

Type 1 Algorithm
Uses
Serving cell is a macrocell
Preferred handover mechanism for macro to macro handovers
Trigger mechanism is PBGT
Ordering for microcell algorithm
Macrocell (Type 1) Macrocell (Type 1)
sys12_ch05_19

Type 2 Algorithm
If a neighbour is defined as a type 2 in the database, that means that a handover to that
cell will only be triggered imperative causes. Normally used to defined macro neighbours
in microcells.
This algorithm type is used for Macrocells neighbours and any other neighbours to which
power budget handovers are not allowed. The element pbgt_ho_needed shall always be
set to FALSE for neighbours of this type.

Type 2 Algorithm
To retain traffic in a microcellular layer, the marcocell is made a

type 2 neighbour.
This algorithm type is used for macrocells neighbours and any

other neighbours to which power budget handovers are not allowed.
If an imperative handover takes place (rxlev/rxqual), type 2

neighbour gets priority.
Additionally if an type 3 (round the corner neighbour)

generates a handover cause and the handover fails then a type
2 neighbour will be next in the candidate list
Macrocell (type 2 neighbour)
HO fails MS hands up to macrocell

Microcell Microcell
sys12_ch05_20

Type 3 Algorithm
The operator has the option to select a power budget algorithm where once the standard
GSM power budget conditions have been met, an additional restriction must be
overcome before a power budget handover will be initiated to that neighbour cell. The
additional restriction being that of the serving cell uplink and downlink RXLEVs must be
below specified thresholds. These thresholds are defined on a per neighbour basis. This
algorithm prevents power budget handovers to neighbours located around a corner until
the receive levels of the serving cell has dropped below the thresholds, indicating that the
MS has moved around the corner.
This guards against the case where the threshold is crossed only due to a temporary
fade. The probability of this happening both in the uplink and downlink is low due to the
45Mhz frequency separation.
Signal losses of as much as 20–30 dBs in the space of 10–40 metres can be measured
when turning a street corner. With this in mind, it is imperative that the handover
algorithm reacts quickly enough to maintain the call.
In the diagram opposite, a mobile is using Micro 1. When it reaches the area A, the
signal level of Micro 2 will be higher but if the mobile does not turn the corner it is not
necessary to hand–over to Micro 2 as this cell would experience a high drop in rxlev
around the corner 4. This scenario could lead to drop calls when the speed of the
mobiles is high. Using the type–3 algorithm with this configuration will avoid the potential
problems by maintaining the call on micro 1.
Another feature implemented in this configuration is an alternative ordering in the
handover candidate list. When a handover is generated for an around–the–corner type–3
neighbour but the microcell is blocked as the corner is turned, all macro neighbours will
be considered as candidates, ordered by PBGT. This will avoid problems in the scenario
where the mobile turns the corner, as the server signal level is expected to drop abruptly
and a handover to the macro layer is triggered.
An other application for this algorithm would be where there is a serving microcell and an
in building microcell.
GSR5 Enhancements
An optimised type 3 pbgt handover algorithm has been introduced since GSR 5. This
makes use of relative thresholds (path loss) instead of absolute level thresholds. This
takes into account that the BTS maybe using adaptive power control and prevents
handovers occurring at different points for different carriers.
For a handover to take place
[Pbgt(n) > ho_margin] and [dl path loss > dl threshold] and [ul path loss > ul threshold]
Generate handover cause
Note: ul path loss = ul transmit pwr – ul rxlev
dl path loss = dl transmit pwr – dl rxlev

Type 3 Algorithm
If microcell is If the mobile follows this

blocked after the direction, Cell 2 would not
corner is turned, only have to meet power
all macrocells budget requirements, but
are considered the rxlev both on the ul
and dl would have to fall
as neighbours by
below a preset level on
power budget. the server.
A Cell 1
ul_rxlev_serv_l When mobile passes

Cell 2 through A, it would
dl_rxlev_serv_l be undesirable to
hand over to Cell 2
sys12_ch05_21 900 Cell – type 3

neighbour
1800 Cell – serving
PBGT (n) criteria met for 900 cell

Rxlev on 1800 server has to fall below preset level
ul_rxlev_serv_l and dl_rxlev_serv_l (add_neighbour)
sys12_ch05_21

Type 4 Algorithm
This configuration is typically (but not exclusively) used between micro neighbours that
are near LOS related. The algorithm incorporates a delay timer to limit the handover rate
and to force fast moving mobiles to hand up to the macro layer before quality of service
is degraded. This configuration is identified as type 4 in the database definition.
System behaviour is dependent upon mobile speed. If the speed is low enough the
microcellular system will take the call, but if the speed increases the call will be handed
up to the macrocellular layer. The algorithm contains the additional restriction that the MS
must have been on the current channel for at least the number of SACCH periods
defined by the per neighbour parameter qualify_time. This value is compared to a
counter qualify_count, which is initially set to zero when the MS enters that cell and
incremented every time a measurement report is received for that channel until the value
reaches a maximum value of 255. If the mobile qualifies for the standard power budget
handover, the quality_count is compared to the qualify_time. If the qualify_count is
greater than qualify_time, then that neighbour is set to true for a power budget
handover.
qualify_time 0 to 255 SACCH multiframes
In the example opposite, a mobile located in a car handed into the microcellular system
(Microcell 1) when it was stopped at a traffic light: the system considered it was a slow
moving mobile. If the vehicle speed subsequently increases such that the mobile is
considered fast moving by the system, the timer of the serving microcell will prevent the
handover to Microcell 2 and this mobile will be forced to hand up to the macro layer
through an imperative handover.
Note: The timer can be set to zero and then can be used as the standard power budget
handover mechanism between microcells due to candidate ordering.

Type 4 Algorithm
Mobile handed up to Macro Mobilehanded

Mobile handed over
over to to
qualify_time = 100
layer because it has not microcell 2 as
microcell 2 asit itmeets
meets
been in the cell long enough powerbudget
power budget requirements
requirements Approx time 50s
to handover to mircrocell 3 andqualifies
and qualifiesforfor time
time
for power budget reasons becauseit ithas
because has been
been
stationaryatatthethe
stationary traffic
traffic lights
lights
formore
for morethan
than50s
50 s
Microcell 3 Microcell 2 Microcell
Time spent in microcell 2 = 10s
qualify_time = 0
time = 0s
Microcell 3 = type 4 Microcell 2 = type 4 Microcell 1 = type 4
A Pbgt handover is triggered from microcell 1 by type 4 neighbour
Candidate ordering places type 4 neighbours at the top of list
Time is not a factor for microcell 2 as qualify_time = 0
sys12_ch05_22

Type 5 Algorithm
In this case the trend of the neighbour signal level is monitored. To allow a handover to a
neighbour defined to use this configuration, its level has to exceed a threshold for a
defined period of time. This configuration may be used to hand down from the macro to
the micro layer when a microcell neighbour is deemed to have a high signal level
continuously for a period of time. The period and threshold may be configured to control
the handover rate between layers and to identify the mobiles whose speed is over the
desired limit and therefore should remain in the macro layer.
Algorithm Description
The rxlev threshold (rxlev_ncell_h) is set in add_neighbor as is the qualify_delay timer
which is set in SACCH multiframes. This delay is stored in the element
qualify_delay_count and is initialised to the value set in qualify_delay. Once the call
qualifies for the standard GSM power budget algorithm and the neighbour exceeds the
rxlev threshold, the qualify_delay_count is decremented. If the neighbour goes below
the rxlev threshold the qualify_delay_count is reset to the qualify_delay value. The
power budget need is only set to true once the qualify_delay_count reaches 0.
qualify_delay 0 to 255 SACCH multiframes
rxlev_ncell_h 0 to 63
In the example opposite, a fast moving mobile is identified by the serving macrocell and
is never handed down to the micro layer. It did not report the microcell signal level as
exceeding the required threshold for long enough.

Type 5 Algorithm
Macro
Microcell C
MS qualifies for
Pbgt handover
Rxlev = –70dBm
Time in secs = 10
qualify_delay = 30 (approx 15s)
rxlev_ncell_h = 40 (–70dBm)
sys12_ch05_24

Optimisation of type 5 handovers Version 1 Rev 1
Optimisation of type 5 handovers

Type 5 handovers are intended for hand–down calls from macrocells to microcells. A
problem occurs though with the indoor environment. This is because good quality might
exist with relatively low RXLEV. As hand–downs are based on relatively high threshold
(based on outdoor situation) a hand–down to macrocell to microcell might not take place,
even when the microcell is the correct cell for the call to be in. To avoid this problem,
optimisation of this procedure causes type 5 handover algorithm to ignore the level
threshold when the power budget between the serving cell and the neighbour cell meets
a settable handover margin.
ho_margin_type5 –63 to 63
def = 63
(set in modify_neighbor)
If rxlev(n) > rxlev_ncell_h or pbgt(n) > ho_margin_type5(n)
Then decrement qualify_delay_count
or else reset qualify_delay_count
if rxlev(n) < rxlev_ncell_h or pbgt(n) < ho_margin_type5 (n)
If qualify_delay_count = 0 and pbgt(n) > ho_margin_type5 (test only)
Then handover maybe generated if
pbgt(n) – ho_margin_cell > 0

Version 1 Rev 1 Optimisation of type 5 handovers
Optimisation of type 5 handovers
rxlev_ncell_h = 30 ho_margin_type5 = 10
qualify_delay = 10 ho_margin(n) = 6
– 94dBm
Serving Cell (Macro)
– 81dBm
Neighbour Cell (Pico)
Pbgt (n) = 13dB
rxlev (n) > rxlev_ncell_h or pbgt (n) > ho_margin_type5 (n)

– 81> – 80 No 13 > 10
Decrement qualify_delay_count (10 SACCH)
Genrate handover if pbgt(n) – ho_margin(n) > 0 13 – 6 > 0 true Better cell handover

Type 6 Algorithm (Delay PBGT using Dynamic ho_margin) Version 1 Rev 1
Type 6 Algorithm (Delay PBGT using Dynamic ho_margin)

This configuration is designed to penalise the handover margin for a defined period of
time. When the PBGT calculation exceeds the ho_margin, the penalty will be applied
and when a timer expires a different value will be subtracted from the ho_margin.
Effectively it attempts to limit the handover rate and may be used to hand down to the
microcellular layer as fast mobiles may be identified via this mechanism as well. It may
also be used between microcells to force the fast mobiles to hand up to the macro layer.
In addition, the algorithm has the flexibility to allow the handovers during the penalty time
in the scenario where rxlevs of the cells change very fast and the PBGT calculation
exceeds the dynamic ho_margin requirements.
The algorithm makes use of a dynamic handover margin. It also makes use of three
database parameters set in add_neighbor.
ho_static_offset 0 to 127
ho_dynamic_offset 0 to 127
delay_time 0 to 255
Description of variables
ho_margin(n) Per neighbour handover margin.
ho_margin _dyn Local variable used within this procedure only
qualify_delay_count(n) Value stored per neighbour in the active data block
Algorithm Definition
Initially if the pbgt(n) is greater than ho_margin(n) , then the count of
qualify_delay_count is set to delay_time. For each measurement report received, the
PBGT(n) is checked and criteria 1 and 2 calculated.
If:
qualify_delay_count(n) > 0
then
qualify_delay_count(n) = qualify_delay_count(n) – 1 (SACCH Multiframes)
and
ho_margin_dyn = ho_margin(n) + ho_static_offset
If qualify_delay_count(n) = 0 then
ho_margin_dyn = ho_margin(n) + ho_static_offset(n) – ho_dynamic_offset(n)
If pbgt(n) > 0 and pbgt(n) > ho_margin_dyn
Then a power budget handover reason is set to true for this neighbour.

Version 1 Rev 1 Type 6 Algorithm (Delay PBGT using Dynamic ho_margin)
Type 6 Algorithm
ServCell N/bourCell
PBGT(n) > ho_margin......Timer starts

ho_margin_dyn = ho_margin(n) + ho_static_offset(n)
Timer expires
ho_margin_dyn = ho_margin(n)+ho_static_offset – ho_dynamic_offset
If PBGT(n) > 0 and PBGT(n) > ho_margin_dyn PBGT handover need
PBGT(n)(10dBm) > ho_margin_dyn

ho_static_offset = 4
(2 + 4 – 2 = 4)
Yes – so the indoor cell

ho_dynamic_offset = 2
set to true for this
delay_time = 60 (30s)
neighbour
PBGT(n)(4dB > ho_margin (2dB)
Count = 60 SACCH
PBGT(n)(0dB)>ho_margin_dyn
ho_margin_dyn = 2+4 = 6
Too much for PBGT to indoor cell (2 + 4 – 2) = 4
No so the indoor cell is set false as a neighbour
Diagram number
Time taken 30s

Handover Scenario for Adjacent Channels (Both BCCH Carriers) Version 1 Rev 1
Handover Scenario for Adjacent Channels (Both BCCH Carriers)

Ideally there should be separation between the micro and macro layer frequency bands.
If the frequency spectrum is limited in a particular network it may be necessary to assign
adjacent channel frequencies.
The GSM recommendations indicate that degradations occur at an adjacent channel
interference level of about –9dB in a fading channel (no shadowing). This means that for
a mobile moving from one microcell to another, where the channels assigned are
adjacent (see diagram), there is a limited window in which handover can occur.
Only as the neighbour cell’s signal gets within 9dB of the serving channel does the
neighbour BSIC become decode–able. The MS can then start reporting this neighbour
channel and the BSS can start the averaging process. If the handover command is not
sent before the target channel exceeds the serving channel by 9dB, the handover may
fail because the handover command becomes corrupted.
The other constraint on the handover is that the handover process itself will only start
when the power budget expression exceeds the ho_margin.
The handover success rate is largely dependent on mobile speed and adjacent channel
handover parameters.
To minimise problems the following recommendations should be adopted;
S Use as large a frequency set as possible in the microcell layer. As far as possible
avoid the use of adjacent channels in adjacent cells.
S Wherever possible, avoid the use of adjacent channels in neighbour cells which
are “round the corner” from each other. The rapid signal changes in a “round the
corner” scenario make the window in the diagram smaller in terms of distance
travelled.
S Avoid the use of adjacent channels in neighbour cells which may encounter fast
moving mobiles.
S Use short averaging periods and low ho_margins for adjacent channel handovers.
S In cases where micro/macrocell frequencies are separated only by a narrow guard
band, (one channel), the microcell frequency which is nearest to the macrocell
frequency, should be assigned to the microcells furthest away (in distance) from
the macrocell.
S If none of the above recommendations can be adopted then use of the 7th
algorithm type may be utilised.

Version 1 Rev 1 Handover Scenario for Adjacent Channels (Both BCCH Carriers)
Handover Scenario for Adjacent Channels (Both BCCH

Carriers)
Power Serving
Neighbour
9dB 9dB
Distance
Adjacent Target ho_command

BSIC is PBGT becomes
decode – able beats unreliable
here ho_margin
S Large micro frequency set

S Avoid adj channel frequencies for round the corner neighbours
S Avoid the use of adj channels which are likely to encounter fast handovers
S Use short averaging periods and low ho_margins for adj channel
S Distance adj channel micros from macro
S Alternatively use the type 7 handover algorithm
sys12_ch_03_09

Type 7 Algorithm
In large microcellular deployments where frequency spectrum for micros is limited, there
are situations where it is impossible to avoid deploying adjacent microcells with adjacent
BCCH frequencies. As a mobile being served by one of these cells approaches the
interfering neighbour cell, the quality of the call degrades perhaps to the point of dropping
altogether. Assuming that both cells have only a single carrier, neither an intra–cell
handover nor a handover to the interfering neighbour improves the situation.
This algorithm allows a third Cell, which is not on an adjacent channel, to be the
preferred target for handover even though an interfering neighbour may have the
strongest signal. When Power budget – adj_chan_ho_margin > 0
a handover will be generated before the neighbour signal strength (and thus interference)
becomes too strong to drop the call.
Algorithm Definition
During the handover detection phase the type 7 algorithm computes the power budget
equation using rxlev averages from the bin dl_rxlev_av_h_dec for the serving cell and
ncell_rxlev_av_h_calc for type 7 neighbour cells and evaluates the equation
Power budget – adj_chan_ho_margin > 0
If any of the type 7 neighbours pass the above equation, a handover cause of
ADJ_CHAN_INTF is detected, this is an imperative handover even through the power
budget equation is used to detect the handover. The relative priority of this handover is
just above that of the power budget handover. The handover is performed to a cell
different from this neighbour. This is managed because we delete the neighbour that
activated this condition from the candidate list as it will be explained in the candidate list
generation section.
Any neighbours that satisfy criteria 1 will be a candidate for handover. If no neighbours
satisfy criteria 1 then no handover will be generated.
A database parameter is included to detect the risk coming from neighbours in adjacent
frequencies, when defined as type 7, this is adj_chan_ho_margin.
adj_chan_ho_margin
– 63 to 63 (set in add_neighbor)

Type 7 Algorithm
Cell A Cell B
ARFCN 10 ARFCN 11
Type 7
Serving cell
ARFCN 21
Cell C
pbgt – adj_chan_ho_margin > 0 (for cell B)

Cell B satisfies criteria for PBGT handover but fails additional
constraint of adj_chan_ho_margin
Cell C passes criteria 1 so handover generated to it
sys12_ch05_26


Type 7 Algorithm Example
Handover to Macro
Macro
ARFCN = 21
ARFCN = 10
Micro (Serving)
adj_chan_ho_margin = 9
pbgt(n) Micro = 10 ho_margin(n) = 6 Handover to

Micro when pbgt
pbgt(n) – adj_chan_ho_margin > 0 allows – use adj
channel int test
10 – 9 > 0 PBGT handover changed to imperative
ARFCN = 11
Micro
sys12_ch05_27

Interference Avoidance Test Version 1 Rev 1
Interference Avoidance Test

Another problematic situation could appear when calls are handed over to a cell that has
a neighbour with adjacent (BCCH) frequency. It is possible to enable the BSS to perform
an interference avoidance test on the neighbour candidate before handing it over a call.
This test can be done regardless of which of the seven types is used for this neighbour.
If adj_chan_intf_test enabled in NEIG1and any other valid neighbour NEIG2 (of the
current cell) has an adjacent channel frequency with the candidate neighbour (NEIG1)
then perform following check:
Candidate neighbour rxlev – rxlev of neighbour on adj chan < adj_chan_rxlev_diff
If check is true then delete neighbour N1 from candidate list.

adj_chan_intf_test
0 = no 1 = yes
adj_chan_rxlev_diff
– 63 to 63 (both set in add_neighbor)
Example
A mobile is on a serving cell and detects a neighbour with an adjacent channel frequency,
the candidate neighbour rxlev is –70dBm and the adjacent channel neighbour rxlev is
–60dBm.
adj_chan_rxlev_diff = –9dB
So
–70 –(–60) < –9
–10 < –9
The check is true as –9dB is more positive than –10dB hence candidate cell would be
removed from the neighbour list.
The check would then be performed on the other neighbour.
–60 –(–70) < –9
10 < –9
The check is false as –9dB is not more positive than 10dB hence candidate cell would be
included in the neighbour list.

Version 1 Rev 1 Interference Avoidance Test
Adjacent Channel Interference Avoidance Test
adj_chan_intf_test = 1
Cell A Cell B
For Cell B and Cell C
ARFCN 20 ARFCN 10
Serving cell
ARFCN 11
Cell C
Cell B and Cell C is a valid neighbour of the serving cell A
Cell B rxlev – Cell C rxlev < adj_chan_rxlev_diff
If test fails remove candidate neighbour from candidate list
sys12_ch05_28

Setting of Candidate List Version 1 Rev 1
Setting of Candidate List

Using the microcell implementation, each neighbour is assigned a power budget
algorithm to be used for that neighbour. Upon receipt of each measurement report the
BSS uses the assigned algorithm for each neighbour reported by the MS to determine if
the MS qualifies for a power budget handover to that neighbour. The BSS then
evaluates the number of neighbours that qualify for a power budget handover. These
neighbours are then prioritised based on the algorithm used to determine the power
budget handover qualification and the value of the power budget calculation.
The BSS will then manipulate the list of candidate cells based on the flow chart opposite.
Also to be considered is how many neighbours will be evaluated in the list. This can be
defined by the database parameters below.
neighbor_journal =1 No warm up period for neighbours, all neighbour information
padded with zeros. Averaging and power budget calculation will begin immediately.If a
previously reported neighbour is missing in the measurement, a zero rxlev is used for the
neighbour. Stored neighbour information will be removed when the disuse count is equal
to the surrounding cell hreqave (set in add_neighbor) or 8 depending on the setting of
disuse_cnt_hreqave.
neighbor_journal = 0 There is a warmup period for the surround cell hreqave before
power budget calculations begin. The last received rxlev for the unreported neighbour will
be used for missing data. Stored neighbour information will be removed when the disuse
count is equal to the surrounding cell hreqave (set in add_neighbor) or 8 depending on
the setting of disuse_cnt_hreqave.
disuse_cnt_hreqave 0 Use max count which equals 8
1 Use surround cell hreqave (set in add_neighbor)

Version 1 Rev 1 Setting of Candidate List
Setting of Candidate List
In
Remove any neighbours that fail

the interference avoidance test
Remove any neighbour that does not satisfy

additional requirements of its algorithm (NA type 1 and 2)
Evaluate Criteria 1, then all that pass evaluate by
Criteria 2 so all candidates sorted in order of PBGT with
The strongest neighbour first
Neighbour candidate list:

– All algorithm 3 neighbours
Handover triggered by yes – All algorithm 1 and 2 neighbours
type 3 neighbour – Any algorithm 4,5 and 6 neighbours
Prefers type 3 neighbours, uses type 2
neighbours as default candidates, then others
no as last resorts
Out
yes – Remove algorithm 2 neighbours
Handover triggered by
– Any algorithm 4,5 and 6 neighbours
type 4,5 or 6 neighbour
– Any algorithm 1 neighbours
no

yes – Remove any algorithm 7 neighbours
Handover triggered by
which fail test:
imperative handovers or adj chan int – All algorithm 1 and 2 neighbours
– Any other neighbours
no
Out
SYS12_Ch4_29

Micro – Micro Quality Handover Version 1 Rev 1
Micro – Micro Quality Handover

When a RXQUAL handover condition exists, a layer indication for the serving cell and the type of
neighbour within the environment (identified by the PBGT algorithm utilised by that neighbour) will
be used to prioritise the microcell neighbours, thereby attempting to handover, as well as maintain,
the call within the microcellular layer. The lower the number for the layer indication, the larger the
layer. Currently, this means that cell level 0 is the macro layer, cell level 1 is the micro layer and
cell level 2 is the pico layer. RXQUAL handovers can effectively be disabled to a specific
neighbour by setting the ho_margin_rxqual[n] for that neighbour to 63. Prioritisation and
ordering of handover candidates will only be performed if the functionality is enabled via the
prioritize_microcell flag, and the bounce_protect_qual_tmr is not active.
Commands:
Element Min Max Default Value Definition Comments
layer_number 0 2 0 0 = Macrocell per cell element
1 = Microcell
2 = Picocell
prioritize_microcell 0 1 1 0 = Disabled per cell element
Layer of serving cell will not impact
sorting of candidate list.
1 = Enabled
Layer of serving cell will impact
sorting of candidate list.
Ordering
The following ordering will only be performed if the functionality is enabled via the
prioritize_microcell flag, and the bounce_protect_qual_tmr (Timed Offset upon
RXQUAL Handover) is not active. The dependency on bounce_protect_qual_tmr is to
prevent a call from ping–pongs between two microcells if bad RXQUAL exists in both.
RXQUAL condition with call in microcell layer:
All neighbours which exceed rxlev_min[n] + Max (0,Pa)
All neighbours remaining after exclusion procedure considering handover margin per
cause
Neighbour types prioritized :
(a)
4,5,6 sorted by PBGT – ho_margin followed in the list by
(b)
3 sorted by PBGT – ho_margin followed in the list by
(c)
1,2 sorted by PBGT – ho_margin
RXQUAL condition with call in macrocell layer:
All neighbours which exceed rxlev_min[n] + Max (0,Pa)
All neighbours remaining after exclusion procedure considering handover margin per
cause
Neighbour types prioritised :
(a)
1 sorted by PBGT – ho_margin followed in the list by
(b)
2,3,4,5,6 sorted by PBGT – ho_margin

Version 1 Rev 1 Micro – Micro Quality Handover
Micro – Micro Quality Handover
Prioritize_microcell = 1 Neighbour types 1 – Followed by 2,3,4,5 and 6
layer_number = 0 layer_number = 0
Neighbour Neighbour types 1 and 2

type 5
layer_number = 1 layer_number = 1
Neighbour types 4, 5, 6 followed by 3
sys12_ch05_35

Micro – Micro Quality Handover Version 1 Rev 1

Chapter 3
Concentric Cells

Version 1 Rev 1

Version 1 Rev 1
Chapter 3
Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–1
Multiband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–2
Power Based Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Handover to Inner Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–4
Power Based Concentric Cells – HO to Inner Zone Power Level . . . . . . . . . . . . . . . . . . 3–6
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Handover to Inner Carrier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–6
Handover to Outer Zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–8
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–10
Power Budget Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12
Mobile Power Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–12
Interference Based Algorithm – Handover to Inner Zone . . . . . . . . . . . . . . . . . . . . . . . . . 3–14
Direct Inner Zone Threshold and Neighbour Report Timer . . . . . . . . . . . . . . . . . . . . . . . . 3–16
Interference Based Algorithm – Handover to Outer Zone . . . . . . . . . . . . . . . . . . . . . . . . . 3–18
Power Control When Using Interference Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–20
Concentric Cells – Channel Allocation Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
outer_zone usage_level . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
Flow Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
intra_cell_handover_allowed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
Emergency call pre–emption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22
Immediate Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3–22

Version 1 Rev 1

Version 1 Rev 1 Concentric Cells
Concentric Cells
Objectives
S Describe the decision process for power based concentric cells
S Describe the decision process for interference based concentric cells

Concentric Cells Version 1 Rev 1
Concentric Cells
Concentric Cells is an optional feature which provides cell resource partitioning using the
concept of the concentric cell structure (outer and inner zones) to allow for tighter re–use
patterns and increased frequency economy.
This feature describes the use of a single BCCH using interference estimation or
measurement to move traffic between the conventional macrocell underlay (Outer zone)
and the super reuse layer (Inner zone).
Concentric Cell is an elegant and simple technique in which the size of cells on the super
re–use layer (inner zone) is self–governed by interference or by the power that the
carriers on the inner zone transmit.
With this feature the operator may configure non–BCCH carriers within a cell to have a
smaller coverage area. The carriers equipped within a cell may be grouped into two
zones:
S Zone 0: Also referred to as the “outer zone”, is reserved for carriers that may
broadcast at the maximum transmit level defined for the cell.
S Zone 1: Also referred to as the “inner zone”, may be defined with non–BCCH
carriers transmitting lower power than the BCCH carrier, or having a tighter reuse
pattern that reduces the useful coverage area of the carrier.
The Mobile Station connected to Zone 0 must meet specific criteria before it can be
assigned a traffic channel configured on a carrier in Zone 1 and vice versa. There are two
different “use algorithms”, specified by the operator on a per cell basis, to trigger the
transitions between the two zones of the cell.
S Power Based Concentric Cells: Inner zone carriers transmit less power than outer
ones and the transitions between zones are based on absolute level thresholds.
S Interference Based Concentric Cells: Inner and outer zone carriers transmit all the
same power within and the transitions between zones are based on some
interference conditions. These interference conditions are protection margins
against potential interfering neighbours.
The use of a single BCCH implies that the carriers placed in the outer zone are available
in the whole cell coverage area whereas the inner zone carriers are only available in a
restricted area close to the site location. The signalling previous to the call set–up is
established in the outer zone and whenever it is possible to move to the inner, the call is
transferred to the inner carriers.
The Concentric Cell feature is basically a capacity enhancement feature. The possibility
of implementing tighter reuse patterns in the area close to the antenna site permits to
increase the capacity at the same time that quality is guaranteed by the use of
interference estimation algorithm
Multiband
From software release GSR 5.0 multiband operation of concentric cells is allowed. For
example if DCS1800 is being added to an existing GSM900 network, the existing
GSM900 BCCH plan can be used, since there is no need to plan DCS1800 BCCHs when
1800MHz carriers are added. For this feature to be efficient the network should have
sufficient number of multiband–capable mobiles and equipment should be collocated and
synchronized. (InCell cabinets cannot be mixed with M–Cell/Horizon cabinets in the
same logical area). In the example described above, all mobiles must be at least
GSM900 capable to access the system. Since the BCCH carriers are defined in the
GSM900 band, single band DCS1800 mobiles will be unable to access the system.

Concentric Cells
Zone 1 – Inner Zone
Non – BCCH
Transmitting at BCCH
lower power than Broadcast at max tx
BCCH or level defined for that
Zone 0 – Outer Zone
cell
Having a tighter
Other non_BCCH carriers
reuse pattern that
reduces the useful
coverage area of Multiband Operation of Concentric Cells
the carrier Supported from GSR 5.0
SYS12_Ch01_14

Power Based Concentric Cells Version 1 Rev 1
Power Based Concentric Cells

To enable concentric cells and the whether a power, interference or dual band operation
is being selected, is set by the database parameter:
inner_zone_alg = <*> Where 0 = Disabled
1 = Power based use algorithm
2 = Interference based use algorithms
3 = Dual band in use

In the power based intra–cell handover algorithm carriers in the inner zone are given
reduced maximum uplink and downlink transmit levels, which define the coverage area of
the inner zone.
The decision to move traffic between zones is based on the downlink and uplink receive
levels with respect to the serving cell, as well as database parameters, which are
prompted when inner_zone_alg = 1.
S ms_txpwr_max_inner
Valid Range: PGSM, EGSM and GSM 850 5 to 39 dBm Default value: max_tx_ms
DCS 1800 and PCS 1900 0 to 30 dBm Default value: max_tx_ms
S zone_ho_hyst
Valid range: 0 to 30 Default = 0
S rxlev_dl_zone
S rxlev_ul_zone
Handover to Inner Zone

A handover is initiated when both the uplink and the downlink receive level averages are
greater than the sum of the respective uplink or downlink thresholds defined for the inner
zone plus the per cell hysteresis for interzone handover plus the difference between the
current uplink/downlink transmit power and the maximum uplink/downlink transmit power
of the inner zone carrier.
Initiate handover into the inner zone if the following is true for the inner zone carrier(s):
rxlev_dl > rxlev_dl_zone + zone_ho_hyst + (bs_txpwr – bs_txpwr_max_inner)
and
rxlev_ul > rxlev_ul_zone + zone_ho_hyst + (ms_txpwr – ms_txpwr_max_inner)
where:
rxlev_dl/ul_zone = minimum rxlev in inner zone
–110dBm(0) to –47dBm(63)
bs/ms_txpwr = current tx power in outer zone (max_tx_bts and
max_tx_ms). Non–bcch carriers can use adaptive
pwr control.
bs_txpwr_max_inner = trx maximum power capability –
trx_pwr_red (Set in RTF equipage)
This is the reduced power downlink due to being an inner cell. Each carrier can have a
different trx_pwr_red value, giving multiple sub–zones inide zone 1.

Version 1 Rev 1 Power Based Concentric Cells
Power Based Concentric Cells – Handover to Inner Zone
inner_zone_alg = 1
rxlev_dl_zone = 33 (–77 dBm)
rxlev_ul_zone = 36 (–74 dBm) rxlev_ul = –63dBm
zone_ho_hyst = 3 dB
trx_pwr__red = 3 (6dB) rxlev_dl = –65 dBm
Zone 1
ms_txpwr_max_inner = 31 dBm
Mobile Power
bs_txpwr_max_inner = trx max power
Class = 4
Zone 0
capability – trx_pwr_red
rxlev_dl > rxlev_dl_zone + zone_ho_hyst + (bs_txpwr – bs_txpwr_max_inner)
–65 > – 77 +3 + (43 – (43 – 6))
–65 > –68
rxlev_ul > rxlev_ul_zone + zone_ho_hyst + (ms_txpwr – ms_txpwr_max_inner)
–63 > –74 +3 + (33 –31)
–63 > –69
SYS12_Ch05_10

Power Based Concentric Cells – HO to Inner Zone Power Level Version 1 Rev 1
Power Based Concentric Cells – HO to Inner Zone Power Level
Overview
Using the power based algorithm, the operator may set each carrier in the inner zone to
different maximum downlink transmit power levels. Using this configuration, the BSS
shall perform handovers between inner zone carriers based on the same algorithms used
to perform handovers between zones. By utilizing this functionality, the operator can
effectively have multiple sub–zones within zone 1. However, all carriers defined to be in
zone 1 share the same maximum uplink transmit level. All carries defined to be in zone 0
shall have maximum downlink transmit level defined by the BCCH power level and the
maximum uplink transmit level as defined per cell in the database.
Handover to Inner Carrier

The HDPC provides the minimum and maximum power level that satisfies the two
handover algorithms. Call processing also utilizes these values to select a channel on a
carrier that has the lowest maximum transmit level that is within the given range. The
maximum power level for a candidate carrier is one power level weaker than the serving
carrier and is calculated by incrementing the serving carriers maximum transmit power
level:
maximum power level = serv_txpwr_max + 1
Where: serv_txpwr_max = trx_pwr_red defined for the serving carrier
The minimum power for the candidate carrier is derived from the downlink transmit power
criterion as follows:
minimum power > rxlev_dl_zone + zone_ho_hyst + bs_txpwr – rxlev_dl
All parameters in the above equation are converted into dBm before calculation of the
minimum power. The minimum power is then converted from dBm to level units. If the
computed value falls between two different levels in the conversion table, the stronger
power level shall be used
Prior to sending the zone handover recognized message, the handover process must
verify that the calculation range is valid, and that the cell has at least one carrier within
the calculated range. To facilitate this process a list of carriers is provide in descending
order by TRX power level reduction value (trx_pwr_red) Therefore last entries will be
outer zone carriers. The call does not qualify for an inner carrier handover if the minimum
power level turns out to be stronger than the maximum power level or no carriers in the
list has a trx_pwr_red value within the minimum and maximum power level range,
inclusively.
If the call qualifies for both an inner carrier handover and the standard interference
handover, the max power level is adjusted to cell max, max_tx_bts This allows CP to
assign the call to an outer carrier when there are no resources available for the inner
carrier handover and thereby satisfying the standard interference handover requirement.

Version 1 Rev 1 Power Based Concentric Cells – HO to Inner Zone Power Level
Power Based Concentric Cells – Handover to Inner Zone

Power Level
39 dBm
serv_txpwr_max = 2 (39 dBm)
37 dBm
13 dBm rxlev_dl = –50 dBm

rxlev_dl = 60 (–50 dBm)
bs_txpwr = 3 (37 dBm)
zone_ho_hyst = 4 dB
Zone 1
Zone 0
Handovers into
min power > rxlev_dl_zone + zone_ho_hyst + bs_txpwr – rxlev_dl inner carriers
with maximum
> –80 + 4 + 37 – (–50) power levels of
> 11 dBm (level 16 – in between levels so . . . ) 15 to 3 are
allowed
min power = 15 (13 dBm)
max power level = serv_txpwr_max + 1

=2+1
= 3 (37 dBm)
SYS12_Ch05_11

Concentric Cells Version 1 Rev 1
Concentric Cells
Handover to Outer Zone

A handover is initiated when either the uplink or the downlink receive level average is
below the respective uplink or downlink threshold defined for the inner zone and a further
increase of the transmit power is not allowed.
Initiate handover into the outer zone if the following is true:
rxlev_dl < rxlev_dl_zone AND bs_txpwr = bs_txpwr_max_inner
OR
rxlev_ul < rxlev_ul_zone AND ms_txpwr = ms_txpwr_max_inner
where:
rxlev_ul/dl_zone = minimum rxlev in inner zone
–110dBm(0) to –47dBm(63)
bs_txpwr_max_inner = TRX maximum – power trx_pwr_red
This is the reduced power downlink due to being an inner cell.
ms_txpwr_max_inner = specifies the max power an MS can use in the inner zone of a
concentric cell, see W23
bs/ms_txpwr = current tx power in inner zone

Concentric Cells – Handover to Outer Zone
inner_zone_alg = 1
rxlev_ul_zone = 36 (–74 dBm) rxlev_ul = – 76 dBm
ms_txpwr_max_inner = 31 dBm
rxlev_dl = – 76 dBm
trx_pwr_red = 3 (6dB) Zone 1
Mobile Power
bs_txpwr_max_inner = trx max power
Class = 4
Zone 0
capability – trx_pwr_red
rxlev_dl < rxlev_dl_zone AND bs_txpwr = bs_txpwr_max_inner
–76 < –77 AND 27 = (33 – 6) X
OR
rxlev_ul < rxlev_ul_zone AND ms_txpwr = ms_txpwr_max_inner
–76 < –74 AND 31 = 31
SYS12_Ch05_12

Interference Based Concentric Cells Version 1 Rev 1
Interference Based Concentric Cells
Overview
The interference algorithm is based on the interference estimation in the inner zone. The
handover to the inner zone is triggered if no interference is expected from any neighbour,
and as soon as interference is expected from any neighbour the call makes handover to
the outer zone.
The interference estimation is just a modified power budget calculation with all the
interfering neighbours. To be free of interference from a particular neighbour, the power
budget with the serving cell must be better that the one with the neighbour in a threshold
(inner_zone_threshold) and a margin (inner_zone_margin) to prevent ping–pong.
So, with this new configuration, the thresholds were defined on a per neighbour basis,
and depending on the type of interference expected from the neighbour: Co–channel or
adjacent–channel interference, and the influence of the cell: front to front, back to front or
front to back interference.
The database parameter that indicates that the neighbour uses an interfering frequency
(i.e. may be adjacent or co–channel) is:
interfering_nbr (set in add_neighbor)
Range: 0 to 1
0 = no
1 = yes

Version 1 Rev 1 Interference Based Concentric Cells
Thresholds set per neighbour
Neighbour 2
Neighbour 1 Neighbour 3
Serving Cell
Power budget calculated for all neighbours

To be free of interference from a particular neighbour: pbgt(s) must be better than
pbgt (n)s + threshold + margin
Handover to the inner zone if no interference from any neighbour

As soon as interference expected handover to the outer zone
SYS12_Ch05_13

Interference Based Concentric Cells Version 1 Rev 1
Power Budget Calculation

For concentric cell inter zone handovers, the usual power budget formula is modified to
remove consideration of the mobiles transmit power capacity, as follows:
Pbgt (n)’ = (ms_txpwr_max – rxlev_dl – pwr_c_d) – (ms_txpwr_max (n) –
rxlev_ncell (n))
where: pwr_c_d = maximum downlink Tx power in outer zone – actual downlink Tx
power
ms_txpwr_max = maximum mobile transmit power defined per cell
An assumption is made at this stage that the difference between the serving cell
maximum BS transmit power level and the neighbour cell maximum BS transmit power
level is equal to the difference the serving cell maximum MS transmit power level and the
neighbour cell maximum MS transmit power level.
(i.e. ms_txpwr_max – ms_txpwr_max(n) = bs_txpwr_max – bs_txpwr_max(n)).
This is because bs_ txpwr_max(n) is not presently available in the database and the MS
power levels are used in the equation instead of the BS power levels.
Mobile Power Factor

Since the focus of this algorithm is to prevent the MS from getting into a position where it
can experience or cause interference, an additional factor is calculated to account for the
mobile reporting poor quality and the decision_alg_num database parameter being set
to 1, to allow a power increase due to quality even when the rxlev is above its upper
threshold. This factor is defined here and used in the equations below:
ms_pwr_factor = rxlev_ul + (ordered_power_level – used_power_level) –
l_rxlev_ul_p
This calculation incorporates pending power control changes and, to be conservative, is
based on the lower end of the power box and should deter the MS from being served by
the inner zone.

Version 1 Rev 1 Interference Based Concentric Cells
ms_txpwr_max = 33
ms_txpwr_max = 33 rxlev(n2) = –80
rxlev(n1) = –90
rxlev (s) = –70
max_tx_ms = 33
pwr_c_d = 0
Pbgt(n)’ = (ms_txpwr_max – rxlev_dl – pwr_c_d) – (ms_txpwr_max(n) – rxlev_ncell(n))
Pbgt(n1)’ = (33 – (–70) – 0) – (33 – (–90)) = –20dB
Pbgt(n2)’ = (33 – (–70) – 0) – (33 – (–80)) = –10dB
decision_alg_type =1
rxlev (n2) = –75

rxlev (n2) = –65
used_power_level = 27dBm
ordered_power_level = 29dBm
rxlev (s) = –70

– 47dBm 0 0.14
63
1 0.28
2 0.57
3 1.13
rxlev_ul = –70dBm
4 2.26
–74dBm (l_rxlev_ul_p)
35 400
5 4.53
6 9.05
– 110dBm 7 18.1
0
ms_pwr_factor = rxlev_ul+(ordered_power_level – used_power_level) – l_rxlev_ul_p

–70 + (29 – 27) – (–74)
sys12_ch06_p29
= 6dB

Interference Based Algorithm – Handover to Inner Zone Version 1 Rev 1
Interference Based Algorithm – Handover to Inner Zone

In deciding whether a call is suitable to be served by an inner zone channel, the BSS
(HDPC) must satisfy itself that both of the conditions below are true. However, it should
be noted that they must be true in relation to all neighbours that contain a co– or
adjacent–channel interfering carrier frequency.
Uplink Criteria: (Checks if the mobile is going to interfere with neighbour cells)
pbgt(n) +ms_pwr_factor + inner_zone_threshold(n) +inner_zone_margin(n) ≤ 0
and
Downlink Criteria: (Checks if the neighbours are going to interfere with the mobile)
rxlev_dl + pwr_c_d – (rxlev_ncell(n) + inner_zone_threshold(n) +
inner_zone_margin(n)) ≥ 0
Where:
inner_zone_threshold(n)
Range 0 to 63
and
inner_zone_margin(n)
Range 0 to 63
and are per neighbour database defined values.

Version 1 Rev 1 Interference Based Algorithm – Handover to Inner Zone
Interference Based Algorithm – Handover to Inner Zone
interfering_nbr = 1 interfering_nbr = 1
rxlev (n2) = –90 rxlev (n1) = –80

pbgt (n2)’ = –20 pbg (n1)’ = –10
ms_pwr_factor = 0
inner_zone_threshold(n1) = 15dB pwr_c_d = 43 – 43 = 0
inner_zone_threshold(n2) = 15dB rxlev (s) = –70
inner_zone_margin(n1&2) = 3dB
Uplink Downlink
Pbgt(n)’ + ms_pwr_factor + inner_zone_threshold(n) Rxlev_dl + pwr_c_d – (rxlev_ncell (n) +
+ inner_zone_margin(n) 0 inner_zone_threshold(n) + inner_zone_margin(n)) 0
Neighbour 1 – 10 + 0 + 15 + 3 0 Neighbour 1 –70 + 0 – (–80 + 15 + 3) 0

8 0 No –8 0 No
Neighbour 2 – 20 + 0 + 15 + 3 0 Neighbour 2 –70 + 0 – (–90 +15 +3) 0
–2 0 Yes 2 0 Yes
SYS12_Ch05_14

Direct Inner Zone Threshold and Neighbour Report Timer Version 1 Rev 1
Direct Inner Zone Threshold and Neighbour Report Timer

The handover process uses two database parameters (direct_inner_zone_threshold
and neighbor_report_timer) to determine the minimum number of measurement
reports that must be received from the MS on the current channel prior to moving the MS
to the inner zone. If the call is on an SDCCH, the handover process shall accelerate the
process in an effort to reduce the number of channel changes for the MS. Using this
method, the call may be assigned directly to a TCH in the inner zone rather than moving
first to an outer zone TCH the then to another TCH in the inner zone. This method
allows the handover process to initiate the inner zone handover as soon as a downlink
rxlev average has been calculated if the calculated average is greater than the
direct_inner_zone_threshold . If the MS is on an SDCCH on a non–BCCH carrier,
power control shall be considered in the calculation as shown below:
dl_rxlev + ((current_dl_power_level – max_tx_bts ) * 2) > direct_inner_zone_threshold
Note: The value 2 is used in the algorithm to convert absolute values into dBm.
If the above statement is TRUE, the MS qualifies for an inner zone resource.
This method is based on the assumption that if the serving cell receive level is strong
enough, neighbor cells will not cause harmful interference. For all other cases, the use
of the neighbor_report_timer is required.
Since this algorithm is based on neighbour information reported by the MS, the MS must
be allowed enough time to report on interfering neighbours before moving the MS to the
inner zone. This delay is defined in SACCH periods by the database element
neighbor_report_timer. The handover process counts the number of measurement
reports received on a channel in the qualify_count element. Prior to receipt of the
specified number of measurement reports (i.e., qualify_count <
neighbor_report_timer), a handover to the inner zone can only be initiated if for ALL of
the defined interfering neighbours the handover process has received hreqave
measurements and the handover criteria is met. Once the delay has been met (i.e.,
qualify_count >= neighbor_report_timer), the handover process shall assume that
any neighbours which have not been reported by the MS are not strong enough to
prohibit handover into the inner zone. As long as all reported interfering neighbours meet
the specified criteria, the handover into the inner zone shall be initiated. When
computing averages to determine if the call meets the inner zone use criteria, the
handover process shall compute an average using all received measurements (min of 2)
for a given neighbour if less than hreqave measurements have been received.
direct_inner_zone_threshold
Valid Range 0 to 63
Default = 63
neighbor_report_timer
Valid Range 0 to 255 SACCH Periods
Default = 10

Version 1 Rev 1 Direct Inner Zone Threshold and Neighbour Report Timer
Direct Inner Zone Threshold and Neighbour Report Timer
max_tx_bts = 43 dBm For all other cases:
Mobile on SDCCH and has Before moving mobile to the inner

received its second dl_rxlev from zone, interfering neighbours must
the serving cell have time to report their level
dl_rxlev = –70 neighbor_report_timer = 10 (sacch)
Current dl power level = 33 dBm qualify_count < neighbor_report_timer
direct_inner_zone_threshold = 45 (–65dBm) Ho can only take place if all interfering

n/bours reported hreqave
dl_rxlev + ((current_dl_power_level – max_tx_bts)*2) > measurements and HO criteria met
qualify_count neighbor_report_timer
– 70 + ((5 – 0)*2) > –65 Any interfering n/bours not reported
exclude
–60 > –65
SYS12_Ch05_15

Interference Based Algorithm – Handover to Outer Zone Version 1 Rev 1
Interference Based Algorithm – Handover to Outer Zone

The handover process shall initiate a handover out of the inner zone if the following
algorithm is true for any interfering neighbour:
Uplink Criteria: (Is mobile interfering with the neighbour?)
pbgt(n)’ + ms_pwr_factor + inner_zone_threshold(n) > 0
OR
Downlink Criteria: (Is the neighbour interfering with the mobile?)
rxlev_dl + pwr_c_d – rxlev_ncell(n) – inner_zone_threshold(n) < 0

Version 1 Rev 1 Interference Based Algorithm – Handover to Outer Zone
Interference Based Algorithm – Handover to Outer Zone
rxlev(n2)= –60
pbgt(n2) = –8 rxlev(n1) = –55
pbgt(n1) = –10
inner_zone_threshold(n1) = 15dB ms_pwr_factor = 3 (in both cases)
pwr_c_d = 43 – 33 = 10
inner_zone_threshold(n2) = 15dB rxlev(s)= –65
Uplink Downlink
pbgt(n)’ + ms_pwr_factor + inner_zone_threshold(n) > 0 rxlev_dl + pwr_c_d – rxlev_ncell(n)–

inner_zone_threshold(n) < 0
Neighbour 1 –10 + 3 + 15 > 0 Neighbour 1 – 65 + 10 – (–55) –15 < 0
8 > 0 Yes –15 < 0 Yes
Neighbour 2 –8 + 3 + 15 > 0 Neighbour 2 – 65 + 10 – (–60) – 15 < 0
10 > 0 Yes
–10 < 0 Yes
SYS12_Ch05_16

Power Control When Using Interference Algorithm Version 1 Rev 1
Power Control When Using Interference Algorithm

If the call is active on a channel in the inner zone, the BSS performs an additional check
prior to ordering a power decrement. When the BSS power control algorithm determines
that the downlink power should be decremented, a check will be performed to verify that
the power decrement will not cause the MS to subsequently require a handover to the
outer zone. The power control decrement is only allowed if the following is TRUE for ALL
neighbours that have been identified as interferers:
rxlev_dl – power decrement – rxlev_ncell(n) > inner_zone_threshold(n)
If the call is active on a channel in the inner zone, and the BTS is not transmitting at the
maximum power level the following equation is evaluated for ALL neighbours which have
been identified as interferers:
rxlev_dl + power increment – rxlev_ncell(n) > inner_zone_threshold(n)
If a power increment is necessary to satisfy the above equation for ALL interfering
neighbours, the power level increment is ordered. The BSS selects the minimum power
increment that satisfies the above equation for ALL interfering neighbours. The power
increment can only be ordered if the ordered power level remains below the maximum
transmit level.

Version 1 Rev 1 Power Control When Using Interference Algorithm
Power Control When Using Interference Algorithm
rxlev(n2) = –60
rxlev(n1) = –70
rxlev(s) = – 60
inner_zone_threshold(n1) = 15dB 1st Example 2nd Example
2 dB power 6 dB power
inner_zone_threshold(n) = 15dB decrement increment
ordered ordered
Power Control Decrement Power Control Increment
rxlev_dl – power decrement – rxlev_ncell(n) rxlev_dl + power decrement – rxlev_ncell(n)
> inner_zone_threshold(n) > inner_zone_threshold(n)
Neighbour 1 – 60 – 2 – (–70) > 15 Neighbour 1 –60 + 6 – (–70) > 15

8 > 15 No 16 > 15 Yes
Neighbour 2 – 60 – 2 – (–60) > 15 Neighbour 2 –60 + 6 – (–60) > 15

–2 > 15 No 6 > 15 No
SYS12_Ch05_17

Concentric Cells – Channel Allocation Rules Version 1 Rev 1
Concentric Cells – Channel Allocation Rules
outer_zone usage_level
A database threshold, outer_zone_usage_level, has been introduced which allows the
operator to specify the level of traffic channel congestion which must be reached in the
outer zone prior to the use of the inner zone resources. Since inner zone frequencies
may have a tighter re–use pattern, this allows the operator to only use those frequencies
more prone to interference if the cell is congested. If the operator chooses to use inner
zone resources whenever a MS is qualified, regardless of outer usage, the database
parameter outer_zone_usage_level can be set to 0. The tch resources in the outer
zone must be greater than outer_zone_usage_level for this feature to operate.
outer_zone_usage_level
Valid Range 0 to 100 (Indicating the percentage of outer zone TCH usage)
Default = 0
Flow Control
The traffic channel flow control, congestion relief, and dynamic reconfiguration features,
use the traffic channel’s usage in the outer zone ONLY to determine of the cell is
congested. Congestion relief procedures only initiate handovers for calls in the outer
zone. To avoid barring of access classes prior to using the inner zone resources, the
outer_zone_usage_level should be set to a lower value than both the
normal_overload_threshold and the critical_overload_threshold used by the CRM
flow control feature.
intra_cell_handover_allowed
The BSS does not consider the intra_cell_handover_allowed flag when initiating
inter–zone handovers. Inter–zone handovers can be enabled or disabled separately
using the database parameters included with the implementation of this feature. If a
zone handover attempt into the inner zone fails due to congestion (that is, no inner zone
resource available) and the call qualifies for an interference handover, the call will not
handover due to interference if the intra_cell_handover_allowed flag is disabled.
Emergency call pre–emption

The BSS selects a call from the outer zone to be pre–empted for the emergency call
pre–emption procedure.
Immediate Assignments
The BSS always selects an outer zone channel for an Immediate Assignment, even if a
traffic channel is allocated. If there are no resources available in the outer zone, the BSS
sends an Immediate Assignment Reject.

Version 1 Rev 1 Concentric Cells – Channel Allocation Rules
Concentric Cells – Channel Allocation Rules
S outer_zone_usage_level 0 to 100%
% TCH Congestion in outer zone before
handover to inner zone allowed
S Flow Control, Congestion Relief, Dynamic Channel

Reconfiguration all happen in outer zone only
S Intra_cell_handover_allowed parameter irrelevant for

inter–zone handovers
S option_emergency_preempt always pre–empts an outer

zone call
S All Immediate Assignments in outer zone

Concentric Cells – Channel Allocation Rules Version 1 Rev 1

Chapter 4
Multiband Operation

Version 1 Rev 1

Version 1 Rev 1
Chapter 4
Multiband Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Multiband Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–1
Multiband Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–6
Enhanced SDCCH to TCH (preferred band) Assignment . . . . . . . . . . . . . . . . . . . . . . . . . 4–8
Multiband Neighbour Measurement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–10
MSC Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–12
ALM for EGSM Carriers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
EGSM Layer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
Database parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
Neighbour Re–ordering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–14
ALM for EGSM Carriers Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–16
Coincident Multiband Handover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Feature objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Cell Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–20
Configuring Coincident Multiband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–22
Coincident Multiband External Neighbour Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–24
Feature Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–26
Feature Overview (Continued) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–28
Frequency Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Primary Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Secondary band . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Dependancies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–30
Modification Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
inner_zone_alg <value>cell=<cell_desc> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Equipping DRI and RTF groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Outer zone usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–32
Dual band Inner Zone use Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34
Propagation Differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34
Power losses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–34
Dual Band Inner Zone Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–36
Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–38
BTS Power Control on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
BTS Power Control off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
MS Power Control on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
MS Power Control off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40
Handovers to n/bours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–40

Version 1 Rev 1
Enabling the Dual Band Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42

Multiband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42
Power Budget Calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Power Budget Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Handover Power Level Inner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Transmit Power Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
Dependancies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–46
EGSM Layer Management Within a Dualband Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–48
Ping–Pong Handover Prevention Between Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–50
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–50
Causes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–50
Controlling the Behaviour of Ping–Pongs Between Zones . . . . . . . . . . . . . . . . . . . . . . . . 4–52
Description of the reasons to introduce this feature . . . . . . . . . . . . . . . . . . . . . . . . 4–54
Description of IMRM functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–56
Intelligent Multilayer Resource Management – PCPB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–58
Per Call Preferred Band (PCPB) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–58
When PCPB is set . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–58
IMRM – Forced Recalculation of PCPB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–60
General Call Handling for an IMRM Cell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–62
Building the Handover Candidate List . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–62
Intelligent Multilayer Resource Management – 2G to 3G Handover . . . . . . . . . . . . . . . . 4–64
2G – 3G Handover Implications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–64
Interactions with SERVICE HANDOVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–64
Interactions with UMTS band preferred flag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–64
IMRM – Database Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–66
IMRM – Database Parameters Continued . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–68

Version 1 Rev 1 Multiband Operation
Multiband Operation
Objectives
S Describe the ALM features
S Describe Co–incident multiband feature
S Describe Single BCCH feature
S Describe Intelligent Multilayer Resource Management

Multiband Inter–cell Handover Version 1 Rev 1
Multiband Inter–cell Handover

Multiband inter–cell handover is an optional feature which allows a single Network
Operator with licences in multiple frequency bands (GSM 850, GSM 900, DCS 1800,
PCS 1900) to support the use of multiband mobiles. By supporting transparent
handovers between bands, Multiband inter–cell handover allows seamless operation of
the mobile in a multiband environment. This feature includes the following:
S Multiband support at site level. (BTS site with GSM 850, GSM 900, DCS1800 and
PCS 1900 in homogeneous cabinets).
S Multiband Inter–cell handovers.
S Unique Traffic Management in a multiband network using Advanced Load
Management.
A multiband network can be either single or multi–layer. So, for example, GSM 900
macro cells can operate alongside DCS 1800 macro cells. Alternatively DCS 1800 micro
cells could, for example, underlay GSM 900 macro cells.
All handovers between bands are inter cell and with the introduction of Single BCCH
intra–cell handovers are now supported, also the normal intra–cell handovers between
GSM and EGSM channels.
Frequency hopping is still supported as before, that is that a mobile can hop within its
own band. Hopping between bands is not supported.

Version 1 Rev 1 Multiband Inter–cell Handover
Multiband Inter–cell Handover
Sufficient
GSM 850
Multiband
Mobiles needed
GSM 900 GSM 900
DCS 1800
GSM 900 DCS 1800
Inter – Cell
GSM 900 GSM 900 Supported
GSM 900 GSM 900
DCS 1800 DCS 1800 DCS 1800 DCS 1800
EGSM
GSM 900 Intra – Cell
supported with
DCS 1800
Single BCCH for
dual Band Cells
GSM 900 GSM 900
Feature
DCS 1800
DCS 1800 DCS 1800
Frequency Hopping
PCS 1900 supported within
Bands
SYS12_Ch05_18

Multiband Inter–cell Handover Version 1 Rev 1
Multiband Database Parameters

In order to enable the multiband feature and all its functionality, the parameter
mb_preference is used.
chg_element mb_preference < * > location
<*>
0= multiband handovers disabled
1= multiband handovers enabled

Once this is done, the BSS will take notice of the add_cell prompt frequency_type,
which sets the frequency band for the cell.
frequency_type (add_cell prompt)
1 or PGSM
2 or EGSM
4 or DCS 1800
8 or PCS 1900
16 or GSM 850
After a call is set up on a particular cell of course a handover may become necessary. It
is possible to specify, for each cell, the frequency band(s) of the target cell for any
handover that is made out of that cell. This is done by the interband_ho_allowed
parameter.
The system then chooses a particular band from within the interband_ho_allowed
selection based on the preference set by subsequent parameters.
chg_element interband_ho_allowed < * > <cell_desc>
<*> 1 2 3 4 5 6 7 8 9 10 11
PGSM y X y X y X y X y X y
EGSM X y y X X y y X X y y
DCS 1800 X X X y y y y X X X X
PCS 1900 X X X X X X X y y y y
Check W23 for GSM 850 values.

Version 1 Rev 1 Multiband Inter–cell Handover
GSM 900 DCS 1800
mb_preference 1 <location>
frequency_type = 1
interband_ho_allowed 5 <cel_desc>
SYS12_Ch05_19

Multiband Database Parameters Version 1 Rev 1

Having set the frequency bands to which a call in the cell can handover
(interband_ho_allowed) it is possible to specify a preference for a particular one. For
example, if interband_ho_allowed= 1 then a call could handover to a PGSM, EGSM or
PCS1900 neighbour cell; it may be useful to try to hand most calls over to the PCS 1900
in a multilayer system. A preference for a particular band is set by the band_preference
parameter. It is not, however, certain that all handovers out of this cell will always go to
the preferred band, this depending upon another parameter, band_preference_mode.
This parameter can cause the BSS to ignore the band_preference setting, or to take it
into account when ordering target neighbour cells for inclusion in the
handover_recognised message.
The band_preference parameter displays the frequency bands that the cell prefers to
use for handovers and specifies the destination frequency band for inter–cell handovers.
Valid range
1 (PGSM),
2 (EGSM),
4 (DCS1800),
8 (PCS1900)
16 (GSM850)
Default value The frequency type of the cell (as set by frequency_type).
The band_preference_mode parameter specifies the method the system uses to

program a Multiband MS with the preferred frequency band for a given cell in the BSS.
0. The BSS attempts to hand a Multiband MS over to the strongest neighbour that
the MS reported when a handover is required for normal radio resource reasons.
1. The BSS attempts to assign a Multiband MS to the strongest preferred band

neighbour that the MS reported at the time of SDCCH to TCH assignment. If the
BSS cannot assign a preferred band TCH the BSS will not try to direct this MS to
the preferred band for the life of the current call connection. The BSS always
hands the MS over to the strongest MS–reported neighbour when a handover is
required for normal radio resource reasons.
2. The BSS attempts to hand a Multiband MS over to the strongest preferred band
neighbour that the MS reported when a handover is required for normal radio
resource reasons. The BSS places preferred band neighbours ahead of
non–preferred band neighbours in order to attempt to assign a channel from the
preferred band for the MS.
3. This value combines the functions of values 1 and 2.
4. The BSS continually attempts to hand a Multiband MS over to a preferred band

TCH immediately after initial assignment. The BSS will not attempt to allocate a
TCH in the preferred band for this MS at the time of SDCCH–to–TCH assignment.
The BSS will enter a mode of continually monitoring for qualified preferred–band
neighbours reported by the MS in order to hand the MS over. The BSS will stay in
this mode until it finds a neighbour TCH in the preferred band for the current
serving cell. Handovers for normal radio resource reasons may occur during the
monitoring mode, and these handovers will be to the strongest preferred band
neighbour reported by the MS.
5. This value combines the functions of values 1, 2, and 4.
6. This value functions identically to value 5, except it is only triggered when the cell
is congested.

Version 1 Rev 1 Multiband Database Parameters
band_preference = 4
MS has received SDCCH
and is waiting for TCH
band_preference_mode = 1
(Chooses strongest preferred DCS 1800

band neighbour if possible, does
not attempt to direct to preferred
band during duration of call)
PGSM
band_preference_mode = 4 PGSM
Strongest
Overall
Immediately after initial
assignment, BSS constantly monitors for
a qualified preferred band neighbour) PGSM
Serving
MS needs to handover for normal

DCS1800
radio reasons DCS 1800
band_preference_mode = 0 Strongest
(Handover to strongest neighbour)

band_preference_mode = 2 PGSM
(Handover to strongest preferred band neighbour)
band_preference_mode = 3 band_preference_mode = 5 band_preference_mode = 6
(Combines 1 and 2) (Combines 1, 2 and 4) (Combines 1, 2 and 4 but triggered for
congestion reasons)
sys12_ch06_18

Enhanced SDCCH to TCH (preferred band) Assignment Version 1 Rev 1
Enhanced SDCCH to TCH (preferred band) Assignment

In the case of values 1, 3, 5 and 6, it has been found that the MS does not report on
neighbour cells from other frequency bands fast enough to allow the TCH assignment to
the preferred band neighbour cell. A feature released in GSR 5.0 makes an allowance
for this. The parameter works by specifying the number of measurement reports that the
RSS waits before responding to the CRM if the MS does not report a preferred band
neighbour.
sdcch_tch_band_reassign_delay
Valid Range 0 to 4 (SACCH multiframes)
Use of this parameter may cause a delay of up to two seconds.

Version 1 Rev 1 Enhanced SDCCH to TCH (preferred band) Assignment
Enhanced SDCCH to TCH (preferred band) Assignment
S The parameter works by specifying the number of measurement

reports that the RSS waits before responding to the CRM if the
MS has not reported a preferred band neighbour
S This is needed to allow time for the MS to report neighbour cells

from other frequency bands
S sdcch_tch_band_reassign_delay
Valid Range 0 to 4 (SACCH multiframes)
Use of this parameter may cause a delay of up to two seconds

Multiband Neighbour Measurement Version 1 Rev 1
Multiband Neighbour Measurement

Multiband mobiles of course produce measurement reports relating to the serving cell
and the best six neighbours when in dedicated mode, just as single band mobiles do.
However, to ensure an equal chance of selecting each bands target cells, it is possible to
“reserve” some of the six positions for neighbours in a measurement report for each
available band. This is done via the multiband_reporting database parameter.
multiband_reporting<element_value><location><cell_number>
Value type Integer
Valid range 0 to 3
0. Normal reporting of the six strongest neighbour cells with known and allowed NCC
part of the BSIC, irrespective of the band used.
1. Report the strongest neighbour cell, with known and allowed NCC part of BSIC, in
each of the frequency bands in the neighbour cell list, excluding the frequency
band of the serving cell. The remaining positions in the measurement report shall
be used for reporting Cells in the band of the serving Cell. Any still remaining
positions will be used to report the next strongest identified neighbours in other
bands irrespective of the band used.
2. Report the two strongest cells, with known and allowed NCC part of BSIC, in each
of the frequency bands in the neighbour cell list, excluding the frequency band of
the serving cell. The remaining positions in the measurement report shall be used
for reporting Cells in the band of the serving Cell. Any still remaining positions will
be used to report the next strongest identified neighbours in other bands
irrespective of the band used.
3. Report the three strongest cells, with known and allowed NCC part of BSIC, in
each of the frequency bands in the neighbour cell list, excluding the frequency
band of the serving cell. The remaining positions in the measurement report shall
be used for reporting Cells in the band of the serving Cell. Any still remaining
positions will be used to report the next strongest identified neighbours in other
bands irrespective of the band used.
Default value 0

Version 1 Rev 1 Multiband Neighbour Measurement
Multiband Neighbour Measurements

Example:
multiband_reporting 3 <location> <cell_number>
Neighbour List DCS 1800
Three strongest neighbours from n1

bands other than the serving cell
PGSM PGSM
n1, n3 and n5
n6
n2
PGSM
Then the next three neighbours from the Serving
band of the serving cell
DCS1800
n2, n4 and n6 DCS 1800
n5
n3
Any remaining positions taken by PGSM

neighbours from any band regardless of
n4
band used
SYS12_Ch05_21

MSC Requirements Version 1 Rev 1
MSC Requirements
The MSC can support BSS equipment from different vendor for each frequency band.
This provides the operator the ability to distribute the changes required for Multiband
operation
To have a working dualband capability in the network, some MSC requirements apply.
The MSC needs to have the capability to handle Classmark 3 (CM3) information
element. CM3 information is sent by multiband mobile to MSC contains info of multiband
capabilities and the MS power classes in the different bands. The CM3 info then is stored
in the MSC for the duration of the call. In case the mobile is required to perform a
multiband handover, the CM3 info must be transmitted to the target BSS, which informs
the new BSS about the multiband capabilities of the mobile.
If a handover becomes necessary in a multiband environment, the network must of
course know the frequency band capabilities of the mobile so that a PGSM mobile is not
handed over to a DCS 1800 cell for example.
In internal handovers this discrimination is handled by the BSC as part of its normal
handover control function, but in external handovers the target BSC must be told the
mobile’s capabilites. Moreover, the MSC must know the mobile’s capabilities in case this
affects its choice of BSC; in a multilayer configuration each layer could be controlled by a
different BSC.
There are 3 GSM–defined messages for informing the network of the mobile’s
capabilities
Classmark 1 Classmark 2 Classmark 3

Phase of MS Phase of MS PGSM/EGSM/DC S 1800
Early classmark sending Early classmark sending support
enabled enabled A4/5/6/7 support
A5/1 support A5/1/2/3 support Power class
Power Class Power Class
Synchronization
Supplementary Services
SMS support
EGSM support
Classmark 3 support
Classmark 3 is the important message in multiband, but is normally only sent by the
mobile when interrogated by the MSC. In order to save time it is possible to send
classmark 3 spontaneously using the parameters opposite. This will happen within 40ms
if the initial layer 3 message at call setup unless specified otherwise, and is
communicated to the target BSC of an external handover in the handover request
message.

Version 1 Rev 1 MSC Requirements
Classmark of Mobile
S chg_element early_classmark_sending <*>0
<*> 0= disabled
1= enabled on A–interface, disabled on air interface
2= disabled on A–interface, enabled on air interface
3= enabled on A–interface and air interface
Def = 0
S chg_element early_classmark_delay <*>0
<*> 0 to 100,000 ms
S Def = 0

ALM for EGSM Carriers Version 1 Rev 1
ALM for EGSM Carriers
EGSM Layer Management

In a predominantly PGSM and DCS1800 multiband network, there are problems with
utilization of the EGSM frequencies. This is because of the interaction with the multiband
handover feature. The multiband handover feature uses two database parameters
band_preference and band_preference_mode. If for example band_preference was
set to DCS1800 and band_preference_mode = 4, meaning on trigger of a normal
handover try to direct the call to the preferred band. Then if an EGSM capable MS
established on a PGSM cell with EGSM capabilities, if there are idle EGSM TCH
capacity the MS will be assigned to the EGSM TCH resource. But when a handover is
triggered due to RF reasons (better cell etc) the MS will be targeted to the DCS1800
band, because it is the preferred band. Consequently EGSM resources are under
used.The re–ordering of candidate neighbour cells when a handover is triggered depends
on the MS being EGSM capable and the MS having established on a EGSM resource. It
does not operate with the co–incident multiband feature and cannot support external
handovers to EGSM neighbours. It does not operate with EGSM BCCH frequencies or
support hopping through EGSM frequencies within PGSM/EGSM cell.
Database parameters
chg_element bss_egsm_alm_allowed <*><location> (BSS only)
<*>
0 = EGSM ALM feature disabled 1 = EGSM ALM feature enabled
Neighbour Re–ordering
If we take the case of band_preference_mode = 4, the RSS process orders the
neighbours into two distinct groups before reporting them to the CP process. These
groups are preferred band neighbours and non–preferred band neighbours. If the MS is
EGSM capable and it is currently established on an EGSM TCH channel. The
non–preferred band neighbours (in this case PGSM) will be checked to see if they have
any EGSM resources. If a neighbour does have EGSM resources, it will be placed at the
head of the list as the highest priority neighbour.

Version 1 Rev 1 ALM for EGSM Carriers
ALM for EGSM Carriers
Preferred band
neighbour (DCS1800)
Preferred
Non – Preferred
neighbour (PGSM)
Non – Preferred
Non – Preferred
neighbour (PGSM/EGSM)
Candidate neighbours reported from RSS
chg_element bss_egsm_alm_allowed 1 <location>
Non – Preferred band (PGSM/EGSM)
Preferred band (DCS1800)
Non – Preferred band (PGSM)
Candidate neighbours sorted by CP
sys12_05_alm1

ALM for EGSM Carriers Examples Version 1 Rev 1
ALM for EGSM Carriers Examples
Example 1
EGSM Capable MS Establishes on a PGSM Resource
In this case the database parameters band_preference and band_preference_mode
will direct the call to the preferred band. For instance if an EGSM capable MS establishes
on a PGSM TCH resource and a handover is triggered. If band_preference = DCS1800
and band_preference_mode = 4, then when the next handover is triggered the MS will
be directed to the DCS1800 layer. Once on the DCS1800 layer the MS will continue to be
directed to the DCS1800 layer. If at any time the MS is handed into a PGSM/EGSM cell,
if EGSM TCH resources are available, will be granted an EGSM resource.
Example 2
EGSM Capable MS Establishes on a EGSM Resource
Before this feature the MS would have been directed to a DCS1800 resource on
handover. To make better use of the EGSM resources the candidate neighbour cells are
manipulated so that any PGSM neighbour with EGSM capabilities is preferred. If the
handover to the PGSM/EGSM cell results in the MS being assigned to a PGSM
resource. The BSS will revert to directing the MS to the preferred band in this case
DCS1800.
If the handover fails to the PGSM/EGSM neighbour due to no resources, then the BSS
attempts to target the MS to the next neighbour which may be a PGSM/EGSM,
DCS1800 or PGSM cell. Once the MS is directed to the DCS1800 layer, it will continue to
be directed to the DCS1800 layer as directed by band_preference and
band_preference_mode.

Version 1 Rev 1 ALM for EGSM Carriers Examples
ALM for EGSM Carriers Example 1
EGSM capable MS establishes on a PGSM TCH resource
DCS1800 DCS1800
PGSM/EGSM PGSM/EGSM
EGSM MS on PGSM TCH
If on PGSM resource will be directed by band_preference and band _preference_mode
band_preference = DCS1800 band_preference_mode = 4
If a handover occurs to a PGSM/EGSM neighbour and there are no EGSM resources
On the next handover the MS will be directed to the DCS1800 layer

ALM for EGSM Carriers Examples Version 1 Rev 1

Version 1 Rev 1 ALM for EGSM Carriers Examples
ALM for EGSM Carriers Example 2
EGSM capable MS establishes on a EGSM TCH resource
DCS1800
DCS1800
PGSM/EGSM
PGSM/EGSM
EGSM MS on EGSM TCH
If on EGSM resource will not be directed by band_preference and band_preference_mode

if there are EGSM neighbours
If there are no PGSM/EGSM resources the BSS attempts to target the MS to the next
neighbour which could be (in order) PGSM/EGSM , DCS1800 or PGSM
If a handover occurs to a PGSM/EGSM neighbour and there are no EGSM resources and
the MS is assigned to a PGSM resource, then the MS will be directed to DCS1800 layer
On the next handover the MS will be directed to the DCS1800 layer and once on the
DCS1800 layer will directed to DCS1800 neighbours
Diagran Number

Coincident Multiband Handover Version 1 Rev 1
Coincident Multiband Handover

This feature enables operators to install new radios in a different frequency band. This
installation will turn an operator’s network into a multiband network. One obstacle to this
type of upgrade is the investment in time and money already made by the operator in
optimising the existing network. With the addition of a secondary network, with different
propagation characteristics, this optimisation effort would have to be repeated. This can
deter some operators, who want the extra capacity, from installing a multiband network.
To avoid this problem of optimising two networks, it is logical that the new secondary
network should complement the existing infrastructure. To achieve this, the software
must be configurable enough to allow the new network to use the same cell boundaries
established by the original network. This can be done by using mobile–reported
measurement reports of the primary network while established on the secondary
network. This allows the mobile to be handled as if it were on the primary network, using
the primary’s boundaries and minimizing propagation characteristics differences, whilst
not taking any primary network resources.
This feature is designed to complement the Multiband feature and the functionality
described here is only available if that feature is enabled.
Feature objectives
This feature has two main objectives:
S To ensure that the specific DCS 1800 cell will only unload the traffic from its
coincident GSM cell and not take traffic away from surrounding GSM cells. This is
achieved by defining the DCS cell boundaries by the underlying GSM cell
boundaries.
S To maintain the quality in the GSM network and only have one network to optimise.
This is achieved by having the same handover boundaries between the GSM and
DCS cells.
Cell Definitions
Coincident Cell
A cell that has a co–located neighbour cell whose cell boundary follows that of the said
cell, but has a different frequency type to that of the neighbour cell. The coincident cell
has only one GSM1800 neighbour, which is collocated.
Primary Cell
A cell (GSM900), that is already optimised in the network and has a co–located
neighbour, whose cell boundary follows that boundary of the said cell. The primary cell
has a preferred band equal to the frequency type of the coincident cell (GSM1800). If no
coincident GSM1800 cell exists, then no GSM1800 neighbours are defined.
Secondary Cell
A cell, which is not optimised and has a co–located neighbour whose cell boundary
follows the boundary of the said cell. The secondary cell has a preferred band the same
as that of its own frequency type (GSM1800). The co–located GSM1800 cell has all the
same GSM900 neighbours, as does the GSM900 cell, in addition to the co–located
GSM900 (coincident) cell itself. In addition to the GSM900 cells, the GSM1800 cell may
have other GSM1800 neighbours.
This feature will not affect normal multiband handovers to a preferred band.

Version 1 Rev 1 Coincident Multiband Handover
Coincident Multiband Handover
One way neighbour

To increase capacity cell
Optional two way A and C is added to cover
neighbour the same area as cell B
and C
Two way neighbour
Secondary C Secondary A
Coincident neighbour
Primary C Primary B D
Primary
These cells are optimised and power budget handovers can occur
B & D also C & B are neighbours of each other
All belong to the same frequency band
sys12_ch06_22

Configuring Coincident Multiband Version 1 Rev 1
Configuring Coincident Multiband

chg_element coincident_mb <value> <location> cell=<cell_desc>
Value (valid range):
0. Coincident Multiband is disabled
1. Coincident Multiband utilises better cell detection
2. Coincident Multiband utilises coincident cell redirection
Prompts for : S GSM cell id of the host cell
S coincident_offset –63 to 63
S low_signal_thres 0 to 63
The BSS will use an additional offset to the power budget equation when the neighbour being used for
downlink measurements (GSM900) is not reported. If the MS is on a TCH on cell A (DCS1800) and
downlink measurements for cell B (GSM900) were not being reported, then the serving cell’s
measurements would be used in the power budget equation with addition of the offset.
When a handover condition is present to a neighbour with a coincident preferred band cell, the MS
supports multiple frequency bands and the MS reported receive level of the target cell is above the
threshold defined by this parameter; the BSS will attempt to hand the MS directly to the coincident
preferred band cell. This functionality is only used if coincident_mb is set to 2 and is set in both
directions (both cells have to be coincident to each other).
Example
In the case shown opposite, Cell A and Cell B are co–located coincident neighbours of each other.
Cell B is part of the GSM900 network, while Cell A has been added and is part of the, secondary,
GSM1800 network.
Assume that a mobile was using a traffic channel on cell A (DCS1800). The MS would be measuring
the strength of Cell B and Cell D (GSM900 – because they are defined in the neighbour database).
When Cell A receives the measurement report from the MS, in a coincident cell, the BSS uses the
measurement level of Cell B as the downlink measurement, instead of using the downlink receive
level of Cell A to make a decision as to whether a handover is needed. This is done because the
propagation characteristics of the two cells can vary. The BSS uses the signal strength reports of Cell
D from the mobile to determine whether there are any viable candidates for the needed handover
(PBGT calculations). If Cell B was not decoded as a neighbour then coincident_offset is applied to
the pbgt calculation to compensate for the lower propagation characteristics of the DCS1800 Cell.
If C (DCS1800) was also a neighbour of A, the downlink receive level of cell A will be used in the
serving cell power budget calculations as it is in the same frequency band.
Coincident Cell Redirection

This is the enhanced functionality of handing over to an unreported neighbour. If the BSS decides that
Cell E (GSM900) is a viable candidate for handover for a MS occupying a traffic channel on Cell A
(DCS1800), the BSS will detect that Cell F (DCS1800) is a coincident cell of Cell E, and will redirect
the handovers to Cell F as long as the rxlev of Cell E is detected as being above low_signal_thres.
The value of low_signal _thres is set at a level which takes into account the difference in rxlev
between the GSM900 cell and its DCS1800 co–incident neighbour.
The co–located coincident cells (GSM900 and DCS1800) must be synchronised in order to perform a
handover to an unreported neighbour; therefore the cells must be located at the same site. They also
have to use the same BSIC to have successful communication upon handover (this requirement only
applies if coincident_mb is set to 2).
The cells must be synchronised because the Handover Command sent to the MS has the cell E
(GSM900) cell description (the cell the MS was reporting on in the measurement reports), but the cell
F (DCS1800) channel description. If the cells are not synchronised the handover will fail.
The Handover Access burst is encoded using the BSIC of the target cell – cell E (GSM900) and thus
cell F must have the same value in order to successfully decode the message.

Version 1 Rev 1 Configuring Coincident Multiband
Configuring Coincident Multiband
Cell F Cell A Cell C
DCS1800 DCS1800 DCS1800
Cell E Cell B Cell D
PGSM PGSM PGSM
coincident_mb =2 for both cells coincident_mb = 1 for cells A,C,B and D

E and F
Optionally A and C can be neighbours
BSIC same for E and F
Sync handovers enabled
Or they are not and coincident_offset
between cells F and E used to compensate for the lower
band_preference =4 for cell E signal strength of the DCS 1800 cell.
This offset is added to the ho_margin
PBGT handover to cell F when
measured rxlev above
low_signal_thres

Coincident Multiband External Neighbour Enhancements Version 1 Rev 1
Coincident Multiband External Neighbour Enhancements

Prior to GSR6 problems were encountered when an external handover occurred between
cells with coincident neighbours with coincident_mb = 2. This was because the criteria
for a seamless redirected handover to the secondary DCS1800 cell is based upon the
rxlev of the primary GSM900 neighbour cell being above low_signal_thres. In the case
of an external neighbour the result of this calculation would never be used as it is made
in the source BSC. Hence mobiles were being redirected to the secondary DCS1800 cell
incorrectly and causing bad quality in the network. The solution is to offer a new
coincident multiband option of 3.
Operation
chg_element coincident_mb <value> <location> cell=<cell_desc>
value = 3 Internal cells uses coincident_mb = 2
External cells uses coincident_mb = 1

For the example on the opposite page we have a coincident cells on the border of two
BSCs A and B. For these cells we have set coincident_mb = 3. If a handover from a
secondary DCS1800 cell occurs internally then the redirected handover can occur in the
normal way by coincident_mb = 2 and coincident_offset as the calculation of
low_signal_thres can be made within the same BSC and the correct decision can be
made whether to redirect or not. However if the handover from a secondary DCS1800
cell is external then it uses coincident_mb = 1 so better cell detection is used based
upon coincident_offset. If however the actual cell size was the same for the GSM900
and DCS1800 coincident cells then calculation of low_signal_thres is no longer of
consequence and the border cells can be set at coincident_mb = 2.

Version 1 Rev 1 Coincident Multiband External Neighbour Enhancements
Coincident Multiband External Neighbour Enhancements
BSC A BSC B
Cell
Cell F Cell
Cell A Cell
Cell C
DCS1800
DCS1800 DCS1800
DCS1800 DCS1800
DCS1800
Cell
Cell E Cell
Cell B Cell
Cell D
PGSM PGSM PGSM
coincident_mb =3 for cells F and E coincident_mb = 3 for cells A and B
BSIC same for E and F + Sync handovers BSIC same for A and B + Sync handovers
For external neighbours uses coincident_mb = 2 for cells C and D

coincident_mb = 1
BSIC same for C and D + Sync handovers
For internal handovers uses same as

coincident_mb = 2
SYS03_ch05_coinenh

Single BCCH for Dual Band Cells Version 1 Rev 1
Single BCCH for Dual Band Cells

This is a feature developed in GSR 5 software release. GSM specifications allow the use
of a common BCCH for different bands of operation when resources across all bands are
co–located and synchronised. With this feature it is possible for carriers within a cell to be
configured in different frequency bands.
Feature Overview
Restricted Features
The following restricted features need to be enabled
Dual Band Cells
Concentric Cells
Multiband Handovers
Homogeneous Cabinet (Cabinets at a site can be of different frequency types)
Heterogeneous Cabinet (Cabinets are able to support multiple frequency types and is
required for combined cabinet configurations only)
Frequency Hopping
Because Frequency Hopping between different bands in not allowed per GSM
specifications, the dual band cells feature only supports frequency hopping that are
defined to contain frequencies from a single frequency band. In a dual band cell the
hopping systems may contain either primary or secondary band frequencies, but not a
combination of both.

Version 1 Rev 1 Single BCCH for Dual Band Cells
n Restricted Features
S Dual Band Cells

S Concentric Cells
S Multiband Handovers
S Homogenous Cabinet
S Heterogenous Cabinet
n Frequency Hopping

Single BCCH for Dual Band Cells Version 1 Rev 1
Feature Overview (Continued)

The single BCCH for dual band cells provides the capability to configure and manage
cells with carriers from different frequency bands by using the concentric cells
configuration.
S Primary band carriers are configured in the outer zone, to provide total cell
coverage
S To be consistent with the concentric cells feature the BCCH and SDCCHs must be
in the primary band, along with any other non–BCCH carriers of the same band
S Secondary band carriers are configured in the inner zone and these contain the
remaining non–BCCH carriers. In effect the inner zone coverage could be the
same as the outer zone
S For this feature to operate efficiently the operator would need a subscriber base
populated with a sufficient number of multiband capable mobiles
S The feature benefits operators by providing a convenient way of expanding system
capacity by utilizing frequencies from the secondary band provided a sufficient
multiband capable subscriber population exists
S This strategy enables system capacity to be increased without modifying the
frequency plan.
S Or, the neighbour list

Version 1 Rev 1 Single BCCH for Dual Band Cells
S System Expansion Primary Band

Outer Zone
Contains BCCH carrier, SDDCCH’s

and any optional non – BCCH
carriers
Secondary Band
S No need to modify Sufficient number of
frequency plan Inner Zone multiband mobiles
D
Remaining non –
BCCH carriers
S No need to modify
associated
neighbour lists
SYS12_Ch05_24

Frequency Types Version 1 Rev 1
Frequency Types
Two different frequency types at cell level can be configured, these can be a combination
of PGSM, EGSM, DCS1800 or GSM850. Any of these bands can be assigned as the
primary band for the cell.
Primary Band
The primary band is set using frequency_type, to add or change a frequency type, add
cell or change cell element is used.
Secondary band
The secondary band is set using secondary_freq_type database parameter. This is
prompted after the inner zone algorithm has been set to 3 to enable the dual band cells
feature, or can be modified using the change cell element command.
Dependancies
S If the primary cell frequency type is DCS1800 the secondary frequency type can
either be PGSM, EGSM or GSM850
S If the primary cell frequency type is PGSM or EGSM the secondary frequency type
must be DCS1800 or GSM850
S Cell and cabinet frequency types must be allowed at the BSS as per the
frequency_types_allowed command

Version 1 Rev 1 Frequency Types
Frequency Types
S Primary band set by frequency_type

Primary Band
S Secondary band set by:
PGSM
secondary_freq_type
Range 1 PGSM
2 EGSM DCS1800
EGSM
4 DCS1800
16 GSM850
PGSM DCS1800
S frequency_type = DCS1800 DCS1800
S secondary_freq_type = PGSM Secondary Band
DCS1800
or EGSM
EGSM
S frequency_type = PGSM or EGSM

S secondary_freq_type = DCS1800
S frequency_types_allowed
SYS12_Ch05_25

Modification Overview Version 1 Rev 1
Modification Overview
inner_zone_alg <value>cell=<cell_desc>
The procedure to establish a dual band cell configuration begins with modifying the inner
zone algorithm element for the new dual band cell. This is accomplished by using a value
of 3.
Once this value is entered the following secondary band parameters are prompted:
S Frequency Type of the secondary band
S BTS maximum transmit power level
S MS maximum transmit power level
S Handover power level
S Handover hysteresis
S Downlink receive level threshold
S Uplink receive level threshold
S Dual band offset
S Power budget mode
S These parameters are explained fully later.
Equipping DRI and RTF groups

With dual band cells it is necessary to equip DRI and RTF groups per cell since the
frequency type of the RTF must match the radio equipment tied to the DRI. There must
be different DRI and RTF groups associated with the primary band and the secondary
band of a dual band cell. Secondary band carriers must be equipped as inner zone
carriers.
Outer zone usage

At this point the operator must indicate the percentage of outer zone traffic channels that
need to be in use prior to the assignment of secondary band channels. This is set by
outer_zone_usage_level database parameter.

Version 1 Rev 1 Modification Overview
Modification Overview
S inner_zone_alg <value> cell = <cell_desc>

S Where value 3 = dual band cell in use
– Frequency type of the secondary band
– BTS maximum transmit power level
– MS maximum transmit power level
– Handover power level
– Handover hysteresis
– Downlink receive level threshold
– Uplink receive level threshold
– Dual band offset
– Power budget mode
S DRIs and RTFs for the secondary band must be equipped
– outer_zone_usage_level

Dual band Inner Zone use Algorithms Version 1 Rev 1
Dual band Inner Zone use Algorithms

The dual band inner zone use algorithm differs from the power based use algorithm in a
number of ways. Rather than defining the maximum transmit power for the inner zone on
a per carrier basis the inner zone use algorithm defines the maximum transmit power as
one value applied to all secondary band carriers.
Propagation Differences
In order to account for propagation differences between bands and allow secondary band
carriers to provide total cell coverage, the inner zone use algorithm allows the maximum
transmit power level of secondary band carriers to exceed the maximum transmit power
level of the primary band.
Power losses
Unlike the power based algorithm which uses the power level at the radio as a reference
point and assumes a consistent degradation of the signal for all carriers in the cell from
that point on , the inner zone use algorithm must consider other factors when comparing
signal strengths from different frequency bands to accurately determine whether a mobile
can be served by a secondary band channel. These factors are:
S Due to different level of combining the loss of power between the radio unit and the
top of the antenna may not be consistent across all radio units within the cell. The
power difference is calculated by subtracting the secondary band power loss from
the primary band power loss.
S Due to the radio frequency propagation being weaker at 1800 MHz than at 900
MHz, propagation loss over the air interface has got to be taken into consideration.
S These factors are accounted for in the database parameter
dual_band_offset = <*>
Range = –63 to 63

Version 1 Rev 1 Dual band Inner Zone use Algorithms
Dual band Inner Zone use Algorithms
S Max transmit power same for all secondary

carriers Primary Band
Max power
S Max transmit power of secondary primary = 37
can exceed mas trasmit power of dBm
primary
S Radio power level changes
Max power Loss of power
– Power loss from radio secondary = 43 between radio
to top of antenna dBm and top of
antenna
Power D = primary band power loss –
secondary band power loss Secondary Band
RF propagation is
– Propagation loss weaker at
1800MHz than
900MHz
S dual_band_offset = Power D + Propagation D
Range = –63 to 63
SYS12_Ch05_26

Dual Band Inner Zone Algorithms Version 1 Rev 1
Dual Band Inner Zone Algorithms

This section concerns the use of dual band inner zone algorithms.
S Basically inter zone management is provided by the concentric cells feature.
S It uses the power based use algorithm which manages traffic between zones using
algorithms based on uplink and downlink receive levels.
S Also the operator is able to manually set preferences by using the database
element, outer_zone_usage_level. If it is set to 0, channels in the inner zone are
used whenever a mobile is qualified to use those resources. If set from 1 to 100
inner zone resources are allocated only when a mobile is qualified and at least the
specified percentage of outer zone traffic channels are in use.
S Traffic between frequency bands of different cells is currently managed by the
multiband feature. To achieve a satisfactory algorithm for inter–zone traffic
management, with dual band cells, the concentric cells power based use algorithm
is enhanced with multiband features inter–band traffic management shifted from
inter–cell to intra–cell level.

Version 1 Rev 1 Dual Band Inner Zone Algorithms
Dual Band Inner Zone Use Algorithms
S Concentric Cells
Primary Band
S Uplink and downlink receive levels
Secondary Band
S outer_zone_usage_level = 0 to 100
S Enhanced multiband feature
SYS12_Ch05_27

Dual Band Inner Zone Use Algorithms Version 1 Rev 1

In comparing the receive levels of the outer zone to the inner zone threshold, the inner
zone use algorithm must adjust for values being from two different frequency bands and
convert the primary band receive levels to an estimated value for the secondary band.
This is done using the dual band offset parameter.
RXLEVINNER = RXLEVOUTER + dual_band_offset
This offset is applied to both uplink and downlink receive levels
Algorithms
The calculated receive level inner value is then used in the dual band inner zone
algorithm for both uplink and downlink
RXLEV_DL INNER > rxlev_dl_zone + zone_ho_hyst + (bts_txpwr –
bts_txpwr_max_inner)
RXLEV_UL INNER > rxlev_ul_zone + zone_ho_hyst + (ms_txpwr –
min(ms_txpwr_max_inner,P)
Within this algorithm are database parameters that are set per cell after the
inner_zone_alg = 3 (dual band use)
rxlev_dl/ul_zone = <*> * = Range 0 to 63
zone_ho_hysteresis = <*> * = Range –63 to 63
bts_txpwr_max_inner = <*> * = Range as defined for max_tx_bts (0 to 21)
ms_txpwr_max_inner = <*> * = Range as defined for max_tx_ms (5 to 39 PGSM
and EGSM
0 to 36 DCS 1800)
P = maximum capability of the mobile in the inner zone frequency band.

Version 1 Rev 1 Dual Band Inner Zone Use Algorithms
Dual Band inner Zone Use Algorithms
S RXLEVINNER = RXLEVOUTER + dual_band_offset
S (RXLEV_DLINNER > rxlev_dl_zone + zone_ho_hyst + (bts_txpwr – bts_txpwr_max_inner)
S (RXLEV_ULINNER > rxlev_ul_zone + zone_ho_hyst + (ms_txpwr –

S rxlev_dl/ul_zone Range 0 to 63
S zone_ho_hysteresis Range –63 to 63
S bts_txpwr_max_inner Range as defined for max_tx_bts (0 to 21)
S ms_txpwr_max_inner Range as defined for max_tx_ms (5 to 39 PGSM and

EGSM 0 to 36 DCS1800)
S P is the maximum power of MS in inner zone

Dual Band Inner Zone Use Algorithms Version 1 Rev 1

This page deals with the algorithms necessary to handover calls from the secondary
band to either the primary band or a qualified neighbour. The algorithms for uplink and
downlink depend on whether BTS and mobile power control is switched on or off.
BTS Power Control on

rxlev_dl < rxlev_dl_zone and bts_txpwr = bts_txpwr_max_inner
Receive level downlink is less than the receive level threshold and the BTS is at full
power
BTS Power Control off

rxlev_dl < rxlev_dl_zone
Receive level downlink is less than the receive level threshold
MS Power Control on
rxlev_ul < rxlev_ul_zone and ms_txpwr = min(ms_txpwr_max_inner,P)
Receive level uplink is less than the receive level threshold and the mobile is at full power
MS Power Control off

rxlev_ul < rxlev_ul_zone
Handovers to n/bours
The neighbour cells are assessed first to see if they are suitable cells to handover too
pbgt(n) > ho_margin
If any neighbour qualifies, a handover is initiated otherwise the mobile is moved to the
outer zone.

Version 1 Rev 1 Dual Band Inner Zone Use Algorithms
S rxlev_dl < rxlev_dl_zone and bts_txpwr = bts_txpwr_max_inner
S rxlev_dl < rxlev_dl_zone
S rxlev_ul < rxlev_ul_zone & ms_txpwr = min(ms_txpwr_max_inner,P)
S rxlev_ul < rxlev_ul_zone
S pbgt(n) > ho_margin if neighbour qualifies inter–cell handover

S If no neighbour qualifies handover MS to outer zone

Enabling the Dual Band Feature Version 1 Rev 1
Enabling the Dual Band Feature

A resource from either the secondary or primary band of a dual band cell will be allocated
for assignments or handovers provided the necessary criteria is met. These include the
previously discussed restricted features that need to be enabled and the need for the
inner zone algorithm to be set to 3. There are further criteria for enabling the dual band
feature.
Multiband
S The database parameter multiband preference has to be set to 1 to enable the
multiband feature.
mb_preference <value> <location>
Valid Range =
0 multiband feature disabled
1 multiband feature enabled

S The database feature coincident multiband must be set to disabled in order to
change inner zone algorithm to indicate dual band cells. This is because dual
band and coincident multiband cannot be configured simultaneously.
coincident_mb = 0 (disabled)
S The mobile must support the frequency band of the inner zone.
S The database parameter band preference mode must be set to either 1,3,5 or 6
band_preference_mode = 1, 3, 5 or 6
S The parameter interband_ho_allowed defines the frequency types of the BCCH
carrier of target cells that are allowed for intercell handover. If the target cell is a
dual band cell the actual channel assigned by the target cell may be of a frequency
type not specified by interband_ho_allowed as long as the mobile supports that
frequency type.
chg_element interband_ho_allowed <value> <location> cell=<cell_desc>
Valid range
1 to 11 (PGSM, EGSM, DCS1800 and PCS1900)
16 to 27 (The above plus GSM850)

S The percentage of outer zone traffic channel usage meets or exceeds the outer
zone usage level.

Version 1 Rev 1 Enabling the Dual Band Feature
Enabling the Dual Band Feature
S mb_preference <value> <location>

Valid Range = 0 multiband feature disabled
1 multiband feature enabled
Primary Band
S coincident_ mb set to 0 or disabled

Inner zone signal
strength criteria met
S band_preference_mode = 1,3,5
or 6
Secondary Band
S interband _ho_allowed Multiband
mobile
S TCH usage exceeds outer_zone_usage_level
SYS12_Ch05_28

Handover and Power Control Version 1 Rev 1
Handover and Power Control

With the dual band feature it is necessary to perform intra cell handovers both within the
secondary and primary bands as well as between the secondary and primary bands of a
dual band cell. The BSS performs power level conversions during intra cell channel
changes between channels of different frequency bands.
It is also necessary to perform inter–cell handovers from the secondary and primary
bands of a dual band cell as well as to the secondary and primary bands of a dual band
cell.
The power budget equation determines the need for an inter–cell handover by essentially
comparing the serving cell BCCH signal strength to the neighbour cell BCCH signal
strength. This means the signal strength in a dual band cell must come from the primary
zone. When the call is in the secondary zone, the signal strength reported by the mobile
cannot be used in the power budget equation, because frequencies in the secondary
band have a different propagation than frequencies in the primary band.

Version 1 Rev 1 Handover and Power Control
Handover and Power Control
Primary Primary
Band Band
Secondary Secondary
Band
Band
Serving cell Neighbour cell
BCCH BCCH signal
signal Primary strength
strength Band
If call is in the
secondary zone,
signal strength
reported by
Secondary mobile cannot be
used in pbgt
Band
equation
SYS12_Ch05_29

Power Budget Calculation Version 1 Rev 1
Power Budget Mode

There are two ways to obtain the primary zone signal strength, selectable via the
pbgt_mode data base element.
If pdgt_mode = 1
If the mobile is assigned to a resource on the secondary band, the mobile will use the
serving channel measurements and then subtract the dual_band_offset. This estimated
value is then inserted into the power budget equation.
If the pbgt_mode = 0
The serving cell BCCH is included in the ba_sacch neighbour cell list of the serving cell.
The mobile will then report the serving cell signal strength for the primary band, which
can be used in the calculation of power budget for neighbours with the same frequency
band. The actual number of neighbour frequencies that can be reported on is reduced by
one, also the number of true neighbours that the MS can report on is reduced from six to
five. If pbgt_mode = 0 then the server is auto equipped as a neighbour.
Handover Power Level Inner

The database parameter ho_pwr_level_inner specifies the handover power level for the
inner zone. It is set when the inner_zone_alg is set to dual band cell, the BSS then
prompts for the value to be entered. This allows secondary and primary bands to have
different handover power levels, rather than having one value for the entire cell.
Transmit Power Capability

Before development of this feature, transmit power capability could only be modified
when the frequency type of the cell is set to DCS 1800 or PCS 1900. The tx_pwr_cap is
used to indicate that the carrier units are capable of high power. The dual band cells
feature has modified this parameter so that it can be set when the primary, outer zone
frequency type of the cell is PGSM, EGSM, DCS 1800 or GSM850.
Dependancies
This parameter is valid only if the RCUs, (D)RCUs, SCUs or TCUs at the site are
inactive.The system does not accept this parameter if the associated DRIs are unlocked.

Version 1 Rev 1 Power Budget Calculation
S pbgt_mode = 0
S RXLEV_DLEST_BCCH = RXLEVINNER_ZONE – dual_band_offset
S RXLEV_DLEST_BCCH is then used in power budget equation
S pbgt_mode = 1
S BCCH frequency of serving cells is added to the BA SACCH neighbour cell list of
serving cell
S Serving cell BCCH takes the place of an actual neighbour
S Serving cell is auto equipped as a neighbour
S ho_pwr_level_inner Range from 2 to 19,0 to 15 based on the phase and

class of the mobile
S tx_power_cap Used to indicate that the carrier units are capable of

high power

EGSM Layer Management Within a Dualband Cell Version 1 Rev 1
EGSM Layer Management Within a Dualband Cell

Dualband cells allow DCS1800 secondary band carriers to be considered as a preferred
band neighbour. But before the secondary band of he dualband cell can be considered it
must first qualify, by passing some entry criteria calculated on the downlink rxlev of the
primary band BCCH reported. If the secondary band of the dualband cell does qualify it is
sorted as a preferred band neighbour. In the modified candidate list shown opposite the
non–preferred band neighbour BCCH (PGSM/EGSM) cells with DCS1800 secondary
band resources appear in the list twice. Once as a preferred band resource and once as
a non–preferred band resource. If the MS is EGSM capable and is currently established
on an SDCCH, band_preference_mode is set to 1, 3 or 5 and there are free EGSM
resources in the current cell. The band_preference_mode which would normally
handover the call to the strongest preferred band neighbour cell will be ignored in this
case, and a free EGSM resource will be allocated to the call.
To implement the EGSM layer management feature call processing ignores any zone
handovers directed to the DCS1800 frequency band when a EGSM capable MS is on an
EGSM TCH in the primary band.If an intercell handover is triggered and the EGSM
capable MS is on an EGSM TCH resource in a dualband cell. The MS is directed to the
next available cell with an EGSM resource, whether it be a single band cell or a primary
band resource within a dualband cell. If this handover cannot take place, for example
congestion reasons. The MS will be targeted to the next neighbour in the neighbour list,
the neighbour maybe a single band DCS1800 cell, a dualband cell with DCS1800
resources or a single band PGSM cell, as directed by band_preference. When an
EGSM capable MS establishes on a PGSM TCH resource in a dualband cell and a zone
handover is triggered to direct the MS to the secondary band within the cell. The zone
handover will be processed and the MS shall be handed into the secondary band
(DCS1800).

Version 1 Rev 1 EGSM Layer Management Within a Dualband Cell
EGSM Layer Management Within a Dualband Cell
Preferred band
neighbour (DCS1800)
Preferred band Non–preferred band

neighbour (PGSM)
Non–preferred band
Non–preferred band Non–preferred band

with secondary DCS1800
Candidate neighbours reported from RSS Non–preferred band
neighbour (PGSM) with
secondary DCS1800
Non–preferred band (PGSM/EGSM)
Non–preferred band neighbour
(PGSM/EGSM) with secondary DCS1800
chg_element bss_egsm_alm_allowed 1 <site number>
Preferred band (DCS1800)
Non–preferred band (PGSM)
Candidate neighbours sorted by CP

Ping–Pong Handover Prevention Between Zones Version 1 Rev 1
Ping–Pong Handover Prevention Between Zones
Description
It has been found in real networks that the receive level in the outer zone (GSM900) is
significantly high compared to inner–zone (GSM1800) within the same cell. When the call
is in outer–zone, based on the single BCCH algorithm, this call is eligible to enter
inner–zone based on the estimation of inner zone receive level provided in
dual_band_offset parameter and inner zone entry criteria.
But unfortunately after the call moved to inner zone, the actual receive level is way below
the estimation, therefore the call is moved back to outer zone. At the outer zone, the
same process described in above paragraph is repeated. Such repetitive handover
between inner and outer zone is also known as ping–pong handover in a Single BCCH
cell. In the scenario above, the time spent in each zone during ping–pong is very short
and significantly degrades the voice quality of that call. From BSS point of view, such
ping–pong handover represents a very inefficient resource usage.
Causes
The root causes of such ping–pong handover in a Single BCCH cell are:
S Antenna parameter settings. Single BCCH feature is designed around the
assumption that the outer zone and inner zone effective coverage footprint is more
or less the same. Also, possibly the inner–zone radiated power level is uniformly
less then the outer–zone radiated power level as defined in dualband offset.
Antenna settings such antenna configuration, heights, alignment, bore angle, tilts,
etc. can be optimised to achieve the assumptions above.
S RF propagation nature difference between GSM900 and GSM1800. This is
especially applicable in fringe cell coverage or indoor coverage.
S In some networks, this is due to usage of wideband repeaters by the network
operator or their competitor.
Even when those root causes have been properly addressed and the Single BCCH cell
coverage has been properly optimised, there is still a possibility of high receive level
difference between outer an inner zone. Such possibility will lead to as increase volume
of ping–pong handover in the network. Therefore it is necessary to enhance the Single
BCCH feature to identify and prevent such ping–pong handover scenario.

Version 1 Rev 1 Ping–Pong Handover Prevention Between Zones
Ping–Pong Handover Prevention Between Zones
hdpc2_wksp4_sbbch_pin1

Controlling the Behaviour of Ping–Pongs Between Zones Version 1 Rev 1
Controlling the Behaviour of Ping–Pongs Between Zones

There are a number of parameters that control the behaviour of pingpongs between
zones. These are
zone_pingpong_count
<*> Value Range 1–255 Default 3
This counts how many times a zone ping–pong handover is allowed during
zone_pingpong_enable_win .
zone_pingpong_enable_win
<*> Value Range 1–255 (s) Default 30
This timer decides how long zone ping–pong handovers can be done continuously.
zone_pingpong_disable_win
<*> Value Range 1–255 (s) Default 30
This timer decides how long zone ping–pong handovers are not allowed after ping–pong
handover has happened after “zone_pingpong_count” times during
“zone_pingpong_enable_win”.
zone_pingpong_preferred_zone
<*> Value Range 0 – Outer zone
1 – Inner zone
255 – Current zone (no preferred zone)
Default 255
This parameter determines which is the preferred hop target zone.
Starting BSS Software GSR6 Horizon 2 version, Single BCCH feature has been
enhanced to prevent ping–pong handover scenario. Essentially the enhancement is
defined as:
S 1. IF The number of inter–zone handover (regardless the direction) exceeds the

number set in zone_pingpong_count AND within the period of time set in
zone_pingpong_enable_win
S THEN Start the zone_pingpong_disable_win timer; Cancel further zone
handover by forcing to stay in the preferred zone set in the
zone_pingpong_preferred_zone until Rule–2 below is satisfied.
S 2. IF The zone handover disable timer set in zone_pingpong_disable_win is
expired
S THEN Further zone handover is allowed until Rule–1.

Version 1 Rev 1 Controlling the Behaviour of Ping–Pongs Between Zones
Controlling the Behaviour of Ping–Pongs Between Zones
zone_pingpong_count = 3
zone_pingpong_enable_win = 30(s)
If 3 hops between zones

occur within enable win
timer value
THEN
Disable win timer keeps

MS in preferred zone
until it expires
zone_pingpong_preferred_zone = 0(pgsm)
zone_pingpong_disable_win = 30(s)
hdpc2_ch6_pin2

Intelligent Multilayer Resource Management Version 1 Rev 1
Intelligent Multilayer Resource Management
Description of the reasons to introduce this feature

Over many years, numerous features have been introduced to aid in the management of
multi–frequency band networks. Some to support the initial introduction of a new
frequency band i.e. DCS1800 and later EGSM, and others to try and optimise resource
utilisation across the multitude of different bands e.g. Multiband Handover, SBCCH and
EGSM Layer Management.
These algorithms, generally are in competition rather than complimentary, and heavily
biased towards a mobiles capabilities in terms of the frequencies it supports. Though
valid at the time of introduction, it can lead to load imbalance because of the influence of
one feature over the other.
The two main areas of concern that are impacted by this feature are:
S Imbalance between bands e.g. DCS1800 heavily utilised whilst other bands not so
S Imbalance between layers i.e. macro overlay running at very high utilisation levels
whilst micro underlay can be very lightly used.
The first of these has a direct impact on the second i.e. where the micro underlay is not
the same frequency type as the macro preference, then traffic which should be supported
on the micro layer is targeted to the preferred band macro layer, thus causing the effect
of over–utilisation in the macro layer and under–utilisation in the micro layer.

Version 1 Rev 1 Intelligent Multilayer Resource Management
MS directed to DCS1800
resources by band preference
DCS 1800 IZ DCS 1800 IZ Macro

PGSM OZ PGSM OZ Layer
Micro
PGSM PGSM PGSM PGSM PGSM PGSM
Layer
PGSM Micro Layer under utilised

hdpc2_ch4_imrm1

Intelligent Multilayer Resource Management Version 1 Rev 1
Description of IMRM functionality

This feature addresses the band imbalance i.e. allowing for better distribution of traffic
across all available frequency bands. This is because it is possible to remove the
preference based purely on band preference and allows for more powerful optimisation of
the network based on the operators preferred target cells.
This is achieved by weighting the cells according to the operators preference.
For initial assignments and incoming external or internal handovers the parameter
band_preference is used to define the target resource for this mobile. How it does this
depends on the setting of band_preference_mode. Prior to this feature the setting of
band_preference was statically set, now this feature allows an additional setting of
dynamic (16). This setting is used in conjunction with other database settings to set the
Per Call Preferred Band (PCPB).
Firstly the mobile will be examined to see if has the capability to support the bands
allowed in the cell. This is done by the early classmark sending or classmark enquiry
procedures. Secondly if a multiRAT capable call is involved in an incoming handover and
the SERVICE HANDOVER IE is defined and set to either UMTS ’should not be used’ or
’shall not be used’, then the UMTS band shall be excluded by the BSS.
So when the exclusion procedures based on the last paragraph have been carried out
and there are multiple bands available then the following procedures will apply:
S The remaining band weights will be scaled relative to each other to sum 100
S The scaled weightings will be used to define sequential per band ranges
(corresponding to the scaled values) to span 1–100
S The BSS shall generate a random number between 1 and 100
S The band–range that the random number falls into shall define the Per Call
Preferred Band.
Notes:
If more than one band is set to maximum weighting then the PCPB is set to the band of
the BCCH carrier.
If only one band is set to its maximum or only one band is greater than zero, then that
band is the PCPB.
If all the bands are weighted with a setting of zero then the PCPB is set to the band of
the BCCH carrier.

Version 1 Rev 1 Intelligent Multilayer Resource Management
IMRM Flow Chart
Retrieve Is MS NO
All active call Service NO Check Remove
cell PGSM
HO IE > MS PGSM
connections band capable
000 capability band
weights ?
YES
YES
Scale remaining weights Remove

relative to each other to UMTS band
sum 100. Map to number
Is MS
line 1 –100. Generate NO Remove
EGSM EGSM
random number. Set
PCPB according to Set band as Set PCPB to capable band
random number lookup ?
PCPB BCCH band
on number line.
YES
YES YES YES
If more
If more If only 1
than 1
than 1 band set Is MS NO Remove
band set
band to max DCS1800 DCS1800
to max
NO weighting NO weighting NO YES capable? band
weighting
> 0? or > 0?
?
Else set PCPB

to BCCH band
hdpc2_ch4_imrm2

Intelligent Multilayer Resource Management – PCPB Version 1 Rev 1
Intelligent Multilayer Resource Management – PCPB
Per Call Preferred Band (PCPB)

The PCPB is set on a per call basis according to the IMRM algorithm described on the
previous page. The decision on how to set the band weightings on a per call basis is
decided by the following:
S The available capacity on each band of the cell
S The mobile of multi–band mobiles served by the cells
S Any special service considerations, for example if UMTS is available.
Any band that has a maximum weighting set and is within the mobiles capabilities is
considered to be the preferred band and the PCPB is set to this. This is very similar to
the static band_preference setting, but is on a per call basis.
When there is no maximum weighting, then the PCPB will be set on a per call basis
according to the band weighting ratio so as to distribute the calls proportionally across
the bands.
When PCPB is set

PCPB is set under the following conditions:
S On initial call set–up
S On an incoming internal handover where no preferred band has been set. This will
happen when the source cell is non–IMRM or where the preferred band is
unsupported in the target cell
S On an incoming external handover from another BSC
S Where the recalculate IMRM preferred band flag is set on a cell.

Version 1 Rev 1 Intelligent Multilayer Resource Management – PCPB
Intelligent Multilayer Resource Management – PCPB
PCPB set on: Incoming internal

handover when no
preferred band set
On call set–up
Incoming external
handover
hdpc2_ch4_imrm3

IMRM – Forced Recalculation of PCPB Version 1 Rev 1
IMRM – Forced Recalculation of PCPB

The preferred band is now set on a per call basis when the enabled. So the preferred
band will be tagged onto a particular mobile for the life of that call as long as it remains
within the same BSC. In some cases we might want to either recalculate a preferred
band or force the preferred band to one particular band. For instance if there was a
macro layer consisting of dual band cells with PGSM and dcs1800 bands and the PCPB
had been set to the dcs1800 band. Then the mobile would be directed to that band by
band preference mode for the life of the call. However if the mobile moved to an area
where there was a layer of microcells with a operating on a frequency band of PGSM the
PCPB would now cause under utilisation of these cells, highly undesirable. So in these
cells we would set the parameter imrm_force_recalc to 1. This forces a recalculation of
PCPB and if the weighting of the PGSM microcells was 100% then PCPB would now be
PGSM. As long as the microcell neighbours qualified then a handover would occur to
them. Assuming that band preference mode had been set to prefer handovers to the
preferred band. This example is illustrated on the PPT.
The same principle could be applied if the mobile moved into an area of UMTS
coverage.

Version 1 Rev 1 IMRM – Forced Recalculation of PCPB
IMRM – Forced Recalculation of PCPB
Mobile handed in
DCS 1800 IZ DCS 1800 IZ

Macro
PGSM OZ PGSM OZ Layer
PCPB = dcs1800
imrm_force_recalc = 1
If constraints
of
microcellular
criteria met PGSM PGSM PGSM Weighting = 100%
hdpc2_ch4_imrm4

General Call Handling for an IMRM Cell Version 1 Rev 1
General Call Handling for an IMRM Cell

When band preference has been set for the IMRM cell the move to the preferred band is
still restricted by whatever band preference mode is set to. This pre–dates this feature
and is there is no change to the parameter values of band_preference_mode.
When the band preference has been set and band preference mode allows the handover
to take place then the resources are checked in the following order:
S Try assigning an internal resource for the preferred band
S Try qualified neighbours of the preferred band
S Try any outer zone resources
S Try queuing/directed retry.
An example of this is shown on the PPT slide where the PCPB has been set to dcs1800.
Building the Handover Candidate List

Conventionally the handover candidate list is built by first ordering by Criteria 2 (PBGT–
ho_margin) and then re–ordered on the basis of a fixed preferred band.
With the IMRM algorithm this changes to:
S Ordered by Criteria 2 (PBGT – ho_margin)
S Re–ordered on the basis of the PCPB value
S Preferred band takes into account the mobiles capabilities and preferred band
weighting
S PGSM and EGSM bands are targeted separately of each other.

Version 1 Rev 1 General Call Handling for an IMRM Cell
General Call Handling for an IMRM Cell
For example if PCPB = dcs1800
DCS 1800 IZ DCS 1800 IZ
PGSM OZ PGSM OZ
Try assigning an internal resource of the dcs1800 band
Try qualified neighbours of the preferred band
Try any outer zone resource
Try queuing/directed retry
hdpc2_ch4_imrm5

Intelligent Multilayer Resource Management – 2G to 3G Handover Version 1 Rev 1
Intelligent Multilayer Resource Management – 2G to 3G Handover
2G – 3G Handover Implications
If a 2G/3G mobile moves into the area of 3G coverage there are three ways to capture
the mobile into the 3G cells. All three methods rely on the BSS setting the
3G_SEARCH_PRIO bit. This bit is an element in the 3G Measurement Information
Parameter description IE, it allows the mobile to use additional search frames for
searching 3G cells. These have a precedence and are listed in order below:
S SERVICE HANDOVER IE
S UMTS band preferred flag
S IMRM band preferred
Interactions with SERVICE HANDOVER

The SERVICE HANDOVER is sent from the core network to the BSS in the
ASSIGNMENT REQUEST or HANDOVER REQUEST to indicate a preference for 3G.
This takes precedence over both preference for UMTS and IMRM preferred layer.
If SERVICE HANDOVER = 000 it means that the mobile should prefer UMTS. So if the
preferred band is not set to UMTS, any UMTS cells which are measured are added to
the top of the list.
If SERVICE HANDOVER = 001 (should not use UMTS) or 010 (shall not use UMTS) and
UMTS is set to the preferred band, the preferred band is recalculated excluding UMTS.
Interactions with UMTS band preferred flag

The GSR8 2G–3G handover algorithms introduce a UMTS_BAND_PREFERRED flag.
This is used to indicate to the network the operator preference for the UMTS band. When
the 2G–3G handover algorithm is used in conjunction with the IMRM algorithms the
UMTS_BAND_PREFERRED overrides the IMRM preferred layer when set.

Version 1 Rev 1 Intelligent Multilayer Resource Management – 2G to 3G Handover
Intelligent Multilayer Resource Management – 2G to 3G

Handovers
Core Network
SERVICE HANDOVER IE
BSS RNC
BTS NODE B
UMTS BAND PREFERRED
IMRM BAND PREFERRED
hdpc2_ch4_imrm6

IMRM – Database Parameters Version 1 Rev 1
IMRM – Database Parameters

There are five new per cell database parameters and one modified database parameter
to support this feature.
New parameters:
chg_element imrm_pgsm_weight <*> <location> cell <cell id>
* = 0 to 100
Default = 0 where the IMRM feature is not enabled
This parameter sets the value of preference of the pgsm band, this is used when
calculating the PCPB when a mobile becomes active within a cell.
chg_element imrm_egsm_weight <*> <location> cell <cell id>
* = 0 to 100
This parameter sets the value of preference of the egsm band, this is used when
chg_element imrm_dcs1800_weight <*> <location> cell <cell id>
* = 0 to 100
This parameter sets the value of preference of the dcs1800 band, this is used when
chg_element imrm_umts_weight <*> <location> cell <cell id>
* = 0 to 100
This parameter sets the value of preference of the umts band, this is used when
chg_element imrm_force_recalc <*> <location> cell <cell id>
* = 0 Disabled
1 Enabled
Default = 0
When this flag is enabled , a recalculation on the preferred band to handover to is
executed on the specified cell.

Version 1 Rev 1 IMRM – Database Parameters
Database Parameters
chg_element imrm_pgsm_weight <*><location> cell <cell id>

* = 0 to 100 Default = 0
chg_element imrm_egsm_weight <*><location> cell <cell id>

* = 0 to 100 Default = 0
chg_element imrm_dcs1800_weight <*><location> cell <cell id>

* = 0 to 100 Default = 0
chg_element imrm_umts_weight <*><location> cell <cell id>

* = 0 to 100 Default = 0
chg_element imrm_force_recalc <*><location> cell <cell id>

* = 0 Disabled 1 Enabled Default = 0
hdpc2_ch4_imrm7

IMRM – Database Parameters Continued Version 1 Rev 1
IMRM – Database Parameters Continued

Modified Parameter:
chg_element band_preference <*> <location> cell <cell id>
* = 16 or “dynamic” (new value)
This parameter allows the operator to set the weighting for each frequency band. The
weighting for UMTS will only be prompted if 2G/3G handover feature is unrestricted.
When this value is entered further prompts allow the operator to set the weighting.
Enter the weighting for PGSM:
Enter the weighting for EGSM:
Enter the weighting for DCS1800:
Enter the weighting for UMTS:
When IMRM is enabled in a cell the default configuration is dependant on whether EGSM
is configured in that cell or not. The default combinations are shown in the PPT slide.

Version 1 Rev 1 IMRM – Database Parameters Continued
IMRM – Database Parameters Continued
chg_element band_preference <*> <locaction> cell <cell id>
* = 16 or ”dynamic” (new value)
EGSM PGSM EGSM DCS1800 PCS850 PCS1900 GSM450 UMTS

Support
YES 45 10 45 N/A N/A N/A 0
NO 50 0 50 N/A N/A N/A 0
Default values assigned if IMRM enabled
hdpc2_ch4_imrm8

IMRM – Database Parameters Continued Version 1 Rev 1

Chapter 5
Adaptive Multi–Rate and Half–Rate

Version 1 Rev 1

Version 1 Rev 1
Chapter 5
Adaptive Multi–Rate and Half–Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Adaptive Multi–Rate and Half Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–1
Half Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–2
Adaptive Multi–Rate (AMR) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
AMR Full – Rate Channel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
Full Rate Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
AMR Half – Rate Channel Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
Half Rate Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
Active Codec Set Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–4
AMR Half–Rate Further Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–6
Enabling Half Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
RTF Change . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–8
Channel Allocation for AMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
Speech . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–10
Force Half–Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Reconfiguration of Existing Full–Rate Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12
Reservation of Half–Rate Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–14
AMR Full – Rate Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–16
AMR Half – Rate Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–18
Enabling/Disabling Link Adaptation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–20
AMR FR/HR Commands to Specify ACS and Associated Parameters . . . . . . . . . . . . . . 5–22
AMR FR/HR Commands to Specify ACS and Associated Parameters–Cont’d . . . . . . . 5–24
Downlink Adaptation Change Minimum Time Period . . . . . . . . . . . . . . . . . . . . . . . 5–26
MS Monitor Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
Downlink Adaptation MS Monitor Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–28
(AMR) Half Rate Handover and Power Control Parameters . . . . . . . . . . . . . . . . . . . . . . . 5–30
AMR or GSM Half–Rate Intracell Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–32
AMR or GSM Half Rate Intra–cell Handover Hop Count . . . . . . . . . . . . . . . . . . . . . . . . . . 5–34

Version 1 Rev 1

Version 1 Rev 1 Adaptive Multi–Rate and Half Rate
Adaptive Multi–Rate and Half Rate
Objectives
S Discuss Half Rate
S Discuss Adaptive Multi–Rate.
S Consider AMR Half and Full Rate
S Consider AMR Half and Full Rate Link Adaptation
S Discuss MS Monitor Functionality
S Discuss Handover and Power Control Parameters for AMR

Half Rate Version 1 Rev 1
Half Rate
The GSM Half Rate feature offers enhanced capacity over the air interface,
corresponding to the proportion of mobiles within a coverage area that supports Half
Rate. An air timeslot is split into two sub–channels, each containing a half rate channel.
Speech quality is considered inferior to other speech codecs but has a high penetration
level (of GSM HR capable mobiles) due to its early introduction into the standards. Due
to these large penetration levels it is considered a viable option for high density areas.
A GSM HR call can fit within an 8kbps timeslot (an Ater channel) on the terrestrial
resource from the BSC to the RXCDR, rather than the 16kbps timeslot required for FR
calls. If a percentage of the active calls can be assumed to be HR, then efficiencies can
be gained by reducing the number of terrestrial resources between the BSC and RXCDR.
This is possible only if the BSC can dynamically allocate a timeslot to a CIC on an
8kbps/16kbps basis. This dynamic allocation is performed across a trunked interface
between the BSC and a remote transcoder (RXCDR). This interface is called the Ater
interface. The dynamic allocation is an enhancement to the existing Auto Connect mode
feature, referred to as ”Enhanced Auto Connect mode”. Enhanced Auto Connect is part
of the AMR feature and is mentioned here only to point out that GSM HR will enjoy the
same benefit.
The backhaul requirements between the BTS and BSC may also be reduced to 8kbps as
long as subrate (8K) switching is present at the BSC. Both GDP and GDP2 boards will
be enhanced to support GSM HR. GDP will be introduced first, followed by GDP2 in a
future release.

Version 1 Rev 1 Half Rate
Half Rate
MS A – Sub Channel 0
IDLE SACCH
Half Rate TCH – MS A Half Rate TCH – MS A
25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Half Rate TCH – MS B Half Rate TCH – MS B

SACCH IDLE
MS B – Sub Channel 1
hdpc2_Ch5_hrdia

Adaptive Multi–Rate (AMR) Version 1 Rev 1
Adaptive Multi–Rate (AMR)

Adaptive Multi–Rate (AMR) is introduced in GSR7 and provides two modes of working
AMR full–rate channel mode (AMR FR) and AMR half–rate channel mode (AMR HR).
AMR Full – Rate Channel Mode

This mode of working provides higher speech quality in areas of poor RF conditions.
Full Rate Link Adaptation

AMR FR link adaptation works in conjunction with the rest of the AMR feature set, namely AMR,
Call downgrade on CIC capability mismatch and Enhanced GDP provisioning. It provides improved
speech quality in poor RF environments by adapting the speech rates and level of error correction
on a call. Speech quality is improved by reducing the speech rate and increasing the level of error
correction in poor RF environment. The speech rate used is determined by the codec mode used.
The Active Codec Set (ACS) refers to the set of up to 4 AMR codec modes that can be utilised for
any given voice call in the uplink and downlink direction.
AMR Half – Rate Channel Mode

This mode of working allows two AMR calls to be placed on a single air interface timeslot. This
gives an increase in cell capacity with no additional hardware. However extra backhaul is maybe
required between BSC and BTS if there being no 8kbps switching. This means that AMR half–rate
speech data has to be carried in 16kbps TRAU format between BSC and BTS. Given that
potentially 16 AMR half–rate calls can be supported on an AMR half–rate carrier, an AMR half–rate
RTF must have four associated E1 timeslots provisioned between BSC and BTS. However if DSW
are utilised in the BSS then 8kbps swithing is supported.
Due to reduced bandwidth, an AMR half–rate call will in general have a lower QoS than a full–rate
call. For this reason the user will be able to specify a congestion level that has to be exceeded in an
AMR half–rate cell before new calls will be assigned to a half–rate channel. In addition, when the
received bit error rate (Rxqual) indicates that a half rate channel is suffering interference and that
the speech quality of the call is therefore impaired, an intra–cell handover back to full–rate (or to
another half–rate channel) is supported to maintain quality of service.
There is also a lower QoS provided by AMR half–rate calls.
Half Rate Link Adaptation

AMR HR link adaptation operates in a similar way to AMR FR link adaptation. The differences are
the bit rates of the HR codec modes supported, different initial HR codec mode and different
associated uplink and downlink codec mode adaptation thresholds and hystersis values.
Active Codec Set Values

In total there are 8 Active Codec Set values.
0 12.20 kbps
1 10.20 kbps
2 7.95 kbps
3 7.40 kbps
4 6.70 kbps
5 5.90 kbps
6 5.15 kbps
7 4.75 kbps
The BSS supports:–
12.1, 10.2, 7.4, 6.7 and 5.15 kbps for a full rate channel.
7.95, 7.4, 6.7, 5.9 and 5.15 kbps for a half rate channel.

Version 1 Rev 1 Adaptive Multi–Rate (AMR)
Adaptive Multi–Rate (AMR)
Dependant on:
– Enhanced GDP Provisioning
– Call downgrade on CIC
capability mismatch
Up to 16 AMR half rate calls
Up to 8 AMR full rate calls

MSC RXCDR BSC BTS Or a combination of the two.
Up to four codec
modes can be
included in FR and
HR Active Codec
Set
Which Codec Mode

0 used depends on
RF conditions
For half rate rtf – two E1 timeslots required if DSW’s not utilised
SYS12_amr_01

AMR Half–Rate Further Considerations Version 1 Rev 1
AMR Half–Rate Further Considerations

The operator may set a database parameter in order to override any MSC channel rate
preference (if given) and the cell’s congestion threshold, causing AMR calls to be
assigned directly to Half–Rate channels. This allows temporary forcing (from the OMC) of
Half–Rate usage during busy periods. Intra–Cell handovers for quality reasons from
Half–Rate are still permitted when the override flag is set, but the target resource for the
intra–cell handover will be forced to half–rate.
In addition to the ability to specify that new ’half–rate capable’ calls should be assigned
to half–rate traffic channels when cell congestion exceeds the threshold, the operator will
have the ability to specify a second (or alternative) congestion threshold. When this
congestion threshold is exceeded in an AMR half–rate channel mode cell, the BSS SW
will re–assign ’half–rate capable’ full–rate calls to half–rate traffic channels.
Congestion and quality–related intracell handovers can occur between AMR FR and
AMR HR channel modes, and between GSM FR/EFR and AMR HR. The following
conditions apply to determination of a ’half–rate capable call’ for either congestion
based FR–HR intracell handovers or quality based half–rate intra–cell handovers:
S The MSC must identify to the BSC that the call is capable of both channel types and at
least one FR and one HR (the AMR HR) speech version in the Channel Type IE in the
Assignment Request or Handover Request.
S The identified FR and HR speech versions must be enabled at the BSS level (AMR
FR/AMR HR/EFR) and Cell level (AMR FR/HR).
S The MSC must not specify that ’rate changes not allowed after initial assignment’
in the Channel Type IE.
Note: If ’rate changes not allowed after initial assignment’ is specified by the MSC,
the BSS must only allow the call to use the channel type allocated initially. Therefore any
procedures, such as congestion based FR–HR intra–cell handovers or quality based
half–rate intra–cell handovers, which will result in a channel rate change are not allowed.
S The specified CIC for the call must be AMR capable (uses the transcoding resources of
an enhanced transcoding GDP), which means that it will support half–rate and all of the
FR speech versions. Note that if the CIC used changes during the call (at the request
of the MSC), the call may become routed onto a basic GDP or XCDR, and so it shall
no longer be a half rate capable call.
The portion of the feature relating to handover of existing Full–Rate calls to Half–Rate is
used in conjunction with the Congestion Relief feature, and verifies that this feature is in
use. Mobiles which are considered the best candidates for using Half–Rate are those
closest to the centre of the cell, as indicated by those not included in the power budget
criterion for standard Congestion Relief (handing over to the strongest neighbour cell).

Version 1 Rev 1 AMR Half–Rate Further Considerations
AMR Half–Rate Further Considerations
Assignment or Handover Request Msg

– At least one FR and one AMR HR
speech version in the channel type IE
– MSC must not specify ’rate changes
not allowed after initial assignment’ in
the channel type IE
Identified AMR FR and AMR

HR must be enabled at cell
MSC RXCDR BSC BTS
level
G
D
P
Identified AMR FR and AMR

HR must be enabled at BSS
level
Specified CIC for the call must be

AMR capable (Enhanced GDP)
SYS12_amr_02

Enabling Half Rate Version 1 Rev 1
Enabling Half Rate

Many of the parameters associated with the AMR feature are generic to both Half Rate
and AMR. In the case of enabling Half Rate there are two new parameters unique to half
Rate.
At BSS level
chg_element gsm_bss_half_rate_enabled <*> <location>
<*> 0 = Disabled
1 = Enabled
In the case of remote transcoding the AXCDR must have CIC validation enabled. Also if
the parameter handover_required_sp_ver_used is disabled this parameter will not be
allowed to be enabled.
At cell level
chg_element gsm_half_rate_enabled <*><site no>cell = <cell_id>
<*> 0 = Disabled
1 = Enabled
The GSM Half Rate feature can only be used at sites comprised of Horizonmacro,
Horizonmacro2, MCell2 or MCell6 cabinets. Or a combination of these cabinets.
RTF Change
If the AMR Half Rate or GSM Half Rate feature is enabled then when the RTF’s are
equipped two further prompts will appear. One to state whether Half Rate is enabled on
that RTF and the other to state whether 8kbps of TRAU is allowed on that RTF.
Note: If AMR half Rate is enabled and the 7.95kbps Codec Mode exists in the Active
Codec Set the 8kbps TRAU option will not be prompted.
Example:
equip 1 rtf
Existing equip outputs unchanged
Enter the value for Half Rate enabled = 1
Is 8kbps TRAU allowed (yes/no)?: yes
Existing equip outputs unchanged
COMMAND ACCEPTED

Version 1 Rev 1 Enabling Half Rate
Enabling Half Rate
MSC
Handover request or assignment request
required channel is half–rate
Enabling\Disabling pararmeters per BSS

BSC
gsm_bss_half_rate_enabled
BTS
Multi–Zone Cell
Single Zone cell
Equiping RTF’s
Enabling\Disabling parameters per Cell half_rate_enabled
gsm_half_rate_enabled Allow_8k_trau
SYS12_amr_02a

Channel Allocation for AMR Version 1 Rev 1
Channel Allocation for AMR

In the Channel Type information element within the Handover Request and Assignment
Request messages from the MSC there is a “Speech/data indicator” octet. This defines
whether the request is for speech, data or signalling. the operation of the BSS is different
for each option.
Speech
The ’Channel rate and type’ octet contained within the Channel Type Information
element in the Handover request and Assignment request messages from the MSC
contains the following:
S Required channel rate – i.e. Full–rate, half–rate or either full–rate or half–rate.
S In the case of either, the preferred channel rate may be indicated.
S In the case of either, whether rate changes are permitted after initial channel allocation
may also be indicated.
Also the ’permitted speech version indication’ octets within the channel type
information element list is in order of preference, the speech versions which maybe used
for the call.
Full–rate Channel Required
If the MSC specifies that a call must be allocated a full rate channel by setting the
’Channel rate and type’ octet within the Channel type information element in an
assignment request or handover request message to a ’full rate TCH channel Bm’.
AMR Half–rate Channel Required
If an assignment request or handover request message from the MSC specifies the
’Channel rate and type’ octet within the channel type information element as ’half rate
TCH channel Lm’ the BSS will attempt to allocate a half rate channel to the call if ’GSM
speech half rate version 3’ is in the ’permitted speech version indication’ list. If not
the BSS rejects the request.
The BSS can only allocate an AMR half–rate channel if the following are true:
S The AMR half–rate channel mode is enabled at BSS level
S The AMR half–rate channel is enabled for the target cell
S There are AMR half–rate channels available in the target cell and the MSC specifies
that AMR half–rate
If none of these are true and the MSC specifies that an AMR half–rate channel is to be
used, then the BSS rejects the assignment/handover request. This is done by sending
an assignment failure message to the MSC which can have the cause value ’requested
speech version unavailable’ for AMR being disabled, or ’no radio resource available’
for the case of no AMR half–rate channel resources being available in the target cell.

Version 1 Rev 1 Channel Allocation for AMR
Channel Allocation for AMR

MSC
required channel is half–rate
Enabling/Disabling parameters per BSS

BSC
amr_bss_half_rate_enabled
BTS
Single Zone cell Multi–zone cell
Enabling/Disabling parameters per cell

amr_half_rate_enabled
ch6_amr_en/dis
chg_element amr_bss_half_rate_enabled <*><location>
<*> 0 = Disabled
1 = Enabled
chg_element amr_half_rate_enabled <*><site> cell = <cell_id>
<*> 0 = Disabled
1 = Enabled
Note: CIC Validation must be enabled and in the case of handovers the
’handover_required_speech_ver_used’ must also be included in the handover required
message.

Force Half–Rate Version 1 Rev 1
Force Half–Rate
In the case of the MSC specifying that either a full–rate or a half–rate channel can be
allocated to a call, the BSS decides what to allocate. The BSS will attempt to allocate a
full–rate channel to the call if any of the following are true:
S The AMR or GSM half–rate channel mode is disabled at BSS level
S The AMR or GSM half–rate channel mode is disabled for the target cell
S The ’Channel rate and type’ octet indicates that rate changes after initial channel
allocation are not allowed
S The CIC selected for the call does not have (AMR) half–rate capability.
In addition to this if there is no preferred channel rate , or that a full–rate channel is
preferred. The BSS will attempt to allocate a full–rate to the call unless the criteria is met
which allows the BSS to ignore the precedence specified by the MSC. The criteria
governing this procedure is two fold.
S The force_hr_usage per BSS element is set.
chg_element force_hr_usage <*> <location>
<*> 0 = disabled
1 = enabled
S The per cell new_calls_hr congestion level has been exceeded.
This congestion threshold indicates at what congestion level the BSS SW should start
assigning new ’half–rate capable’ calls as AMR or GSM half–rate calls. A limitation
exists based on the number of idle half–rate channels and free generic traffic channels in
the cell.
chg_cell_element new_calls_hr <*> cell = <cell_id>
<*> 0 to 101(%)
Setting this element to 101 effectively disables the new calls at half–rate congestion
mechanism.
Reconfiguration of Existing Full–Rate Calls

The BSS supports the configuration of the new reconfig_fr_to_hr congestion threshold
on a per–cell basis to indicate at what congestion level the BSS SW should instigate
reconfiguration of “half–rate capable” full–rate calls to AMR or GSM half–rate calls.
chg_cell_element reconfig_fr_to_hr <*> cell = <cell_id>
<*> 0 to 101(%)
Setting this element with a value of 101 effectively disables the reconfigure half–rate full
rate calls to half–rate congestion mechanism.

Version 1 Rev 1 Force Half–Rate
Force Half–Rate
MSC
– required channel is full rate or half–rate capable
Per BSS parameter to force full–rate calls

BSC to AMR or GSM half rate
force_hr_usage
BTS
Single Zone cell Multi–Zone cell
Congestion parameter for forcing half–rate capable calls to AMR or GSM half rate
new_calls_hr reconfig_fr_to_hr
ch_6_amr_force

Reservation of Half–Rate Resources Version 1 Rev 1
Reservation of Half–Rate Resources

The operator will have the ability to reserve a number of half–rate resources (on generic
timeslots) for use in congestion. Full–Rate calls are prevented from using these
resources until there are no other timeslots available in the cell/zone. The reserved
generic timeslots will be applied to the inner and outer zones within a multi–zone cell. For
example, if the operator specifies to reserve two generic timeslots, this will result in two
timeslots being reserved on the inner zone and two timeslots being reserved on the outer
zone.
It should be noted that the reservation of generic timeslots is applied to each zone within
multi–zone cells (Concentric Cell, Dual Band Cell). Within a cell that does not support
multiple zones, all the cell resources are considered to be in the outer zone.
The hr_res_ts element specifies the maximum number of half–rate capable timeslots to
be reserved within each zone of the cell. Within the inner zone, the actual value can be
dynamically limited to be less than hr_res_ts, if the BSS detects that the
inner_hr_usage_thres will not be able to be exceeded because of the setting of
hr_res_ts. hr_res_ts is also limited by the number of half–rate capable resources
available in the cell or zone. There are no specific dedicated Half–Rate reserved
timeslots. Any timeslot on a Half–Rate capable carrier can be considered ’reserved’ if
Full–Rate calls have not been assigned to them due to there only being hr_res_ts
number of timeslots left in the cell/zone.
chg_element hr_res_ts <*><site> cell = <cell_id>
<*> 0 to 2558
Default = 2

Version 1 Rev 1 Reservation of Half–Rate Resources
Reservation of Half–Rate Resources
BTS
Multi – Zone Cell

Single Zone cell
Reservation of timeslots for half–rate usage

hr_res_ts
SYS!”_amr_10

AMR Full – Rate Link Adaptation Version 1 Rev 1
AMR Full – Rate Link Adaptation

Full Rate AMR Link Adaptation provides the mechanism by which the BSS adapts
between speech codec modes in an AMR codec on the uplink and downlink of an AMR
FR call, to provide the most suitable level of error correction for the RF environment.
Uplink and downlink codec modes are considered separately and can be adapted
separately. The AMR feature provides a set of Full Rate codec modes. With Full Rate
Link Adaptation, up to four of these codec modes could be placed in the per cell Full
Rate Active Codec Set. It is over this Active Codec Set that the call is adapted according
to the quality of the link between the mobile and the BSS. The Full Rate codec modes
supported are:
AFS 12.2 kbps
AFS 10.2 kbps
AFS 7.4 kbps
AFS 6.7 kbps
AFS 5.15 kbps
The higher the bit rate of the codec mode indicated the higher the speech rate and the
lower the error correction rate. Upto 4 of these codec modes can be included in the FR
ACS.
For each pair of codec of modes there is an associated threshold and hysteresis value.
The associated threshold is used as the lower decision threshold for switching the codec
mode to a lower mode with a lower speech rate. The sum of the associated threshold
and associated hysteresis is used as the upper decision threshold for switching the
codec mode to a less robust mode with a higher speech rate. The threshold and
hysteresis are expressed in terms of normalized Carrier to Interference (C/I) values.
CODEC_MODE_1 Represents the lowest codec mode (lowest speech bit
rate, highest error correction bit rate) of the FR ACS
CODEC_MODE_2 Represents the second lowest codec mode, if the ACS
contains more than one codec mode.
CODEC_MODE_3 Represents the third lowest codec mode, if the ACS
contains more than two codec modes.
CODEC_MODE_4 Represents the highest codec mode (highest speech bit
rate, lowest error correction bit rate) of the ACS if the
ACS contains four codec modes.
The FR ACS, Full Rate Initial Codec mode and the associated codec mode adaptation
threshold and hysteresis values to be used are communicated to the mobile and the
channel coder on call initialization and handover.
FR AMR codecs provide different levels of error correction and allow different channel bit
error rates for acceptable quality of service. As an example, at the lowest codec mode
(low speech rate, high error correction) a larger BER may be acceptable as more of the
errors will be corrected, where as in a higher codec mode a larger BER would be
unacceptable as less errors will be corrected. The differences in AMR channel
characteristics prompt the introduction for a new set of HDPC RXQUAL algorithm
thresholds. The new HDPC parameters are specific to AMR FR calls and utilize the
existing GSM Handover and Power Control algorithms. These new HDPC parameters
allow an AMR FR capable cell to be tailored for AMR FR capable mobiles, to increase
the range of cells and improve service in poor coverage areas, minimize interference
levels to improve speech quality, increase capacity (through tighter–reuse of frequencies)
and increase service quality by lowering the number of handovers for AMR FR. This
release of Full Rate Link Adaptation is tailored towards maximizing speech quality and
hence all defaulted values supplied in the software are geared to that goal.

Version 1 Rev 1 AMR Full – Rate Link Adaptation
AMR Full–Rate Link Adaptation
C/I
CODEC_MODE_4
THR3 + HYST3
THR3
Available Full Rate
Codec Modes CODEC_MODE_3
AFS 12.2 kbps
AFS 10.2 kbps THR2 + HYST2
AFS 7.4 kbps THR2

Up to 4 can be
AFS 6.7 kbps chosen CODEC_MODE_2
AFS 5.15 kbps
THR1 + HYST1
THR1
CODEC_MODE_1
SYS12_amr_3

AMR Half – Rate Link Adaptation Version 1 Rev 1
AMR Half – Rate Link Adaptation

Half Rate AMR Link Adaptation provides similar functionality to Full Rate AMR Link
Adaptation but for the Half Rate AMR channel. In Half Rate AMR Link Adaptation there is
a different Half Rate Active Codec Set. This AHS can contain up to four of the Half Rate
AMR codec modes that are supported. The Half Rate codec modes supported are AHS
7.95 kbps, 7.4 kbps, 6.7 kbps, 5.9 kbps and 5.15 kbps. There is also a different Half Rate
Initial Codec Mode and different associated uplink and downlink codec mode adaptation
thresholds and hysteresis values for Half Rate AMR calls. The existing GSM Handover
and Power Control algorithms are still used for the Half Rate AMR channel, but similar to
Full Rate Link Adaptation a new set of Handover and Power Control thresholds are
introduced. The new Half Rate AMR HDPC RXQUAL thresholds are different to the Full
Rate AMR HDPC thresholds because the Half Rate channel will display different
characteristics to a Full Rate AMR channel. For these reasons the customer may wish to
configure the Handover and Power Control algorithms in a different manner to cater for
the Half Rate AMR channel. The MS Monitor introduced in Full Rate AMR Link
Adaptation also applies to Half Rate AMR calls.
CODEC_MODE_1 Represents the lowest codec mode (lowest speech bit
rate, highest error correction bit rate) of the HR ACS
CODEC_MODE_2 Represents the second lowest codec mode, if the HR
ACS contains more than one codec mode.
CODEC_MODE_3 Represents the third lowest codec mode, if the HR ACS
contains more than two codec modes.
CODEC_MODE_4 Represents the highest codec mode (highest speech bit
rate, lowest error correction bit rate) of the HR ACS if
the ACS contains four codec modes.

Version 1 Rev 1 AMR Half – Rate Link Adaptation
AMR Half–Rate Link Adaptation
C/I
CODEC_MODE_4
THR3 + HYST3
THR3
Available Half Rate
Codec Modes CODEC_MODE_3
AHS 7.95 kbps
AHS 7.4 kbps THR2 + HYST2
AHS 6.7 kbps THR2

Up to 4 can be
AHS 5.9 kbps chosen
CODEC_MODE_2
AHS 5.15 kbps
THR1 + HYST1
THR1
CODEC_MODE_1
SYS12_amr_5

Enabling/Disabling Link Adaptation Version 1 Rev 1
Enabling/Disabling Link Adaptation

It is possible in certain situations to disable Link Adaptation for calls in a cell. This is
achieved by the use of four parameters.
chg_element amr_fr_dl_la_enabled <*><site>cell = <cell_id>
<*> 0 – disabled
1 – enabled
Default = 1
chg_element amr_fr_ul_la_enabled <*><site>cell = <cell_id>
<*> 0 – disabled
1 – enabled
Default = 1
chg_element amr_hr_dl_la_enabled <*><site>cell = <cell_id>
<*> 0 – disabled
1 – enabled
Default = 1
chg_element amr_hr_ul_la_enabled <*><site>cell = <cell_id>
<*> 0 – disabled
1 – enabled
Default = 1

Version 1 Rev 1 Enabling/Disabling Link Adaptation
Enabling/Disabling Link Adaptation
BSC
BTS
Multi – Zone Cell

Single Zone cell
Enabling \ Disabling Parameters Per Cell
amr_fr_dl_la_enabled
amr_fr_ul_la_enabled
amr_hr_dl_la_enabled
amr_hr_ul_la_enabled
SYS12_amr_11

AMR FR/HR Commands to Specify ACS and Associated Parameters Version 1 Rev 1
AMR FR/HR Commands to Specify ACS and Associated

Parameters
The database parameter chg_acs_params is dealt with here. For this parameter to take
effect the BTS type must be AMR capable. Namely these are solely Horizonmacro
cabinets, solely MCell2/6 cabinets or a mixture of Horizonmacro and MCell2/6. The AMR
firmware is available on CTU, TCUA and TCUB. Also AMR Full–Rate or Half–Rate must
be enabled in the cell for the AMR parameters to come into effect. This command allows
the parameters to be set before or after AMR is enabled in the cell, thereby allowing the
performance to be optimised for calls subsequently initiated in the cell.
chg_acs_params <mode> <cell_id>
mode = 0 Full rate
1 Half rate
2 Both rates
This command is used to specify up to 4 codec modes, to be used in the ACS,
associated thresholds and hysteresis values for the cell.
Depending on whether Full rate, Half rate or both is entered a number of further prompts
are displayed. On this page are the prompted parameters for Full rate.
Active Codec Set values 0 12.20kbps
1 10.20kbps
2 7.95kbps
3 7.40kbps
4 6.70kbps
5 5.90kbps
6 5.15kbps
7 4.75
The BSS supports 12.2, 10.2, 7.4, 6.7 and 5.15kbps for a FR channel.
Enter AMR Full Rate active codec set : Range 0,1,3,4 and 6
Parameter: amr_fr_acs
Description: Up to 4 AMR codec modes that can be used for any given voice call in the
uplink or downlink direction.
Default (0,1,3 and 6)
Enter AMR Full Rate initial codec mode : Range 0,1,3,4 and 6
Parameter: amr_fr_initial_codec_mode
Description: Codec mode used at the beginning of a call. If one mode is entered for FR
ACS, then the FR Initial Codec Mode will default to this if valid.
Default: 1
Enter AMR Full Rate uplink adaptation thresholds : Range 0 to 63 (0.5dB steps)
Parameter(s): amr_fr_uplink_threshold3
amr_fr_uplink_threshold2
amr_fr_uplink_threshold1
Description: Lower Full–rate uplink decision threshold for switching from one mode to
another.
Default: 20, 14 and 9 (10dB, 7dB and 4.5dB).

Version 1 Rev 1 AMR FR/HR Commands to Specify ACS and Associated Parameters
Full–Rate Example
Note: In this example previously only one mode was configured
MMI – RAM 0115 –> chg_acs_params 0 2 3 4 0 2 678 01
AMR Full Rate active codec set : 1
AMR Full Rate initial codec set : 1
Enter AMR Full Rate active codec set : 1 3 4 6
Enter AMR Full Rate initial codec mode : 1
Enter AMR Full Rate uplink adaptation thresholds : 40 30 20
Enter AMR Full Rate uplink adaptation hysteresis : 1 1 2
Enter AMR Full Rate downlink adaptation thresholds : 45 35 25
Enter AMR Full Rate downlink adaptation hysteresis : 1 1 2
Enter AMR Full Rate uplink adaptation thresholds for frequency hopping : 16 11 4
Enter AMR Full Rate uplink adaptation hysteresis for frequency hopping : 1 1 1
Enter AMR Full Rate downlink adaptation thresholds for frequency hopping : 27 22 14
Enter AMR Full Rate downlink adaptation hysteresis for frequency hopping : 1 1 1
COMMAND ACCEPTED
SYS12_amr_06

AMR FR/HR Commands to Specify ACS and Associated Parameters–Cont’d Version 1 Rev 1
AMR FR/HR Commands to Specify ACS and Associated

Parameters–Cont’d
Enter AMR Full Rate uplink adaptation hysteresis : Range 0 to 15 (0.5dB steps)
Parameter(s):
amr_fr_uplink_hystersis3
Description: The sum of the associated threshold and hysteresis is used as the upper
decision threshold for switching the codec mode.
Default: 1,1,1 (0.5dB).
Enter AMR Full Rate downlink adaptation thresholds : Range 0 to 63 (0.5dB steps)
Parameter(s): amr_fr_downlink_threshold3
amr_fr_downlink_threshold2
amr_fr_downlink_threshold1
Description: Lower Full–rate downlink decision threshold for switching from one mode to
another.
Default: 30, 24 and 19 (15dB, 12dB and 9.5dB).
Enter AMR Full Rate downlink adaptation hysteresis :
Parameter(s):
amr_fr_downlink_hystersis3
Description: The sum of the associated threshold and hysteresis is used as the upper
decision threshold for switching the codec mode.
Default: 1,1,1 (0.5dB).
Enter AMR Full Rate uplink adaptation thresholds for frequency hopping:
Range 0 to 63 (0.5dB steps)
Parameter(s):
amr_fr_uplink_threshold3_hopping
Description: Uplink switching thresholds applied to frequency hopping channels.
Default: 16, 11 and 4 (8.0dB, 5.5dB and 2.0dB)
Enter AMR Full Rate uplink adaptation hysteresis for frequency hopping:
Parameter(s):
amr_fr_uplink_hystersis3_hopping
Description: Uplink hysteresis applied to frequency hopping channels
Default: 1, 1, 1 (0.5dB)
Enter AMR Full Rate downlink adaptation thresholds for frequency hopping:
Parameter(s):
amr_fr_downlink_threshold3_hopping

Version 1 Rev 1 AMR FR/HR Commands to Specify ACS and Associated Parameters–Cont’d
Full–Rate Example Non–Hopping
CODEC_MODE_4
1 – 10.2kbps 20 + 0.5 = 20.5dB Uplink
THR3 + HYST3 22.5 + 0.5 = 23dB Downlink
20dB Uplink THR3
CODEC_MODE_3 22.5dB Downlink
3 – 7.4kbps 15 + 0.5 = 15.5dB Uplink
15dB Uplink THR2
CODEC_MODE_2 17.5dB Downlink
4 – 6.7kbps
10 + 1 = 11dB Uplink
THR1 + HYST1 12.5 + 1 = 13.5dB Downlink
10dB Uplink THR1
12.5dB Downlink
Initial CODEC_MODE_1
Codec
6 – 5.15kbps
Mode
SYS12_amr_07

AMR FR/HR Commands to Specify ACS and Associated Parameters–Cont’d Version 1 Rev 1
Description: Downlink switching thresholds applied to frequency hopping channels

Default: 26, 21 and 14 (13.0dB, 10.5dB and 7.0dB)
Enter AMR Full Rate downlink adaptation hysteresis for frequency hopping:
Range 0 to 15 (0.5dB)
Parameter(s):
amr_fr_downlink_hystersis3_hopping
Description: Downlink hysteresis applied to frequency hopping channels.
Default: 1,1,1 (0.5dB)
Downlink Adaptation Change Minimum Time Period

In the case of downlink adaptation procedure it is possible to specify the minimum time
period between initiating changes in the downlink codec mode. When the parameter is
set to a value greater than the inherent delay in the adaptation process, a wait period is
added to slow down the adaptation.
chg_element amr_dl_la_mode_chg_min <*> 0
<*> 0 to 255 (ms) Default = 100ms

Version 1 Rev 1 AMR FR/HR Commands to Specify ACS and Associated Parameters–Cont’d
Full–Rate Example Hopping
C/I
CODEC_MODE_4
1 – 10.2kbps 8 + 0.5 = 9.5dB Uplink
8dB Uplink THR3

13.5dB Downlink
CODEC_MODE_3
3 – 7.4kbps 5.5 + 0.5 = 6dB Uplink
THR2 + HYST2 11 + 0.5 = 11.5dB Downlink
5.5dB Uplink THR2
CODEC_MODE_2 11dB Downlink
4 – 6.7kbps 2 + 0.5 = 2.5dB Uplink
THR1 + HYST1 7 + 0.5 = 7.5dB Downlink
2dB Uplink THR1
Initial CODEC_MODE_1 7dB Downlink

Codec
6 – 5.15kbps
Mode
SYS12_amr08

MS Monitor Functionality Version 1 Rev 1
MS Monitor Functionality
Full Rate AMR Link Adaptation introduces MS Monitor functionality that monitors and
compensates for the inability of some mobiles to accurately estimate the current
conditions of the channel that it is using. The threshold and hysteresis values supplied for
AMR calls by the network at call initialization may be ineffective for some mobiles in
certain RF conditions. The MS Monitor is introduced as a mechanism to adjust the
downlink codec mode adaptation thresholds during a call so that the MS is able to
correctly adapt across the ACS as needed. The MS Monitor works by monitoring a
mobile during a call and detecting conditions that indicate that the downlink codec mode
adaptation thresholds need adjusting. The MS Monitor will decrease the thresholds at the
MS if they are deemed to be too high and increase the thresholds if they appear to be too
low. If a mobile’s thresholds are too low, i.e. the range of C/I values that the MS is
measuring is below the lowest threshold in the ACS, then the mobile will request the
lowest codec mode whilst simultaneously indicating to the network that that call is in very
good RF quality conditions. The mobile could operate very well in these conditions in the
highest codec mode. The Monitor checks these conditions over a certain period of time
and if the quality of the call is high enough then the downlink adaptation thresholds will be
modified in the mobile. Similarly, the MS Monitor will increase the thresholds at the
mobile if the network sees that the MS is requesting the highest codec mode, whilst
indicating that the call is in poor RF quality conditions, as this would indicate that the
range of C/I values measured by the mobile were above the highest threshold in the
ACS.
Downlink Adaptation MS Monitor Parameters

The BSS MS Monitor, monitors AMR mobiles over a period defined as
amr_ms_monitor_period and collects CMR values and RXQUAL values. At the end of
this period the data that has been collected is processed and a decision made whether or
not to adapt the thresholds used by the mobile. The BTS shall monitor the Codec Mode
Request values for individual calls in order to determine mobiles for which the downlink
adaptation thresholds should be adjusted.
chg_element amr_ms_monitor_period <*> 0
<*> 10 to 120 (SACCH) Default = 40 (SACCH)
Description: Used for detecting MSs continually requesting the highest or lowest modes.
chg_element amr_ms_high_cmr <*> 0
<*> 50 to 100 (%) Default = 99%
Description: Percentages for monitoring AMR MSs continually requesting the highest codec mode.
chg_element amr_ms_low_cmr <*> 0
<*> 50 to 100 (%) Default = 95%
Description: Percentages for monitoring AMR MSs continually requesting the lowest codec mode.
chg_element amr_ms_high_rxqual <*> 0
<*> 0 to 7 (QBand Units) Default = 2.5% BER or QBand Unit 4
Description: Threshold for monitoring AMR MSs continually requesting the highest codec mode.
chg_element amr_ms_low_rxqual <*> 0
<*> 0 to 7 (QBand Units) Default = 0.5% BER or QBand Unit 2
Description: Threshold for monitoring AMR MSs continually requesting the lowest codec mode.
chg_element amr_dl_thresh_adjust <*> 0
<*> 1 to 7 (dB) Default = 3dB
Description: For applying compensation to the C/I adaptation thresholds.

Version 1 Rev 1 MS Monitor Functionality
MS Monitor Functionality
Rxqual Thresholds
0
When an AMR MS has requested
Lower threshold for
the lowest codec mode at least 95%
monitoring AMR MSs
(def) of the monitoring period
requesting the lowest
(40SACCH def)
2 codec mode
Default
Apply increase or decrease

to dl adaptation thresholds
4 Default
When an AMR MS has requested
Higher threshold for
the highest codec mode at least
monitoring AMR MSs
99% (def) of the monitoring period
requesting the highest
(40SACCH def)
codec mode
7
SYS12_amr_12

(AMR) Half Rate Handover and Power Control Parameters Version 1 Rev 1
(AMR) Half Rate Handover and Power Control Parameters

The ability to set unique thresholds for power control and handovers is allowed. This is
because the active codec set used in the cell will affect the thresholds. These additional
thresholds are AMR or GSM half rate specific, with existing parameters and levels still
applicable for non–AMR calls. The Rxlev thresholds applied for an AMR or GSM half rate
traffic channel remain the same as for existing call types (e.g. GSM FR and EFR
speech).
Full Rate
l_rxqual_ul_p_amr_fr (Def 226 BER or 4 QBand)
l_rxqual_ul_h_amr_fr (Def 453 BER or 5 QBand)
l_rxqual_ul_h_hopping_amr_fr (Def 453 BER or 5 QBand)
l_rxqual_ul_p_hopping_amr_fr (Def 113 BER or 3 QBand)
l_rxqual_dl_p_amr_fr (Def 113 BER or 3 QBand)
l_rxqual_dl_h_amr_fr (Def 226 BER or 4 QBand)
l_rxqual_dl_h_hopping_amr_fr (Def 0 BER or 0 QBand)
l_rxqual_dl_p_hopping_amr_fr (Def 0 BER or 0 QBand)
Half Rate
l_rxqual_ul_p_hr (Def 57 BER or 2 QBand)
l_rxqual_ul_h_hr (Def 113 BER or 3 QBand)
u_rxqual_ul_p_hr (Def 28 BER or 1 QBand)
l_rxqual_ul_h_hopping_hr (Def 0 BER or 0 QBand)
l_rxqual_ul_p_hopping_hr (Def 0 BER or 0 QBand)
l_rxqual_dl_p_hr (Def 57 BER or 2 QBand)
l_rxqual_dl_h_hr (Def 113 BER or 3 QBand)
u_rxqual_dl_p_hr (Def 14 BER or 0 QBands)
l_rxqual_dl_h_hopping_hr (Def 0 BER or 0 QBand)
l_rxqual_dl_p_hopping_hr (Def 0 BER or 0 QBand)
All range values 0 to 1810 BER if alt_qual_proc = 0
0 to 7 QBand if alt_qual_proc = 1

Version 1 Rev 1 (AMR) Half Rate Handover and Power Control Parameters
(AMR) Half Rate Handover and Power Control Parameters
Rxqual Thresholds
BER QBands
0 0
u_rxqual_xx_x_hr
The ability to set
unique handover and
power control
thresholds for half rate
is supported
l_rxqual_xx_x_xx
1810 7
SYS12_amr_13

AMR or GSM Half–Rate Intracell Handovers Version 1 Rev 1
AMR or GSM Half–Rate Intracell Handovers

The support of intra–cell quality handovers for half–rate channels is provided by the
database parameter hr_intracell_ho_allowed.
For interference based handovers it further specifies the possible target channel types
i.e. full and/or half rate. A Half rate channel will be targeted where the BSS
force_half_rate usage flag is set, or in the case where half rate usage is linked to
congestion, if either the new_calls_hr or the reconfig_fr_hr thresholds have been
reached. A full rate channel will be targeted in all other cases.
For quality based intracell handovers, it is possible to either disable (by disabling all
intracell handovers) or support targeting of a full rate resource. A half rate resource is not
a supported target for quality based intracell handovers.
This has four settings listed below:
chg_element hr_intracell_ho_allowed <*> <site> cell = <cell_id>
<*>
0 – Half–rate intra–cell quality handovers are not initiated by the BSS. Handover required
sent to the MSC.
1 – Half–rate intra–cell handovers are disabled. Handover required is not sent to the
MSC.
2 – Half–rate intra–cell handovers are enabled. Full–rate only is allowed for interference
and quality based handover.
3 – Half–rate intra–cell handovers are enabled. Half–rate and full–rate are allowed for
interference based handover. Full–rate only allowed for quality based handover.
Related controls
force_hr_usage
When set will allow targeting of half rate channels for interference based handovers with
a hr_intracell_ho_allowed setting of 3. Overriden by a setting of 2 (full rate only) and
ignored for settings of 0 or 1 (internal handovers either not supported or disabled).
Unless disabled (settings of 0,1), quality based handovers will always target full rate
channels.
new_calls_hr/reconfig_fr_hr
When cell congestion exceeds either threshold, interference based handovers will target
half rate channels with hr_intracell_ho_allowed setting of 3, full rate targeted with a
setting of 2. Unless disabled (settings of 0, 1), quality based handovers will always target
full rate channels.

Version 1 Rev 1 AMR or GSM Half–Rate Intracell Handovers
(AMR) Half–Rate Intracell Handovers
BTS
7 7
0 0
hr_intracell_ho_allowed (enabled)
SYS12_amr_14

AMR or GSM Half Rate Intra–cell Handover Hop Count Version 1 Rev 1
AMR or GSM Half Rate Intra–cell Handover Hop Count

A unique hop count counter is provided for AMR or GSM half rate intra–cell quality
handovers from half–rate channels is provided for by the database parameter
hr_fr_hop_count.
chg_element hr_fr_hop_count<*><site> cell = <cell_id>
<*> 0 to 255 Default = 1
Used in conjunction with hr_intracell_ho_allowed to restrict the number of intracell
handovers between half rate and full rate in any one (hop_count_timer) period (see also
hop_count). For a call switching between a half rate channel and a full rate channel, the
BSS shall disable intracell handovers and retain on a full rate channel when this
threshold (and/or the existing hop_count threshold) is reached. Half rate support shall
be re–enabled at expiry of the hop_count_timer period.
hop_count
Used in conjunction with hr_intracell_ho_allowed to restrict the number of intracell
handovers. Considers existing full to full and new half to half and/or half to full rate
handovers. For half rate intracell handovers with full rate target channel support only
(hr_intracell_ho_allowed settings of 2 or 3 based on handover type as above) either
this and/or hr_fr_hop_count being reached will disable intracell handovers from the
allocated full rate channel for the remainder of the hop_count_timer period. This shall
cover congestion based handovers requiring a half rate channel i.e. full rate calls with
intracell handovers currently suspended due to reaching the hop_count limit shall not be
subject to full to half rate reconfiguration when instigated for a cell. For a call on a half
rate channel with intracell handovers currently disabled, qualification for a quality based
intracell handover shall be considered as imperative and an intracell handover to full rate
performed where possible – as intracell handovers are disabled the call shall be retained
on the new full rate channel for the remainder of the hop_count_timer period.

Version 1 Rev 1 AMR or GSM Half Rate Intra–cell Handover Hop Count
AMR or GSM Half Rate Intra–cell Handover Hop Count
BTS
7 7
0 0
hr_fr_hop_count (reached) within hop_count_timer
Or for all intra–cell handovers hop_count (reached) within hop_count_timer
SYS12_amr_15

AMR or GSM Half Rate Intra–cell Handover Hop Count Version 1 Rev 1

Chapter 6
Lab Exercises

Version 1 Rev 1

Version 1 Rev 1
Chapter 6
Lab Exercises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Lab Worksheets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–1
Lab Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–2
CTP Traces using MMI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–8
Using TEMS Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–9
Using MDTT Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–10
Lab Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–11
Lab Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–12
Exercise 1 – Directed Retry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–13
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–13
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–13
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–14
Exercise 2 – Congestion Relief Type 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–15
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–15
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–16
Final Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–16
Exercise 3 – Congestion Relief Type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–17
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–17
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–18
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–19
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–19
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–20
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–21

Version 1 Rev 1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–22
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–23
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–24
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–25
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–26
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–27
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–28
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–29
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–29
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–31
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–31

Version 1 Rev 1

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–32
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–32
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–33
Exercise 11 – Adjacent Channel Interference Avoidance Test . . . . . . . . . . . . . . . . . . . . . 6–34
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–34
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–34
Exercise 12 – Micro – Micro Quality Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–35
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–35
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–35
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–36
Exercise 13 – Power Based Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–37
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–37
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–37
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–38
Exercise 14 – Interference Based Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–39
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–39
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–39
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–40
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–41
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 v

Version 1 Rev 1
Exercise 15 – Multiband Handovers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–42

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–42
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–42
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–43
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–44
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–45
Exercise 16 – Single BCCH (SBCCH) Multiband Handover . . . . . . . . . . . . . . . . . . . . . . . 6–46
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–46
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–47
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–48
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–48
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–49
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–50
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–50
vi wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1
Exercise 17 – Intelligent Multilayer Resource Management . . . . . . . . . . . . . . . . . . . . . . . 6–51

Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–51
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–52
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–52
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–53
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–53
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–54
Exercise 18 – Coincident Multiband . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–55
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–55
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–55
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–56
Exercise 18 – GSM Half Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–57
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–57
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–58
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–58
EMOTOROLA LTD. 2005 wks 04: Handover detection and power control workshops 2 vii

Version 1 Rev 1
viii wks 04: Handover detection and power control workshops 2 EMOTOROLA LTD. 2005

Version 1 Rev 1 Lab Worksheets
Lab Worksheets
Objectives
S Complete procedures to use CTP to analyse calls
S Complete procedures to use TEMS software to analyse calls
S Complete procedures to use MDTT software to analyse calls
S Complete the lab worksheet for directed retry
S Complete the lab worksheets for congestion relief
S Complete the lab worksheets for microcellular handovers
S Complete the lab worksheets for concentric cells
S Complete the lab worksheets for multiband handovers
S Complete the lab worksheet for half rate

Lab Introduction Version 1 Rev 1
Lab Introduction
Lab exercises give you opportunity to practise using some parameters and processes
covered during the workshop presentations. The students will split up to maximum of two
teams, where each team will perform all of these exercises.
Team members will have the following to perform the exercises:
1. Three Cells ( Server, Neighbor and Interferer)
2. Mobile Station with a valid SIM card
3. CTP Workstation
4. MDTT Software connected to the Mobile Station
5. OMC Session
When following an exercise steps, the cells are referred to as Cell S, Cell N1, Cell N2
and Cell N3.
Team 1 Cells
Cell BCCH NON BCCH CGI
S
N1
N2
N3
Team 2 Cells
Cell BCCH NON BCCH CGI
S
N1
N2
N3
The frequencies chosen at the beginning of the course could change depending on the
signal strength of the surrounding network cells. The RF we use on this course is the bit
of leakage that occurs when terminating into the dummy loads and RF cabling. Whilst
this does not in fact radiate very far, we have to try to prevent any interference to MS
users within the immediate area.

Version 1 Rev 1 Creating CTP Traces
Creating CTP Traces

In almost all lab exercises, a trace is needed to view the results. The trace is simply a
process that can be started for each cell that will gather information for calls running in
that cell. The traces can be configured in various ways.
For our purposes a trace is to be created for cells A & B for each team. To create a trace
follow the following steps:
1. Start OMC Configuration Management – the circled item on the OMC GUI Below
wkshp01ch61

Creating CTP Traces Version 1 Rev 1
2. Expand the Tree until you reach the cell for which a Trace is to be created
wkshp01ch62

Creating CTP Traces

3. Choose the cell for which a trace is to be created
4. From the Options Menu choose Call trace and then Choose Create Trace
wkshp01ch63
5. Start filling the Trace Information

6. Give the Trace a Name for example Team1–A–1
7. Scroll down till you reach ”Continue Beyond Scope”
8. For ”Continue Beyond Scope” choose Yes
9. For Max Total Calls type 100
10. Scroll down till you reach ”Record Type”
11. For ”Record Type” Choose Radio
12. Scroll down till you reach ”RSS Measurement Interval”
13. In RSS Measurement Interval type 1

14. From the file menu choose create

15. This will create the Trace and you can watch its status in the Trace View window

wkshp01ch64

16. The Trace View window can be accessed by
a. Choosing the cell in the main navigation form
b. From Options menu choose Call Trace
c. Choose View Trace
wkshp01ch65
CTP Traces using MMI

See W23.

Version 1 Rev 1 Using TEMS Software
Using TEMS Software

Message and parameter display
S Layer 2 messages
S Layer 3 messages
S Details of the serving cell
S Details of the neighbour cells
S Details of the dedicated channel
S Details of radio channel
S Graphical representation
Mobile control
S Frequency scanning
S Cell selection and reselection control
S Handover control
S SIM card handling
S MS properties control
Network analysis
S Traffic channel testing
S Layer 3 message control
S Hypotheses testing
Receive and replay modes
This information can be displayed in the following modes:
Receive raw data: TEMS receives messages and parameters from the phone and
displays them in real time. It can record the data in log files for future replay.
Replay log file: TEMS replays messages and parameters from previously recorded log
files.
Export data
Messages and parameters can be exported from previously recorded log files to an Excel
worksheet.

Using MDTT Software Version 1 Rev 1
Using MDTT Software

Message and parameter display
MDTT decodes selected GSM and GPRS air information messages. It uses the decoded
messages to provide the following information:
S Layer 3 messages.
S RLC/MAC messages.
S LLC messages.
S Details of the serving cell.
S Details of neighbouring cells.
S Radio parameters charts.
S Data transfer parameter charts.
S LLC parameters.
S Errors.
Receive and replay modes
This information can be displayed in the following modes:
Receive raw data: MDTT receives messages and parameters from the phone and
displays them in real time. It can record the data in log files for future replay.
Replay log file: MDTT replays messages and parameters from previously recorded log
files.
Export data
Messages and parameters can be exported from previously recorded log files to an
Excel worksheet.

Version 1 Rev 1 Lab Layout
Lab Layout
The MSC simulator is provided by a Tekelec or Nethawk. There are 8 CIC’s equipped
from CIC number 1 to 8. In total there are 8 BTS sites which have been grouped into two
test areas for completion of the lab exercises. Each BTS has two carriers, sites 1,2 and 3
are Incell and sites 11 and 12 are MCell2’s , 23 and 24 are Mcellmicros. Initially (template
database) the priority for the traffic channels is placed on the non bcch carriers. This
allows tests to be carried out on BTS power control because downlink power control is
not allowed on bcch carriers.

Lab Layout Version 1 Rev 1
Lab Layout
Kilkenny Config Soft Switch or Tekelec
OMC Server
RXCDR 02
OMC Server
BSC 01
BTS 2 BTS 3 BTS 4 BTS 5 BTS 6 BTS 7
hdpc2_ch6_killab1
BTS Site 6 BTS Site 3 BTS Site 4

1800
1800
1800
900
1800
900
900
1800
BTS Site 7 BTS Site 2 BTS Site 5

900
900
900
900
1800
900
900
1800
hdpc2_ch6_killab2

Version 1 Rev 1 Exercise 1 – Directed Retry
Exercise 1 – Directed Retry
Objectives
To observe the directed retry feature in action and become more familiar with the
database parameters that control the feature.
Initial Settings
Set the timer BSSMAP_T11 to 20000 bssmap_t11
Set the congestion handover margin to –4 from S to N modify_neighbor
Enable directed retry within the BSC dr_preference
Enable directed retry within Cell S dr_standard_congest
Set Cell S receive level to approx –80dBm max_tx_bts
Set Cell N power approx –82dBm max_tx_bts
Lock all tch timeslots on Cell S lock_device, pchn
From the MDTT window make sure that the difference in signal level between Cell S and
Cell N1 is not more than 4 dBs
Start a call on cell S for 30 seconds noting that the call handed over to Cell N1
Terminate the call either from MS
Notice that cell S trace view should have no active calls and one completed call
Student Analysis
Place the cursor on the handover recognised message.
Conclusions
Check the CTP log to make sure that the handover recognised message was sent with a
directed retry cause value.
Calculate criteria 2 for the neighbour to confirm correct neighbour selection.
What is downlink receive level from the serving cell? __________________
What is the downlink receive level from the neighbour cell? _________________
What is the power class of the MS? _________________
What is the ms_txpwr_max of the serving cell? _________________
What is the ms_txpwr_max of the neighbour cell? _________________
What is the max_tx_bts of the serving cell? _________________
What is the actual output power of the BTS? _________________
What is the cong_ho_margin for the neighbour cell? ________________
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
You know have all the information necessary to calculate the power budget then see
whether the neighbour is qualified at that point in time for a directed retry handover.

Exercise 1 – Directed Retry Version 1 Rev 1
Pbgt(n) = [min(ms_txpwr_max, P) – rxlev_dl – PWR_C_D] – [min(ms_txpwr_max,

P) – rxlev_dl]
Now calculate the power budget.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
pbgt(n) – ho_margin_cong(n) > 0
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
Set bts power to so it falls more than 4dB below that of the serving cell max_tx_bts
Make sure from MDTT that Cell S rxlev is higher than Cell B rxlev by more than 4dBs
Try to start a call on cell S
Student Analysis
Place the cursor anywhere within the timeline of the call.
Conclusions
Check the CTP log and explain why the call is never able to move from the SDCCH to
TCH.
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Candidate signature Trainers signature Date
–––––––––––––––– ––––––––––––– –––––––––––––

Version 1 Rev 1 Exercise 2 – Congestion Relief Type 1
Exercise 2 – Congestion Relief Type 1
Objectives
To observe the Congestion Relief Type 1 feature in operation and become more familiar
with the applicable database parameters.
Initial Settings
Disable all handover types so will only handover for congestion dl_rxqual_ho_allowed
ul_rxqual_ho_allowed
interfer_ho_allowed
dl_rxlev_ho_allowed
ul_rxlev_ho_allowed
pwr_handover_allowed
distance_ho_allowed
Disable directed retry within the BSC dr_preference
Disable directed retry within Cell S dr_standard_congest
Enable Congestion Relief Type 1 in Cell S ho_exist_congest
Set the congestion margin to –4dB from Cell S to Cell N1 modify_neighbor
Congestion relief is to be triggered whenever all TCH’s are in use and at least one more
TCH is requested tch_congest_prevent_thres
Set the maximum power on Cell S to 29dB max_tx_bts
Set the maximum power on Cell N1 to 21dB max_tx_bts
Lock all but two tch timeslots on Cell S lock_device, pchn
Student Activity
Start two calls on Cell S, this will consume the remaining TCHs
Increase Cell N power until it is less than Cell S power by not more than 4dB (remember
congestion handover margin is –4dB)
Start another call on Cell S
Terminate the calls after about 2.5mins

1 st Call – Call Start Time..................... SCCP Reference Number.................... .
2 nd Call – Call Start Time..................... SCCP Reference Number.................... .
3 rd Call – Call Start Time..................... SCCP Reference Number.................... .
Student Analysis
From CTP check where both the first, second and third call ended up after the third call
moved onto a traffic channel.

Exercise 2 – Congestion Relief Type 1 Version 1 Rev 1
Conclusions
First call carrier___________ and timeslot __________
Second call carrier ___________ and timeslot __________
Third call carrier ___________ and timeslot __________
For the call that experienced the handover what was the handover cause value?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
What conclusions do you draw from this exercise?
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Final Settings
Do not return the settings to template database, they should be kept for the exercise for
congestion relief type 2.

–––––––––––––––– ––––––––––––– –––––––––––––

Exercise 3 – Congestion Relief Type 2
Objectives
To observe the Congestion Relief Type 2 feature in operation and become more familiar
with the applicable database parameters.
To observe the effect of the enhanced relief database parameter.
Initial Settings
Enable Congestion Relief Type 2 in Cell S ho_exist_congest
Disable congest at source in Cell S and N1 congest_at_source
Disable congest at target in Cell S and N1 congest_at_target
Disable enhanced relief at Cell S and N1 enhanced_relief
Set the congestion margin to –4dB from Cell S to Cell N1 and N2 modify_neighbor
Congestion relief is to be triggered whenever all TCH’s are in use and at least one more
TCH is requested in Cell S anc Cell N1 tch_congest_prevent_thres
Set the maximum power on Cell S to 29dBm max_tx_bts
Set the maximum power on Cell N1 to 21dBm max_tx_bts
Lock all but two timeslots on Cell S lock_device, pchn
Student Activity
Start two calls on Cell S, this will consume the remaining TCHs
Increase Cell N1 power until it is less than Cell S power by not more than 4dB
(remember congestion handover margin is –4dB)
Terminate the calls after about 2.5mins

Student Analysis
From CTP check where both the first, second and third call ended up after the third call
moved onto a traffic channel.

Conclusions
Third call carrier ___________ and timeslot __________
For the call that experienced the handover what was the handover cause value?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
From the previous activity what differences between do you think there are between
congestion relief type 1 and congestion relief type 2?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
In this part of the exercise we are going to investigate the effect of enabling congestion
relief at the neighbour cell N1.
Enable congestion relief type 2 at Cell N1 ho_exist_congest
Lock all tch timeslots except three on Cell N1 lock_device, pchn
Student Activity
Start one call on Cell S.
Start two calls on Cell N1 to take two of the available tch timeslots.
Increase Cell N2 power until it is less than Cell N1 power by not more than 4dB
(remember congestion handover margin is –4dB).
Start another call on Cell S.
Terminate the calls after about 2.5mins.
4 th Call – Call Start Time..................... SCCP Reference Number.................... .
Student Analysis
From CTP check where both the first, second and third calls ended up. Then check if the
fourth call was able to take a channel.

Conclusions
Third call carrier___________ and timeslot___________
Explain what happened to the fourth call.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
In this part of the exercise we are going to investigate the effect of the effect of the
enhanced relief parameter.
Enable the enhanced relief parameter in Cell N1 enhanced_relief
All other database parameters remain the same.
Student Activity
Repeat the previous activity.

Student Analysis
From CTP check where both the first and second call ended up. Then check if the fourth
call was able to take a channel.
Conclusions
Third call carrier _____________ and timeslot ___________
Was the fourth call able to take a TCH? Explain the results.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
In this part of the exercise we are going to investigate the effect of the effect of the
congest at target parameter on an incoming non imperative congestion handover.
Enable the congest at target parameter in Cell N1 congest_at_target
All other database parameters remain the same.

Student Activity
Repeat the previous activity.
Student Analysis
From CTP check where both the first and second call ended up. Then check if the fourth
call was able to take a channel.
Conclusions
Third call carrier _____________ and timeslot ___________
Was the fourth call able to take a TCH? Explain the results.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
In this part of the exercise we are going to further investigate the effects of the enhanced
relief database parameter. We have seen from the previous exercise that the target cell
will not accept the handover if its cause value of the handover is congestion and the
congestion criteria has been met in the target cell. Now for the same set of
circumstances we are going to see if the target cell will accept an imperative cause value
for the handover.
Enable dl rxlev handovers in Cell S dl_rxlev_ho_allowed
Set the trigger level for dl rxlev handovers to –50dBm l_rxlev_dl_h
Enable per cause value handover margins ho_margin_usage_flag
Set handover margin for rxlev to –20dB modify_neighbor
Note: By default the n = p = 1 and hreqave = 4 and hreqt = 1 for dl rxlev handovers.
Also inter_cell_handover_allowed = 1.
Student Activity
Start one call on Cell S, the rxlev should be less than –50dBm therefore triggering the
downlink rxlev handover..
Terminate the call after about 2.5 mins.
Call Start Time..................... SCCP Reference Number.................... .

Student Analysis
From CTP check that the conditions were met for a dl rxlev handover to take place.
Conclusions
Was the rxlev dl handover from Cell S able to take place?.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
Now we are going to enable the congest at source parameter in Cell S.
Student Activity
Start one call on Cell S, the rxlev should be less than –50dBm therefore triggering the
downlink rxlev handover..
Terminate the call after about 2.5 mins.
Student Analysis
From CTP check that the conditions were met for a dl rxlev handover to take place.
Conclusions
Was the rxlev dl handover from Cell S able to take place?.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Return all the database settings to their default values.

–––––––––––––––– ––––––––––––– –––––––––––––

Exercise 4 – PBGT Algorithm Type 1 Version 1 Rev 1
Exercise 4 – PBGT Algorithm Type 1
Objectives
To observe Type 1 Power Budget Algorithm handovers in action.
To become more familiar with the database parameters that control Power Budget Type 1
handovers.
Initial Settings
Turn off all handovers except power budget on cell S pwr_handover_allowed
Set maximum ms transmit power to 19 dBm on S max_tx_ms
Set ms_txpwr_max to 19 dBm for cell N1 as a n/bour to cell S ms_txpwr_max_cell
Disable pwr cntl for both ul and dl on cells S & N1 ms_power_control_allowed
bts_power_control_allowed
Please note that by now the only thing that controls the power budget formula is the
downlink receive signal level
Set the power on cell S to 25 dBm max_tx_bts
Set power on cell N1 to 19 dBm max_tx_bts
Set handover margin between S and N1 to 4 ho_margin_cell
Use the per cell hreqave value for the pbgt handover use_neighbor_pbgt_hreqave
Set the per cell hreqave to 5 surround_cell, hreqave
Set the per neighbour hreqave for PBGT HO between S & N1 to 10 modify_neighbor
Set hreqave for averaging downlink level to 1 rxlev_dl_ho, hreqave
Set the decision pointers to relevant bins decision_1_p_bgt_rxlev_av_h
Student Activity
Start a call on cell S
Start increasing the power of cell N1 max_tx_bts
Notice when the handover occurs
Terminate the call
Student Analysis
Display RxLevDown, N1_RxlevDown ABIS, BSSMAP and DTAP messages.
Conclusions
Examine results on CTP and verify the handover trigger is better cell.
Confirm by calculation that the trigger point occurs in the correct place. To calculate this
you will need:
hreqave ______________
ho_margin _________________
receive level downlink from server _________________
receive level downlink from neighbour __________________
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Version 1 Rev 1 Exercise 4 – PBGT Algorithm Type 1
Further Settings
Set cell N1 power back to 19 dBm max_tx_bts
Use the per neighbor hreqave value for the pbgt ho use_neighbor_pbgt_hreqave
Student Activity
Terminate the call
Student Analysis
Display RxLevDown, N1_RxlevDown ABIS, BSSMAP and DTAP messages.
Conclusions
you will need:
hreqave ______________
ho_margin _________________
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––– ––––––––––––– –––––––––––––


To observe the type 2 power budget algorithm in action.
To become more familiar with the database parameters that control power budget type 2
algorithm.
Initial Settings
Change Cell N1 to power budget type 2 modify_neighbor
Change Cell N2 to power budget type 4 with a timer value of 0 modify_neighbor
Set initial power level of all Cells S and N1 to 23dBm max_tx_bts
Set the power level of Cell N2 to 23dBm max_tx_bts
Enable power budget handovers pwr_handover_allowed
Disable all other handover types dl_rxqual_ho_allowed
ul_rxqual_ho_allowed
interfer_ho_allowed
dl_rxlev_ho_allowed
ul_rxlev_ho_allowed
Student Activity
Start increasing cell N1 power until PBGT(n) – ho_margin(n) > 0 max_tx_bts
Terminate the call
Student Analysis
Display BTS Power, RxlevDown, N1_RxlevDown and ABIS, BSSMAP, DTAP messages.
Conclusions
Was a power budget handover triggered between Cells S and N? Please state reasons
for your results.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
In this part of the exercise we are going to create the conditions for an imperative
handover to take place between Cells S and N1.
Enable dl rxlev handovers dl_rxlev_ho_allowed
Enable the per cause handover margin ho_margin_usage_flag
Set the handover margin rxlev to 4dB for Cells N1 and N2 modify_neighbor
Note: By default the n = p = 1 and hreqave = 4 and hreqt = 1 for dl rxlev handovers.
Also inter_cell_handover_allowed = 1.

Student Activity
Start decreasing Cell S power until the conditions for the rxlev handover are met
max_tx_bts
Terminate the call
Student Analysis
Conclusions
Which cell did the MS handover to? Explain the reasons.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
–––––––––––––––– ––––––––––––– –––––––––––––


To become more familiar with the database parameters that control the power budget
type 3 algorithm.
Initial Settings
Enter the uplink receive level threshold of the serving cell to 63 (–47dBm)
Enter the downlink receive level threshold of the serving cell to 30 (–80dBm)
Set initial power level of Cells S and N1 to 23dBm max_tx_bts
Set the power level of Cell N2 to 33 dBm max_tx_bts
Enable dl power control on Cell S bts_power_control_allowed
Enable ul power control on Cell S ms_power_control_allowed
Lock all BCCH tch timeslots lock_device pchn
Set the ho margin cell to 6dB for both Cells N1 and N2 modify_neighbor
Note: In this exercise we are going to move the MS to the non BCCH carrier so we can
see the effect off power control on the type 3 algorithms. Also to make the analysis
simplier the ul rxlev threshold has been set to –47dBm so it always qualifies.
Student Activity
Start a call on Cell S
Start increasing Cell N1 power until PBGT(n) – ho_margin(n) > 0
max_tx_bts
If the rxlev dl from serving cell is better or equal to –80dBm then decrease power of
serving cell max_tx_bts
Terminate the call
Student Analysis
Conclusions
Was a power budget handover triggered between Cells S and N1? Please state reasons
for your results.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Note: To check the rxlev thresholds you will need to input values into the algorithms:
adaptive level dl = Av dl rxlev + (Max BTS Power – Actual BTS Power)
adaptive level ul = Av ul rxlev + (Max MS Power – Actual MS Power)

Further Settings
In this part of the exercise we are going to lock all the tch timeslots on the type 3
neighbour (Cell N1) and create the conditions for a PBGT handover to Cell N1.
Lock all tch time slots on Cell N1 lock_device pchn
Student Activity
Start increasing Cell N1 power until PBGT(n) – ho_margin(n) > 0
max_tx_bts
If the rxlev dl from serving cell is better or equal to –80dBm then decrease power of
serving cell max_tx_bts
Terminate the call
Student Analysis
Conclusions
What happened now that all the tch timeslots are locked. Please state reasons for your
results.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Note: To check the rxlev thresholds you will need to input values into the algorithms:
adaptive level dl = Av dl rxlev + (Max BTS Power – Actual BTS Power)
adaptive level ul = Av ul rxlev + (Max MS Power – Actual MS Power)

–––––––––––––––– ––––––––––––– –––––––––––––

Objectives
algorithm.
Initial Settings
Enter the qualifying time threshold to 100 SACCH
Set initial power level of all Cells S and N1 to 23dBm max_tx_bts
Disable dl power control bts_power_control_allowed
Set ho margin cell to 6dB for both Cells N1 and N2 modify_neighbor
Student Activity
Start increasing Cell N1 power until a Pbgt ho would normally occur (must be done in
50s) max_tx_bts
After a handover occurs terminate the call.
Student Analysis
Display BTSpower, RxlevDown, N1_RxlevDown and N2_RxlevDown.
Conclusions
Examine the CTP log and verify the trigger is Better Cell
Which cell did the MS handover to and why?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
How long did it take for the handover to occur? __________________
When would a handover to the Type 2 neighbour occur?
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Return the power level of Cell N1 to 23dBm max_tx_bts

–––––––––––––––– ––––––––––––– –––––––––––––

Objectives
algorithm.
Initial Settings
Enter the qualifying delay time to 100 SACCH
Enter the neighbour cell receive level threshold to –80dBm
Student Activity
Start increasing Cell N1 power until a Pbgt ho occurs (delay time is 50s max_tx_bts
Terminate the call

Student Analysis
Conclusions
Examine MDTT and CTP log and verify the trigger is Better Cell
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
When would a handover occur if the neighbour was a Type 1?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Return the ho margin from Cell S to Cell N2 back to 6dB ho_margin_cell
Further Settings
Set the ho_margin_type5 to 6dB modify_neighbor
Set the neighbour cell receive level threshold to –70dBm
Note: You will have to add Cell N1 as a type 5 neighbour again to change receive level
threshold.

Student Activity
Start increasing Cell N1 power until a Pbgt ho occurs (delay time is 50s) max_tx_bts
Note: In this case the receive level threshold should not be reached, but the PBGT
criteria should be. Check that this is so.
Terminate the call

–––––––––––––––– ––––––––––––– –––––––––––––

Objectives
algorithm.
Initial Settings
Enter the delay time to 100 SACCH
Enter the handover static offset to 10dB
Enter the handover dynamic offset to 10dB
Student Activity
Start increasing Cell N1 power until Pbgt – ho_margin(n) > 0 max_tx_bts
Wait for 50s until a Pbgt handover occurs
Terminate the call
Student Analysis
Display BTSpower, RxlevDown and N1_RxlevDown.
Conclusions
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––– ––––––––––––– –––––––––––––

Objectives
algorithm.
Initial Settings
Change Cell N1 to an adjacent channel frequency chg_rtf_freq
Enter the adjacent channel interference detection handover margin 9dB
Student Activity
Start increasing Cell N1 power until Pbgt – ho_margin(n) > 0 but not more than adjacent
channel interference detection handover margin max_tx_bts
Wait until a Pbgt handover occurs
Terminate the call
Student Analysis
Conclusions
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Student Activity
Adjust the adjacent channel interference detection margin so the adjacent channel
neighbour will trigger a handover to the type 2 neighbour modify_neighbor
Start increasing Cell N1 power until Pbgt – adjacent_channel_ho_margin > 0
max_tx_bts
Wait until a handover occurs
Terminate the call

Student Analysis
Conclusions
Examine MDTT and CTP log and verify the trigger is adjacent channel interference.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––– ––––––––––––– –––––––––––––

Exercise 11 – Adjacent Channel Interference Avoidance Test Version 1 Rev 1
Exercise 11 – Adjacent Channel Interference Avoidance Test
Objectives
To observe the adjacent channel interference avoidance test algorithm in action.
To become more familiar with the database parameters that control the adjacent channel
interference avoidance test.
Initial Settings
Change Cell N1 to power budget type 1 from source Cell S modify_neighbor
Enable adjacent channel interference avoidance test in both neighbours
Enter rxlev difference for adjacent channel interference avoidance test to –8dB
Set the handover margin to Cell N1 from Cell S to 2dB ho_margin_cell
Change the handover margin to Cell N2 from Cell S to 20dB ho_margin_cell
Student Activity
Note: The level of N2 should be about 6dB greater than N1, but the 20dB handover
margin to N2 will prevent a pbgt handover occurring to N2. If the levels actually
monitored in the lab don’t represent this, change the power of cells affected.
Start increasing the power of Cell N1 until a handover occurs
Terminate the call
Student Analysis
Conclusions
What happened when the level of Cell N1 increased above the handover margin?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
At what level in comparison to Cell S did the handover occur to Cell N1? State reasons
for this.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
–––––––––––––––– ––––––––––––– –––––––––––––

Version 1 Rev 1 Exercise 12 – Micro – Micro Quality Handovers
Exercise 12 – Micro – Micro Quality Handovers
Objectives
To observe the micro – micro rxqual handover algorithm in action.
To become more familiar with the database parameters that control the micro – micro
quality handover.
Initial Settings
Enter the qualifying time threshold to 0
Set the microcell priority to enabled on Cells S, N1 and N2 prioritize_microcell
Set layer number to 1 for Cells S and N1 layer_number
Set layer number to 0 for Cell N2 layer_number
Set ho_margin_cell to 63 for cells N1 and N2 modify_neighbor
Set ho_margin_usage_flag to enabled ho_margin_usage_flag
Set the ho_margin_rxqual to –20dB to Cells N1 and N2 from Cell S modify_neighbor
Note: For this exercise it is necessary to either create interference using another cell
(Cell I) or use the TEMs phone to modify the Rxqual bits in the uplink SACCH.
Set initial power level of Cells S to 23dBm max_tx_bts
Set the power level of Cell N1 and N2 to 33dBm max_tx_bts
Student Activity
Start increasing Cell I power until it creates enough interference to create a handover
max_tx_bts
Wait until a Rxqual handover occurs
Terminate the call
Student Analysis
Display BTSpower, RxlevDown, N1_RxlevDown, RxqualDown and N2_RxlevDown.
Conclusions
Examine MDTT and CTP log and verify the trigger is Rxqual_dl
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
Lock all the timeslots on Cell N1 lock_pchn

Exercise 12 – Micro – Micro Quality Handovers Version 1 Rev 1
Student Activity
Start increasing Cell I power until it creates enough interference to create a handover
max_tx_bts
Wait until a Rxqual handover occurs
Terminate the call
Student Analysis
Display BTSpower, RxlevDown, N1_RxlevDown, RxqualDown and N2_RxlevDown.
Conclusions
Examine MDTT and CTP log and verify the trigger is Rxqual_dl
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––– ––––––––––––– –––––––––––––

Version 1 Rev 1 Exercise 13 – Power Based Concentric Cells
Exercise 13 – Power Based Concentric Cells
Objectives
To observe the power based concentric cells algorithm in action.
To become more familiar with the database parameters that control the power based
concentric cells algorithm.
Initial Settings
Enable power based concentric cells inner_zone_alg
Set the maximum power for the inner zone to 33dBm ms_txpwr_max_inner
Set the zone handover hysterisis to 3dB zone_ho_hyst
Set the receive level downlink zone to –90dBm rxlev_dl_zone
Set the receive level uplink zone to –90dBm rxlev_ul_zone
Student Activity
Increase the transmit power of the BTS until the receive level beats the receive level
downlink zone and hysterisis max_tx_bts
Wait until the mobile moves to an inner zone resource
Terminate the call
Student Analysis
Display RxLevDown and BTSPower
Conclusions
Examine results on CTP
Place the cursor at the point the assignment command message is generated.
What is the dl receive level for the server at this point? __________________
Calculate that the trigger point for movement from the outer zone to the inner zone is
correct
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Exercise 13 – Power Based Concentric Cells Version 1 Rev 1
Student Activity
Decrease the transmit power of the BTS until the receive level falls below the receive
level downlink zone max_tx_bts
Wait until the mobile moves to an outer zone resource
Terminate the call
Student Analysis
Conclusions
Calculate that the trigger point for movement from the inner zone to the outer zone is
correct
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
–––––––––––––––– ––––––––––––– –––––––––––––

Version 1 Rev 1 Exercise 14 – Interference Based Concentric Cells
Exercise 14 – Interference Based Concentric Cells

Objectives
To observe the interference based concentric cells algorithm in action.
To become more familiar with the database parameters that control the interference
based concentric cells algorithm.
Initial Settings
Disable all intercell handovers inter_cell_handover_allowed
Enable interference based concentric cells inner_zone_alg
Set the neighbour report timer to 10 neighbor_report_timer
Enable Cell N1 as a type 1 neighbour modify_neighbor
Enable Cell N1 as a interfering neighbour modify_neighbor
Set the inner zone threshold to 9dB inner_zone_threshold
Set the inner zone margin to 3dB inner_zone_margin
Set the direct inner zone threshold to –47dBm direct_inner_zone_threshold
Set the maximum transmit power of Cell N1 to its minimum max_tx_bts
Set the transmit power of Cell S to 33dBm max_tx_bts
Change cell zone to 1 for rtf 01 on Cell S modify_value
Set outer zone usage level to 0 outer_zone_usage_level
Student Activity
Terminate the call
Student Analysis
Conclusions
What is the dl receive level for the neighbour at this point? ________________
Calculate that the trigger point for movement from the outer zone to the inner zone is
correct
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Exercise 14 – Interference Based Concentric Cells Version 1 Rev 1
Student Activity
Increase the power of the neighbour gradually until the mobile moves to the outer zone
Terminate the call
Return the power of the neighbour to its minimum
Student Analysis
Conclusions
Calculate that the trigger point for movement from the inner zone to the outer zone is
correct
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
Change the value of the direct inner zone threshold to enable direct zone access
Student Activity
Terminate the call
Student Analysis

Version 1 Rev 1 Exercise 14 – Interference Based Concentric Cells
Conclusions
Calculate that a direct inner zone assignment is made.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––– ––––––––––––– –––––––––––––

Exercise 15 – Multiband Handovers Version 1 Rev 1
Exercise 15 – Multiband Handovers

Objectives
To observe the multiband handover algorithm (ALM) in action. This includes handover on
sdcch, handover at anytime and handover for radio reasons.
To become more familiar with the database parameters that control the multiband
handover algorithm.
Initial Settings
Note: To achieve all the different permutations four cells will have to made available, two
900 and two 1800. We shall be investigating the the effects of the different.
Enable multiband handovers in all Cells mb_preference
Set frequency type to pgsm in Cell S, N2 and dcs1800 in cell N1, N3 frequency_type
Set interband handovers allowed between all four cells interband_ho_allowed
Enable power budget handovers between all four cells pwr_handover_allowed
Set the power level of Cell S 23dBm max_tx_bts
Set the power level of Cell N1, N2 and N3 to 33dBm max_tx_bts
Set the ho_margin_cell for cell N1 to 6dB modify_neighbor
Set the band preference to dcs1800 on cells S, N, N2 and N3 band_preference
Set the band preference parameter so it takes the strongest neighbour regardless of
band band_preference_mode
Student Activity
Start increasing the power of cell N1 (if required) max_tx_bts
Terminate the call
Student Analysis
Display RxLevDown, N1(to 3)_RxlevDown ABIS, BSSMAP and DTAP messages.
Conclusions
you will need:
hreqave ______________
ho_margin _________________
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Did the mobile handover to the expected neighbour cell?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Version 1 Rev 1 Exercise 15 – Multiband Handovers
Further Settings
Note. In this part of the exercise the first procedure is to be repeated with the exception
that the band preference mode is going to be enabled to handover for radio reasons to
the preferred band neighbour.
Set band preference mode so the call handover to the strongest preferred band
neighbour band_preference_mode
Conclusions
Examine results on CTP and verify what the handover trigger is.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
you will need:
hreqave ______________
ho_margin _________________
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
Note. In this part of the exercise we are going to try to continually handover the mobile
from a tch of the 900 serving cell to a tch of a dcs1800 neighbour without being triggered
by radio reasons.
Set band preference mode so the call handovers to the strongest dcs1800 neighbour cell
continually band_preference_mode

Exercise 15 – Multiband Handovers Version 1 Rev 1
Conclusions
Examine results on CTP, what is the handover trigger?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
you will need:
hreqave ______________
ho_margin _________________
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
For this part of the exercise we are going to look at the functionality of the advanced load
feature band preference mode. In particular the ability to be able to set up a call on a 900
cell, but take the tch from a dcs1800 cell.
Set the preferred band to dcs 1800 band_preference
Set band preference mode so the call is set up on sdcch of 900 cell but takes tch from
1800 cell band_preference_mode
Note: To enable this to work the hreqave for the neighbour cell must be four or less and
the database parameter sdcch_tch_band_reassign_delay be set to 4
Make sure hreqave for rxlev_dl serving cell and rxlev_dl neighbour cell is set to 4 or less.
rxlev_dl_ho
surround_cell
Student Activity
Terminate the call
Student Analysis

Version 1 Rev 1 Exercise 15 – Multiband Handovers
Conclusions
Examine results on CTP and verify the handover trigger is band reassignment.
Did the MS move from the sdcch of the 900 cell to the tch of the 1800 cell?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––– ––––––––––––– –––––––––––––

Exercise 16 – Single BCCH (SBCCH) Multiband Handover Version 1 Rev 1
Exercise 16 – Single BCCH (SBCCH) Multiband Handover

Objectives
To observe the Single BCCH multiband handover algorithm in action.
To become more familiar with the database parameters that control the Single BCCH
multiband handover algorithm.
Initial Settings
Note: For this exercise the coincident multiband feature must be disabled for the cells to
be used in this exercise. There are a number of sites with dual band cells, these should
conform to the database settings below, but it advisable to check.
Set the inner zone algorithm to 3 to enable SBCCH inner_zone_alg
Set secondary frequency type to dcs1800 secondary_freq_type
Set maximum base transmit power for the inner zone to 23dBm bts_txpwr_max_inner
Set maximum MS transmit power for the inner zone to 23dBm ms_txpwr_max_inner
Set handover power level for the inner zone to 5 ho_pwr_level_inner
Set inner zone handover hysteresis to 3dB zone_ho_hyst
Set downlink receive level threshold for the inner zone to –95dBm rxlev_dl_zone
Set uplink receive level threshold for the inner zone to –95dBm rxlev_ul_zone
Set dual band offset to –6dB dual_band_offset
Set the pbgt mode to allow the serving cell BCCH in the neighbour list pbgt_mode
Set the outer zone usage level to 0% outer_zone_usage_level
Set band preference to dcs1800 band_preference
Set band preference mode to handover to strongest neighbour of any band
band_preference_mode
Note: In a dual band cell the parameter transmit power capability must be set to 1. To do
this the dri’s on the dual band cell must be locked before hand.
Lock the dri’s on the site lock_device
Set the transmit power capability to high power tx_power_cap
Unlock the dri’s unlock_device
Disable BTS and MS power control in all the cells ms_power_control_allowed
The sdcch to tch reassignment delay should be set to 4 sacch
Note: To test the SBCCH feature we should be able to do both intracell and intercell
handovers. Intercell handovers we be considered for non–preferred band, preferred band
BCCH and non–preferred band with preferred band resources (dual band) neighbours.
Therefore three two way neighbours will have to be added to the serving dual band cells
database, a pgsm, a dcs1800 and dual pgsm/dcs1800 neighbour.
Add a pgsm neighbour (N1) to Cell S add_neighbor
Add a dcs1800 neighbour (N2) to Cell S add_neighbor
Add a dual band neighbour (N3) to Cell S add_neighbor
Set the ho margin to 6dB for all neighbours ho_margin_cell
Set neighbour hreqave to 4 surround_cell
Set serving cell hreqave to 4
Set serving cell hreqt to 1 rxlev_dl_ho
Note: The signal strength of the four cells can be set to a similar level. However if this
part of the exercise does not meet expectations then look carefully at the levels and
thresholds to ensure correct operation.
Set all cells to have an output power of 23dBm max_tx_bts

Version 1 Rev 1 Exercise 16 – Single BCCH (SBCCH) Multiband Handover
Student Activity
Note: A call is to be set up on Cell S (dual band cell).

Notice when an intracell handover occurs to a dcs1800 resource
Terminate the call
Student Analysis
Display RxLevDown, RxLevUp, ABIS, BSSMAP and DTAP messages.
Conclusions
Examine results on CTP and verify the intracell handovers.
Did the MS move from the pgsm TCH of Cell S to a dcs1800 TCH on the inner zone.?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Verify the intra zone trigger points for the ul and dl.
rxlevel_dlinner_zone > rxlev_dl_zone + zone_ho_hyst + (bs_txpwr– bts_txpwr_max_inner)
rxlevel_ulinner_zone > rxlev_ul_zone + zone_ho_hyst + ms_txpwr–

––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
We are going to repeat the last exercise, but this time set the band preference mode to
allow a sdcch to tch band reassignment on the dual band cell.
Set the band preference mode parameter to complete a band reassignment from sdcch
(pgsm) to tch (dcs1800) band_preference_mode
Student Activity

Notice when an intracell handover occurs to a dcs1800 resource
Terminate the call
Student Analysis
Display RxLevDown, RxLevUp, ABIS, BSSMAP and DTAP messages.

Conclusions
Did the MS move from the pgsm SDCCH of Cell S to a dcs1800 TCH on the inner zone.?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Verify the intra zone trigger points for the ul and dl.
rxlevel_dlinner_zone > rxlev_dl_zone + zone_ho_hyst + (bs_txpwr– bts_txpwr_max_inner)
rxlevel_ulinner_zone > rxlev_ul_zone + zone_ho_hyst + ms_txpwr–
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
We are going to repeat the last exercise, but this time lock the timeslots on the dcs1800
rtf’s on the serving dual band cell. This will create the conditions for the inner zone
appearing to be congested.
Lock the timeslots on the inner zone dcs1800 rtf’s lock_device pchn
Increase the power of the dual band neighbour cell N3 so it qualifies as a neighbour
max_tx_bts
Student Activity
Notice when an intercell handover occurs to the dual band neighbour
Terminate the call
Student Analysis
Display RxLevDown, N1_RxlevDown, ABIS, BSSMAP and DTAP messages.
Conclusions
Did the MS move from the pgsm SDCCH of Cell S to a dcs1800 TCH on the neighbour
dual band cell?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
In this part of the exercise we are going to unlock the inner zone timeslots and allow the
mobile to take an inner zone dcs1800 resource. Then the conditions should be created to
handover the mobile to a preferred band neighbour even though the strongest neighbour
is in the non–preferred band.
Set the output power of Cell S to 33dBm max_tx_bts
Set the output power of Cell N1 to 35dBm max_tx_bts

Version 1 Rev 1 Exercise 16 – Single BCCH (SBCCH) Multiband Handover
Student Activity
Start reducing the power of Cell S until a handover occurs
Terminate the call
Student Analysis
Display RxLevDown, N1(to N3)_RxlevDown, ABIS, BSSMAP and DTAP messages.
Conclusions
Did the MS move from the dcs1800 resource on the serving cell to the expected
neighbour cell?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Note: If the MS handed over to the neighbour cell with the BCCH in the preferred band,
repeat this exercise, but this time reduce the power level of Cell N2 (dcs1800 BCCH) so
it does not qualify as a neighbour.
Did the MS move to a dcs1800 resource on the dual band cell (pgsm BCCH)?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
In this part of the exercise we are going to examine what happens when a call is set up in
a dual band cell and the mobile takes a call from the inner zone (dcs1800) and
interference is experienced on the dcs1800 frequency. To generate the interference you
will have to change the BCCH frequency of Cell N2 to make it co–channel with the inner
zone frequency being used in your cell. Also to see all the implications, rxqual dl and
interference dl handovers will have to be enabled in Cell S.
Change the BCCH frequency of Cell N2 to make it co–channel with the inner zone
resource of Cell S chg_rtf_freq
Set the output power of Cell N2 to its minimum max_tx_bts
Set the output power of Cell S to 23dBm max_tx_bts
Enable rxqual dl handovers dl_rxqual_ho_allowed
Enable interference handovers interfer_ho_allowed
Note: The threshold rxqual should be set to 5 or 4.53 BER and the interference rxlev
threshold should be set to –95dBm. If these settings need to be adjusted because of the
receive levels in the classroom do so now.
Alter rxqual dl threshold if necessary l_rxqual_dl_h
Alter interference dl rxlev threshold if necessary u_rxlev_dl_ih
Student Activity
Note:.
Notice when the handovers occur
Terminate the call after a sufficient number of intracell handovers have occurred
Reduce the output power of Cell N2 to its minimum max_tx_bts

Student Analysis
Display RxLevDown, RxqualDown ABIS, BSSMAP and DTAP messages.
Conclusions
Examine results on CTP and verify the handover triggers.
Did the MS behave in the expected way?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
You are now going to use the multiple zone ping–pong handover prevention mechanism
to reduce the number of inter–zone handovers and keep the mobile on the preferred
zone. The preferred zone in this case would be the one without interference.
Set the zone ping–pong count to 3 zone_pingpong_count
Set the zone ping–pong enable win to 30s zone_pingpong_enable_win
Set the zone ping–pong disable win to 30s zone_pingpong_disable_win
Set the zone ping–pong preferred zone to the outer zone_pingpong_preferred_zone
Student Activity
Note:.
Notice when the handovers occur
Terminate the call after you have been able to observe the correct operation of the
mechanism
Reduce the output power of Cell N2 to its minimum max_tx_bts
Conclusions
Examine results on CTP and verify the handover triggers.
Did the MS behave in the expected way?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
–––––––––––––––– ––––––––––––– –––––––––––––

Version 1 Rev 1 Exercise 17 – Intelligent Multilayer Resource Management
Exercise 17 – Intelligent Multilayer Resource Management
Objectives
To observe the IMRM handover algorithm in action.
To appreciate the database parameters that control the IMRM feature.
Initial Settings
Note: For this exercise you can use the dualband cell as the serving cell (S) with one
1800 cell as a type 1 neighbour (N1) and another 900 cell as a type 5 neighbour (N2).
The initial settings from the previous exercise can be reused for the dualband cell, with
the exception of band preference mode that should direct the call to the inner zone.
This is to show the emphasis the pre GSR8 software places on band preference and how
IMRM overcomes these limitations.
Set the inner zone algorithm to 3 to enable SBCCH inner_zone_alg
Set secondary frequency type to dcs1800 secondary_freq_type
Set maximum base transmit power for the inner zone to 23dBm bts_txpwr_max_inner
Set maximum MS transmit power for the inner zone to 23dBm ms_txpwr_max_inner
Set handover power level for the inner zone to 5 ho_pwr_level_inner
Set inner zone handover hysteresis to 3dB zone_ho_hyst
Set downlink receive level threshold for the inner zone to –95dBm rxlev_dl_zone
Set uplink receive level threshold for the inner zone to –95dBm rxlev_ul_zone
Set dual band offset to –6dB dual_band_offset
Set the pbgt mode to allow the serving cell BCCH in the neighbour list pbgt_mode
Set the outer zone usage level to 0% outer_zone_usage_level
Set band preference to dcs1800 in the serving cell band_preference
In the serving cell set the band preference to set–up the call and handover to the
strongest preferred band neighbour band_preference_mode
Set a pgsm cell (N2) as a type 5 neighbour with the timer set to zero and the setting of
rxlev set so the type 5 neighbour easily qualifies add_neighbor
Set the dcs1800 cell (N1) as a type 1 neighbour add_neighbor
Enable reciprocal pbgt handovers between the serving cell and the two neighbours
pwr_handover_allowed
Disable BTS and MS power control in all the cells ms_power_control_allowed
The sdcch to tch reassignment delay should be set to 4 sacch
If the transmit power capability is not set to high power perform the operations below:
Lock the dri’s on the site lock_device
Set the transmit power capability to high power tx_power_cap
Unlock the dri’s unlock_device
Student Activity
Start a call on cell S (in this case the SBCCH cell)
Notice when the handover occurs to one of the neighbour cells
Terminate the call

Exercise 17 – Intelligent Multilayer Resource Management Version 1 Rev 1
Student Analysis
Conclusions
Examine results on CTP and examine where the handover took place and to which
neighbour cell the mobile handed over to.
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
Note: In this part of the exercise you are going to simulate what happens when the per
call band preference is set to pgsm in the serving dual band cell (S).
Set the per cell band preference in the serving cell band_preference
Set the pgsm weight to 100 the others 0 imrm_pgsm_weight
Student Activity
Terminate the call
Student Analysis
Conclusions
Examine results on CTP and examine where the handover took place and to which
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
Note: The band preference setting for the neighbour pgsm cell (N2) will be set to
dcs1800 and a further pgsm cell (N3) added to the neighbour database of the existing
pgsm neighbour cell. As well as adding the dcs1800 cell (N1) to the pgsm neighbour (N2)
database.
Set the band preference to dcs1800 in the pgsm cell (N2) band_preference
Add a pgsm neighbour (n3) as a type 4 to the existing pgsm neighbour (N2) of the
dualband cell (S). The timer can be set to 0 add_neighbor
Add the dcs1800 cell (N1) as type 1 neighbour(S) of the existing pgsm neighbour (N2)
add_neighbor
Enable power budget handovers in pgsm neighbour cell (N2) pwr_handover_allowed
Note: The rxlev of neighbours N2 and N3 will have to be high enough to qualify for a
handover.

Version 1 Rev 1 Exercise 17 – Intelligent Multilayer Resource Management
Student Activity
Terminate the call
Student Analysis
Conclusions
Examine results on CTP and examine where the first handover took place and to which
Did the mobile handover to the first expected neighbour cell?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Did the mobile handover to the second expected neighbour cell?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Further Settings
Note: In this part of the exercise we are going to repeat the above exercise but use the
recalculate the per call band preference and redirect the traffic to the dcs1800 cell.
Set the recalculate the per call band preference flag to one for N2 imrm_force_recalc
Set the band preference to 16 band_preference
Set the dcs1800 weighting to 100 and the others to 0 imrm_dcs1800_weight
Student Activity
Notice when the handover occurs to the first and second neighbour cells
Terminate the call
Student Analysis
Conclusions
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Exercise 17 – Intelligent Multilayer Resource Management Version 1 Rev 1
Further Settings
Note: In this part of the exercise we are going to repeat the above exercise but use the
recalculate the per call band preference and redistribute the traffic equally between the
dcs1800 and pgsm neighbours cells.
Set the recalculate the per call band preference flag to one for N2 imrm_force_recalc
Set the band preference to 16 band_preference
Set the dcs1800 weighting to 50 imrm_dcs1800_weight
Set the pgsm weighting to 50 imrm_dcs1800_weight
Student Activity
Notice when the handover occurs to the first and second neighbour cells
Terminate the call
Repeat this a number of times to get a good representation of results.
Student Analysis
Conclusions
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––– ––––––––––––– –––––––––––––

Version 1 Rev 1 Exercise 18 – Coincident Multiband
Exercise 18 – Coincident Multiband
Objectives
To observe the coincident multiband handover algorithm in action.
To appreciate the database parameters that control the co–incident multiband feature.
Initial Settings
Note: To configure coincident multiband to a value of 2 it is necessary to have the two
coincident cells (900 and 1800) equipped at the same site, have the same BSIC and the
coincident cells must have synchronised neighbours. It is much easier if the cells are
within the same cabinet avoiding the use of cabinet expansion.
Disable the SBCCH feature if enabled inner_zone_alg
Enable coincident multiband to 1 in all four cells coincident_mb
Set the output power of all cells to 23dBm max_tx_bts
Set the coincident offset to the difference in rxlev between the 900 and 1800 carriers
coincident_offset
Add the coincident cells as two way neighbours add_neighbor
Add the 900 cells as one way neighbours of the 1800 non–coincident cells
add_neighbour
Note: If the server is a 900 cell the 1800 neighbour should be a type 5 with the rxlev
threshold and timer set to appropriate values. If the server is a 1800 cell the 900
neighbour should be a type 3 with the rxlev ul/dl set to appropriate values. Do not add the
1800 cells as neighbours of each other.
Student Activity
Start a call on one of the 1800 cells.
Increase the transmit power of the 900 non–coincident neighbour cell until a pbgt
handover(s) occurs max_tx_bts
Terminate the call.
Student Analysis
Conclusions
Examine the results on CTP and confirm the handover trigger was better cell.
On which cell did the MS eventually end up on and what intermediate cells if any did it
handover through?
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Explain why
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

Exercise 18 – Coincident Multiband Version 1 Rev 1
Further Settings
In this part of the exercise we are going to test the functionality of the feature when
coincident multiband is set to a value of 2 so it is using the coincident redirection ability of
the algorithm.
Set coincident multiband to 2 in all cells coincident_mb
Set low signal threshold to an appropriate value depending on the rf conditions in the lab
low_signal_thres
Note: Ensure that two coincident cells (900 and 1800) equipped at the same site, have
the same BSIC and the coincident cells have synchronised neighbours.
Student Activity
Start a call on one of the 1800 cells.
Increase the transmit power of the 900 non–coincident neighbour cell until a pbgt
handover(s) occurs max_tx_bts
Terminate the call.
Student Analysis
Conclusions
Examine the results on CTP and confirm the handover trigger was better cell.
On which cell did the MS eventually end up on and what intermediate cells if any did it
handover through?
–––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
Explain why
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––– ––––––––––––– –––––––––––––

Version 1 Rev 1 Exercise 18 – GSM Half Rate
Exercise 18 – GSM Half Rate

Objectives
To observe the half rate algorithm in action.
To appreciate the database parameters that control the half rate feature.
Initial Settings
Enable the handover required speech version used flag
handover_required_sp_ver_used
Enable half rate at BSS level gsm_bss_half_rate_enabled
Enable half rate at Cell level gsm_half_rate_enabled
Set the half rate timeslot reserved to 2 hr_res_ts
Set the force half rate usage flag to enabled force_hr_usage
Note: The rtf being used to test this feature will have to be enabled to allow half rate.
Also if 8kbps switching is being used (if DSW’s equipped at both the BSC and RXCDR)
then the flag to allow 8k trau will have to be set when equipping the rtf.
If necessary unequip the rtf unequip rtf

Re–equip the rtf as necessary equip rtf
Student Activity
Start a call on the half rate equipped cell.
Ensure that the MS moved to the half rate resource.
Terminate the call.
Further Settings
In this part of the exercise we are going to disable the force half rate usage flag and use
the full rate to half rate congestion mechanism to make use of the half rate resources.
Disable the force half rate usage flag force_hr_usage
Set the new calls half rate threshold to 50% new_calls_hr
Note: assuming one rtf is to be used and one sdcch is equipped with no additional control
channels, there should be 6 tch channels remaining.
Lock down two of the tch’s lock_device pchn
Student Activity
Start a call on one of the remaining tch’s.
Start another call on one ofthe remaining tch’s
Terminate the calls.

Exercise 18 – GSM Half Rate Version 1 Rev 1
Conclusions
What type of resource did the first call take? ___________________
What type of resource did the second call take?__________________
Further Settings
In this part of the exercise we are going to automatically reconfigure existing full rate calls
into half rate calls when a threshold is reached.
Disable the new calls half rate threshold new_calls_hr
Set reconfigure full rate to half rate to 50% reconfig_fr_to_hr
Note: assuming one rtf is to be used and one sdcch is equipped with no additional control
channels, there should be 6 tch channels remaining.
Lock down two of the tch’s lock_device pchn
Student Activity
Start a call on one of the remaining tch’s.
Start another call on one ofthe remaining tch’s
Terminate the calls.
Conclusions
What type of resource did the first call take? ___________________
What happened to the next call and the existing full rate calls when the threshold was
exceeded ?
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––

–––––––––––––––– ––––––––––––– –––––––––––––

Glossary of technical terms and
abbreviations
10TH JULY 95 Manual Title Goes Here G–1

G–2 Manual Title Goes Here 10TH JULY 95

Numbers
Numbers
# Number.
2 Mbit/s link As used in this manual set, the term applies to the European
4-wire 2.048 Mbit/s digital line or link which can carry 30
A-law PCM channels or 120 16 kbit/s GSM channels.
4GL 4th Generation Language.

A
A
A interface Interface between MSC and BSS.
A3 Authentication algorithm that produces SRES, using RAND
and Ki.
A38 A single algorithm performing the function of A3 and A8.
A5 Stream cipher algorithm, residing on an MS, that produces
ciphertext out of plaintext, using Kc.
A8 Ciphering key generating algorithm that produces Kc using
RAND and Ki.
AB Access Burst.
Abis interface Interface between a remote BSC and BTS. Motorola offers a
GSM standard and a unique Motorola Abis interface. The
Motorola interface reduces the amount of message traffic and
thus the number of 2 Mbit/s lines required between BSC and
BTS.
ABR Answer Bid Ratio.
ac–dc PSM AC–DC Power Supply module.
ac Alternating Current.
AC Access Class (C0 to C15).
AC Application Context.
ACC Automatic Congestion Control.
ACCH Associated Control CHannel.
ACK, Ack ACKnowledgement.
ACM Accumulated Call meter.
ACM Address Complete Message.
ACPIM AC Power Interface Module. Used in M-Cell6 indor ac BTS
equipment.
AC PSM AC Power Supply Module. Used in M-Cell6 BTS equipment.
ACSE Associated Control Service Element.
ACU Antenna Combining Unit.
A/D Analogue to Digital (converter).
ADC ADministration Centre.
ADC Analogue to Digital Converter.
ADCCP ADvanced Communications Control Protocol.
ADM ADMinistration processor.
ADMIN ADMINistration.
ADN Abbreviated Dialling Number.
ADPCM Adaptive Differential Pulse Code Modulation.
AE Application Entity.
AEC Accoustic Echo Control.
AEF Additional Elementary Functions.

A
AET Active Events Table. Alarms and events are sent to the
Events Log in the GUI. Different operators will have different
subscription lists. All alarms and events are sent to the AET
before they are re-routed to different subscription lists.
AFC Automatic Frequency Control.
AFN Absolute Frame Number.
AGC Automatic Gain Control.
AGCH Access Grant CHannel. A GSM common control channel
used to assign MS to a SDCCH or a TCH.
Ai Action indicator.
AI Artificial Intelligence.
AIB Alarm Interface Board.
AIO A class of processor.
Air interface The radio link between the BTS and the MS.
AM Amplitude Modulation.
AMA Automatic Message Accounting (processor).
AM/MP Cell broadcast mobile terminated message. A message
broadcast to all MSs in a cell.
AoC Advice of Change.
AoCC Advice of Change Charging supplementary service.
AoCI Advice of Change Information supplementary service.
AOC Automatic Output Control.
AP Application Process.
ARFCN Absolute Radio Frequency Channel Number. An integer
which defines the absolute RF channel number.
ARQ Automatic ReQuest for retransmission.
ARP Address Resolution Protocol.
ASCE Association Control Service Element. An ASE which
provides an AP with the means to establish and control an
association with an AP in a remote NE. Maps directly onto
the Presentation layer (OMC).
ASE Application Service Element (OMC)
ASE Application Specific Entity (TCAP).
ASN.1 Abstract Syntax Notation One.
ASP Alarm and Status Panel.
ASR Answer Seizure Ratio.
ATB All Trunks Busy.
ATI Antenna Transceiver Interface.
ATT (flag) ATTach.
ATTS Automatic Trunk Testing Subsystem.
AU Access Unit.
AuC Authentication Centre. A GSM network entity which provides
the functionality for verifying the identity of an MS when
requested by the system. Often a part of the HLR.

A
AUT(H) AUThentication.
AUTO AUTOmatic mode.

B
B Interface Interface between MSC and VLR.

BA BCCH Allocation. The radio frequency channels allocated in a
cell for BCCH transmission.
BAIC Barring of All Incoming Calls supplementary service.
BAOC Barring of All Outgoing Calls supplementary service.
BBBX Battery Backup Board.
BBH Base Band Hopping.
BCC BTS Colour Code.
BCCH Broadcast Control CHannel. A GSM control channel used to
broadcast general information about a BTS site on a per cell
or sector basis.
BCD Binary Coded Decimal.
BCF Base station Control Function. The GSM term for the digital
control circuitry which controls the BTS. In Motorola cell sites
this is a normally a BCU which includes DRI modules and is
located in the BTS cabinet.
BCIE Bearer Capability Information Element.
BCU Base station Control Unit. A functional entity of the BSS
which provides the base control function at a BTS site. The
term no longer applies to a type of shelf (see BSC and BSU).
BCUP Base Controller Unit Power.
BER Bit Error Rate. A measure of signal quality in the GSM
system.
BES Business Exchange Services.
BFI Bad Frame Indication.
BHCA Busy Hour Call Attempt.
BI all Barring of All Incoming call supplementary service.
BIB Balanced-line Interconnect Board. Provides interface to 12
balanced (6-pair) 120 ohm (37-pin D-type connector) lines for
2 Mbit/s circuits (See also T43).
BIC–Roam Barring of All Incoming Calls when Roaming outside the
Home PLMN Country supplementary service.
BIM Balanced-line Interconnect Module.
Bin An area in a data array used to store information.
BL BootLoad. Also known as download. For example, databases
and software can be downloaded to the NEs from the BSS.
BLLNG BiLLiNG.
bit/s Bits per second (bps).
Bm Full rate traffic channel.
BN Bit Number. Number which identifies the position of a
particular bit period within a timeslot.
BPF Bandpass Filter.
BPSM mBCU Power Supply Module.

B
BS Basic Service (group).

BS Bearer Service. A type of telecommunication service that
provides the capability for the transmission of signals
between user-network interfaces. The PLMN connection type
used to support a bearer service may be identical to that used
to support other types of telecommunication service.
BSC Base Station Controller. A network component in the GSM
PLMN which has the digital control function of controlling all
BTSs. The BSC can be located within a single BTS cabinet
(forming a BSS) but is more often located remotely and
controls several BTSs (see BCF, BCU, and BSU).
BSG Basic Service Group.
BSIC Base Transceiver Station Identity Code. A block of code,
consisting of the GSM PLMN colour code and a base station
colour code. One Base Station can have several Base
Station Colour Codes.
BSIC-NCELL BSIC of an adjacent cell.
BSP Base Site control Processor (at BSC).
BSN Backward Sequence Number.
BSS Base Station System. The system of base station equipment
(Transceivers, controllers and so on) which is viewed by the
MSC through a single interface as defined by the GSM 08
series of recommendations, as being the entity responsible
for communicating with MSs in a certain area. The radio
equipment of a BSS may cover one or more cells. A BSS
may consist of one or more base stations. If an internal
interface is implemented according to the GSM 08.5x series
of recommendations, then the BSS consists of one BSC and
several BTSs.
BSSAP BSS Application Part (of Signalling System No. 7) (DTAP +
BSSMAP).
BSSC Base Station System Control cabinet. The cabinet which
houses one or two BSU shelves at a BSC or one or two RXU
shelves at a remote transcoder.
BSSMAP Base Station System Management Application Part (6-8).
BSSOMAP BSS Operation and Maintenance Application Part (of
Signalling System No. 7).
BSU Base Station Unit shelf. The shelf which houses the digital
control modules for the BTS (p/o BTS cabinet) or BSC (p/o
BSSC cabinet).
BT British Telecom.
BT Bus Terminator.
BTC Bus Terminator Card.
BTF Base Transceiver Function.
BTP Base Transceiver Processor (at BTS). One of the six basic
task groups within the GPROC.

B
BTS Base Transceiver Station. A network component in the GSM

PLMN which serves one cell, and is controlled by a BSC.
The BTS contains one or more Transceivers (TRXs).
Burst A period of modulated carrier less than one timeslot. The
physical content of a timeslot.

C
C
C Conditional.
C Interface Interface between MSC and HLR/AUC.
C7 ITU-TSS Signalling System 7 (sometimes referred to as S7 or
SS#7).
CA Cell Allocation. The radio frequency channels allocated to a
particular cell.
CA Central Authority.
CAB Cabinet.
CADM Country ADMinistration. The Motorola procedure used within
DataGen to create new country and network files in the
DataGen database.
CAI Charge Advice Information.
CAT Cell Analysis Tool.
CB Cell Broadcast.
CB Circuit Breaker.
CBC Cell Broadcast Centre.
CBCH Cell Broadcast CHannel.
CBF Combining Bandpass Filter.
CBL Cell Broadcast Link.
CBM Circuit Breaker Module.
CBMI Cell Broadcast Message Identifier.
CBSMS Cell Broadcast Short Message Service.
CBUS Clock Bus.
CC Connection Confirm (Part of SCCP network connectivity).
CC Country Code.
CC Call Control.
CCB Cavity Combining Block, a three way RF combiner. There
are two types of CCB, CCB (Output) and CCB (Extension).
These, with up to two CCB Control cards, may comprise the
TATI. The second card may be used for redundancy.
CCBS Completion of Calls to Busy Subscriber supplementary
service.
CCCH Common Control CHannels. A class of GSM control
channels used to control paging and grant access. Includes
AGCH, PCH, and RACH.
CCCH_GROUP Group of MSs in idle mode.
CCD Common Channel Distributor.
CCDSP Channel Coding Digital Signal Processor.
CCF Conditional Call Forwarding.
CCH Control CHannel. Control channels are channels which carry
system management messages.
CCH Council for Communications Harmonization (referred to in
GSM Recommendations).

C
CCIT Comité Consultatif International Télégraphique et

Téléphonique. This term has been superceded by ITU–TSS
(International Telecommunications Union –
Telecommunications Sector).
CCM Current Call Meter.
CCP Capability/Configuration Parameter.
CCPE Control Channel Protocol Entity.
CCS Hundred call-seconds. The unit in which amounts of
telephone traffic are measured. A single call lasting one
hundred seconds is one CCS. See also erlang.
Cct Circuit.
CDB Control Driver Board.
CDE Common Desktop Environment. Part of the SUN software
(crontab – cron job file).
CDR Call Detail Records.
CDUR Chargeable DURation.
CEB Control Equalizer Board (BTS).
CED Called station identifier.
CEIR Central Equipment Identity Register.
Cell By GSM definition, a cell is an RF coverage area. At an
omni-site, cell is synonymous with site; at a sectored site, cell
is synonymous with sector. This differs from analogue
systems where cell is taken to mean the same thing as site.
(See below).
1 Cell =
1 Sector
Omni Site 6-Sector Site

1-Cell Site or
(1 BTS) 6-Cell Site
(6 BTSs)
CEND End of charge point.

CEPT Conférence des administrations Européennes des Postes et
Telecommunications.
CERM Circuit Error Rate Monitor.
CF Conversion Facility.
CF all Call Forwarding services.
CFB Call Forwarding on mobile subscriber Busy supplementary
service.
CFC Conditional Call Forward.
CFNRc Call Forwarding on mobile subscriber Not Reachable
supplementary service.
CFNRy Call Forwarding on No Reply supplementary service.

C
CFU Call Forwarding Unconditional supplementary service.

Channel A means of one-way transmission. A defined sequence of
periods (for example, timeslots) in a TDMA system; a defined
frequency band in an FDMA system; a defined sequence of
periods and frequency bands in a frequency hopped system.
CIM Coaxial Interconnect Module.
CHP CHarging Point.
CHV Card Holder Verification information.
CKSN Ciphering Key Sequence Number.
CI Cell Identity. A block of code which identifies a cell within a
location area.
CI CUG Index.
CIC Circuit Identity Code.
CIR, C/I Carrier to Interference Ratio.
Ciphertext Unintelligible data produced through the use of encipherment.
CKSN Ciphering Key Sequence Number.
CLI Calling Line Identity.
CLIP Calling Line Identification Presentation supplementary
service.
CLIR Calling Line Identification Restriction supplementary service.
CLK Clock.
CLKX Clock Extender half size board. The fibre optic link that
distributes GCLK to boards in system (p/o BSS etc).
CLM Connectionless Manager.
CLR CLeaR.
CM Configuration Management. An OMC application.
CM Connection Management.
CMD CoMmanD.
CMM Channel Mode Modify.
CMIP Common Management Information Protocol.
CMISE Common Management Information Service Element. An ASE
which provides a means to transfer management information
via CMIP messages with another NE over an association
established by ASCE using ROSE (OMC).
CMR Cellular Manual Revision.
CNG CalliNg tone.
COLI COnnected Line Identity.
Collocated Placed together; two or more items together in the same
place.
Coincident Cell A cell which has a co-located neighbour whose cell boundary
follows the boundary of the said cell. The coincident cell has
a different frequency type, but the same BSIC, as that of the
neighbour cell.
COLP COnnected Line Identification Presentation supplementary
service.

C
COLR COnnected Line Identification Restriction supplementary

service.
CODEX Manufacturer’s name for a type of multiplexer and packet
switch commonly installed at the Motorola OMC-R.
COM Code Object Manager.
COM COMplete.
COMB Combiner.
CONNACK CONNect ACKnowledgement.
COMM, Comms COMMunications.
CommsLink Communications Link. (2Mbit/s)
CONF CONFerence circuit.
CONFIG CONFIGuration Control Program.
CP Call Processing.
CPU Central Processing Unit.
C/R Command/Response field bit.
CR Carriage Return (RETURN).
CR Connection Request (Part of SCCP network connectivity).
CRC Cyclic Redundancy Check (3 bit).
CRE Call RE-establishment procedure.
CREF Connection REFused (Part of SCCP network connectivity).
CRM Cell Resource Manager.
CRM-LS/HS Cellular Radio Modem-Low Speed/High Speed. Low speed
modem used to interwork 300 to 2400 bit/s data services
under V.22bis, V.23, or V.21 standards. High speed modem
used to interwork 1200 to 9600 bit/s data services under
V.22bis, V.32, or V.29/V.27ter/V.21 standards.
CRT Cathode Ray Tube (video display terminal).
CSFP Code Storage Facility Processor (at BSC and BTS).
CSP Central Statistics Process. The statistics process in the BSC.
CSPDN Circuit Switched Public Data Network.
CT Call Transfer supplementary service.
CT Channel Tester.
CT Channel Type.
CTP Call Trace Product (Tool).
CTR Common Technical Regulation.
CTS Clear to Send. Method of flow control (RS232 Interface).
CTU Compact Transceiver Unit (M-Cellhorizon radio).
CUG Closed User Group supplementary service.
Cumulative value The total value for an entire statistical interval.
CW Call Waiting supplementary service.

D
D
D Interface Interface between VLR and HLR.
D/A Digital to Analogue (converter).
DAB Disribution Alarm Board.
DAC Digital to Analogue Converter.
DACS Digital Access Cross-connect System.
DAN Digital ANnouncer (for recorded announcements on MSC).
DAS Data Acquisition System.
DAT Digital Audio Tape.
DataGen Sysgen Builder System. A Motorola offline BSS binary object
configuration tool.
dB Decibel. A unit of power ratio measurement.
DB DataBase.
DB Dummy Burst (see Dummy burst).
DBA DataBase Administration/Database Administrator.
DBMS DataBase Management System.
dc Direct Current.
DCB Diversity Control Board (p/o DRCU).
DCCH Dedicated Control CHannel. A class of GSM control
channels used to set up calls and report measurements.
Includes SDCCH, FACCH, and SACCH.
DCD Data Carrier Detect signal.
DCE Data Circuit terminating Equipment.
DCF Data Communications Function.
DCF Duplexed Combining bandpass Filter. (Used in
Horizonmacro).
DCN Data Communications Network. A DCN connects Network
Elements with internal mediation functions or mediation
devices to the Operations Systems.
DC PSM DC Power Supply Module.
DCS1800 Digital Cellular System at 1800 MHz. A cellular phone
network using digital techniques similar to those used in GSM
900, but operating on frequencies of 1710 – 1785 MHz and
1805 – 1880 MHz.
DDF Dual-stage Duplexed combining Filter. (Used in
Horizonmacro).
DDS DataGen Directory Structure.
DDS Data Drive Storage.
DDS Direct Digital Synthesis.
DEQB Diversity Equalizer Board.
DET DETach.
DFE Decision Feedback Equalizer.
DGT Data Gathering Tool.

D
DHP Digital Host Processor.

DIA Drum Intercept Announcer.
DINO E1/HDSL Line termination module.
DINO T1 Line termination module.
DISC DISConnect.
Discon Discontiuous.
DIQ Diversity In phase and Quadrature phase.
DIR Device Interface Routine.
DL Data Link (layer).
DLCI Data Link Connection Identifier.
DLD Data Link Discriminator.
DLNB Diversity Low Noise Block.
DLSP Data Link Service Process.
DLSP Digital Link Signalling Processor.
Dm Control channel (ISDN terminology applied to mobile service).
DMA Deferred Maintenance Alarm. An alarm report level; an
immediate or deferred response is required (see also PMA).
DMA Direct Memory Access.
DMR Digital Mobile Radio.
DMX Distributed Electronic Mobile Exchange (Motorola’s
networked EMX family).
DN Directory Number.
DNIC Data network identifier.
Downlink Physical link from the BTS towards the MS (BTS transmits,
MS receives).
DP Dial/Dialled Pulse.
DPC Destination Point Code. A part of the label in a signalling
message that uniquely identifies, in a signalling network, the
(signalling) destination point of the message.
DPC Digital Processing and Control board.
DPNSS Digital Private Network Signalling System (BT standard for
PABX interface).
DPP Dual Path Preselector.
DPR, DPRAM Dual Port Random Access Memory.
DPSM Digital Power Supply Module.
DRAM Dynamic Random Access Memory.
DRC Data Rate Converter board. Provides data and protocol
conversion between PLMN and destination network for 8
circuits (p/o IWF).
DRCU Diversity Radio Channel Unit. Contains transceiver, digital
control circuits, and power supply (p/o BSS) (see RCU).
(D)RCU Generic term for radio channel unit. May be standard RCU or
diversity radio channel unit DRCU.

D
DRI Digital Radio Interface. Provides encoding/decoding and

encryption/decryption for radio channel (p/o BSS).
DRIM Digital Radio Interface extended Memory. A DRI with extra
memory.
DRIX DRI Extender half size board. Fibre optic link from DRI to
BCU (p/o BSS).
DRX, DRx Discontinuous reception (mechanism). A means of saving
battery power (for example in hand-portable units) by
periodically and automatically switching the MS receiver on
and off.
DS-2 German term for 2 Mbit/s line (PCM interface).
DSE Data Switching Exchange.
DSI Digital Speech Interpolation.
DSP Digital Signal Processor.
DSS1 Digital Subscriber Signalling No 1.
DSSI Diversity Signal Strength Indication.
DTAP Direct Transfer Application Part (6-8).
DTE Data Terminal Equipment.
DTF Digital Trunk Frame.
DT1 DaTa form 1 (Part of SCCP network connectivity).
DTI Digital Trunk Interface.
DTMF Dual Tone Multi-Frequency (tone signalling type).
DTR Data Terminal Ready signal. Method of flow control (RS232
Interface).
DTRX Dual Transceiver Module. (Radio used in M-Cellarena and
M-Cellarena macro).
DTX, DTx Discontinuous Transmission (mechanism). A means of
saving battery power (for example in hand-portable units) and
reducing interference by automatically switching the
transmitter off when no speech or data are to be sent.
Dummy burst A period of carrier less than one timeslot whose modulation is
a defined sequence that carries no useful information. A
dummy burst fills a timeslot with an RF signal when no
information is to be delivered to a channel.
DYNET DYnamic NETwork. Used to specify BTSs sharing dynamic
resources.

E
E
E See Erlang.
E Interface Interface between MSC and MSC.
EA External Alarms.
EAS External Alarm System.
Eb/No Energy per Bit/Noise floor.
EBCG Elementary Basic Service Group.
EC Echo Canceller. Performs echo suppression for all voice
circuits.
ECB Provides echo cancelling for telephone trunks for 30 channels
(EC).
ECID The Motorola European Cellular Infrastructure Division.
ECM Error Correction Mode (facsimile).
Ec/No Ratio of energy per modulating bit to the noise spectral
density.
ECT Event Counting Tool.
ECT Explicit Call Transfer supplementary service.
EEL Electric Echo Loss.
EEPROM Electrically Erasable Programmable Read Only Memory.
EGSM900 Extended GSM900.
EI Events Interface. Part of the OMC-R GUI.
EIR Equipment Identity Register.
EIRP Effective Isotropic Radiated Power.
EIRP Equipment Identity Register Procedure.
EL Echo Loss.
EM Event Management. An OMC application.
EMC ElectroMagnetic Compatibility.
EMF Electro Motive Force.
EMI Electro Magnetic Interference.
eMLPP enhanced Multi-Level Precedence and Pre-emption service.
EMMI Electrical Man Machine Interface.
EMU Exchange office Management Unit (p/o Horizonoffice)
EMX Electronic Mobile Exchange (Motorola’s MSC family).
en bloc Fr. — all at once (a CCITT #7 Digital Transmission scheme);
En bloc sending means that digits are sent from one system
to another ~ (that is, all the digits for a given call are sent at
the same time as a group). ~ sending is the opposite of
overlap sending. A system using ~ sending will wait until it
has collected all the digits for a given call before it attempts to
send digits to the next system. All the digits are then sent as
a group.
EOT End of Tape.
EPROM Erasable Programmable Read Only Memory.

E
EPSM Enhanced Power Supply Module (+27 V).

EQB Equalizer Board. Control circuit for equalization for 8 time
slots each with equalizing circuitry and a DSP (p/o RCU).
EQCP Equalizer Control Processor.
EQ DSP Equalizer Digitizer Signal Processor.
Erlang International (dimensionless) unit of traffic intensity defined as
the ratio of time a facility is occupied to the time it is available
for occupancy. One erlang is equal to 36 CCS. In the US
this is also known as a traffic unit (TU).
ERP Ear Reference Point.
ERP Effective Radiated Power.
ERR ERRor.
ESP Electro-static Point.
ESQL Embedded SQL (Structured Query Language). An RDBMS
programming interface language.
E-TACS Extended TACS (analogue cellular system, extended).
Ethernet Type of Local Area Network.
ETR ETSI Technical Report.
ETS European Telecommunication Standard.
ETSI European Telecommunications Standards Institute.
ETX End of Transmission.
EXEC Executive Process.

F
F Interface Interface between MSC and EIR.

FA Fax Adaptor.
FA Full Allocation.
FA Functional Area.
FAC Final Assembly Code.
FACCH Fast Associated Control Channel. A GSM dedicated control
channel which is associated with a TCH and carries control
information after a call is set up (see SDCCH).
FACCH/F Fast Associated Control Channel/Full rate.
FACCH/H Fast Associated Control Channel/Half rate.
FB Frequency correction Burst (see Frequency correction burst).
FC-AL Fibre Channel Arbitration Loop. (Type of hard disc).
FCCH Frequency Correction CHannel. A GSM broadcast control
channel which carries information for frequency correction of
the mobile (MS).
FCP Fault Collection Process (in BTS).
FCS Frame Check Sequence.
FDM Frequency Division Multiplex.
FDMA Frequency Division Multiple Access.
FDN Fixed Dialling Number.
FDP Fault Diagnostic Procedure.
FEC Forward Error Correction.
FEP Front End Processor.
FER Frame Erasure Ratio.
FFS, FS For Further Study.
FH Frequency Hopping.
FIB Forward Indicator Bit.
FIR Finite Impulse Response (filter type).
FK Foreign Key. A database column attribute; the foreign key
indicates an index into another table.
FM Fault Management (at OMC).
FM Frequency Modulation.
FMIC Fault Management Initiated Clear.
FMUX Fibre optic MUltipleXer.
FN Frame Number. Identifies the position of a particular TDMA
frame within a hyperframe.
FOA First Office Application.
FOX Fibre Optic eXtender.
FR Full Rate. Refers to the current capacity of a data channel on
the GSM air interface, that is, 8 simultaneous calls per carrier
(see also HR – Half Rate).

F
FRU Field Replaceable Unit.

Frequency correction Period of RF carrier less than one timeslot whose modulation
bit stream allows frequency correction to be performed easily
within an MS burst.
FS Frequency Synchronization.
FSL Free Space Loss. The decrease in the strength of a radio
signal as it travels between a transmitter and receiver. The
FSL is a function of the frequency of the radio signal and the
distance the radio signal has travelled from the point source.
FSN Forward Sequence Number.
FTAM File Transfer, Access, and Management. An ASE which
provides a means to transfer information from file to file
(OMC).
ftn forwarded-to number.
FTP Fault Translation Process (in BTS).
FTP File Transfer Protocol.

G
G
G Interface Interface between VLR and VLR.
Gateway MSC An MSC that provides an entry point into the GSM PLMN
from another network or service. A gateway MSC is also an
interrogating node for incoming PLMN calls.
GB, Gbyte Gigabyte.
GBIC Gigabit Interface Converter.
GCLK Generic Clock board. System clock source, one per site (p/o
BSS, BTS, BSC, IWF, RXCDR).
GCR Group Call Register.
GDP Generic DSP Processor board. Interchangeable with the XCDR
board.
GDP E1 GDP board configured for E1 link usage.
GDP T1 GDP board configured for T1 link usage.
GHz Giga-Hertz (109).
GID Group ID. A unique number used by the system to identify a
user’s primary group.
GMB GSM Multiplexer Board (p/o BSC).
GMR GSM Manual Revision.
GMSC Gateway Mobile-services Switching Centre (see Gateway
MSC).
GMSK Gaussian Minimum Shift Keying. The modulation technique
used in GSM.
GND GrouND.
GOS Grade of Service.
GPA GSM PLMN Area.
GPC General Protocol Converter.
GPROC Generic Processor board. GSM generic processor board: a
68030 with 4 to 16 Mb RAM (p/o BSS, BTS, BSC, IWF,
RXCDR).
GPROC2 Generic Processor board. GSM generic processor board: a
68040 with 32 Mb RAM (p/o BSS, BTS, BSC, IWF, RXCDR).
GPRS General Packet Radio Service.
GPS Global Positioning by Satellite.
GSA GSM Service Area. The area in which an MS can be reached
by a fixed subscriber, without the subscriber’s knowledge of
the location of the MS. A GSA may include the areas served
by several GSM PLMNs.
GSA GSM System Area. The group of GSM PLMN areas
accessible by GSM MSs.
GSM Groupe Spécial Mobile (the committee).
GSM Global System for Mobile communications (the system).
GSM MS GSM Mobile Station.
GSM PLMN GSM Public Land Mobile Network.

G
GSR GSM Software Release.

GT Global Title.
GTE Generic Table Editor. The Motorola procedure which allows
users to display and edit MCDF input files.
Guard period Period at the beginning and end of timeslot during which MS
transmission is attenuated.
GUI Graphical User Interface.
GUI client A computer used to display a GUI from an OMC-R GUI
application which is beingbrun on a GUI server.
GUI server A computer used to serve the OMC-R GUI application
process running locally (on its processor) to other computers
(Gui clients or other MMI processors).
GWY GateWaY (MSC/LR) interface to PSTN.

H
H
H Interface Interface between HLR and AUC.
H-M Human-Machine Terminals.
HAD, HAP HLR Authentication Distributor.
HANDO, Handover HANDOver. The action of switching a call in progress from
one radio channel to another radio channel. Handover allows
established calls to continue by switching them to another
radio resource, as when an MS moves from one BTS area to
another. Handovers may take place between the following
GSM entities: timeslot, RF carrier, cell, BTS, BSS and MSC.
HCU Hybrid Combining Unit. (Used in Horizonmacro).
HDLC High level Data Link Control.
HDSL High bit-rate Digital Subscriber Line.
HLC High Layer Compatibility. The HLC can carry information
defining the higher layer characteristics of a teleservice active
on the terminal.
HLR Home Location Register. The LR where the current location
and all subscriber parameters of an MS are permanently
stored.
HMS Heat Management System. The system that provides
environmental control of the components inside the ExCell,
TopCell and M-Cell cabinets.
HO HandOver. (see HANDO above).
HPU Hand Portable Unit.
HOLD Call hold supplementary service.
HPLMN Home PLMN.
HR Half Rate. Refers to a type of data channel that will double
the current GSM air interface capacity to 16 simultaneous
calls per carrier (see also FR – Full Rate).
HS HandSet.
HSI/S High Speed Interface card.
HSM HLR Subscriber Management.
HSN Hopping Sequence Number.
HU Home Units.
HW Hardware.
Hyperframe 2048 superframes. The longest recurrent time period of the
frame structure.

I
I Information frames (RLP).

IA Incomming Access (closed user group (CUG) SS
(supplementary service)).
IA5 International Alphanumeric 5.
IADU Integrated Antenna Distribution Unit. (The IADU is the
equivalent of the Receive Matrix used on pre-M-Cell BTSs).
IAM Initial Address Message.
IAS Internal Alarm System.
IC Integrated Circuit.
IC Interlock Code (CUG SS).
IC(pref) Interlock Code op the preferential CUG.
ICB Incoming Calls Barred.
ICC Integrated Circuit(s) Card.
ICM In-Call Modification.
ICMP Internet Control Message Protocol.
ID, Id IDentification/IDentity/IDentifier.
IDN Integrated Digital Network.
IDS INFOMIX Database Server. (OMC-R relational database
management system).
IE Information Element (signalling).
IEC International Electrotechnical Commission.
IEEE Institute of Electrical and Electronic Engineers.
IEI Information Element Identifier.
I-ETS Interim European Telecommunication Standard.
IF Intermediate Frequency.
IFAM Initial and Final Address Message.
IM InterModulation.
IMACS Intelligent Monitor And Control System.
IMEI International Mobile station Equipment Identity. Electronic
serial number that uniquely identifies the MS as a piece or
assembly of equipment. The IMEI is sent by the MS along
with request for service.
IMM IMMediate assignment message.
IMSI International Mobile Subscriber Identity. Published mobile
number (prior to ISDN) (see also MSISDN) that uniquely
identifies the subscription. It can serve as a key to derive
subscriber information such as directory number(s) from the
HLR.
IN Intelligent Network.
IN Interrogating Node. A switching node that interrogates an
HLR, to route a call for an MS to the visited MSC.
INS IN Service.

I
INS Intelligent Network Service.

InterAlg Interference Algorithm. A single interference algorithm in a
cell.
Interworking The general term used to describe the inter-operation of
networks, services, supplementary services and so on. See
also IWF.
Interval A recording period of time in which a statistic is pegged.
Interval expiry The end of an interval.
I/O Input/Output.
IOS Intelligent Optimization Platform.
IP Initialisation Process.
IP Internet Protocol.
IPC Inter-Process Communication.
IP, INP INtermodulation Products.
IPR Intellectual PRoperty.
IPSM Integrated Power Supply Module (–48 V).
IPX (A hardware component).
ISAM Indexed Sequential Access Method.
ISC International Switching Centre.
ISDN Integrated Services Digital Network. An integrated services
network that provides digital connections between
user-network interfaces.
ISG Motorola Information Systems group (formally CODEX).
ISO International Organisation for Standardization.
ISQL Informix Structured Query Language.
ISUP ISDN User Part (of signalling system No. 7).
IT Inactivity Test (Part of SCCP network connectivity).
ITC Information Transfer Capability.
ITU International Telecommunication Union.
ITU–TSS International Telecommunication Union – Telecommunications
Sector.
IWF InterWorking Function. A network functional entity which
provides network interworking, service interworking,
supplementary service interworking or signalling interworking.
It may be a part of one or more logical or physical entities in a
GSM PLMN.
IWMSC InterWorking MSC.
IWU InterWorking Unit.

K
K
k kilo (103).
k Windows size.
K Constraint length of the convolutional code.
KAIO Kernal Asynchronous Input/Output.
kb, kbit kilo-bit.
kbit/s, kbps kilo-bits per second.
kbyte kilobyte.
Kc Ciphering key. A sequence of symbols that controls the
operation of encipherment and decipherment.
kHz kilo-Hertz (103).
Ki Individual subscriber authentication Key (p/o authentication
process of AUC).
KIO A class of processor.
KSW Kiloport SWitch board. TDM timeslot interchanger to connect
calls (p/o BSS).
KSWX KSW Expander half size board. Fibre optic distribution of
TDM bus (p/o BSS).
kW kilo-Watt.

L
L
L1 Layer 1.
L2ML Layer 2 Management Link.
L2R Layer 2 Relay function. A function of an MS and IWF that
adapts a user’s known layer2 protocol LAPB onto RLP for
transmission between the MT and IWF.
L2R BOP L2R Bit Orientated Protocol.
L2R COP L2R Character Orientated Protocol.
L3 Layer 3.
LA Location Area. An area in which an MS may move freely
without updating the location register. An LA may comprise
one or several base station areas.
LAC Location Area Code.
LAI Location Area Identity. The information indicating the location
area in which a cell is located.
LAN Local Area Network.
LANX LAN Extender half size board. Fibre optic distribution of LAN
to/from other cabinets (p/o BSS etc).
LAPB Link Access Protocol Balanced (of ITU–TSS Rec. x.25).
LAPD Link Access Protocol Data.
LAPDm Link Access Protocol on the Dm channel.
LC Inductor Capacitor (type of filter).
LCF Link Control Function.
LCN Local Communications Network.
LCP Link Control Processor.
LE Local Exchange.
LED Light Emitting Diode.
LF Line Feed.
LI Length Indicator.
LI Line Identity.
LLC Lower Layer Compatibility. The LLC can carry information
defining the lower layer characteristics of the terminal.
Lm Traffic channel with capacity lower than a Bm.
LMP LAN Monitor Process.
LMS Least Mean Square.
LMSI Local Mobile Station Identity. A unique identity temporarily
allocated to visiting mobile subscribers in order to speed up
the search for subscriber data in the VLR, when the MSRN
allocation is done on a per cell basis.
LMT Local Maintenance Terminal.
LNA Low Noise Amplifier.
LND Last Number Dialled.

L
Location area An area in which a mobile station may move freely without
updating the location register. A location area may comprise
one or several base station areas.
LPC Linear Predictive Code.
LPLMN Local PLMN.
LR Location Register. The GSM functional unit where MS
location information is stored. The HLR and VLR are location
registers.
LSSU Link Stations Signalling Unit (Part of MTP transport system).
LSTR Listener Side Tone Rating.
LTA Long Term Average. The value required in a BTS’s GCLK
frequency register to produce a 16.384 MHz clock.
LTE Local Terminal Emulator.
LTP Long Term Predictive.
LTU Line Terminating Unit.
LU Local Units.
LU Location Update.
LV Length and Value.

M
M
M Mandatory.
M Mega (106).
M-Cell Motorola Cell.
M&TS Maintenance and Troubleshooting. Functional area of
Network Management software which (1) collects and
displays alarms, (2) collects and displays Software/Hardware
errors, and (3) activates test diagnostics at the NEs (OMC).
MA Mobile Allocation. The radio frequency channels allocated to
an MS for use in its frequency hopping sequence.
MAC Medium Access Control.
MACN Mobile Allocation Channel Number.
Macrocell A cell in which the base station antenna is generally mounted
away from buildings or above rooftop level.
MAF Mobile Additional Function.
MAH Mobile Access Hunting supplementary service.
MAI Mobile Allocation Index.
MAIDT Mean Accumulated Intrinsic Down Time.
MAINT MAINTenance.
MAIO Mobile Allocation Index Offset.
MAP Mobile Application Part (of signalling system No. 7). The
inter-networking signalling between MSCs and LRs and EIRs.
MAPP Mobile Application Part Processor.
MB, Mbyte Megabyte.
Mbit/s Megabits per second.
MCAP Motorola Cellular Advanced Processor.
MCC Mobile Country Code.
MCDF Motorola Customer Data Format used by DataGen for simple
data entry and retrieval.
MCI Malicious Call Identification supplementary service.
MCSC Motorola Customer Support Centre.
MCU Main Control Unit for M-Cell2/6. Also referred to as the Micro
Control Unit in software.
MCUF Main Control Unit, with dual FMUX. (Used in M-Cellhorizon).
MCU-m Main Control Unit for M-Cell Micro sites (M-Cellm). Also
referred to as the Micro Control Unit in software.
MCUm The software subtype representation of the Field Replaceable
Unit (FRU) for the MCU-m.
MD Mediation Device.
MDL (mobile) Management (entity) - Data Link (layer).
ME Maintenance Entity (GSM Rec. 12.00).

M
ME Mobile Equipment. Equipment intended to access a set of

GSM PLMN and/or DCS telecommunication services, but
which does not contain subscriber related information.
Services may be accessed while the equipment, capable of
surface movement within the GSM system area, is in motion
or during halts at unspecified points.
MEF Maintenance Entity Function (GSM Rec. 12.00).
MF MultiFrame.
MF Multi-Frequency (tone signalling type).
MF MultiFunction block.
MGMT, mgmt Management.
MGR Manager.
MHS Message Handling System.
MHS Mobile Handling Service.
MHz Mega-Hertz (106).
MI Maintenance Information.
MIB Management Information Base. A Motorola OMC-R
database. There is a CM MIB and an EM MIB.
MIC Mobile Interface Controller.
Microcell A cell in which the base station antenna is generally mounted
below rooftop level. Radio wave propagation is by diffraction
and scattering around buildings, the main propagation is
within street canyons.
min minute(s).
ms micro-second (10–6).
mBCU Micro Base Control Unit.
MIT Management Information Tree. Name of a file on the
Motorola OMC-R.
MM Man Machine.
MM Mobility Management.
MME Mobile Management Entity.
MMF Middle Man Funnel process.
MMI Man Machine Interface. The method in which the user
interfaces with the software to request a function or change
parameters.
MMI client A machine configured to use the OMC-R software from an
MMI server.
MMI processor MMI client/MMI server.
MMI server A computer which has its own local copy of the OMC-R
software. It can run the OMC-R software for MMI clients to
mount.
MML Man Machine Language. The tool of MMI.
MMS Multiple Serial Interface Link. (see also 2Mbit/s link)
MNC Mobile Network Code.
MNT MaiNTenance.

M
MO Mobile Originated.
MO/PP Mobile Originated Point-to-Point messages.
MOMAP Motorola OMAP.
MoU Memorandum of Understanding.
MPC Multi Personal Computer (was p/o OMC).
MPH (mobile) Management (entity) - PHysical (layer) [primitive].
MPTY MultiParTY (Multi ParTY) supplementary service.
MPX MultiPleXed.
MRC Micro Radio Control Unit.
MRN Mobile Roaming Number.
MRP Mouth Reference Point.
MS Mobile Station. The GSM subscriber unit.
MSC Mobile-services Switching Centre, Mobile Switching Centre.
MSCM Mobile Station Class Mark.
MSCU Mobile Station Control Unit.
msec millisecond (.001 second).
MSI Multiple Serial Interface board. Intelligent interface to two
2 Mbit/s digital links (see 2 Mbit/s link and DS-2) (p/o BSS).
MSIN Mobile Station Identification Number.
MSISDN Mobile Station International ISDN Number. Published mobile
number (see also IMSI). Uniquely defines the mobile station
as an ISDN terminal. It consists of three parts: the Country
Code (CC), the National Destination Code (NDC) and the
Subscriber Number (SN).
MSRN Mobile Station Roaming Number. A number assigned by the
MSC to service and track a visiting subscriber.
MSU Message Signal Unit (Part of MTP transport system). A
signal unit containing a service information octet and a
signalling information field which is retransmitted by the
signalling link control, if it is received in error.
MT Mobile Terminated. Describes a call or short message
destined for an MS.
MT (0, 1, 2) Mobile Termination. The part of the MS which terminates the
radio transmission to and from the network and adapts
terminal equipment (TE) capabilities to those of the radio
transmission. MT0 is mobile termination with no support for
terminal, MT1 is mobile termination with support for an S-type
interface and MT2 is mobile termination with support for an
R-type interface.
MTM Mobile-To-Mobile (call).
MTP Message Transfer Part.
MT/PP Mobile Terminated Point-to-Point messages.
MTBF Mean Time Between Failures.
MTK Message Transfer LinK.
MTL MTP Transport Layer Link (A interface).

M
MTP Message Transfer Part.

MTTR Mean Time To Repair.
Multiframe Two types of multiframe are defined in the system: a
26-frame multiframe with a period of 120 ms and a 51-frame
multiframe with a period of 3060/13 ms.
MU Mark Up.
MUMS Multi User Mobile Station.
MUX Multiplexer.

N
N
N/W Network.
NB Normal Burst (see Normal burst).
NBIN A parameter in the hoping sequence.
NCC Network (PLMN) Colour Code.
NCELL Neighbouring (of current serving) Cell.
NCH Notification CHannel.
ND No Duplicates. A database column attribute meaning the
column contains unique values (used only with indexed
columns).
NDC National Destination Code.
NDUB Network Determined User Busy.
NE Network Element (Network Entity).
NEF Network Element Function block.
NET Norme Européennes de Telecommunications.
NETPlan Frequency planning tool.
NF Network Function.
NFS Network File System.
NHA Network Health Analyst. Optional OMC-R processor feature.
NIC Network Interface Card.
NIC Network Independent Clocking.
NIS Network Information Service. It allows centralised control of
network information for example hostnames, IP addresses
and passwords.
NIU Network Interface Unit.
NIU-m Network Interface Unit, micro.
NLK Network LinK processor(s).
Nm Newton metres.
NM Network Management (manager). NM is all activities which
control, monitor and record the use and the performance of
resources of a telecommunications network in order to
provide telecommunication services to customers/users at a
certain level of quality.
NMASE Network Management Application Service Element.
NMC Network Management Centre. The NMC node of the GSM
TMN provides global and centralised GSM PLMN monitoring
and control, by being at the top of the TMN hierarchy and
linked to subordinate OMC nodes.
NMSI National Mobile Station Identification number.
NMT Nordic Mobile Telephone system.
NN No Nulls. A database column attribute meaning the column
must contain a value in all rows.
Normal burst A period of modulated carrier less than a timeslot.
NPI Number Plan Identifier.

N
NRZ Non Return to Zero.

NSAP Network Service Access Point.
NSP Network Service Provider.
NSS Network Status Summary.
NT Network Termination.
NT Non Transparent.
NTAAB New Type Approval Advisory Board.
NUA Network User Access.
NUI Network User Identification.
NUP National User Part (of signalling system No. 7).
NV NonVolatile.
NVRAM Non-Volatile Random Access Memory.
nW Nano-Watt (10–9).

O
O Optional.
OA Outgoing Access (CUG SS).
O&M Operations and Maintenance.
OASCU Off-Air-Call-Set-Up. The procedure in which a
telecommunication connection is being established whilst the
RF link between the MS and the BTS is not occupied.
OCB Outgoing Calls Barred within the CUG.
OCXO Oversized Voltage Controlled Crystal Oscillator.
OD Optional for operators to implement for their aim.
OFL % OverFlow.
offline IDS shutdown state.
online IDS normal operatng state.
OIC Operator Initiated Clear.
OLM Off_Line MIB. A Motorola DataGen database, used to modify
and carry out Radio Frequency planning on multiple BSS
binary files.
OLR Overall Loudness Rating.
OMAP Operations and Maintenance Application Part (of signalling
system No. 7) (was OAMP).
OMC Operations and Maintenance Centre. The OMC node of the
GSM TMN provides dynamic O&M monitoring and control of
the PLMN nodes operating in the geographical area
controlled by the specific OMC.
OMC-G Operations and Maintenance Centre — Gateway Part.
(Iridium)
OMC-G Operations and Maintenance Centre — GPRS Part.
OMC-R Operations and Maintenance Centre — Radio Part.
OMC-S Operations and Maintenance Centre — Switch Part.
OMF Operations and Maintenance Function (at BSC).
OML Operations and Maintenance Link.
OMP Operation and Maintenance Processor.
OMS Operation and Maintenance System (BSC–OMC).
OMSS Operation and Maintenance SubSystem.
OOS Out Of Service.
OPC Originating Point Code. A part of the label in a signalling
message that uniquely identifies, in a signalling network, the
(signalling) origination point of the message.
ORAC Olympus Radio Architecture Chipset.
OS Operating System.
OSI Open Systems Interconnection.
OSI RM OSI Reference Model.
OSF Operation Systems Function block.

O
OSF/MOTIF Open Software Foundation Motif. The basis of the GUI used
for the Motorola OMC-R MMI.
OSS Operator Services System.
Overlap Overlap sending means that digits are sent from one system
to another as soon as they are received by the sending
system. A system using ~ will not wait until it has received all
digits of a call before it starts to send the digits to the next
system. This is the opposite of en bloc sending where all
digits for a given call are sent at one time.

P
P
PA Power Amplifier.
PAB Power Alarm Board.
PABX Private Automatic Branch eXchange.
PAD Packet Assembler/Disassembler facility.
Paging The procedure by which a GSM PLMN fixed infrastructure
attempts to reach an MS within its location area, before any
other network-initiated procedure can take place.
PATH CEPT 2 Mbit/s route through the BSS network.
PBUS Processor Bus.
PBX Private Branch eXchange.
PC Personal Computer.
PCH Paging CHannel. A GSM common control channel used to
send paging messages to the MSs.
PCHN Paging Channel Network.
PCHN Physical Channel.
PCM Pulse Code Modulation (see also 2 Mbit/s link which is the
physical bearer of PCM).
PCN Personal Communications Network.
PCR Preventative Cyclic Retransmission. A form of error
correction suitable for use on links with long transmission
delays, such as satellite links.
PCU Packet Control Unit (p/o GPRS).
PCU Picocell Control unit (p/o M-Cellaccess).
pd Potential difference.
PD Protocol Discriminator.
PD Public Data.
PDB Power Distribution Board.
PDF Power Distribution Frame (MSC/LR).
PDN Public Data Networks.
PDU Power Distribution Unit.
PDU Protected Data Unit.
PEDC Pan European Digital Cellular.
Peg A single incremental action modifying the value of a statistic.
Pegging Modifying a statistical value.
PH Packet Handler.
PH PHysical (layer).
PHI Packet Handler Interface.
PI Presentation Indicator.
Picocell A cell site where the base station antenna is mounted within a
building.
PICS Protocol Implementation Conformance Statement.

P
PID Process IDentifier/Process ID.

PIM PCM Interface Module (MSC).
PIN Personal Identification Number.
PIN Problem Identification Number.
PIX Parallel Interface Extender half size board. Customer alarm
interface (p/o BSS).
PIXT Protocol Implementation eXtra information for Testing.
PK Primary Key. A database column attribute, the primary key is
a not-null, non-duplicate index.
Plaintext Unciphered data.
PlaNET Frequency planning tool.
PLL Phase Lock Loop (refers to phase locking the GCLK in the
BTS).
PLMN Public Land Mobile Network. The mobile communications
network.
PM Performance Management. An OMC application.
PM-UI Performance Management User Interface.
PMA Prompt Maintenance Alarm. An alarm report level; immediate
action is necessary (see also DMA).
PMS Pseudo MMS.
PMUX PCM MUltipleXer.
PN Permanent Nucleus (of GSM).
PNE Présentation des Normes Européennes.
POI Point of Interconnection (with PSTN).
POTS Plain Old Telephone Service (basic telephone services).
p/o Part of.
pp, p-p Peak-to-peak.
PP Point-to-Point.
ppb Parts per billion.
PPE Primative Procedure Entity.
ppm Parts per million (x 10–6).
Pref CUG Preferential CUG.
Primary Cell A cell which is already optimized in the network and has a
co-located neighbour whose cell boundary follows the
boundary of the said cell. The primary cell has a preferred
band equal to the frequency type of the coincident cell.
PROM Programmable Read Only Memory.
Ps Location probability.
PSA Periodic Supervision of Accessability.
PSAP Presentation Services Access Point.
PSM Power Supply Module.

P
PSPDN Packet Switched Public Data Network. Public data

communications network. x.25 links required for NE to OMC
communications will probably be carried by PSPDN.
PSTN Public Switched Telephone Network. The UK land line
telephone network.
PSU Power Supply Unit.
PSW Pure Sine Wave.
PTO Public Telecommunications Operator.
PUCT Price per Unit Currency Table.
PVC Permanent Virtual Circuit.
PW Pass Word.
PWR Power.
PXPDN Private eXchange Public Data Network.

Q
Q
QA Q (Interface) – Adapter.
Q3 Interface between NMC and GSM network.
Q-adapter Used to connect MEs and SEs to TMN (GSM Rec. 12.00).
QAF Q-Adapter Function.
QEI Quad European Interface. Interfaces four 2 Mbit/s circuits to
TDM switch highway (see MSI).
QIC Quarter Inch Cartridge (Data storage format).
QOS Quality Of Service.
Quiescent mode IDS intermediate state before shutdown.

R
R
R Value of reduction of the MS transmitted RF power relative to
the maximum allowed output power of the highest power
class of MS (A).
RA RAndom mode request information field.
RAB Random Access Burst.
RACCH Random Access Control CHannel. A GSM common control
channel used to originate a call or respond to a page.
RACH Random Access CHannel.
RAM Random Access Memory.
RAND RANDom number (used for authentication).
RATI Receive Antenna Transceiver Interface.
RAx Rate Adaptation.
RBDS Remote BSS Diagnostic System (a discontinued Motorola
diagnostic facility).
RBER Residual Bit Error Ratio.
RBTS Remote Base Transceiver Station.
RCB Radio Control Board (p/o DRCU).
RCI Radio Channel Identifier.
RCP Radio Control Processor.
RCU Radio Channel Unit. Contains transceiver, digital control
circuits, and power supply (p/o BSS) (see DRCU).
RCVR Receiver.
RDBMS Relational DataBase Management System (INFORMIX).
RDI Radio Digital Interface System.
RDIS Restricted Digital Information.
RDM Reference Distribution Module.
RDN Relative Distinguished Name. A series of RDN form a unique
identifier, the distinguished name, for a particular network
element.
REC, Rec RECommendation.
REJ REJect(ion).
REL RELease.
RELP Residual Excited Linear Predictive.
RELP-LTP RELP Long Term Prediction. A name for GSM full rate (see
full rate).
resync Resynchronize/resynchronization.
REQ REQuest.
Revgen A Motorola DataGen utility for producing an MMI script from a
binary object database.
RF Radio Frequency.

R
RFC, RFCH Radio Frequency Channel. A partition of the system RF

spectrum allocation with a defined bandwidth and centre
frequency.
RFE Receiver Front End (shelf).
RFEB Receiver Front End Board (p/o DRCU II).
RFI Radio Frequency Interference.
RFM Radio Frequency Module.
RFN Reduced TDMA Frame Number.
RFU Reserved for Future Use.
RJ45 Network cable/Connector type.
RISC Reduced Instruction Set Computer.
RL Remote login.
RLC Release Complete.
RLP Radio Link Protocol. An ARQ protocol used to transfer user
data between an MT and IWF. See GSM 04.22.
RLR Receiver Loudness Rating.
RLSD ReLeaSeD.
RMS Root Mean Square (value).
RMSU Remote Mobile Switching Unit.
RNTABLE Table of 128 integers in the hopping sequence.
ROM Read Only Memory.
ROSE Remote Operations Service Element. An ASE which carries
a message between devices over an association established
by ASCE (a CCITT specification for O & M) (OMC).
Roundtrip Time period between transmit and receive instant of a
timeslot in the BTS, propagation determined by the response
behaviour of the MS and the MS to BTS delay distance.
RPE Regular Pulse Excited.
RPE-LTP Regular Pulse Excitation - Long Term Prediction. The GSM
digital speech coding scheme.
RPOA Recognised Private Operating Agency.
RPR Read Privilege Required. Access to the column is allowed
only for privileged accounts.
RR Radio Resource management.
RR Receive Ready (frame).
RRSM Radio Resource State Machine.
RS232 Standard serial interface.
RSE Radio System Entity.
RSL Radio Signalling Link.
RSLF Radio System Link Function.
RSLP Radio System Link Processor.
RSS Radio SubSystem (replaced by BSS).
RSSI Received Signal Strength Indicator.

R
RSZI Regional Subscription Zone Identity.

RTC Remotely Tuneable Channel Combiner.
RTE Remote Terminal Emulator.
RTF Radio Transceiver Function.
RTF Receive Transmit Functions.
RTS Request to Send. Method of flow control (RS232 Interface).
RU Rack Unit.
Run level System processor operating mode.
Rx Receive(r).
RXCDR Remote Transcoder.
RXF Receive Function (of the RTF).
RXLEV-D Received signal level downlink.
RXLEV-U Received signal level uplink.
RXQUAL-D Received signal quality downlink.
RXQUAL-U Received signal quality uplink.
RXU Remote Transcoder Unit. The shelf which houses the
remote transcoder modules in a BSSC cabinet at a remote
transcoder site.

S
S
S/W SoftWare.
SABM Set Asynchronous Balanced Mode. A message which
establishes the signalling link over the air interface.
SABME SABM Extended.
SACCH Slow Associated Control CHannel. A GSM control channel
used by the MS for reporting RSSI and signal quality
measurements.
SACCH/C4 Slow Associated Control CHannel/SDCCH/4.
SACCH/C8 Slow Associated Control CHannel/SDCCH/8.
SACCH/T Slow Associated Control CHannel/Traffic channel.
SACCH/TF Slow Associated Control CHannel/Traffic channel Full rate.
SACCH/TH Slow Associated Control CHannel/Traffic channel Half rate.
SAGE A brand of trunk test equipment.
SAP Service Access Point. In the reference model for OSI, SAPs
of a layer are defined as gates through which services are
offered to an adjacent higher layer.
SAP System Audits Process.
SAPI Service Access Point Indicator (identifier).
SAW Surface Acoustic Wave.
SB Synchronization Burst (see Synchronization burst).
SBUS Serial Bus.
SC Service Centre (used for Short Message Service).
SC Service Code.
SCCA System Change Control Administration. Software module
which allows full or partial software download to the NE
(OMC).
SCCP Signalling Connection Control Part (6-8).
SCEG Speech Coding Experts Group (of GSM).
SCH Synchronization CHannel. A GSM broadcast control channel
used to carry information for frame synchronization of MSs
and identification of base stations.
SCI Status Control Interface.
SCIP Serial Communication Interface Processor.
SCM Status Control Manager.
SCN Sub-Channel Number. One of the parameters defining a
particular physical channel in a BS.
SCP Service Control Point (an intelligent network entity).
SCSI Small Computer Systems Interface.
SCU Slim Channel Unit.
SCU900 Slim Channel Unit for GSM900.
SDCCH Stand-alone Dedicated Control CHannel. A GSM control
channel where the majority of call setup occurs. Used for
MS to BTS communications before MS assigned to TCH.

S
SDL Specification Description Language.

SDT SDL Developement Tool.
SDU Service Data Unit.
SDR Special Drawing Rights (an international “basket” currency for
billing).
SE Support Entity (GSM Rec. 12.00).
Secondary Cell A cell which is not optimized in the network and has a
co-located neighbour whose cell boundary follows the
boundary of the said cell. The secondary cell has a preferred
band the same as that of its own frequency type.
SEF Support Entity Function (GSM Rec.12.00).
SFH Slow Frequency Hopping.
SI Screening Indicator.
SI Service Interworking.
SI Supplementary Information.
SIA Supplementary Information A.
SID Silence Descriptor.
SIF Signal Information Field. The bits of a message signal unit
that carry information for a certain user transaction; the SIF
always contains a label.
SIM Subscriber Identity Module. Removable module which is
inserted into a mobile equipment; it is considered as part of
the MS. It contains security related information (IMSI, Ki,
PIN), other subscriber related information and the algorithms
A3 and A8.
SIMM Single Inline Memory module.
SIMM System Integrated Memory Module.
SIO Service Information Octet. Eight bits contained in a message
signal unit, comprising the service indicator and sub-service
field.
SITE BSC, BTS or collocated BSC-BTS site.
SIX Serial Interface eXtender. Converts interface levels to TTL
levels. Used to extend 2 serial ports from GPROC to external
devices (RS232, RS422, and fibre optics).
SK Secondary Key. A database column attribute, the secondary
key indicates an additional index and/or usage as a
composite key.
SL Signalling Link.
SLNK Serial Link.
SLR Send Loudness Rating.
SLTM Signalling Link Test Message.
SM Switch Manager.
SM Summing Manager.
SMAE System Management Application Entity (CCITT Q795, ISO
9596).
SMCB Short Message Cell Broadcast.

S
SME Short Message Entity.

SMG Special Mobile Group.
SMP Motorola Software Maintenance Program.
SMS Short Message Service.
SMSCB Short Message Service Cell Broadcast.
SMS-SC Short Message Service - Service Centre.
SMS/PP Short Message Service/Point-to-Point.
Smt Short message terminal.
SN Subscriber Number.
SND SeND.
SNDR SeNDeR.
SNR Serial NumbeR.
SOA Suppress Outgoing Access (CUG SS).
SP Service Provider. The organisation through which the
subscriber obtains GSM telecommunications services. This
may be a network operator or possibly a separate body.
SP Signalling Point.
SP Special Product.
SP SPare.
SPC Signalling Point Code.
SPC Suppress Preferential CUG.
SPI Signalling Point Inaccessible.
SPP Single Path Preselector.
SQE Signal Quality Error.
SQL Structured Query Language.
SRD Service Request Distributor.
SRES Signed RESponse (authentication).
SS Supplementary Service. A modification of, or a supplement
to, a basic telecommunication service.
SS System Simulator.
SSA SCCP messages, Subsystem-allowed (see CCITT Q.712
para 1.15).
SSAP Site System Audits Processor.
SSC Supplementary Service Control string.
SSF Subservice Field. The level 3 field containing the network
indicator and two spare bits.
SSM Signalling State Machine.
SSN SubSystem Number.
SSP Service Switching Point (an intelligent network element).
SSP SCCP messages, Subsystem-prohibited (see CCITT Q.712
para 1.18).
SSP SubSystem Prohibited message.

S
SSS Switching SubSystem (comprising the MSC and the LRs).

SS7 ANSI Signalling System No. 7 (alias C7).
STAN Statistical ANalysis (processor).
STAT STATistics.
stats Statistics.
STC System Timing Controller.
STMR Side Tone Masking rating.
SUERM Signal Unit Error Rate Monitor.
STP Signalling Transfer Point.
Superframe 51 traffic/associated control multiframes or 26
broadcast/common control multiframes (period 6.12s).
Super user User account that can access all files, regardless of
protection settings, and control all user accounts.
SURF Sectorized Universal Receiver Front-end (Used in
Horizonmacro).
SVC Switch Virtual Circuit.
SVM SerVice Manager.
SVN Software Version Number.
SW Software.
SWFM SoftWare Fault Management.
sync synchronize/synchronization.
Synchronization burst Period of RF carrier less than one timeslot whose modulation
bit stream carries information for the MS to synchronize its
frame to that of the received signal.
SYS SYStem.
SYSGEN SYStem GENeration. The Motorola procedure for loading a
configuration database into a BTS.

T
T
T Timer.
T Transparent.
T Type only.
T43 Type 43 Interconnect Board. Provides interface to 12
unbalanced (6-pair) 75 ohm (T43 coax connectors) lines for
2 Mbit/s circuits (See BIB).
TA Terminal Adaptor. A physical entity in the MS providing
terminal adaptation functions (see GSM 04.02).
TA Timing Advance.
TAC Type Approval Code.
TACS Total Access Communications System (European analogue
cellular system).
TAF Terminal Adaptation Function.
TATI Transmit Antenna Transceiver Interface. The TATI consists
of RF combining equipments, either Hybrid or Cavity
Combining. (See CCB).
TAXI Transparent Asynchronous Transmitter/Receiver Interface
(physical layer).
TBD To Be Determined.
TBR Technical Basis for Regulation.
TBUS TDM Bus.
TC Transaction Capabilities.
TCAP Transaction Capabilities Application Part (of Signalling
System No. 7).
TCB TATI Control Board.
TCH Traffic CHannel. GSM logical channels which carry either
encoded speech or user data.
TCH/F A full rate TCH.
TCH/F2.4 A full rate TCH at 2.4 kbit/s.
TCH/FS A full rate Speech TCH.
TCH/H A half rate TCH.
TCH/H2.4 A half rate TCH at 2.4 kbit/s.
TCH/H4.8 A half rate TCH at 4.8 kbit/s.
TCH/HS A half rate Speech TCH).
TCI Transceiver Control Interface.
TCP/IP Transmission Control Protocol/Internet Protocol.
TC-TR Technical Commitee Technical Report.
TCU Transceiver Control Unit.
TDF Twin Duplexed Filter. (Used in M-Cellhorizon).
TDM Time Division Multiplexing.

T
TDMA Time Division Multiple Access.

TDU TopCell Digital Unit.
TE Terminal Equipment. Equipment that provides the functions
necessary for the operation of the access protocols by the
user.
Tei Terminal endpoint identifier.
TEI Terminal Equipment Identity.
TEMP TEMPorary.
TEST TEST control processor.
TFA TransFer Allowed.
TFP TransFer Prohibited.
TFTP Trivial File Transfer Protocol.
TI Transaction Identifier.
Timeslot The multiplex subdivision in which voice and signalling bits
are sent over the air. Each RF carrier is divided into 8
timeslots.
Timing advance A signal sent by the BTS to the MS. It enables the MS to
advance the timing of its transmission to the BTS so as to
compensate for propagation delay.
TLV Type, Length and Value.
TM Traffic Manager.
TMI TDM Modem Interface board. Provides analogue interface
from IWF to modems for 16 circuits (p/o IWF).
TMM Traffic Metering and Measuring.
TMN Telecommunications Management Network. The
implementation of the Network Management functionality
required for the PLMN is in terms of physical entities which
together constitute the TMN.
TMSI Temporary Mobile Subscriber Identity. A unique identity
temporarily allocated by the MSC to a visiting mobile
subscriber to process a call. May be changed between calls
and even during a call, to preserve subscriber confidentiality.
TN Timeslot Number.
TON Type Of Number.
Traffic channels Channels which carry user’s speech or data (see also TCH).
Traffic unit Equivalent to an erlang.
Training sequence Sequence of modulating bits employed to facilitate timing
recovery and channel equalization in the receiver.
TRAU Transcoder Rate Adaption Unit.
TRU TopCell Radio unit.
TRX Transceiver(s). A network component which can serve full
duplex communication on 8 full-rate traffic channels according
to specification GSM 05.02. If Slow Frequency Hopping
(SFH) is not used, then the TRX serves the communication
on one RF carrier.
TS Technical Specification.

T
TS TeleService.
TS TimeSlot (see Timeslot).
TSA TimeSlot Acquisition.
TSA TimeSlot Assignment.
TSDA Transceiver Speech & Data Interface.
TSC Training Sequence Code.
TSI TimeSlot Interchange.
TSDI Transceiver Speech and Data Interface.
TSM Transceiver Station Manager.
TSW Timeslot SWitch.
TTCN Tree and Tabular Combined Notation.
TTL Transistor to Transistor Logic.
TTY TeleTYpe (refers to any terminal).
TU Traffic Unit.
TUP Telephone User Part (SS7).
TV Type and Value.
Tx Transmit(ter).
TXF Transmit Function (of the RTF).
TXPWR Transmit PoWeR. Tx power level in the
MS_TXPWR_REQUEST and MS_TXPWR_CONF
parameters.
TxBPF Transmit Bandpass Filter.

U
U
UA Unnumbered Acknowledgment. A message sent from the
MS to the BSS to acknowledge release of radio resources
when a call is being cleared.
UDI Unrestricted Digital Information.
UDP User Datagram Protocol.
UDUB User Determined User Busy.
UHF Ultra High Frequency.
UI Unnumbered Information (Frame).
UIC Union International des Chemins de Fer.
UID User ID. Unique number used by the system to identify the
user.
UL Upload (of software or database from an NE to a BSS).
Um Air interface.
UMTS Universal Mobile Telecommunication System.
UPCMI Uniform PCM Interface (13 bit).
UPD Up to Date.
Uplink Physical link from the MS towards the BTS (MS transmits,
BTS receives).
UPS Uninterruptable Power Supply.
UPU User Part Unavailable.
Useful part of burst That part of the burst used by the demodulator; differs from
the full burst because of the bit shift of the I and Q parts of
the GMSK signal.
USSD Unstructured Supplementary Service Data.
UUS User-to-User Signalling supplementary service.

V
V
V Value only.
VA Viterbi Algorithm (used in channel equalizers).
VAD Voice Activity Detection. A process used to identify presence
or absence of speech data bits. VAD is used with DTX.
VAP Videotex Access Point.
VBS Voice Broadcast Service.
VC Virtual Circuit.
VCO Voltage Controlled Oscillator.
VCXO Voltage Controlled Crystal Oscillator.
VDU Visual Display Unit.
VGCS Voice Group Call Service.
VLR Visitor Location Register. A GSM network element which
provides a temporary register for subscriber information for a
visiting subscriber. Often a part of the MSC.
VLSI Very Large Scale Integration (in ICs).
VMSC Visited MSC. (Recommendation not to be used).
VOX Voice Operated Transmission.
VPLMN Visited PLMN.
VSC Videotex Service Centre.
V(SD) Send state variable.
VSP Vehicular Speaker Phone.
VSWR Voltage Standing Wave Ratio.
VTX host The components dedecated to Videotex service.

W
W
WAN Wide Area Network.
WPA Wrong Password Attempts (counter).
WS Work Station. The remote device via which O&M personnel
execute input and output transactions for network
management purposes.
WSF Work Station Function block.
WWW World Wide Web.

X
X
X.25 CCITT specification and protocols for public packet-switched
networks (see PSPDN).
X.25 link A communications link which conforms to X.25 specifications
and uses X.25 protocol (NE to OMC links).
XBL Transcoder to BSS Link. The carrier communications link
between the Transcoder (XCDR) and the BSS.
XCB Transceiver Control Board (p/o Transceiver).
XCDR Full-rate Transcoder. Provides speech transcoding and 4:1
submultiplexing (p/o BSS, BSC or XCDR).
XCDR board The circuit board required to perform speech transcoding at
the BSS or (R)XCDR). Also known as the MSI (XCDR)
board. Interchangeable with the GDP board.
XFER Transfer.
XID eXchange IDentifier.
X-Term X terminal window.

Z
Z
ZC Zone Code

Z


WKS04 HDPC2 GSR8 PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

WKS04 HDPC2 GSR8 PDF

Uploaded by

Copyright:

Available Formats

CHAPTER 1 CHAPTER 2 CHAPTER 3 CHAPTER 4 CHAPTER 5

GSM SOFTWARE RELEASE 8

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

Copyrights, notices and trademarks

and MOTOROLA are registered trademarks of Motorola Inc.

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

Type 3 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2–16

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

Enabling the Dual Band Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4–42

FOR TRAINING PURPOSES ONLY –

Force Half–Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5–12

FOR TRAINING PURPOSES ONLY –

Exercise 3 – Congestion Relief Type 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–17

FOR TRAINING PURPOSES ONLY –

Exercise 8 – PBGT Algorithm Type 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–29

FOR TRAINING PURPOSES ONLY –

Exercise 14 – Interference Based Concentric Cells . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6–39

FOR TRAINING PURPOSES ONLY –

Exercise 17 – Intelligent Multilayer Resource Management . . . . . . . . . . . . . . . . . . . . . . . 6–51

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

WARNING Failure to comply with Motorola’s operation, installation and

ETSI specification number

FOR TRAINING PURPOSES ONLY –

Special key sequences

CTRL–c Press the Control and c keys at the same time.

FOR TRAINING PURPOSES ONLY –

Reporting safety issues

FOR TRAINING PURPOSES ONLY –

Warnings and cautions

Example and format

Failure to comply with warnings

Example and format

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

Potentially hazardous voltage

FOR TRAINING PURPOSES ONLY –

When dismantling heavy assemblies, or removing or replacing equipment, the competent

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

Devices sensitive to static

Special handling techniques

FOR TRAINING PURPOSES ONLY –

Congestion Relief Mechanisms

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

Congestion Relief Mechanisms

FOR TRAINING PURPOSES ONLY –

FOR TRAINING PURPOSES ONLY –

Serving Cell Neighbour Cell

MS is on SDCCH, but wants TCH – non available

If there is a qualified neighbour, MS hands over

FOR TRAINING PURPOSES ONLY –

Congestion Handover Criteria

FOR TRAINING PURPOSES ONLY –

Congestion Handover Criteria

S All neighbours assessed to see if they meet criteria 1

S Then ordered by pbgt – congest_ho_margin > 0